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.

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. 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. 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. 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. 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. And the winner is…
Microsoft Active Directory!
But…

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. 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. 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. 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. 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. 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. 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. Provisioning an LDS instance

15. Provisioning an LDS instance

16. Provisioning an LDS instance

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. 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. 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. 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. 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. ADAMSync Configuration File
<?xml version="1.0"?>
<doc>
<configuration>
<description>Auth Sync</description>
<security-mode>object</security-mode>
<source-ad-name>prdauth03.auth.uncg.edu</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. 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. 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. 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. 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. 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. 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. 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. Questions?
Robert Gorrell
rwgorrel@uncg.edu
Jeff Whitworth
jnwhitwo@uncg.edu