Recently I’ve been working on using the Metacoda Identity Sync Plug-in to synchronize SAS platform identities (users and groups) with their counterparts from multiple Microsoft Active Directory (AD) Domains contained within a single Forest. In a future post I’ll talk about extending this to multiple domains from multiple trusted forests.
In the recent Metacoda Plug-ins 5.0 R5 release there have been a few enhancements to make it easier to sync with multiple domains (and avoid using custom code hooks):
- Members of “Included Groups” are followed into other domains within the same forest.
- You can opt to prefix the SAS User and Group names with the NetBIOS domain name. You might choose to do this if you have any users or groups in different domains with the same sAMAccountName and want to avoid non-unique user/group name validation errors when they get to the SAS platform.
- There are more user login options available to help appropriately qualify the inbound login for the SAS user using the domain of the Active Directory user.
I’ll show a relatively simple example. This might help other people who need to sync SAS users from multiple AD domains. The diagram below summarizes the Active Directory deployment:
- There are two AD domains within a single AD forest: one domain for Australia (with NetBIOS name AU) and one domain for Europe (with NetBIOS name EU).
- The AD group design follows the well known AGUDLP model (Accounts, Global groups, Universal groups, Domain Local groups, Permissions). AGDLP would be simpler for this single forest example, but I plan to extend the example to multi-forest in a future post. You may also find these group design practices referred to as IGUDLA or IGDLA (Identites, Global groups, Universal groups, Domain Local groups, Access)
- The EU domain has a Finance group with Global scope containing the users Robert and Una as members.
- The AU domain has a Finance group with Global scope containing the users Alice, Bob, and Hannah as members.
- A Finance group with Universal scope contains both the AU and EU Global Finance groups as members.
- A Finance group with Domain Local scope in the AU domain contains the Universal Finance group as a single member (at this stage).
- The Metacoda Identity Sync Plug-in will be pointed at the AU domain with only a single AD “Included Group” – the Domain Local Finance group. You can have multiple included groups, but in this example we only need one. All of the other required users and groups, across both domains, will be found because of their direct or indirect membership of that Domain Local group. The management of who becomes a SAS user is done entirely in AD by domain admins. The SAS platform administrators concentrate on the management of the users access to SAS platform resources (and not on user management).
The Metacoda Identity Sync Plug-in is configured by building an Identity Sync Profile (IDSP) using the Identity Sync Profile Wizard. The next few screenshots show some of the key steps to consider when sourcing users from multiple AD domains. Using the example above, we would choose a Group Sync Basis of Included Groups and select the Finance (Domain Local) group as a single target group (all of its members, at any level of nesting, will then become targets for synchronisation with SAS metadata):
When configuring the SAS group name for multiple AD domains, you will want to choose an AD attribute that is known to be unique across all the target domains. If you follow practices in AD to ensure sAMAccountName is unique across all domains you might choose that. If you think sAMAccountName might not be unique across all domains (it doesn’t have to be) then you might choose the alternative pseudo-attribute sAMAccountNameWithDomain. sAMAccountNameWithDomain is a new choice we added in Metacoda Plug-ins 5.0 R5 to prefix the sAMAccountName value with the NetBIOS name of the domain the object was sourced from. For example if the two global Finance groups in the AU and EU domains both had a sAMAccountName value of Finance, then their sAMAccountNameWithDomain values would be AU_Finance and EU_Finance. This would allow the two AD groups to become 2 SAS groups with unique names and avoid non-unique name validation errors.
The same sAMAccountNameWithDomain pseudo-attribute is also available for naming SAS users if you think there is a possibility that users from different AD domains might have the same sAMAccountName.
Metacoda Plug-ins 5.0 R5 also includes a few additional attributes and pseudo-attributes to help with the population of inbound logins/accounts for synchronized SAS users for the various user logon styles that can be used with AD:
- sAMAccountName: This is the bare user logon name (e.g. demoalice, demouna). It might be used with a SAS Metadata Server on Linux or UNIX where the operating system is configured to authenticate against AD and not need a domain qualifier. For a SAS Metadata Server running on Windows the user logon name will need to be further qualified and so it is best to choose one of the other options available here.
- sAMAccountNameWithDomain: A pseudo-attribute that will automatically prefix the sAMAccountName with the NetBIOS name for the domain that contains the user (e.g. AU\demoalice, EU\demouna). This is now the default attribute for newly created Identity Sync Profiles.
- userPrincipalName: This is the explicit User Principal Name (UPN) as specified by a domain admin when the AD user is created (e.g. alice.adams@example.com, una.underwood@example.com). It is sometimes populated with the email address of a user to allow email style logins.
- userPrincipalNameImplicitFQDN: A pseudo-attribute for an implicit UPN that automatically suffixes the sAMAccountName with the fully qualified domain name for the domain that contains the user (e.g. demoalice@au.example.com, demouna@eu.example.com).
- userPrincipalNameImplicitNetBIOS: A pseudo-attribute for an implicit UPN that automatically suffixes the sAMAccountName with the NetBIOS name for the domain that contains the user (e.g. demoalice@AU, demouna@EU).
Having created an IDSP for the multi-domain example above, the first time we run it we will see a preview of the changes we can apply. The IDSP was configured to use the single Domain Local Finance group, and it has found all of its members across all of the domains within the forest. We see the four Finance groups for both domains (the Global, Universal and Domain Local groups):
We see the five users, across both domains, that are members of the two global Finance groups.
We see the group memberships for those users and groups replicating the AD memberships across both domains.
We also see the suitably qualified inbound logins for the SAS users. In this case using the sAMAccountNameWithDomain method.
I hope you’ve found this post useful. Please leave a comment and let me know if you have any questions or feedback based on your own experience of synchronizing SAS identities with multiple AD domains. If you’d like to find out more about our Metacoda Identity Sync Plug-in you can contact me or visit the Metacoda web site (where you can also request a free evaluation).