Today we ran into the following problem at a customer of ours: a couple of security groups had been setup in Microsoft Active Directory (AD), containing users from a trusted domain. Unfortunately, these users were not visible for our My webMethods Server (MWS) that is linked to AD using an LDAP Directory Service. When we checked the Group Members for the group in the MWS User Management Groups portlet, the group members were not visible.
When looking a bit deeper into this problem, we discovered a number of possible causes for this problem.
First of all we discovered that the members of these groups, being users of the trusted domain, were located in a branch of the directory that was not located under the base DN that we configured for the corresponding Directory Service in MWS. AD places the LDAP entries for these users in a top level container called ‘ForeignSecurityPrincipals’. The AD documentation on MSDN teaches us that in AD DS, each domain naming context (NC) contains a well-known Foreign Security Principals container. This container holds objects of class foreignSecurityPrincipal. These objects represent security principals from trusted domains external to the forest, and allow foreign security principals to become members of groups within the domain. This might already explain why MWS doesn’t show the group members, but there is more.
Even after correcting the base DN for the MWS Directory Service, the group members are still not visible in MWS. This is because the LDAP objects for these users in AD are based on different object classes than the standard user objects, more precisely the class 'foreignSecurityPrincipal'. We configured our MWS to identify LDAP users based on the 'person' object class, which contains attributes such as sAMAcountName (User ID), sn (Last Name), givenName (First Name), ... that are not present on the foreignSecurityPrincipal class by the way. Therefore of course, MWS will not recognize these objects as users which explains why we can’t see these group members in MWS. If you would like to troubleshoot the values of an LDAP object’s class or other attributes, a free LDAP browser client such as JXplorer can be of great help by the way.
So the conclusion is that MWS doesn’t support AD users from trusted domains through the LDAP Directory Service.
Author: Kristof Lievens
When looking a bit deeper into this problem, we discovered a number of possible causes for this problem.
First of all we discovered that the members of these groups, being users of the trusted domain, were located in a branch of the directory that was not located under the base DN that we configured for the corresponding Directory Service in MWS. AD places the LDAP entries for these users in a top level container called ‘ForeignSecurityPrincipals’. The AD documentation on MSDN teaches us that in AD DS, each domain naming context (NC) contains a well-known Foreign Security Principals container. This container holds objects of class foreignSecurityPrincipal. These objects represent security principals from trusted domains external to the forest, and allow foreign security principals to become members of groups within the domain. This might already explain why MWS doesn’t show the group members, but there is more.
Even after correcting the base DN for the MWS Directory Service, the group members are still not visible in MWS. This is because the LDAP objects for these users in AD are based on different object classes than the standard user objects, more precisely the class 'foreignSecurityPrincipal'. We configured our MWS to identify LDAP users based on the 'person' object class, which contains attributes such as sAMAcountName (User ID), sn (Last Name), givenName (First Name), ... that are not present on the foreignSecurityPrincipal class by the way. Therefore of course, MWS will not recognize these objects as users which explains why we can’t see these group members in MWS. If you would like to troubleshoot the values of an LDAP object’s class or other attributes, a free LDAP browser client such as JXplorer can be of great help by the way.
So the conclusion is that MWS doesn’t support AD users from trusted domains through the LDAP Directory Service.
Author: Kristof Lievens
No comments:
Post a Comment