Lenore Tumey

AD and LDAP: So Happy Together

Blog Post created by Lenore Tumey Employee on Dec 9, 2015

We spend a lot of time talking about Active Directory, but a lot of companies have a variety of identity repositories.  For example, employees might be managed in AD, while partner identities might be in an OpenDJ LDAP directory.  What if both groups of users need to log into the same instance of a SAML application, but that SAML application can only federate with a single Identity Provider?



Fortunately, RSA Via Access can act as that Identity Provider.  By connecting to both identity sources, we can provide SAML access for users in both repositories.  To set this up, the admin first needs to configure the Identity Routers to connect to the Active Directory and the LDAP servers by configuring both in the Identity Sources (a.k.a. User Stores).  For the sake of this example, we’ll call these Identity Sources, “Corp AD” and “Partner LDAP,” respectively.  Each user who will be accessing this system will just need to have a unique ‘mail’ attribute configured.



Once the Identity Sources are set up, the admin can then configure the SAML application.  When specifying the User Identity details such as the NameID and any extended attributes, use the Attribute Hunting option to enable the ability to search across multiple Identity Sources.  For example, if the SAML app needs the NameID to be the email address, you could pull it from Corp AD ‘mail’ and also look at Partner LDAP ‘mail’.  If the application also requires an extended attribute called FirstName, with Attribute Hunting enabled, you can click the pencil icon to manage the configuration and pull the attribute from the Corp AD ‘givenName’ attribute, or the Partner LDAP ‘userFirstName’ attribute (assuming that’s the name of the attribute holding the user’s first name).



Similarly, when configuring the access policy, the admin can check both the Corp AD and Partner LDAP sources in step 2, and then be able to construct Access Rules using attributes from both identity sources.  For example, you could craft a ruleset for users whose ‘mail’ attributes contain ‘@gmail.com’ to deny access, and another ruleset for employees who are a memberOf the CN=IT-Admins,OU=Groups,DC=example,DC=com group to require step-up authentication when they’re coming from outside the corporate network.  In the rule editor, the admin doesn’t select a specific identity source from which to pull the attribute, so if both sources have the same attribute names, the rule will automatically handle users logging in from either directory.