A Flexible Approach to Creating an Enterprise Directory

Leveraging Microsoft Active Directory LDS

Robert Gorrell – IdM Architect, Enterprise SystemsJeff Whitworth – Manager, Enterprise Systems

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

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.

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.

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

And the winner is…

Microsoft Active Directory!

But…

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.

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?

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.

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.

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.

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.

Provisioning an LDS instance

• Add the AD LDS Role• Create an LDS Instance

1. New or Replica?

2. Name

3. Ports

4. Partition

5. Storage Location

6. Service Account

7. Administrators

8. Pre-load Schema

9. Done

Provisioning an LDS instance

Provisioning an LDS instance

Provisioning an LDS instance

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

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.

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.

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 msDS-UserAccountDisabled to FALSE.

adamsync.exe

• Installing the XML file:Adamsync /install localhost:389 CustomAdamsync.xml

• Synchronizing:Adamsync /sync localhost:389 "DC=fabrikam,DC=com" /log adamsync.log

<?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>

ADAMSync Configuration File

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.

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.

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>

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.

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.

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.

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

Questions?

Robert Gorrellrwgorrel@uncg.edu

Jeff Whitworthjnwhitwo@uncg.edu