Several weeks ago I was tasked with creating single sign-on capabilities for a web application infrastructure (
http://www.alphatheory.com/) that consisted of several Windows and Linux (CentOS 5 64-bit) servers. The client wanted the ability to create a user account in a single location for an employee or contract programmer, utilize that username/password combination for SSH access to the Linux servers, Exchange server account authentication, Sharepoint Service 3.0 Portal sign-on as well as Terminal Services and the CVS repository authentication. The client had a Windows 2003 R2 Active Directory domain I created earlier for Exchange/Sharepoint, so instead of reinventing the wheel, I decided to utilize the new features of Windows 2003 R2; more specifically the new Identity Management for Unix component of the Active Directory Services. (
Ref: MS Technet)
In researching this, I came across several excellent links that I will include at the bottom of this post. Please feel free to visit them for more detailed information.
Windows 2003 R2 Configuration:
The first thing necessary is to install the Identity Management for Unix services. To do this, simply go into the Control Panel -> Add/Remove Windows Components -> Active Directory Services and check the Identity Management for Unix box.
After this is installed, you will have a new tab on all your user properties called
Unix Attributes. This is where you choose the NIS (
Ref: Wikipedia) domain, the UID, login shell, home directory and primary group.
Go ahead and open the properties for the domain Administrator account and configure his/her Unix Attributes. We'll use this account later on to join our server to the Active Directory domain and for verification we can communicate with the domain via LDAP. (
Ref: Wikipedia)
At this point, you should also go ahead and create an Active Directory account for the Winbind service. This account doesn't need any special privlidges or Unix Attributes, a standard Active Directory user account will work. Make sure to specify the password never expires and the user cannot change it to avoid issues with the Domain Security policy. I suggest creating a STRONG password for this account. Here's a link that will create a random, 24 character password for you:
PC Tools Password generator. Make a note of the username/password for this account, as we'll need it later.
That's all you need to configure on the Windows Active Directory controller. Yes, really. Let's move on to the CentOS 5 configuration.
CentOS 5 Configuration:
I am assuming you have CentOS 5 installed and are able to SSH into the server to perform remote management. This will obviously work from the local console as well.
First, verify you have the Samba packages installed by typing the following:
You're looking for something similar to the following output:
If you do not see the following, you can install them by using the following command:
-
yum install samba samba-common samba-client
Now, let's verify we have an NTP daemon installed as Kerberos is dependent on proper synchronization of time across all servers.
-
yum install ntpd
-
chkconfig ntpd on
Let's edit the ntpd.conf file to utilize the NTP pool like all good administrators should.
/etc/ntp.conf:
-
Remove all lines that have server 0.redhat.pool.ntp.org, 1.redhat, 2.redhat, etc.
-
Add a single line of server us.pool.ntp.org
-
Of course, use the public NTP pool that is appropriate for your country/locale.
Save and Exit
Start the NTP Daemon by typing service ntpd start
Let's make sure our CentOS machine can find the Windows Active Directory (aka: AD) server via DNS.
/etc/resolv.conf:
-
search your-ad-domain.local
nameserver ip.address.of.ad.domain.dns.server
Save and Exit
Now, let's make sure if we have a DNS failure, we can still find our Active Directory domain controller via the hosts file. We'll add a line to the bottom of the file pointing to the Windows 2003 Active Directory domain controller.
/etc/hosts:
ip.address.of.ad.domain.controller hostname-of-ad-server.your-ad-domain.local hostname-of-ad-server
Save and Exit
Now, let's edit the Kerberos configuration file - we'll need to add/change a few lines in here for our Active Directory domain.
/etc/krb5.conf:
Note: Use the FQDN of your domain (example: mydomain.local) rather than the NetBIOS name unless otherwise noted.
[libdefaults]
default_realm = YOUR-AD-DOMAIN-NAME.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[domain_realm]
.your-ad-domain = YOUR-AD-DOMAIN.LOCAL
your-ad-domain = YOUR-AD-DOMAIN.LOCAL
Save and Exit
Do not edit anything else, leave everything at their default values or risk the wrath of the evil Linux gremlins when things go wrong later.
The next step is to edit the Lightweight Directory Access Protocol configuration file, ldap.conf.
/etc/ldap.conf:
Delete everything in this file and add the following:
host ip.address.of.ad.domain.dns.server
base dc=your-ad-domain,dc=local
uri ldap://hostname-of-ad-server.your-ad-domain.local/
binddn your-winbind-ad-account@your-ad-domain.local
bindpw strong-winbind-account-password
scope sub
ssl no
nss_base_passwd dc=your-ad-domain,dc=local?sub
nss_base_shadow dc=your-ad-domain,dc=localsub
nss_base_group dc=your-ad-domain,dc=local?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
Save and Exit
Now, let's edit the nsswitch.conf file so our server knows where to look to authenticate accounts.
/etc/nsswitch.conf:
Add the following ines, or edit to match if they are present.
passwd: files winbind ldap
shadow: files winbind ldap
group: files winbind ldap
protocols: files winbind
rpc: files winbind
netgroup: files winbind
automount: files winbind
hosts: files dns
Save and Exit
Now, we need to edit the Samba file so it knows where to look for the proper information. Instead of editing the existing file, I decided to start from scratch since I am not worrying about home directories and such. I just want authentication here.
/etc/samba/smb.conf:
workgroup = AD-NETBIOS-NAME
security = ads
realm = YOUR-AD-DOMAIN.LOCAL
use kerberos keytab = true
password server = hostname-of-ad-server.your-ad-domain.local
Save and Exit
User access is controlled on each server via a file called system_operators, let's edit this file and allow the domain administrator access. Just add a single username per line for any user you'd like to allow access to the server.
/etc/security/system_operators:
root
administrator
Some_Other_User
Save and Exit
Now, let's get the required services started and attempt to communicate with the AD server.
-
chkconfig smb on
-
chkconfig winbind on
-
service smb start
-
service winbind start
Ok, we should have all the Linux configuration files ready to go, name resolution taken care of and our Windows server prepped. Let's test this thing!
Let's initialize the Kerberos system by typing the following:
- kinit administrator@YOUR_AD_DOMAIN.LOCAL
- Capitalization is important here. Use it!
- You should not receive any output. You should simply be returned to your shell prompt after typing the administrator's password.
- getent passwd administrator
- This command will test account enumeration against AD.
- Administrator:*:10001:20000:Administrator:/home/Administrator:/bin/bash
- Something similar to the above should be returned. Don't worry if it's slightly different.
- net ads join
- Ignore anything other than the following:
- Joined YOUR-CENTOS-SERVER to realm 'YOUR-AD-DOMAIN.LOCAL'
You're done!
Reboot your server for good measure (although it shouldn't be necessary) and feel free to log in with any AD accounts you've specified in your system_operators file. A home directory should be automatically created for the users upon initial login.
For futher reading or more detailed information, check out these links: