Active Directory-based authentication, access control and role-based privilege management for Windows, Linux & UNIX
Standard Edition + privileged user auditing
Enterprise Edition + encryption of data-in-motion and server isolation
Any Edition + single sign-on for SAP, Apache and J2EE/Java applications
Single sign-on for cloud apps + mobile device supportMac Edition
Active Directory-based authentication and Group Policy management for Macs + mobile device supportPremium Edition
SaaS and Mac Editions + mobile device supportCentrify for Samsung KNOX
Active Directory-based SSO, MCM and MDM for KNOX-enabled devices
Tuesday, April 21, 2009
We have had a number of customers recently ask us how we could help them integrate their MIT Kerberos realm users with Active Directory. Given that one of the recent features we added in DirectControl v4.2 (shipped in December 2008) was in fact to support this capability, I thought it would be interesting to further elaborate on this feature in a blog post. Mike Patnode, our VP of Technology, was kind enough to write today's blog post, so take it away Mike!
Many organizations who deployed the MIT Kerberos infrastructure many years ago to secure their Unix machines may now be considering a migration to Active Directory. While most people know that Active Directory has its own internal Kerberos KDC, many people are unaware that since the release of Windows 2000, Microsoft has supported cross-Realm authentication with an MIT Kerberos KDC. Now that Microsoft is a founding member of the MIT Kerberos Consortium, future release compatibility can be safely assumed.
First off, Microsoft actually supports a Windows XP desktop authenticating a user from an MIT KDC. This configuration is described in detail in Microsoft's Step-by-Step Guide to Kerberos 5 Interoperability. But for this case, all we're interested in is how to migrate your existing Linux and Unix users and service accounts using DirectControl, which is actually much simpler than configuring a Windows machine to do the same.
Secondly, we need to understand how the existing Unix and Linux boxes are configured. While they may be managing their credentials in the Kerberos KDC, their Unix profile information (username, uid, gid, etc..) still needs to be managed either locally in /etc/passwd, NIS or potentially LDAP. What we can do during the migration process, is import the existing NIS or LDAP user account information into a DirectControl Zone in Active Directory, but continue to use the MIT KDC for obtaining tickets and managing passwords for Unix users. This may be preferred if the Unix team wants to continue to maintain its own credentials policy, or if you have many Kerberos services which you don't want to have to migrate as well.
The first step is to establish a trust between the MIT KDC Realm and your Active Directory Domain. This can be done through the Active Directory Domains and Trusts MMC snap-in. Typically, you only need to create a one-way outgoing trust. IE: Users in the MIT Realm can be authenticated in the Active Directory Domain, but a two-way trust can be configured as well. You can also select whether the trust is transitive to all domains in the forest, or just the current domain you are configuring. The MMC will prompt you for a password, which you must remember when configuring the KDC. You then must establish the trust account on the KDC using the kadmin command. The Microsoft Guide above walks you through each step.
Once this is done, you now need to choose which Active Directory users are going to use the KDC credentials, and create account mappings for each of those users. Once again, the Step-by-Step Guide walks you through the mapping procedure using Microsoft's Active Directory Users and Computers (ADUC). Although this is fine for a single user, this obviously doesn't scale to the 1000's of users you may be migrating. What this mapping process actually does is set the altSecurityIdentifier attribute in the Active Directory user object to "Kerberos:email@example.com". Where name and mit.realm match the user's principal name and realm from the KDC. This can be done with a fairly simple ldapmodify script from the Unix host, assuming you have a well defined method for matching a KDC users with the correct Active Directory entry. Note also this is a multi-value attribute which may contain other items you do not want to disturb.
Now we have a trust established between the KDC and Active Directory, and the user object in Active Directory has been mapped to the proper KDC. We just need to join the computer to the Active Directory domain using adjoin. The reason this works is due to DirectControl's advanced support for one-way trust. It does not rely upon "back-door" service principals to access the user's domain. Instead, the user's Unix profile information is retrieved from the zone in the joined domain, and the untrusting domain is solely used to authenticate the incoming user. We leverage this same architecture for MIT KDC interoperability. By treating the KDC as a one-way trust, the DirectControl agent will never attempt to communicate with an LDAP or GC service in that realm.
Prior to joining the domain, you can also save off the MIT machine credentials from the KDC (krb5.keytab) and add them back using the "ktutil" command once the join is complete. This essentially will allow the machine to be joined to both the KDC realm and Active Directory domain at the same time. This may be important for legacy Kerberos services to continue to run. When you join the Active Directory domain, you may also choose a DirectControl zone for the machine to be joined to. One of the nice features of Zones is to easily segregate the set of users who have access to a set of machines. Once this is done, you can go back to either the DirectControl Console, or ADUC and add the users to the zone. Once again, to do so in batch, you would use the "adupdate add user" command.
From there, the DirectControl agent will download the trust information from the joined domain. When the user logs in, it will see the altSecurityIdentifier and use that to authenticated the user against the trusted MIT KDC domain as if it was a one-way outgoing trust. Whether the user is authenticated against the KDC or AD is completely transparent at login time, but can be checked with the "klist" command which will tell you which domain or realm issued the Kerberos ticket.
In summary, Microsoft has supported AD interoperability with the MIT Kerberos distribution from the very beginning. Centrify DirectControl make it even easier to take advantage of this interoperability.