Authenticating against Active Directory using Winbind and Kerberos
Prerequisites
- Software
- Samba > 3.0.20
- Kerberos MIT / Heimdal
- ntp
- possibly CUPS server
- Permissions and Users
- root user on the server
- Active Directory (AD) user with permission to join AD
- A backup of important system files
- /etc/hosts
- /etc/ntp.conf
- /etc/samba/smb.conf
- /etc/krb5.conf
- /etc/nsswitch.conf
- /etc/pam.d/system-auth
Steps required -- overview
Please note that all instances of the following are examples and will need to be modified to fit your specific distribution.
wm2kad.vmdomain.com = FQDN of the AD server
vmcentos.vmdomain.com = FQDN of the Linux client.
- Time between the Domain Controller (DC) and the Samba server must be in sync
-
- Use NTP
Make certain DNS is functioning properly or set up entries in /etc/hosts
- Kerberos environment must be set up and working
- Configure samba (smb.conf)
- Join to the Domain
- Configure /etc/nsswitch.conf
- Start the samba and winbind services
- Configure PAM
(slightly more) Detail
Setting up NTP
In order for kerberos to grant tickets to your client machine, the clock skew must not be too great (usually 5 minutes or less). Windows 2000 and later workstations automatically synchronize their time to the AD controller. To emulate this behavior in Linux, add
| Code: |
| server w2kad.vmdomain.com |
to the /etc/ntp.conf file and comment out the other server entries. w2kad.vmdomain.com needs to be replaced with your AD server's FQDN
Adding entries to your /etc/hosts file
If your DNS is not functioning properly, you will have many problems getting Winbind AD authentication to work. You may wish to place entries for your client machine and your AD server in /etc/hosts, both FQDN and shortname.
Following is an example of a working /etc/hosts file:
| Code: |
| 127.0.0.1 localhost.localdomain localhost 192.168.50.15 vmcentos.vmdomain.com vmcentos 192.168.50.5 vm2kad.vmdomain.com vm2kad |
Setting up Kerberos
Keep in mind that upper case is very important here. Without proper capitalization of your realms and .domain_realm, Kerberos will not be able to connect. Here is an example of a working /etc/krb5.conf file.
| Code: |
| [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] [realms] [domain_realm] [kdc] [appdefaults] |
You can now test to see if Kerberos is functioning properly by issuing the following command:
| Code: |
| kinit Administrator@VMDOMAIN.COM |
Remember, that capitalization is important! This should ask you for the password for "Administrator" on the DC and report if you have successfully logged in.
Setting up Samba
Please see the following example /etc/samba/smb.conf file:
| Code: |
| /etc/samba/smb.conf #The following needs to be added / updated somewhere in the [global] section of smb.conf workgroup = VMDOMAIN realm = VMDOMAIN.COM security = ADS encrypt passwords = yes preferred master = no server string = Linux Test Machine log level = 3 log file = /var/log/samba/%m max log size = 50 printcap name = cups printing = cups winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind separator + idmap uid = 10000-20000 idmap gid = 10000-20000 template shell = /bin/bash pam password change = yes password server = vm2kad.vmdomain.com template homedir = /home/%U [homes] [printers] |
A couple of important things to note:
- template homedir = %U -- sets the domain user's homepath. The default is to use /home/VMDOMAIN/%U. If you would prefer this behavior, you will need to create the /home/VMDOMAIN directory.
- winbind use default domain = yes -- If you are only authenticating against one domain, this removes the requirement of having to prefix the username with VMDOMAIN+username
- idmap uid = 10000-20000 and idmap gid = 10000-20000 -- This sets the UID and GID mapping of the AD users to the Linux system. Do not set this where you may have local accounts or bad things may happen.
- template shell = /bin/bash -- Sets the default shell for users logging in to the system. This is not set via Winbind and Active Directory. It can be specified with "Windows Services for Unix" when authenticating with LDAP.
- winbind enum groups and winbind enum users allows the command "getent" to return with users and groups respectively.
You may run the command "testparm" to test your samba configuration file. It should print that everything is OK, however it may present a warning about the "+" sign possibly causing problems with domain joins. Ignore this.
You will now need to start the following services in the following order: nmbd, smbd and winbind. On RedHat EL4 and possibly other RedHat based systems, the following code should work:
| Code: |
| /etc/init.d/winbind start ; /etc/init.d/smb start |
Please note that the winbind daemon has two "d"s at the end "winbindd"
You will now need to execute:
| Code: |
| net ads join -U Administrator |
You may use any user that has privileges enough to allow a domain join. This should ask you for a password, and print a domain join notice.
To test that you have properly joined the domain, there are several things you can test:
| Code: |
| net ads testjoin |
Tests the connection to the AD
| Code: |
| wbinfo -u |
Should show all of the members of the domain
| Code: |
| wbinfo -g |
Should show all of the groups available in the domain. Note: If you have more than one domain, the members of the other domain will appear in the form "DOMAIN+mygroup". This is normal and expected
| Code: |
| wbinfo -a username%password |
This checks to see if "username" using "password" can connect to the domain. You must place the password as part of the command, as it will not prompt you.
Editing the /etc/nsswitch.conf file
The next step is to allow Linux to look at the winbind list for usernames and passwords. Below is an example of a working /etc/nsswitch.conf file. Please make note that the only changes made were to add "winbind" to the passwd:, shadow: and group: sections.
| Code: |
| passwd: files winbind shadow: files winbind group: files winbind hosts: files dns bootparams: files |
At this point, you should be able to type:
| Code: |
| getent passwd |
which should return both the local user list and at the end, those that have been imported from Active Directory.
Setting up PAM Authentication for Active Directory.
NOTE: Before you start, you will want to backup your /etc/pam.d directory. Failure at this stage can completely lock you out of your machine. Log in to a root account (or two) from a Virtual Terminal and LEAVE IT LOGGED IN until you are certain that your PAM configuration works.
On RedHat, changing the entire PAM system authentication is done in one file: /etc/pam.d/system-auth. Please see the following for a working system-auth configuration.
| Code: |
| #%PAM-1.0 # # auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so password sufficient /lib/security/$ISA/pam_krb5.so minimum_uid=10000 session required /lib/security/$ISA/pam_limits.so |
Save this file and then change to another Virtual Terminal. Attempt to login as a member of the Active Directory. This should work, and will create their home directory. If you have a local user with the same name, and have chosen /home/%U for the Domain user's home directories, you may run in to trouble. Check as many users as you can, both local and domain, until you are satisfied the configuration works.
NOTE: Make sure the ROOT account can still log in too!