Cause 2013: A Flexible Approach to Creating an Enterprise Directory


Published on

Leveraging Microsoft Active Directory LDS to create a flexible enterprise directory.

As UNCG sought to replace Novell Directory Services with the next generation enterprise authentication and directory services (LDAP), we examined OpenLDAP, Active Directory, and Active Directory Lightweight Domain Services. Hear why we picked a somewhat uncommon approach in the less known AD LDS product and the flexibility it afforded us a middle ground between OpenLDAP and the urge to use existing Active Directory domain. We will also discuss the ADAMSync tool used to populate this environment as well as the MSUserProxy object to centralize authentication.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ESW has expertise in management of both host and software.Open LDAP
  • DIT – Directory Information Tree
  • MS-UserProxy.LDF holds the definition for the simple userProxy class, which has basic attributes and contains the msDS-BindProxy auxiliary class. MS-UserProxyFull.LDF contains the msDS-BindProxy auxiliary class as well, but it also pre-populates additional user attributes into the mayContain attribute of the class. Because of this, the attribute classes have to exist beforehand. So when importing the userProxyFull class, either the user or inetOrgPerson class needs to be imported first. Both user and inetOrgPerson contain the attribute class definitions for the attributes that userProxyFull uses
  • Cause 2013: A Flexible Approach to Creating an Enterprise Directory

    1. 1. A Flexible Approach to Creating an Enterprise Directory Leveraging Microsoft Active Directory LDS Robert Gorrell – IdM Architect, Enterprise Systems Jeff Whitworth – Manager, Enterprise Systems
    2. 2. Background • In 2009, UNCG launched a strategic effort to move general file, print, and applications services from Novell to Microsoft. • By 2011, migration off Novell services was complete but for a heavy dependency on eDirectory as the campus LDAP directory. • …a new enterprise LDAP directory was needed! With a goal of discontinuing Novell licensing by July 2012
    3. 3. Drivers 1. Redundancy – ability to replicate directory across multiple servers. 2. High Availability – ability to support an “active-active” environment. 3. Logging – capture/store transactional logs of all connections for historical and audit purposes. 4. Security – transition to use of secure LDAP only. 5. Independence – The environment will be independent from other services while being maintained by the enterprise IdM. 6. Network – design to operate within the new datacenter model. 7. Production Control – Development and/or Validation tiers to match Production.
    4. 4. Meet the contenders… Microsoft Active Directory • Proprietary product available on Windows. Commercial support available. Windows group has expertise of both host and software. • Cost: Covered by MS Campus Agreement • Pros: Quick implementation time. Some configuration and tools supplied. • Cons: Not as generic as alternative though still adheres to most LDAP standards. Not all aspects are customizable. Open LDAP • Open source product available on Linux. Community support only. Unix has expertise with host but not software. • Cost: Free • Pros: Most generic/universal of all LDAP implementations. 100% customizable • Cons: Longer implementation time. More configuration required. Less provided tools. Just an LDAP server, nothing more.
    5. 5. Features Comparison Microsoft Active Directory • Basic builtin structure • DIT must be based on domain • Schema extension by MS MMC • No plaintext anonymous queries • Default query limited of 10,000 object • Paging controls • Authentication with email or DN • Replication automatically builtin • Management tools provided Open LDAP • No builtin structure • DIT can be domain or geographic • Schema extension by LDIF • Plaintext anonymous queries allowed • No default query limit • No paging controls • Authentication with DN only • Replication available though not builtin • Bring your own management tools
    6. 6. And the winner is… Microsoft Active Directory! But…
    7. 7. Concerns over traditional AD • organization DIT is more comfortable (o=uncg) • already have a general workstation domain and no intention of merging with enterprise authentication = unnecessary overhead. • but mostly… a predefined (corporate style) permissions model that by default allows reading of any users directory information by any other authenticated user = FERPA concerns.
    8. 8. Where to go? • So is Microsoft the right solution after all? • Is there a way to make Active Directory meet our needs without creating undo baggage and without changing the way we operate as a university? • What is Microsoft Lightweight Directory Service we’ve heard whispers about?
    9. 9. Microsoft LDS • < Win2k3: ADAM – Active Directory Application Mode • > Win2k8: LDS – Lightweight Directory Services • basically, a light-weight implementation of Active Directory running as a single service free of domains and domain controllers.
    10. 10. The Architecture • A new authentication AD domain using three Win2k8R2 x64 domain controllers acting as an “Identity Vault” in a protected network. • A minimum of 2 LDS hosting servers, scalable to more, at the datacenter edge • Utilization of F5’s BigIP appliance to route client LDAP traffic into the LDS hosting environment. • AdamSync to provision objects from the “Identity Vault” domain into LDAP instances running in the LDS hosting environment.
    11. 11. Identity Vault Why deploy a new domain to support LDS? • Position authentication as a standalone, independent service. • Flexibility to pre-stage or carry objects that won’t be synced to LDS/LDAP. • Ability to use Microsoft tools to control provisioning process. • Centralize password management. • Apply higher level security practices surrounding the vault.
    12. 12. More architectural details… • Secure LDAP is mandatory. Plaintext LDAP connections are no longer available. • Environment will be exposed to all internal networks but not exposed to the Internet… transition to shibboleth SSO for external authentication use. • Directory collapses to a flat structure encouraging authorization decisions to be made against attribute information rather than directory structure and alleviate management burden of yearly org changes.
    13. 13. Provisioning an LDS instance • Add the AD LDS Role • Create an LDS Instance 1. 2. 3. 4. 5. 6. 7. 8. 9. New or Replica? Name Ports Partition Storage Location Service Account Administrators Pre-load Schema Done
    14. 14. Provisioning an LDS instance
    15. 15. Provisioning an LDS instance
    16. 16. Provisioning an LDS instance
    17. 17. Loading the schema • User Classes supplied by LDS – – – – – – – MS-AZMan.ldf MS-InetOrgPerson.ldf MS-User.ldf MS-UserProxy.ldf MS-UserProxyFull.ldf MS-AdamSyncMetadata.ldf MS-Adam-DisplaySpecifiers-0409.ldf • Load objects required by Active Directory to AdamSync: ldifde -i -f MS-AdamSyncMetadata.LDF -s localhost:389 -j . -c "cn=Configuration,dc=X" #configurationNamingContext
    18. 18. ADSchemaAnalyzer.exe • Load target schema (AD) • Load base schema (LDS) • Mark all non-present elements as included • Create LDIF file • Mark elements as Auto, Included, Excluded, and Present.
    19. 19. userProxy • When a user performs a simple bind to an LDS instance with a proxy object, the bind is redirected to Active Directory by passing the SID and password to a domain controller. The AD LDS server performs the authentication, and the entire process is invisible to the end user. • MS-UserProxy.LDF and MS-UserProxyFull.LDF • msDS-BindProxy auxiliary class. • Must synchronize objectSID attribute in AdamSync. • By default, bind redirection requires an SSL connection.
    20. 20. without userProxy • New ADAM user accounts are disabled by default. You will need to enable the new accounts and set a password. • Enable users by changing the attribute msDSUserAccountDisabled to FALSE.
    21. 21. adamsync.exe • Installing the XML file: Adamsync /install localhost:389 CustomAdamsync.xml • Synchronizing: Adamsync /sync localhost:389 "DC=fabrikam,DC=com" /log adamsync.log
    22. 22. ADAMSync Configuration File <?xml version="1.0"?> <doc> <configuration> <description>Auth Sync</description> <security-mode>object</security-mode> <source-ad-name></source-ad-name> <source-ad-partition>dc=auth,dc=uncg,dc=edu</source-ad-partition> <source-ad-account>administrator</source-ad-account> <account-domain>auth</account-domain> <target-dn>o=uncg</target-dn> <query> <base-dn>ou=accounts,dc=auth,dc=uncg,dc=edu</base-dn> <object-filter>(objectClass=user)</object-filter> <attributes> <include>objectSID</include> <include>sAMAccountName</include> <include>UserprincipalName</include> <include>uid</include> <include>uidNumber</include> <include>gidNumber</include> <include>sn</include> <include>givenName</include> <include>initials</include> <include>middleName</include> <include>displayName</include> …. <exclude> </exclude> </attributes> </query> <user-proxy> <source-object-class>user</source-object-class> <target-object-class>userProxy</target-object-class> </user-proxy> <schedule> <aging> <frequency>0</frequency> <num-objects>0</num-objects> </aging> <schtasks-cmd></schtasks-cmd> </schedule> </configuration> <synchronizer-state> <dirsync-cookie></dirsync-cookie> <status></status> <authoritative-adam-instance></authoritative-adam-instance> <configuration-file-guid></configuration-file-guid> <last-sync-attempt-time></last-sync-attempt-time> <last-sync-success-time></last-sync-success-time> <last-sync-error-time></last-sync-error-time> <last-sync-error-string></last-sync-error-string> <consecutive-sync-failures></consecutive-sync-failures> <user-credentials></user-credentials> <runs-since-last-object-update></runs-since-last-object-update> <runs-since-last-full-sync></runs-since-last-full-sync> </synchronizer-state> </doc>
    23. 23. ADAMSync Aging • Frequency – If set to 0, aging will be not used. – If set to 1, the aging will be called every sync. – If set to 2, the aging will be called every two syncs. • num-objects – number of objects that need to be aged per run. If set to 0, it will always age all objects against Active Directory. If you make this 50, it will only age 50. When you perform the next sync, it will age the next 50.
    24. 24. LDS Roles Reside in CN=Roles container of each directory partition 1. Administrators (CN=Administrators,CN=Roles) – Full access to the partition. Admins specified during setup are assigned to this role. 2. Readers (CN=Readers,CN=Roles) – Read access to the partition. 3. Users (CN=Users,CN=Roles) – No default permission to partition.
    25. 25. LDS Instance Management • start/stop – net start <instancename> • dsdbutil: – list instances – activate instance <instancename> • LDAP port <portnumber> • SSL port <portnumber> • change service account <accountname> <password>
    26. 26. LDS Management Tools • Ldp – LDAP client, connect and modify directory ACE’s. • Ldifde – command line tool for working with LDIF files. Import schema and configuration. • Csvde – command line tool for bulk user import • ADSI Edit – MMC snapin for editing directory objects. • schmmgmt.dll – MMC snapin for editing directory schema.
    27. 27. LDS Replication • Supports multimaster replication just like AD - loose data consistency with convergence. • Very easy to setup... create a new instance and supply the replication source and partition name. • In advent of replication conflict, instances accept the change with the higher version and discard the other change. If the versions are identical, AD LDS instances accept the change with the more recent time stamp.
    28. 28. Lessons learned so far… • LDS coupled with adamsync and userproxy class provide incredible flexibility and ease in spinning up and populating new LDAP instances for testing or specialized purposes. • LDS replication combined with a network load balancer provide a scalable LDAP hosting environment. • LDS experience is difficult to find, especially in a current vintage. • Applications supporting AD as an LDAP source don’t always support LDS… especially when userproxy class is involved.
    29. 29. Next Steps • Support for group objects, supplied by Enterprise Group Management, synced to LDAP by adamsync. • Development tier, connected to Development Banner and IdM tiers, refreshable by adamsync. • FERPA complaint/stripped LDAP directory by adamsync filtering
    30. 30. Questions? Robert Gorrell Jeff Whitworth