ldap/active directory integration making active directory a slave to your enterprise environment....
TRANSCRIPT
LDAP/Active Directory Integration
Making Active Directory a slave to your enterprise environment.
Robert [email protected]
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.
2
Background
UMBC’s Stats:• 11,700 Students• 1200 Faculty• “Centralized” computing environment
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 2000Included…
• Identity management system.• Account management system.• Web SSO (initially for mgmt. apps & Blackboard)• Email Routing (no more sendmail alias files!)
5
UMBC’s Enterprise Directory
Public LDAP(Whitepages)
(SunOne DS5)
Oracle DB
LDAPDirectory
(iPlanet 4.1x)
AuthenticationService
(MIT K5)
MetadirectoryProcesses
(perl)SIS
(HP MPE)
HRSystem
User Input DirectoryManagmentApplications
Replica Replica
SISMirror
OutgoingConnectors
(perl)
To Consumers
Radius,WebAuth,PeopleSoft,etc.
UNIX Systems,Win2K Labs,AFS
Email Clients
Email Routing
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.
8
Directory Services Architecture
ds-master.umbc.eduiPlanet 4.1x +lots of Perlds-slave1
ds-slave2
HRSystem
SIS(Student)
MS Active Directory(ad.umbc.edu)
Blackboard
Border Directory(directory.umbc.edu,
dc=umbc,dc=edu)
Kerberos KDC
slam
research
afsguys
NIS Domains
Legacy Biz. Systems(Oracle)
Web Services
* Web Single Sign-On is provided by WebAuth.* Directory Managment through WebAdmin* Authentication & Authroization data is provided via LDAP
AFS ptsvc.
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 directoryPros:
– 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 Kerberoshttp://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.
22
…and a little LDAPdn: CN=banz,CN=Users,DC=sysad,DC=umbc,DC=edumemberOf: CN=Users,CN=Builtin,DC=sysad,DC=umbc,DC=edumemberOf: CN=Administrators,CN=Builtin,DC=sysad,DC=umbc,DC=eduaccountExpires: 0adminCount: 1altSecurityIdentities: Kerberos:[email protected]: 0badPwdCount: 0codePage: 0cn: banzcountryCode: 0displayName: Robert BanzinstanceType: 4lastLogoff: 0lastLogon: 126810736570214704logonCount: 1logonHours:: ////////////////////////////distinguishedName: CN=banz,CN=Users,DC=sysad,DC=umbc,DC=edu…
23
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=sysad,DC=umbc,DC=eduobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: userobjectGUID:: ia22S8MoEEWpMBCsP0U6aw==objectSid:: AQUAAAAAAAUVAAAAFSWvRxHDX3Pb6wxQ7gMAAA==primaryGroupID: 513pwdLastSet: 126810732088463792name: banzsAMAccountName: banzsAMAccountType: 805306368userAccountControl: 66048uSNChanged: 2726uSNCreated: 1415whenChanged: 20021111212224.0ZwhenCreated: 20021111205605.0Z
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 ([email protected])
– 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 Websitehttp://www.microsoft.com(yes, in this case, it is helpful)
• MIT’s Project Pismere (now WinAthena)http://web.mit.edu/pismere/
29
This page intentionally left blank.