Determining user's groups from Windows image
I received a question from a member of another list, and I'm trying to nail this down…
The question was, given an image of a Windows machine, how does one determine the groups that a particular user belongs to?
I started looking at the SID, but the documentation isn't definitive. I ran a quick test (accessed one of the user accounts on my system and added it to another group), but didn't find anything definitive.
Any thoughts on this would be appreciated.
Just a thought…..
1) Decompress a copy of the image (leaving original intact of course) to a hard drive.
2) Logon as administrator after resetting the password via ERD or any other util.
3) From run line, type lusrmgr.msc. This management console will give you a list of users and their respective group memberships.
4) Document everything including screen shots.
How would you get this information in EnCase, FTK etc. by merely mounting the image? Or Registry viewer? Hmmmm…
Yeah, not sure on how to extract it from an image. That information is stored somewhere in the AD or SAM database, depending on the version.
If you could fire up the image there is code floating around the net that extracts group membership information from the AD using the userInfo.Properties("MemberOf") syntax.
arashiryu suggestion is probably easier.
Good suggestion, but what if that's not possible?
> How would you get this information in EnCase, FTK etc. by merely mounting the image? Or Registry viewer? Hmmmm…
That's the question…
You may try this. I'd need to confirm it but I expect that you'll be able to do so for me.
On my XP box it would appear to contain the correct information.
Interesting…I don't have the "Group Policy" key on my systems at all.
My systems are all standalone.
strange, so is mine / It's on my laptop as well.
I'm beginning to suspect it's due to local security policies being enabled…
The key also exists in HKLM.
The information is also within the SAM hive. I can dig around for it as it is stored in hex and requires translation.
This should help though
I would have to pull Brian Carriers book off the shelf…but is it possible this type of info could be contained in the security descriptor attribute of the file records in the MFT …?
My response was in for a windows workstation not joined to a windows domain and for a local user account.
I don't believe you can use admin pack for server 2000/2003 and the group policy console on windows xp home edition. To run active directory console and group policy console the minimum requirement is a Windows XP Pro workstation joined to a windows domain. You can download tweakui and unlock portion of the windows registry to turn home edition to pro edition. it is cumbersome though from what I have experienced.
This is what I recommend.
1) Create a Server 2000/2003 VM. Designate is as a primary domain controller. Install admin pack for server 2000/2003 and the group policy management console.
Admin pack can be downloaded from
GPMC with sp1 can be downloaded from
2) Create a user account using active directory console. This account will be used to logon to the domain from a windows xp pro workstation. This user account is a member of the domain users group only by default so far.
3) Create some domain global (security) groups using active directory console for testing later.
4) Create a windows xp pro VM. Join it to the domain. Workstation account will be created on/by the domain controller automatically. Reboot.
5) Logon using the domain user account created in step 1. After logon process is completed, record registry settings. Logoff.
6) Jump back on the domain controller and make the user account member of a domain global group created in step 1.
7) Jump back to the xp pro workstation and logon. After logon is complete, record registry changes.
8) Compare the registry changes from step 5 and step 7 and get a delta.
6) Mine this delta for information that changed after the user account is made a member of a additional or new global group. Hope something changed….
Its too bad that I purged my Virtual Machines at the end of the year. One of them would have been perfect for this scenario. We just implemented ESX server and I have requested some slices (space on esx server) since I am migrating our test lab to ESX server. Once that is complete, I plan to test this out. Don't know when I will get my slices . Hopefully soon.
The access token/security descriptor is maintained in the file system. That tells you which groups can and cannot access the file/object. However, that doesn't tell you to which groups a particular user belongs.
I checked my work computer this morning, which is part of a domain, and I have the Registry key you mentioned.
However, all of the entries are SIDs.
I'll keep the key in mind, and add it to my list, though…it could be useful in other scenarios.
From what I see under the key hogfly mention (i'm on a domain
using windows xp pro) my groupmembership key contains
a unique SID for each of the twenty group entries (numbered 0-19).
I assume some are local groups that xp comes bundled with such as
power users, debugger user and helpservices groups (i have 9 local).
The rest I would guess, but can't be sure are SID's for the domain related groups…
With access to the domain controller that the windows image normally
logged on to you could probably get the "names" of the groups if need be.
Unfortunately I can't go poking around too much but if the above is correct then the SID in essence is the group…?
I checked my Xp Pro workstation and found registry entries mentioned by hogfly.
I grabbed one of the SIDs and resolved it by a utility called SidToName. It is a command line util.
The SID was resolved to a group name.
Sidtoname can be downloaded from
There is a list of well known sids published as part of the microsoft windows security resource kit.
A list of them is here
It also appears that accessdata reg viewer will do the group SID translation for you if you load the SAM hive. Can others test this?
The tool you mention uses a publicly available API to get the information from a live system…which, while useful in some ways, doesn't really answer my question.
I'll see what I can do on my end…