[TechNote] Authentication, authorization or user/group search may fail in multiple Active Directory configuration

Authentication, authorization or user/group search may fail in multiple Active Directory configuration

Technote (troubleshooting)

Problem(Abstract)

There are a few issues faced when multiple Active Directory domains are configured under Federated repository (VMM.) where authentication, authorization or user/group search may fail in multiple Active Directory configuration.

Symptom

1. All members are not visible if members are cross-domain
2. Login fails because of duplicate ids

Resolving the problem

1. All members are not visible if members are cross-domainWhen a group contains cross-domain members (members from its own domain and another domain), then members which are not in group’s domain are not returned by VMM, since they are out of scope (of baseEntry) and filtered out. In addition, VMM does not support AD specific setup like, trusted AD domains or usingforeignSecurityPrincipal.
   
   Solution >This can be resolved by creating a Parent Domain Controller (PDC) which includes both the domains and configure newly created PDC under VMM with referral set to follow. This will allow VMM to see all the entries coming from a single repository and will not be filtered out.
   
   For example, if you have two AD domains, ou=AD1,dc=com and ou=AD2,dc=com, then create a Parent Domain Controller, o=com, and include both AD domains under it. Configure PDC, o=com, baseEntry under VMM and set referral to follow.
   
2. Login fails because of duplicate idsLogin through federated repository fails if there are duplicate identities found across the repositories. Federating two or more Active Directory LDAPs with duplicate entries will also cause the login to fail.
   
   Solution >This issue can be resolved by following one or more of these options:
   • Deleting duplicate entries from one of the LDAP
     Occurences of multiple entries cause login failures in DuplicateLogonIdException. Duplicate entries should be removed in order to maintain uniqueness of user entries across repositories configured.
   • Scoping the searchBase to a subtree
     There are cases when user entries are duplicated in sibling subtrees within LDAP. Configuring only needed subtree would limit VMM to operate only on scoped subtree and entries belonging to that subtree. So this way, duplicate entries would be skipped/outscoped of VMM. And login will succeed.
   • Setting the searchFilter for PersonAccount and/or Group entity types
     Searchfilter's do help to keep away entries from search operation. Search is very basic and first operation; if no duplicate is returned in search (using a proper complex search filter to filterout duplicated entries) then duplicate entries would not be searchable and VMM will only work on unique set of entries. It generally happens with admin entries from LDAP; And WAS has a native admin which's in File repository. Similar cases could be answered by SearchFilters.
   • Map the loginProperties to a unique attribute in AD.
     Many times one need to have duplicated set of entries (generally 2 different domains) who contain SAME entries; which blocks login operation on WAS. In such cases, it is suggested to map login property on a very unique attribute from LDAP. Generally it is userPrincipalName(UPN); UPN's are composed of <domainName>/<userId>
     Inclusion of domainName make them unique.
     Solution is to map uid/cn (generally used as login properties) to map on userPrincipalName instead of samAccountName.
     Steps :
     1. deleteIdMgrLDAPAttr (delete UPN occurances for PersonAccount as well group)
     2. addIdMgrLDAPAttr (map UPN to either uid/cn for PersonAccount as well group)
     3. updateIdMgrLDAPRepository (set uid;cn as loginProperties) (optional.. It's by default set to uid;cn)