Linux-OS-Enable Active Directory Authentication-DEVOPS and Automation

Linux-OS-Enable Active Directory Authentication-SAMBA WINBIND and SSSD  (SLDAP/Kerbros) A Methods How To –-Red Hat. SUSE, and Ubuntu.

Image result for sssd on rhel;




Prerequisite Requirements

  • DNS must be working fully – both forward and reverse lookups should be functional. If the Kerberos server (Windows Domain Controller) cannot identify the client via DNS, Kerberos will fail.
  • Accurate time is essential –NTP– if the two systems have too larger difference in time (about 5 minutes), Kerberos will fail.
  • The Active Directory needs to be extended to include the relevant information for *UNIX Account Attributes settings (home directory, shell, and UUID/GUID )ActiveDirectory_AttributeEditor_ObjectSID


  • The best option is SASL/GSSAPI, using a keytab generated by Samba. This does not require Admin privileges on Windows, only permissions to join computers to the domain.


I. Samba WinBind Overview
Before your client can join an AD domain, some adjustments must be made to your network setup to ensure the flawless interaction of client and server.

winbindmsClick on Image To Enlarge Image. 

  •  DNS
    Configure your client machine to use a DNS server that can forward DNS requests to the AD DNS server. Alternatively, configure your machine to use the AD DNS server as the name service data source.
  • NTP
    To succeed with Kerberos authentication, the client must have its time set accurately. It is highly recommended to use a central NTP time server for this purpose (this can be also the NTP server running on your Active Directory domain controller). If the clock skew between your Linux host and the domain controller exceeds a certain limit, Kerberos authentication fails and the client is logged in using the weaker NTLM (NT LAN Manager) authentication. For more details about using active directory for time synchronization, see Joining an AD Domain example illustration under OpenSuSE.

*System clock must match Domain Control clock..

