The world's most trusted forum on Active Directory Security
Hello. I have been working on enumerating group memberships in Active Directory, and invariably one comes across member and memberOf, the former being an attribute on security group objects and the latter being an attribute on user and computer objects.
While it generally seems straight-forward, we notice some inconsistencies for our Builtin Groups, when we look at them on different DCs. I was wondering why this might be so.
Has anyone else on this forum noticed such inconsistencies as well, and if so, have you found any explanation for why these might be different on different DCs?
I would appreciate a simple explanation of member and memberOf work in Active Directory.
One day I too shall have an Aston Martin Mr. Bond!
The memberOf and member attributes are basically what is known as a linked-attribute pair. Each linked-attribute pair in Active Directory consists of a forward-link and a back-link.
A forward-link is one that can be modified, and a back-link is one that just points to the forward-link and cannot be modified.
In that regard, the "member" attribute on group objects is the forward-link, and the "memberOf" attributes on user/computer account objects is the back-link.
You cannot modify the "memberOf" attribute on a user/computer object. It is updated when the corresponding back-link "member" attribute changes. You can modify the "member" field, and when you do, the corresponding forward-link attribute automatically reflects the change.
As to the inconsistencies you may be seeing, you might be referring to seeing inconsistencies when enumerating the membership of Built-in groups on DCs belonging to different domains.
This is because the same Built-in groups exist in multiple domains, and while they have the same SIDs, their memberships differ, so if you're look on a DC in one domain, a Built-in group's members will be those that belong to that domain, and when you look at the builtin group with the same name in the another domain, its membership will be different and comprise of users from that domain.
Hope this helps.
“If you can't explain it simply, you don't understand it well enough” - Albert Einstein
Thank you for your detailed explanation. This does explain some of the inconsistencies we were seeing. I appreciate you taking the time to explain this.
I had another question for you - we were basically trying to enumerate all the Active Directory security groups a domain user account holder belongs to, when we encountered this problem.
So, do you happen to know of any easy way to enumerate all the Active Directory security groups a domaun user account might belongs to?
Thanks for your help!
Yes, in fact, I do, and I'll be happy to share with you what we're using, but before I did so, let me just say that there are many small intricacies when enumerating group memberships that a lot of admins simply aren't aware of, which is why it is very important to make sure that whatever you use to enumerate group memberships is giving you accurate results.
For example, did you know that most scripts cannot evaluate the membership of well-known SIDs like Everyone and Authenticated Users. Similarly, there are some group memberships like Domain Computers, which are generally evaluated dynamically (if you look in AD, you won't find a membership listed for this group), yet you can statically add a SID to this group's membership.
There are many such examples. One other common one is that most scripts written to enumerate group memberships will go into an infinite loop when they encounter circular nested groups.
In fact, there are many such small little intricacies that one needs to be aware of when enumerating group memberships. One of the consequences of these intricacies is that it becomes very difficult to actually write scripts that can take all these intricacies into account.
We learnt some of this the hard way, so now we don't try to use scripts to enumerate group memberships, but in fact, have invested in the most capable Active Directory group membership enumeration tool we found in our research - Gold Finger for AD.
We've been using it for quite some time now, and we're very happy with it. It has other capabilities as well, such as Permissions Analysis, an Effective Permissions Analyzer.
There are other tools as well, and the main test to see is whether they can enumerate well-known SIDs, enumerate dynamic group memberships (with an anomaly) and detect and avoid going into infinite loops with circular nested group memberships.
Whatever tool you end up deciding on, hopefully, my input will help you at least avoid the use of scripts, because scripts are just not going to account for every intricacy, and could easily end up giving you inaccurate results that you won't even be aware of.
Good luck Kasib. Let me know if you have any other questions.
As Guido indicated, memberOf and member attributes are a linked pair, with member being the forward-link and memberOf being the back-link. Only forward-links can be modified; the back-links are read-only and automatically updated by Active Directory when the value of the forward-link changes.
By the way, if you are looking for a way to enumerate all the groups to which a user belongs, or all the users that belong to a specific group, you may find this helpful.
Group membership enumeration seems straight-forward but can get complicated based on numerous factors such as group types, group scopes, different domains etc.
There isn't a system that cannot be broken into.