I am testing a Mattermost Enterprise Edition install and integrating with AD/LDAP. The ID Attribute in Mattermost is supposed to be set to a unique value that does not change, and the documentation recommends the objectGUID attribute for native AD (as opposed to LDAP).
ObjectGUID works fine as an attribute, however it doesn’t work as a non-changing value when implementing AD LDS and synchronizing the AD DS data. Without getting into the technical weeds, AD LDS can pull (using Adamsync) a portion of AD DS into a dedicated LDAP directory. But because AD LDS is its own LDAP directory and maintains its own object GUIDs, the original objectGUID values are moved to a new attribute (sourceObjectGUID) and the actual objectGUID attribute is a new GUID specific to AD LDS.
SID also makes sense in an AD environment as a unique, non-changing value, and it has the benefit of being more admin-friendly (compared to objectGUID) due to its format. I tried setting the ID Attribute in Mattermost to the SID attribute “objectSid” but then the corresponding field in the Users table in the database doesn’t populate. If I switch the attribute to something else (like userPrincipalName) or revert it back to objectGUID, then the database field populates properly, so it’s as if Mattermost can’t parse the SID attribute. Microsoft classifies the attribute syntax as a String(Sid) which is described as an octet string (String(Sid) syntax - Win32 apps | Microsoft Learn)
Does the AD/LDAP integration support the SID for the ID Attribute? If not, any possibility of supporting it in the future? (If nothing else, if SID isn’t supported, recommend adding a note to the documentation warning to not use the SID, to save others from extensive troubleshooting like what I went through.)