Feature Request: reference membership by SID rather than RDN in output

[TheraNinjaCat]

For human readable output, it makes sense to output a human readable name for the membership, however when processing it programmatically, I believe there may be situations in which an RDN is not unique, for example if there are multiple domains, objects have the same relative name across domains, then it may not be clear which of the possible objects the original is a member of.

It would be easy to resolve the structure programmatically if there were an optional output flag that changed the behavior to output the items in the member_of field as the SID string instead of the RDN.

Another option would be relating to #4, where the full DN could be used, but I feel like that's both less human readable, and less useful for programmatically parsing the output.

[janstarke]

I could imagine that some people like to select one of those options you named. The CLI usage could be something like

• --member-of=sid or
• --member-of=rdn or
• --member-of=dn

[TheraNinjaCat]

Through my experimentation I'm finding that there are null-gaps in all of these except RDN, so they can't necessarily be used as a unique key all the time (i.e. an object may be a member of a group with a null SID when trying to use --member-of=sid, and would then include null in the member_of field, which is kinda useless). Potentially it would be a worthwhile allowing a mix of keys for the member_of entry, so maybe --member-of=sid,rdn (or --member-of=sid --member-of=rdn) would return member_of: [[sid, rdn], [sid, rdn], ...], which may help with identification from a messy domain file. Just an idea.

[TheraNinjaCat]

It has also occurred to me that another potentially useful identifier to include as an option would be sam_account_name.