Often I have been asked by the developers about the possibility of Linux servers authenticating against Active Directory so that the users do not have to change passwords on all the servers.Good suggestion, I thought! This will also free me from doing User management on the Linux Servers and let me focus on application and service monitoring and performance of my servers. So here is this paper explainig a brief howto on what I did to achieve this.
AD & Linux Integration – The Problem
From past many years Linux users have been using Samba for creating the Linux servers as Windows NT member servers or Primary Domain Controllers. With Microsoft moving towards Active Directory (AD) as a directory services, Samba has also evolved in letting Linux users integrate with Microsoft servers. AD was introduced with Windows 2000 and for the sake of backward compatibility supports the older NT domain controller protocols.
There are many problems encountered while trying to authenticate Linux servers to AD, couple of those issues are:
- Windows passwords are encrypted using a technique which is unknown to Linux systems.
- Windows domain controllers don’t maintain information which is critical for Linux systems, such as home directory, shell
Winbind to the rescue
Winbind is a service that allows Linux servers to authenticate against the NT Domain controllers or AD servers by linking the Windows database and the Linux native authentication system. Winbind achieves this using PAM (Pluggable Authentication Modules) and NSS (Name Service Switch). request failed: No such user, PAM error was 10, NT error was NT_STATUS_NO_SUCH_USER
PAM is a suit of shared libraries that determine how a user will be authenticated to the Linux system. PAM allows to write a program independent of the authentication scheme being used. The only required thing is that these program needs to be compiled against the PAM libraries and need “authentication modules” to be attatched to them at run-time in order to work.
winbindd is a NSS daemon for resolving names from Windows servers. The NSS allows user and system information to be obtained from different databases such as local FILES, NIS or DNS etc. The winbind service maintains the ‘host’, ‘passwd’ and ‘group’ databases for NSS.
How this is done?
Following are the brief sequence of steps which I took to acheive single signon:
- Configure winbind options in the /etc/samba/smb.conf
- Configure the Kerberos libraries
- Join the Linux server to the windows AD using the net join command
- Start the Samba and Winbind services
- Test that the Winbind is able to authenticate against AD
- Configure the /etc/nsswitch file to query winbind
- Configure the PAM system to use winbind
Configure winbind options in the /etc/samba/smb.conf
Here is the global section of my /etc/samba/smb.conf file. I have put in additional comments so a further explanation of various options is not necessary.
[root@rhel3 root]# vi /etc/samba/smb.conf [global] # Parameters required for Active Directory Authentication workgroup = MYLINUXRULES realm = MYLINUXRULES.COM server string = %h security = ADS encrypt passwords = Yes password server = dc1.mylinuxrules.com # Winbind options # Because we have just one domain so we dont want the domain name to be a # part of username. Alternatively if you have multiple domains and you are sure # that user accounts are unique among each domain then you can use this. winbind use default domain = yes # This option is useful in case the user logs on via ssh etc. Windows servers # dont maintain this information and hence winbind does it. This value cant be # customized on a per user basis, so all accounts maintained by winbind must # use the same shell. template shell = /bin/bash # This is to specify the home directory for a user. Windows servers do not # maintain this information and hence winbind does it. The variables which can # be used here are %D (for domain name) %U (for user name). Samba 3.0.6 onwards # support %D, %N, %U and %u vriables only. Since we have just one domain we are # using just the usernames within the /home for the individual home directories. template homedir = /home/%U # This is the time (in seconds) for which the authentication information will be # cached by winbind. After this time winbind will query the authetication # server again. winbind cache time = 300 # This is the Linux UID range which will be assigned by winbind to users. Local # Linux accounts must not be created in this range. In Linux UIDs 0-500 are # reserved for system users (0 being the one for root), and above 500 is for # ordinary accounts. We have reserved UIDs 1001-4000 for use by winbind # If the Samba version being used is < 3.0.6 then this value has to be defined # as the default value of undefined. From Samba version 3.0.6 onwards if this # value is not set then Winbind will try to map NT domain username to locally # defined accounts. This feature can be useful when you want to rely on domain # controller for the password authentication. The only catch is that on different # Linux systems users might get different UIDs which might cause problem with # softwares such as NFS as they identify accounts on the basis of UIDs/GIDs and not #username. idmap uid = 1001-4000 # This serves the same purpose for groups as above was for users. The default value # of this is undefined. idmap gid = 1001-4000 #------------------------- Other options --------------------------------- printcap name = /etc/printcap load printers = yes cups options = raw log file = /var/log/samba/%m.log max log size = 50 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 .......[[snipped...]]......
Configure the Kerberos libraries
Next edit the /etc/krb5.conf file and place following entries:
[root@rhel3 root]# vi /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = MYLINUXRULES.COM
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
MYLINUXRULES.COM = {
kdc = dc1.mylinuxrules.com:88
admin_server = dc1.mylinuxrules.com:749
default_domain = mylinuxrules.com
}
mickymouse
[domain_realm]
.mylinuxrules.com = MYLINUXRULES.COM
mylinuxrules.com = MYLINUXRULES.COM
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Start the Samba and Winbind services as follows:
[root@rhel3 root]# service smb restart Shutting down SMB services: [ OK ] Shutting down NMB services: [ OK ] Starting SMB services: [ OK ] Starting NMB services: [ OK ] [root@rhel3 root]# service winbind restart Shutting down Winbind services: [ OK ] Starting Winbind services: [ OK ]
Test that the winbind is able to authenticate against AD
To test whether the kerberos libraries are able to authenticate against ADS, we can run the ‘kinit’ program:
[root@rhel3 root]# kinit myaduser01@MYLINUXRULES.COM Password for myaduser01@MYLINUXRULES.COM:
If you just gets the command prompt back then everything is alright.
Now you can join the Linux box to the ADS in the (dn:ou=Linux,ou=Servers,dc=MYLINUXRULES,dc=COM):
[root@rhel3 root]# net ads join Servers\/Unix -U ad_admin_user01 ad_admin_user01's password: Using short domain name -- MYLINUXRULES Joined 'RHEL3' to realm 'MYLINUXRULES.COM'
To test whether the winbind service is able to query the AD we can use the wbinfo program. The -t option tests the trust account we have created and the basic winbind functionality. The resons I have explicitly specified the domain using "–domain" option because we have multiple windows domains runnining on old Windows servers (which all will die soon) and if I dont use this option I cannot make sure that the active directory domain which I wanted to check has been queried. The -u option lists all the usernames from the specified domain. In the username listing the usernames will appear as "\domain\user" if the "winbind use default domain" has been set to "no" in the "/etc/samba/smb.conf" file. If this parameter has been set to "yes" (that’s what I have done) then you will just see the usernames in the output.
[root@rhel3 root]# wbinfo --domain=MYLINUXRULES.COM -t checking the trust secret via RPC calls succeeded [root@rhel3 root]# wbinfo --domain=MYLINUXRULES.COM -u Guest SUPPORT_388945a0 msadc_user_01 msadc_user_02 .....[[snipped...]]....
After these tests are successfull then you can further test the authentication against the Active Directory by using the "-a" switch of "wbinfo".
root@rhel3 root]# wbinfo --domain=MYLINUXRULES.COM -a msadc_user01%password plaintext password authentication succeeded challenge/response password authentication succeeded
Configure /etc/nsswitch to query winbind
To configure the PAM and NSS to use Winbind to authenticate users and return additional account information to the programs needing them we need pam_winbind.so and libnss_winbind.so. The default location of all PAM modules is /lib/security in Linux so the pam_winbind.so should be present in this directory in order for PAM libraries to find it automatically. The libnss_winbind.so is a library and hence should be present in the /lib directory with soft link in /usr/lib directory. On my machines these files are located at the following locations:
- On RHEL AS and Fedora
[root@rhel3 root]# ls -l /lib/security/pam_winbind.so -rwxr-xr-x 1 root root 16032 Jul 21 16:22 /lib/security/pam_winbind.so [root@rhel3 root]# ls -l /usr/lib/libnss_winbind.so lrwxrwxrwx 1 root root 24 Dec 9 16:12 /usr/lib/libnss_winbind.so -> /lib/libnss_winbind.so.2 [root@rhel3 root]# ls -l /lib/libnss_winbind.so.2 -rwxr-xr-x 1 root root 17928 Jul 21 16:22 /lib/libnss_winbind.so.2 [root@rhel3 root]# ls -l /lib/libnss_winbind.so lrwxr-xr-x 1 root root 19 Dec 9 14:15 /lib/libnss_winbind.so -> libnss_winbind.so.2
[root@debian root]# ls -l /lib/security/pam_winbind.so -rw-r--r-- 1 root root 16544 2005-05-27 08:19 /lib/security/pam_winbind.so [root@debian root]# ls -l /lib/libnss_winbind.so.2 -rw-r--r-- 1 root root 17840 2005-05-27 08:19 /lib/libnss_winbind.so.2
To configure NSS edit the /etc/nsswitch file and edit it to use winbind service. Modify the "passwd" and "group" fields to contain winbind as an source for account and group information. Do not touch any other lines (including the line containing the "shadow" word) unless you know what you are doing.
- On RHEL AS and Fedora
[root@rhel3 root]# vi /etc/nsswitch.conf .....[[snipped..]]..... passwd: files winbind shadow: files group: files winbind .....[[snipped..]].....
[root@debian root]# vi /etc/nsswitch.conf .....[[snipped..]]..... passwd: compat winbind shadow: compat group: compat winbind .....[[snipped..]].....
Configure the PAM System to Use winbind
The power of PAM lies in that it enables us to customize authentication on a per-service basis. For example the system can be configured to use the local accounts for console logins, and to use NT domain authentication for remote SSH or FTP logins. For this changes can be done on either /etc/pam.conf file or various configuration files (one per service) located in /etc/pam.d/
Different distributions have PAM configured in different manner. For example RHEL and Fedora uses pam_stack.so modules which pushes part of the PAM configuration in the /etc/pam.d/system-auth file. Similarly Debian Sarge maintains a set of three files /etc/pam.d/common-account (authorization settings common to all services), /etc/pam.d/common-auth (authentication settings common to all services), /etc/pam.d/common-password (containing password related settings common to all services) and /etc/pam.d/common-session (session-related modules common to all services)
So if it is required that all services use Windows authentication then modify the /etc/pam.d/system-auth file on RHEL and Fedora Systems and /etc/pam.d/common-account /etc/pam.d/common-auth /etc/pam.d/common-password /etc/pam.d/common-session files. Otherwise individually each service file can also be modified.
Please note that the sequence of the lines is very important. If you need more info on PAM configuration then you can visit A Linux PAM page
I had to use the winbind on all the services so I changed the /etc/pam.d/system-auth file. Here is how my file looks like:
[root@rhel3 root]# vi /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient pam_winbind.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok try_first_pass auth required /lib/security/$ISA/pam_deny.so account sufficient pam_winbind.so account required /lib/security/$ISA/pam_unix.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow min=6 max=255 password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session required pam_mkhomedir.so skel=/etc/skel umask=0027
Please note that if you happen to run the Red Hat’s "authconfig" tool then this file will be overwritten, so please make a backup copy of this file.
Important points to keep in mind
I use mod_auth_pam with Apache for secure areas on our intranet. This works fine with Winbind and Samba. But if in the PAM files you reverse the order of pam_winbind.so and pam_unix_so in the auth and account lines then although your local unix authentication will work, but Apache does not let you through to the secure area. It is probably because if pam_unix.so is first and you try to use the ADS account, the first time PAM tries to authenticate against local Unix database, it fails and that’s what Apache gets. I dont know the details of all this, but this is what I have found and when I reverse the order it all works very well. If someone comes to know the details then please let me know.
I downloaded the four CDs 
of Soalris Express Community Edition 27 and as I was installing it I realised that this is exactly Soalris 10 (with minor differences, ofcourse) and at some point during the installation I found that this is actually internally being treated as Solaris 11 (SunOS 5.11) by Sun. Overall I found that although still under development