Problem solve Get help with specific problems with your technologies, process and projects.

Using ADFind.exe when LDIFDE fails you

Different Active Directory tools are better suited for different situations. Expert Gary Olsen provides details for how using ADFind is sometimes better than LDIFDE when listing group SIDs in a domain.

Many organizations suffer from "group bloat," which is the continuous addition and expansion of groups without appropriate cleanup. Over time, groups for specific projects or applications that are no longer used are usually ignored rather than deleted. This is not only inefficient, but also a security risk because it leaves you unaware of users with access rights to resources.

When figuring out if you need to clean up groups, look for things like the existence of unresolved security identifiers (SIDs) appearing in places such as Group Policy listings when assigning permissions to resources. Since these groups are only identified by a SID, you would have to look at each group individually using a tool like LDP.exe to see the SID and compare it to what you are looking for. It is important to know which SID goes to which group to avoid deleting valid groups.

What would be nice would be to get a list of all the groups and their SIDs that one could then import to a spreadsheet.

When I recently encountered this issue, my first instinct was to use LDIFDE. However, further research led to my discovery of a freeware tool called ADFind, which eventually solved the problem.

Why LDIFDE doesn't work

The SID for the group object is held in the objectSid attribute. I thought I could expose the SID by using the LDIFDE.exe tool to dump the objectSid attribute. Using the following LDIFDE command produced the following output. Note that the command uses the LDAP filter –l to list just the objectSid attribute.

C:\>ldifde -f groups.ldf -s wtec-dc1 -d
" -r "(objectClass=group)" –l objectSid

dn: CN=IIS_WPG,CN=Users,DC=Wtec,DC=adapps,DC=hp,DC=com
changetype: add
objectSid:: AQUAAAAAAAUVAAAA1er4ABpA+wnRw72u6AMAAA==

dn: CN=Domain Computers,CN=Users,DC=Wtec,DC=adapps,DC=hp,DC=com
changetype: add
objectSid:: AQUAAAAAAAUVAAAA1er4ABpA+wnRw72uAwIAAA==

dn: CN=Domain Controllers,CN=Users,DC=Wtec,DC=adapps,DC=hp,DC=com
changetype: add

It's a nice neat list, but the objectSid value is garbage. I needed a way to convert that output to show the real SID -- or some other way to get the attribute. The LDP tool showed the actual SID, but it won't generate a nice list to evaluate.

ADFind to the rescue

At this point, I tried ADFind, a very useful tool written by Active Directory guru Joe Richards. Using ADFind and a few switches, I made a nice list of all of the groups with their associated SIDs in a readable format.

The command I used in my test domain,, was:

C:\ >adfind -b dc=hpqbox,dc=adapps,dc=hp,dc=com -f "objectClass=group" objectSid
SAMAccountName >groupSids.txt


-b is the basedn
-f is the filter (objectClass)
objectSid SAMAccountName (list of attributes to be       returned -- similar to the –l option in ldifde, but the       separator is a space between attributes
Then we just output it to GroupSids.txt

The output, shown here, is a brief listing showing the domain name of the group, the objectSid value in a format that makes sense and the sAMAccountName of the group, which helped us associate the SID with the group name. Note that you can add the objectGUID attribute to the attribute list in this command to resolve the objectGUID as well.

dn:CN=Exchange Server Administrators (HPQBOX-
>objectSid: S-1-5-21-941844873-3308431943-965420583-1240
>sAMAccountName: Exchange Server Administrators (HPQBOX-ES01)

dn:CN=Network Configuration Operators,CN=Builtin,DC=hpqbox,DC=adapps,DC=hp,DC=com
>objectSid: S-1-5-32-556
>sAMAccountName: Network Configuration Operators

dn:CN=Performance Monitor Users,CN=Builtin,DC=hpqbox,DC=adapps,DC=hp,DC=com
>objectSid: S-1-5-32-558
>sAMAccountName: Performance Monitor Users

dn:CN=Performance Log Users,CN=Builtin,DC=hpqbox,DC=adapps,DC=hp,DC=com
>objectSid: S-1-5-32-559
>sAMAccountName: Performance Log Users

Adding an additional option of –resolveSids to the ADFind command will result in the common name of the objectSid being displayed rather than the actual SID. Thus, the command would look like this:

C:\ >adfind -b dc=hpqbox,dc=adapps,dc=hp,dc=com -f "objectClass=group" objectGuid
objectSid SAMAccountName -resolvesids >groupSids.txt

Notice that the objectGUID has been added to the attribute list in this command, as well as the –resolvesids option. The output for a typical object, shown here, shows the objectSid in a friendly domain/group format as opposed to the SAMAccountName that does not resolve the domain part of the SID. The objectGUID is also displayed in a readable format.

dn:CN=Exchange Server Administrators (HPQBOX-ES01), CN=Users,DC=hpqbox,

tt>>objectGUID: {1F7DAB0E-2633-40B5-9EF0-ED49BEEBC225}
>objectSid: HPQBOX\Exchange Server Administrators (HPQBOX-ES01)
>sAMAccountName: Exchange Server Administrators (HPQBOX-ES01)

ADFind is a valuable tool that you should have in your AD toolbox. I highly recommend visiting to check out ADFind and to review Joe's other tools. They are very powerful and you can't beat the price. In future articles, I will highlight other important ADFind features and applications.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.

Dig Deeper on Windows administration tools