It surprises me but this is still a pretty popular question I get in email. I realize that the usage help for adfind and admod are substantial, but the info on this is in the basic help…
Anyway, I got another email on this and decided I would blog it.
The basic format of AdFind is fairly simple as it is at its core simply a wrapper around the LDAP API. Sure it does some extra decoding that is specific to AD, but it is still a basic LDAP API wrapper and as such functions like many other LDAP tools.
For any LDAP query you need to specify the host, scope, searchbase, filter, credentials, and attributes you want to have returned.
By default if you don’t specify a host, AdFind uses the default DC for the machine you are on. If the machine is not joined to a domain or is joined to an NT4 domain, this is obviously not going to work very well and you will need to specify a machine or possibly a domain name. If you are attempting to connect to ADAM, there is no such default, you need to specify the host directly.
By default if you don’t specify a scope, AdFind uses SUBTREE. The exception is if you are piping DN’s into AdFind, then it will default to a search base of BASE. Yes I know that is a bit annoying, it was a bit annoying also defaulting to SUBTREE in that situation as well, I had no good answer for what it should do but BASE seemed to be the best.
By default if you don’t specify a search base, AdFind uses the default NC of the host specified (or default host if no host specified).
By default if you don’t specify a filter, AdFind uses objectclass=*. This means return every object that you have permissions to see.
By default if you don’t specify credentials, AdFind uses the credentials of the process that spawned it. So if I am logged on as joe and open a command prompt and run AdFind without –u xxx, it will use my joe credentials to connect (or fail). If I am logged on as as joe, but open a command prompt as $joe (via runas or cpau) and run AdFind without –u xxx, it will use my $joe credentials to connect.
By default if you don’t specify a list of attributes, it uses * which tells Active Directory to return the default attribute set. Note that this doesn’t necessarily mean return every attribute that is populated on the object, in fact, by default nTSecurityDescriptor isn’t returned unless you explicitly ask for it. Also constructed attributes aren’t returned if you don’t explicitly request them as well. If you want specific attributes, you specify them as a space delimited list on the command line… attrib1 attrib2 attrib3, etc.
The exception to all of the above is that if you don’t specify anything it will display the basic usage help.
Here is an example command to use the user’s cn (or name) attribute to find their NT Style userid (i.e. sAMAccountName).
adfind -gcb -f name=”somename” samaccountname
This is a pretty basic command and here is the breakdown…
* No host is specified so it will use the default DC for the machine running the command.
* No scope is specified so it will be SUBTREE scope.
* The search base is provided in the –gcb switch, which tells it both to use the Global Catalog port and to use a NULL Base for the query – I.E. Look at the whole directory.
* The filter is name=”somename” which should be self explanatory.
* No credentials are specified so whatever credentials are in effect for the command prompt window running this command are also in effect for the connection to AD.
* There is an attribute list provided and it contains a single value – samaccountname so that will be the only attribute returned.
joe