Synch Linux system clock to NTP server.( Example illustrate from SUSE GUI install)

  • timeanddataver Firewall
    To browse your network neighborhood, either disable the firewall entirely or mark the interface used for browsing as part of the internal zone.
    To change the firewall settings on your client, log in as root and start the YaST firewall module. Select Interfaces. Select your network interface from the list of interfaces and click Change. Select Internal Zone and apply your settings with OK. Leave the firewall settings with Next > Finish. To disable the firewall, just check the Disable Firewall Automatic Starting option, and leave the firewall module with Next > Finish.
  • AD Account
    You cannot log in to an AD domain unless the AD administrator has provided you with a valid user account for that domain. Use the AD username and password to log in to the AD domain from your Linux client.
    Join an existing AD domain during installation (or by later activating SMB user authentication with YaST in the installed system). The domain join during installation is covered in User Authentication Method, (↑Deployment Guide).
    IMPORTANT: Domain Name
    Joining a domain may not succeed if the domain name ends with .local. Names ending in .local cause conflicts with Multicast DNS (MDNS) where .local is reserved for link-local hostnames.
    NOTE: Currently only a domain administrator account, such as Administrator, can join SUSE Linux Enterprise Server into Active Directory.
    To join an AD domain in a running system, proceed as follows:
    Joining an AD Domain


  1. Log in as root and start YaST.
  2. Start Network Services > Windows Domain Membership.
  3. . Enter the domain to join at Domain or Workgroup in the Windows Domain Membership screen . If the DNS settings on your host are properly integrated with the Windows DNS server, enter the AD domain name in its DNS format ( If you enter the short name of your domain (also known as the pre–Windows 2000 domain name), YaST must rely on NetBIOS name resolution instead of DNS to find the correct domain controller.

II. Pre-Staging Steps.

  1. Set host to static/DHCP IP.
2. switch to root and start YaST

3. Add entry for hostname (only static IP)-

IP address: i.e
Hostname: i.e opensuse2.mvp
Host Aliases: opensuse2

click ok to complete entry .


4.  Locate Network settings(YasT) -Add entry for network(only static IP)- Click Host/DNS tab-

Hostname: i.e  opensuse2
Domain name: i.e mvp
Name Server and Domain Search List
Domain Search


5. To join an AD domain in a running system, proceed as follows:
Joining an AD Domain
1. Log in as root and start YaST.(screenshot step 1)
2. Start Network Services > Windows Domain Membership.
3. Enter the domain to join at Domain or Workgroup in the Windows Domain Membership screen
( Please note need to set DNS settings on your host are properly integrated with the Windows in pre-staging required steps )
6. Log in as root and start YaST.

7.  Start Network Services > Windows Domain Membership.

8. Enter the domain to join at Domain or Workgroup in the Windows Domain Membership screen (see Figure 5-2). If the DNS settings on your host are properly integrated with the Windows

adjoin9. Will get a prompt to install samba-winbind, krb5-client. Click Install.


*will see downloading package prompt. Let it finish..


10. Click Yes to join Linux machine to AD domain. -Click Yes


11.  Click on as supersuer— to view entire dialog box.


12.Check Also Use SMB Information for Linux Authentication to use the SMB source for Linux authentication.

13.Check Create Home Directory on Login to automatically create a local home directory for your AD user on the Linux machine.

14.Check Offline Authentication to allow your domain users to log in even if the AD server is temporarily unavailable, or if you do not have a network connection.

15.Select Expert Settings, if you want to change the UID and GID ranges for the Samba users and groups. Let DHCP retrieve the WINS server only if you need it. This is the case when some of your machines are resolved only by the WINS system.

16.Configure NTP time synchronization for your AD environment by selecting NTP Configuration and entering an appropriate server name or IP address. This step is obsolete if you have already entered the appropriate settings in the stand-alone YaST NTP configuration module.

17. Click OK and confirm the domain join when prompted for it.

18..Provide the password for the Windows administrator on the AD server and click OK.

After you have joined the AD domain, you can log in to it from your workstation using the display manager of your desktop or the console.

19.,Input “Domain\user” i.e MVP\rpham (note account must have domain add machine permissions on MS AD)


20. Reboot after successfully joining machine to AD-=Initiate a command shutdown -r – and Log into the machine with AD user account. *remember us the “domain\user” log on syntax..


III. Join in Windows Active Directory Domain with Samba Winbind.
This tutorial needs Windows Active Directory Domain Service in your LAN.
This example shows to configure on the environment below.


  1. How to  Join to AD with Samba Winbind on Red Hat.

Install Winbind.

[root@smb ~]# yum -y install samba-winbind samba-winbind-clients pam_krb5

[2] Configure Winbind.

[root@smb ~]# authconfig \
–enablekrb5 \
– \
– \
–krb5realm=FD3S.SERVER.WORLD \
–enablewinbind \
–enablewinbindauth \
–smbsecurity=ads \
–smbrealm=FD3S.SERVER.WORLD \
– \
–smbworkgroup=FD3S01 \
–winbindtemplatehomedir=/home/%U \
–winbindtemplateshell=/bin/bash \
–enablemkhomedir \
–enablewinbindusedefaultdomain \
Job for winbind.service failed. See ‘systemctl status winbind.service’ and ‘journalctl -xn’ for details.
# it’s no ploblem winbind failed like above now

[3] Join in Windows Active Directory Domain.
# join in Active Directory ( net ads join -U [AD’s admin user])
[root@smb ~]# net ads join -U Administrator -W <AD Domain Short Name> –createcomputer=”<OU path>”
Enter Administrator password:
Using short domain name — <AD Domain Short Name>
Joined ‘LAN’ to dns domain ‘<AD Domain Short Name’
DNS Update for failed: ERROR_DNS_GSS_ERROR

*ignor the DNS error message*

[root@smb ~]# systemctl start winbind
[root@smb ~]# systemctl enable winbind
# show domain info
[root@smb ~]# net ads info
LDAP server: <AD DC IP>
LDAP server name: <AD LDAP FQDN>
Bind Path: dc=<AD Short Name>,dc=NET or COM
LDAP port: 389
Server time: xxx
KDC server: AD DC IP
Server time offset: 0
# show AD users info
[root@smb ~]# wbinfo -u
# try to switch to an AD user
[root@smb ~]# su – known AD user id.
Creating directory ‘/home/<AD user id>’.
[serverworld@lan ~]

2.How to  Join to AD with Samba Winbind on Suse (Coming soon!!!)

3.Install Winbind.

4.Download Winbind packages

The Winbind packages should be automatically included in the repos so It is highly unlikely that you have to download them and install manually.
To check SuSE type “zypper search  winbind”
To install SuSE – “zypper in samba-winbind samba samba-client krb5 krb5-client”

[root@smb ~]# To check SuSE type “zypper search winbind”
To install SuSE – “zypper in samba-winbind samba samba-client krb5 krb5-client”
5. Edd SMB.conf to /etc/samba/smb.conf (see example)
workgroup = WEB (Short name of Domain name, i.e or .net)
map to guest = Bad User
usershare allow guests = No
idmap gid = 10000-20000
idmap uid = 10000-20000
realm = WEB.INTX.COM(Domain name upper case)
security = ADS
template homedir = /home/%D/%U
template shell = /bin/bash
winbind offline logon = yes
winbind refresh tickets = yes
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
obey pam restrictions = yes
allow trusted domains = no
idmap backend = idmap_rid:WEB=10000-20000
6.Add to /etc/pam.d/sshd
auth sufficient
session required skel=/etc/skel umask=0022
7.  Configure Winbind.Host reference
hosts – example
10.x.x.x servername
192.x.x.x server name. servername
/etc/hostname – example
8. Modify /etc/resolv.conf (see example)
9. Set The firewall ports that need to be open are tcp 445, 137, & 138
a. vi /etc/sysconfig/SuSEfirewall2
add to section: FW_CONFIGURATIONS_EXT=”sshd nfs-server” (I think this method only accepts names from /etc/sysconfig/SuSEfirewall2.d/services)
Ad to section: FW_SERVICES_EXT_TCP=”445 137 138″
b. /etc/init.d/SuSEfirewall2_setup restart
Iptables –L (to verify)

10. Join Linux Machine  in Windows Active Directory Domain.
# join in Active Directory ( net ads join -U [AD’s admin user])
[root@smb ~]# net ads join -U Administrator -W <AD Domain Short Name> –createcomputer=”<OU path>”
Enter Administrator password:
Using short domain name — <AD Domain Short Name>
Joined ‘LAN’ to dns domain ‘<AD Domain Short Name’
DNS Update for failed: ERROR_DNS_GSS_ERROR

*Ignore the DNS error message*

Restart Services
/etc/init.d/winbind restart
/etc/init.d/iptables restart (if firewall is on)
/etc/init.d/SuseFirewall2_setup stop/start
11. Verfiy Users and Groups are pulled from AD.
“wbinfo -u” – lists network usernames
“wbinfo -a mynetname%mypassword” – authenticates against domain
“getent passwd” – equiv of /etc/passwd for domain users

# show AD users info
[root@smb ~]# wbinfo -u
# try to switch to an AD user
[root@smb ~]# su – known AD user id.
Creating directory ‘/home/<AD user id>’.
[serverworld@lan ~]$

Example how to Join Ubuntu machine via WinBind. 

How to  Join to AD with Samba Winbind on Ubuntu.


1.Install Winbind.

 aptitude -y install winbind libpam-winbind libnss-winbind krb5-config
2. Configure Winbind.
vi /etc/samba/smb.conf
# line 29: change workgroup name to the one for AD DS and add lines like follows
workgroup = <AD Domain>
password server = <Domain Controller or AD Domain name aka AD VIP
realm = AD VIP
security = ads
idmap config * : range = 16777216-33554431
template homedir = /home/%U
template shell = /bin/bash
winbind use default domain = true
winbind offline logon = false
root@smb:~# vi /etc/nsswitch.conf
# line 7: add like follows
passwd:compat winbind
group:compat winbind
shadow:compat winbind
root@smb:~# vi /etc/pam.d/common-session
# add to the end if you need ( auto create a home directory when initial login )
session optional skel=/etc/skel umask=077
root@smb:~# vi /etc/network/interfaces
# change name server to AD’s one
dns-nameservers <AD DNS Server>
# line 7: add like follows
passwd:compat winbind
group:compat winbind
shadow:compat winbind
root@smb:~# vi /etc/pam.d/common-session
# add to the end if you need ( auto create a home directory when initial login )
session optional skel=/etc/skel umask=077
root@smb:~# vi /etc/network/interfaces
# change name server to AD’s one

III. LDAP and Kerbros Diagram Overview 

winbindmsClick on Image To Enlarge Image 


This next section will provide overview of SSSD Method To Bind To Active Directory.

IV.What is SSSD?
SSSD package description: Provides a set of daemons to manage access to remote directories and authentication mechanisms. Provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources.



How sssd’s components work together

sssd is quite modular: if you read the sssd.conf man page, you’ll learn about services and domains. You will also learn about different providers such as the already mentioned Active Directory provider that we are going to use. Do not be fooled however: providers are not mutually-exclusive. For example, our Active Directory provider works together with the LDAP and the Kerberos providers as shown here:

Individual sssd components working together
Individual sssd components working together

As a consequence, we’ll have to consider not only sssd-ad configuration directives but also some of those of sssd-ldap and sssd-krb5. And, because sssd-krb5 uses the Kerberos library we’ll also have to consider /etc/krb5.conf.

SSSD Advantages
Authentication service enhancements
• Greater extensibility
• Multiple concurrently available identity stores
• ID collision management features
SSL/TLS or SASL/GSSAPI is required
• Single configuration file •
Reduced server loads
• Offline authentication


How Implement SSDD AD (Active Directory)
(SLDAP) on RHEL, SUSE, and Ubuntu

1.Required RPM/Packages on Linux 

krb5-workstations,samba, sssd, sssd-client, openldap-clients,oddjob oddjob-mkhomedir adcli.

2.Required Configuration files, Krb5.conf, Smb.conf, and SSSD.conf,

Configuring_sssd_with_ad_server – SSSD 


 default = FILE:/var/log/krb5libs.log

 default_realm = AD.EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false

# You may also want either of:
# allow_weak_crypto = true
# default_tkt_enctypes = arcfour-hmac

# Define only if DNS lookups are not working
#  kdc =
#  master_kdc =
#  admin_server =
# }

# Define only if DNS lookups are not working

Make sure kinit aduser@AD.EXAMPLE.COM works properly. If not, using KRB5_TRACE usually provides helpful information: KRB5_TRACE=/dev/stdout kinit -V aduser@AD.EXAMPLE.COM.

   security = ads
   realm = AD.EXAMPLE.COM
   workgroup = EXAMPLE

   log file = /var/log/samba/%m.log

   kerberos method = secrets and keytab

   client signing = yes
   client use spnego = yes

Now join the client with:

kinit Administrator
net ads join -k

Alternatively, without using the Kerberos ticket:

net ads join -U Administrator

Additional principals can be created later with net ads keytab add if needed.

You don’t need a Domain Administrator account to do this, you just need an account with sufficient rights to join a machine to the domain. This is a notable advantage of this approach over generating the keytab directly on the AD controller.

To verify the keytab was acquired correctly and can be used to access AD:

klist -ke

Now using this credential you’ve just created try fetching data from the server with ldapsearch (in case of issues make sure /etc/openldap/ldap.conf does not contain any unwanted settings):

/usr/bin/ldapsearch -H ldap:// -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"

By using the credential from the keytab, you’ve verified that this credential has sufficient rights to retrieve user information.

You can also check if searching the Global Catalog works and whether the attributes your environment depends on are replicated to the Global Catalog:

/usr/bin/ldapsearch -H ldap:// -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"

After both kinit and ldapsearch work properly proceed to actual SSSD configuration

Configuring_sssd_with_ad_server – SSSD

SSSD setup

Configuring SSSD consists of several steps:

  • Install the sssd-ad package on the Linux client machine
    • With older distributions (RHEL 6.5 and earlier for example) you might need to install the full sssd package.
  • Make configuration changes to the files below
  • Start the sssd service


Example sssd.conf configuration, additional options can be added as needed.

config_file_version = 2
domains =
services = nss, pam

# Uncomment if you need offline logins
# cache_credentials = true

id_provider = ad
auth_provider = ad
access_provider = ad

# Uncomment if service discovery is not working
# ad_server =

# Uncomment if you want to use POSIX UIDs and GIDs set on the AD side
# ldap_id_mapping = False

# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/

# Comment out if you prefer to user shortnames.
use_fully_qualified_names = True

Set the file ownership and permissions on sssd.conf

chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf

NSS/PAM Configuration

Depending on your distribution you have different options how to enable SSSD.


Use authconfig to enable SSSD, install oddjob-mkhomedir to make sure home directory creation works with SELinux:

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update


Install libnss-sss and libpam-sss to have SSSD added as NSS/PAM provider in /etc/nsswitch.conf and /etc/pam.d/common-* configuration files. Add to PAM session configuration manually. Restart SSSD after these changes.

Configure NSS/PAM manually

Manual configuration can be done with the following changes. The file paths for PAM in the example below are from Debian/Ubuntu, in Fedora/RHEL corresponding manual configuration should be done in /etc/pam.d/system-auth and /etc/pam.d/password-auth.

# /etc/nsswitch.conf

passwd:         files sss
shadow:         files sss
group:          files sss

hosts:          files dns

bootparams:     files

ethers:         files
netmasks:       files
networks:       files
protocols:      files
rpc:            files
services:       files sss

netgroup:       files sss

publickey:      files

automount:      files
aliases:        files

Right after the line, add

auth         sufficient use_first_pass

Right after the line, add

account      [default=bad success=ok user_unknown=ignore]

Right after the line, add

password     sufficient use_authtok

Just before the line, add

session      optional

Right after the line, add

session      optional

4. How to give sudo permissions to an Active Directory group
visudo and Add line to both lines

%adgroup@domain ALL=(ALL) ALL

%domain\\adgroup ALL=(ALL) ALL
Example sssd.conf Configuration

The following is an example sshd.conf configuration file

domains = addomain
config_file_version = 2
services = nss, pam
default_domain_suffix = addomain

ad_domain = addomain
krb5_realm = ADDOMAIN
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = adgroup@addomain

5. How to debug SSSD

Typical Error Message:
“GSSAPI Error: Miscellaneous failure (Server not found in Kerberos database)” error messages all the time.

1.Starting sssd manually in debug mode :
SSSD Troublshooting Command – SSSD- i -d 5

2. DNS is a mustL
In my case, the DHCP service advertising the DNS servers to use ran on a separate machine, and
of course I forgot to specify the IP address of the Samba server there…

The Kerberos client library will do one thing you might not immediately be aware of: reverse DNS lookups.

* If, for example, you decided to use a separate DNS subdomain for Active Directory (which you definitely do want to do) but let your hostname point at and in turn resolves to, things won’t work unless you specify rdns = false in your /etc/krb5.conf.
3. Debug Tools -Wireshark and Methods
Samba’s and System VAR logfiles

a.The logfile which contains information about successful or failed login attempts is /var/log/secure.

It contains information related to authentication and authorization privileges.

For example, sshd logs all the messages there, including unsuccessful login.

b. Be sure to check that logfile if you experience problems logging in with an Active Directory user. 

6. How to clear the SSSD cache?

Example commands
sudo systemctl stop sssd
sudo rm -f /var/lib/sss/db/*
sudo systemctl start sssd

7. SSH access configuration. SSHD

Using SSH configuration
To /etc/ssh/sshd_config, add a AllowGroups line:
AllowGroups Domain Admin

8. Control UNIX ACL on Windows Security. 

We have been discussing access control policies and have been concerned with defining what accesses subjects can make to objects. We model this behavior with a protection matrix and commands. In the last lecture, we pointed out that there are at least two ways to implement the matrix:

  • access control lists (ACLs)– the column for each object stored as a list associated with that object.
  • capabilities — the row for each subject stored as a list associated with that subject.

We noted that there are two generic ways to implement ACLs. One is to employ a mechanism for name interpretation, to put a layer between the names a subject utters and what those names mean. Another is operation interpretation, to put the protection mechanism into the execution of an operation.

Today we will discuss UNIX and NT and see how they handle access control.

UNIX — Access Control

UNIX uses access control lists. A user logs into UNIX and has a right to start processes that make requests. A process is “bigger” than a subject, many domains may correspond to a single process. Each process has an identity(uid). This uid is obtained from the file that stores user passwords: /etc/passwd. An entry in /etc/passwd may look like:

Every process inherits its uid based on which user starts the process. Every process also has an effective uid, also a number, which may be different from the uid.

Finally, each UNIX process is a member of some groups. In the original UNIX every user was a member of one group. Currently, users can be members of more than one group. Group information can be gotten from /etc/passwd or from a file /etc/groups. System administrators control the latter file. An entry in /etc/groups may look like:

When a process is created, associated with it is the list of all the groups it is in.

Recall that groups are a way to shorten access control lists. They are useful in other ways as well.

All of the above implements a form of authentication, knowing the identity of the subject running commands. Objects in UNIX are files. UNIX attempts to make everything look like a file. (E.g., one can think of “writing” to a process as equivalent to sending a message, etc.) Because of this, we will only worry about files, recognizing that just about every resource can be cast as a file.

Here is a high-level overview of the UNIX file system. A directory is a list of pairs: (filename, i-node number). Running the command ‘ls’ will produce a list of filenames from this list of pairs for the current working directory. An i-node contains a lot of information, including:

  • where the file is stored — necessary since the directory entry is used to access the file,
  • the length of the file — necessary to avoid reading past the end of the file,
  • the last time the file was read,
  • the last time the file was written,
  • the last time the i-node was read,
  • the last time the i-node was written,
  • the owner — a uid, generally the uid of the process that created the file,
  • a group — gid of the process that created the file is a member of,
  • 12 mode bits to encode protection privileges — equivalent to encoding a set of access rights.

Nine of the 12 mode bits are used to encode access rights. These access bits can be thought of as the protection matrix entry. They are divided into three groups of three:

The first triplet (u) is for the user, the second (g) for the group and the third (o) for anyone else. If a particular bit is on, then the named set of processes have the corresponding access privileges (r:read, w:write, x:execute).

There are some subtleties however. In order to access a file, it is necessary to utter that object’s name. Names are always relative to some directory, for example: ~fbs/text/cs513/www/L07.html. Directories are just files themselves, but in the case of directories:

  • The “r” (read) bit controls the ability to read the list of files in a directory. If “r” is set, you can use “ls” to look at the directory.
  • The “x” (search) bit controls the ability to use that directory to construct a valid pathname. If the “x” bit is set, you can look at a file contained in the directory.

Thus, for example, the ‘x’ bit allows a user to make the directory under consideration the current working directory and it needs to be on to read files in the current working directory. So a file can be made inaccessible by turning off the ‘x’ bit for the directory in which the file resides.

Does ‘x’ without ‘r’ access make sense? Yes! This is a directory whose files’ names cannot be learned, but whose files are accessible if you happen to know their names. This is actually useful.

Does ‘r’ without ‘x’ access make sense? This is a directory whose files’ names can be learned, but whose files cannot be accessed. It is not very useful.

How do these access bits get set? In UNIX there are number of rules to define how the bits are set initially and how they can be changed. We will discuss how to change them. There is a command ‘chmod’ that changes the mode bits. What objects can chmod access? Only the uid that is the owner of a file can execute chmod for that file (except for root’s uid, of course). There is also a command to change the owner of a file, but that has been removed from more recent systems.

What about the final three of the 12 mode bits? The mechanism discussed so far does not support domain changes. There is a single domain, the user id, and once a process is running it is (abstractly) in that row of the protection matrix. Imagine a situation where we want files to be viewable only from within a particular program. This is not possible in the current framework. But, the additional mode bits allow this. We will only mention two of the three bits. They are: suid (set user id) and sgid (set group id). A file with the suid bit on does not run with the uid of the process making the call, but rather with an effective uid that is the owner of the file. This enables us to change from executing as one subject to executing as another subject. The sgid bit works on the same principle, but for groups.

These additional mode bits are used when there are programs that access lots of objects but in a controlled way (e.g. root privileges). It is useful to have programs that are setuid for a user, and thus do less damage than a user running the program with full root privileges. We do not have the notion of a template, as we discussed previously, so this UNIX mechanism is less powerful. We do not realize the principle of least privilege.

There is a UNIX that uses a notion of an additional access control list, and not just mode bits to handle access control. In this case, each file has mode bits as we have been discussing and also extended permissions. The extended permissions provide exceptions to the mode bits as follows:

  • Specify: for example, “r– u:harry” means that user harry has read only access.
  • Deny: for example “-w- g:acsu” means remove write access from the group acsu.
  • Permit: for example “rw- u:bill, g:swe” means give read and write access to bill if bill is also a member of the group swe. The comma is conjunction.

With extended permissions it’s possible to force a user to enter a particular group before being allowed access to a file.

Windows NT — Access Control

Windows NT supports multiple file systems, but the protection issues we will consider are only associated with one: NTFS. In NT there is the notion of an item, which can be a file or a directory. Each item has an owner. An owner is usually the thing that created the item. It can change the access control list, allow other accounts to change the access control list and allow other accounts to become owner. Entries in the ACL are individuals and groups. Note that NT was designed for groups of machines on a network, thus, a distinction is made between local groups (defined on a particular workstation) and global groups (domain wide). A single name can therefore mean multiple things.

NTFS is structured so that a file is a set of properties, the contents of the file being just one of those properties. An ACL is a property of an item. The ACL itself is a list of entries: (user or group, permissions). NTFS permissions are closer to extended permissions in UNIX than to the 9 mode bits. The permission offer a rich set of possibilities:

  • R — read
  • W — write
  • X — execute
  • D — delete
  • P — modify the ACL
  • O — make current account the new owner (“take ownership”)

The owner is allowed to change the ACL. A user with permission P can also change the ACL. A user with permission O can take ownership. There is also a packaging of privileges known as permissions sets:

  • no access
  • read — RX
  • change — RWXO
  • full control — RWXDPO

NT access control is richer than UNIX, but not fundamentally different.

V. Videos Tutorials LDAP , SSSD , WinBind on Linux.

Integration of RHEL 6 into AD Domain using Kerbross SSSD for SSO.

WinBind Useful Commands.

SSSD on SLES 11 SP4 -Activie Directory.


SSSD More Than AN LDAP Client.

Winbind on Linux 


Linux SLE11 Home Directory Mapping and AD


Create a computer account object on AD via SAMBA commands

Access Control on Unix and NT

Linux SSSD Configuration

Linux SSSD -AD Integration Authentication Provider.

Configuration SSSD -Active Directory Provider

Troubleshooting SSSD

Red Hat Server -Samba  Win bind.

Novell SUSE Enterprise Server Samba Win bind..

Ubuntu Server Samba Win bind.

Authenticate Linux Clients with Active Directory


SSSD on Ubuntu

LDAP and Kerberos on Linux

LDAP and Kerberos on Ubutu

LDAP and Kerberos on RHEL

LDAP and Kerberos on SUSE

Kerbros Krb5.conf Sample

Samba SMB.conf  How To

Integrating Linux Host with Active Directory Kerberos SSO Authentication