When resolving AD Groups within K2, Group Resolution will "break" if one of those AD Groups contain a leading space, or a trailing space.

You cannot create AD Groups with leading or trailing spaces, when using the Active Directory Users and Computers (ADUC). When using ADUC, leading and trailing spaces will get stripped upon saving the Group. You can only create AD Groups with leading and trailing spaces, using script or code. 


From a K2 perspective, it will appear as if the users get removed from their "other" AD Groups ("Regular" groups, that do not contain leading, or trailing spaces) during Group Resolution. During this time, the users belonging to "other" AD Groups, will not get work items where the user's groups are used as a destination. After the "other" groups get resolved, the user would get added back to those groups in K2, and then they will get work items assigned to that group. This will result in users sometimes getting work items, and other times not.

From an AD perspective, users will remain in their groups. You will not be able to find AD Groups with leading and trailing spaces within Active Directory by default. You will have to set a specific filter in Active Directory before you will get return results that contain leading or trailing spaces. 


The Active Directory Users and Computers (ADUC), search dialog strips' leading spaces when searching or filtering. You will have to set filter options within ADUC, to find those groups. The leading space can be in the Relative Distinguished Name (RDN) of the object, in the sAMAccountName (the "pre-Windows 2000" name), or both.

For example, select Filter Options on the View menu of ADUC in an attempt to find a user whose Name starts with a leading space:

Next, click on the Create custom radio button and then the Customize... button:

Then click on the Advanced tab:

And finally, enter an LDAP filter and click OK. In this case, filter on all users where the sAMAccountName starts with a space character. LDAP recognizes the two-character ASCII hexadecimal equivalent of the space character, which is "20", but it must be escaped with the backslash escape character. No other dialog in ADUC recognizes this. The "*" character is the wildcard character. So, our LDAP syntax filter is (sAMAccountName=\20*). A similar LDAP syntax filter can be used to find users where the Name (the value of the cn or Name attribute) begins with a space. Then the LDAP syntax filter would be (Name=\20*).

After you click the "OK" button, only the objects that match the LDAP syntax filter appear in the ADUC. But you still must look into each OU and container to find them.

Next search for " fred" (notice the leading space) to find users with that string in the name and click "Check Names". There is no option to enter an LDAP syntax filter, and this dialog does not recognize "\20". Notice also, that we must know something about the user beside the fact that the RDN begins with a space. If we just enter the space character, it gets stripped off and nothing results.

The result when you click "Check Names" is that all users where the RDN either starts with "fred" (without the leading space), or where the string " fred" (with the leading space) appears anywhere in the RDN. The object we want is found, but so are several others. The results are exactly the same if we query with the string "fred", with no leading space.

We were able to find the group that was using a leading (Or trailing) space, using the above method, found in the following Microsoft article:

Once we removed the user from the group that contained the leading space, K2 was able to resolve all the user's groups successfully.