crowbar27
commented
4 months ago TBH, I am not sure whether I fully understood your problem, but the fact that it mentions "primary group" raised a red alert for me, which I will explain shortly. However, could you provide me with a test case (sample JSON, sample user names like "user1" and groups like "primarygroup", "group1", etc.) to repro this?
I think, however, that this relates to an issue that took me two years to figure out and which is handled wrong by most software, including Microsoft Exchange. The problem is that the primary group is not a "normal group" stored in a list of DNs, but the primary group is in a special field, so if you query the groups of an object, you get all groups except for the primary group. This holds for ADDS as well as OpenLDAP, but ADDS is particularly nasty in that it stores the RID, which is the SID stripped of the domain identifier. You have probably asked why I am working with the SIDs and not just use the DNs of the groups an this is the reason why: In order to get the primary group, I retrieve the RID, concatenate it with the domain SID to obtain the group SID (that is what the converter of the mapping attribute does) and then query the group with that SID.
I think that the hack I gave you in the other ticket will not work for the primary group and I also think that there is no workaround for this at the moment. This issue will need some significant re-implementation, I fear.
Affected library
Environment
Summary In
LdapUserBasethe primary group is always added asGroupSidclaim using the value of thePrimaryGroupAttribute. However, all other groups are added by applying the converter to the specifiedGroupIdentityAttribute.What are you doing? Trying to use
sAMAccountNameasGroupIdentityAttributeby specifying aMappingonLdapOptions.What is the problem? Primary group is never added with it's
sAMAccountName.What behaviour did you expect? Primary group is added through it's
sAMAccountName.Additional context Solution based on comments in #13.