Presentation on theme: "LDAP/Active Directory Integration Making Active Directory a slave to your enterprise environment. Robert Banz Copyright Robert Banz,"— Presentation transcript:
LDAP/Active Directory Integration Making Active Directory a slave to your enterprise environment. Robert Banz Robert.firstname.lastname@example.org Copyright Robert Banz, 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
3 Deep Background Pre-Enterprise Directory environment MIT K5 for Authentication PH/CSO for account management AFS for enterprise file service
4 Foreground Enterprise Directory: August 2000 Included… Identity management system. Account management system. Web SSO (initially for mgmt. apps & Blackboard) Email Routing (no more sendmail alias files!)
6 Demystifying Active Directory Microsoft Active Directory is: –A “NOS” specific directory –LDAP based –Relies on MIT Kerberos 5 for authentication –DNS service records for resource discovery Commentary: It’s a “good thing tm ”
7 What is Kerberos? Kerberos is: “…a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.” -http://web.mit.edu/kerberos/www “Embraced and Extended” by Microsoft …but not as much as the Anti-MS crowd would have you think.
9 Integration Goals One password between the Windows & UNIX environment Little “manual” administration of the Windows environment Access to AFS file space from UNIX
10 Password Integration Options Use Microsoft’s KDC Pros: –Easy integration with MS –MIT K5 applications will integrate cleanly –MIT K4 applications (such as AFS) *are* integrateable ( see OpenAFS mailing list) Cons: –Uses the Microsoft KDC (not only a religious issue) –Need to “re-register” all users’ passwords, a logistical nightmare
11 Password Integration Options Use existing KDC Pros: –No need to “re-register” user passwords –Easy Kerberos 4 compatibility for old applications Cons: –Need to configure Win2k/XP workstations for “cross realm” authentication –Problems with “downlevel” applications and clients.
12 Administration Options Use Microsoft AD as the enterprise directory Pros: –Easy integration. –AD has very good access control & schema management capabilities Cons: –Schema is not 100% “standards” compliant –Need to migrate existing enterprise –Reliance on “vendor specific” extensions could follow…
13 Administration Options “Pull” data from enterprise directory Pros: –Managing AD from the Windows platform is well documented. –ADSI tools can control every aspect, even remotely, of the AD tree. Cons: –We’re UNIX geeks, and all other directory connectors exist on UNIX.
14 Administration Options “Push” data from enterprise directory Pros: –We’re UNIX geeks, and it can run with our existing connector infrastructure. –Most of AD can be managed directly via standard LDAP calls Cons: –Some security/access control features are “opaque” from the LDAP perspective. –Undocumented, unsupported, etc. (but since when has that stopped us?)
15 Our Choices Use our existing MIT KDC –Involves “cross-realm” authentication Managed AD via LDAP from UNIX –“just another perl connector”
16 WHAT is this “cross realm” thing? From the Kerberos FAQ: Any Kerberos principal can authenticate to other principals within the same Kerberos realm. However, it is also possible to configure a Kerberos realm so principals in one realm can authenticate to principals in another realm. This is called cross-realm authentication. The way this is implemented is the KDCs in the two realms share a special cross-realm secret, and this secret is used to prove the identity of principals when crossing the boundary between realms.
17 What’s Missing? ntSecurityDescriptor is an “opaque” field. Is a binary structure, “only usable” via the ADSI libraries. –…but someone may have decoded this by now.
18 Basically… Everything else works: Users authenticate via Kerberos They can get to their files via AFS Their profiles are stored there …it’s all good.
19 Step By Step: Kerberos Integration Setting up Cross-Realm Kerberos http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp –Configure the workstations with your non-AD Kerberos realm Ksetup /addkdc UMBC.EDU kerberos.umbc.edu –Create cross-realm tickets on the MIT KDC –Configure the AD server to accept cross-realm tickets …via the Domain Tree Management tool
20 Step By Step: Kerberos Integration Configure user accounts to accept “foreign” security credentials –Enable “Advanced Features” in “Active Directory Users and Computers” –Right click on the appropriate user, and pick “Name Mappings” –Add the appropriate kerberos identity to the list…
21 On To LDAP 1.Create a “working” cross realm account 2.Look at the resulting account via LDAP 3.…lather, rinse… Try to repeat.
24 LDAP Oddities Password changes (userPassword) have special rules: –It’s actually unicodePwd –…and it’s a double-wide character string (grr…) –…and it can only be set over SSL, either at object creation, or in a single operation Some attributes don’t show up… –ntSecurityDescriptor is not returned unless asked for.
25 Tips & Tricks Creating Accounts Via LDAP Only a small subset of the attributes in the account object need to be provided – the rest are generated by the directory. We set: (items in bold are required in our environment) –distinguishedName – The DN of the object in Active Directory –wwwHomepage – The user’s homepage location (informational) –mail – The user’s advertised mail address (informational) –altSecurityIdentities – The user’s foreign KDC principal. –displayName – The “full name” of the person. –givenName – The person’s first name. –Sn – The person’s last name. –homeDirectory – Location of their home directory.
26 Tips & Tricks Creating Accounts Via LDAP We set – continued (items in bold are required in our environment) –profilePath – Location of their roaming profile. –name – Name (user ID) of the account –samAccountName – The account name, again –userAccountControl – Bit field of certain account properties (by default, an account is in a “locked” state) –userPrincipalName – The princpal of the AD account (user@AD.REALM.COM) –ntSecurityDescriptor – Security settings for this object. –cn – The “common name” of the account (==name)
27 The Goods. Our iPlanet 4.x -> AD connector is freely available (as well as other useful middleware stuffs) http://www.umbc.edu/oit/syssw –lbridged – processes the iPlanet 4.x LDAP changelog –perl-ldap – contains perl modules which make up the actual translation/connection logic
28 For More Information Microsoft’s Website http://www.microsoft.com (yes, in this case, it is helpful) http://www.microsoft.com MIT’s Project Pismere (now WinAthena) http://web.mit.edu/pismere/ http://web.mit.edu/pismere/