Using ldapsearch to get AD data

It has been common for Macs to be bound to Active Directory for a variety of reasons.  Recently, the trend has been to move away from binding due to password/lock out issues, the rise of cloud based services, and SSO options that are more comprehensive of the services users need.

With the move away from binding, one thing we lose is the ability to look up user and group data with dscl. Here is a decent primer on dscl: (just replace every instance of netinfo with dslocal in your mind).

With this move we need another tool to query for information and ldapsearch can do this for us.  There are a lot of ways to use ldapsearch depending on your end goal.  This post will discuss getting user data out of an Active Directory server.  In a future post I hope to explain how I am using this to mount the appropriate file shares for users based on their group membership.

The basic format for ldapsearch is to tell it where to search, with what account to search, what to search for, and what data to return from any matches.  A common search I use is:

ldapsearch -LLL -H "ldap://${adURL}" -b "${searchbase}" "(&(objectCategory=Person)(objectClass=User)(sAMAccountName=$endUser))" memberOf

We start with the command, of course.  Then the -LLL tells the command to limit the output.  I find this gives less output to clean out before I get what I want.  The man page says:

-L     Search  results  are  display in LDAP Data Interchange Format detailed in ldif(5).  A single -L restricts the output to LDIFv1. A second -L disables comments.  A third -L disables printing of the LDIF version.  The defaultis to use an extended version of LDIF.

Then we need to tell ldapsearch where to search.  There are a few parts to this.  The first is the -H option with an ldapuri which will often be the DNS name of the domain controller you want to search on in the form “ldap://”.  (This can generally be found with host -t SRV  If you have multiple DCs, you can search more than one, but I normally pick a close one to search.  Then -b specifies the search base to start the search from.  I use the root of the LDAP structure, but if you know where your data is going to be you can be more specific.  This will be in the form "dc=my,dc=domain,dc=com" or "OU=Computers,dc=my,dc=domain,dc=com".

Next we need to tell ldapsearch who to search as.  In my command above, I don’t make it explicit, but the default is to check for a kerberos ticket granting ticket and use that for authentication.  This works nicely for scripting since there is no password to worry about, but you do need to be sure there will be a TGT when the script/command runs.  Another form of ldapsearch command would be:

ldapsearch -LLL -x -H "ldaps://$adURL" -D "${techNameTest}" -w "$techPW" -b "${searchbase}" "(&(objectCategory=Person)(objectClass=User)(sAMAccountName=$endUser))" memberOf

In this search we first tell ldapsearch to use simple (username/password) authentication with the -x option.  Then specify who to search as with -D and the full form should be "user@domain" or "domain\user".  Then the -w is used to put the password inline with the command.  If there are special characters in the password be sure to wrap it in single quotes; 'pa$$W0rd!'.  For one off searches, you can use -W to have the command prompt for the password.  Also note,when using password base authentication, we should really use ldaps:// in the -H option.  Otherwise the password will be sent across the network in the clear.Screen Shot 2016-09-22 at 10.46.17 AM.pngWith kerberos authentication the password is not sent across the network at all.

Next we specify what to search for.  In this case I am searching for a user’s account, but it could be in many different locations.  We can string filters together using the “(&(filter)(filter)(filter)…)” format.  The filters can include a wide range of things.  I am limiting the search based on objectCategory=Person, objectClass=User, and sAMAccountName=first.last.  It turns out I can get away with just using the sAMAccountName if I know exactly who I am looking for.  If we only need one filter, we can use the form “(filter)”, i.e. "(sAMAccountName=first.last)".

Lastly we tell ldapsearch what data we want back.  This is optional if you want the entire record, but if we just need one piece it is very useful to get that one thing returned.  In this case I am requesting just the memberOf values from the account.  This will tell me the groups this user is a member of.

If we put this all together we can get something like this (note you can limit the output further with 2>/dev/null , which will redirect the authentication messages which are sent to stderr):

$ldapsearch -LLL -H "ldap://" -b "dc=my,dc=domain,dc=com" "(sAMAccountName=last)" memberOf

SASL/GSSAPI authentication started
SASL username:
SASL data security layer installed.

memberOf: CN=AM IT Infrastructure Group,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=AM AON IT,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=WebReports_ReadOnly,OU=Groups,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=IT - MaaS360 AM Compliance Block,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=AM MFA VPN,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=Configuration Management,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=IT - Lync Users in AM,OU=Distribution Lists,OU=Exchange,OU=US,DC=AM,DC=DOMAIN,DC=COM
memberOf: CN=IT - Cisco usCUCMCluster02 Users,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=L\#Contractor,OU=Groups,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=IT - Exchange 365 Users in AM,OU=Distribution Lists,OU=Exchange,OU=US,DC=MY,DC=DOMAIN,DC=COM
memberOf: CN=AON IT Contractors (US),OU=Distribution Lists,OU=Exchange,OU=US,DC=AM,DC=DOMAIN,DC=COM
memberOf: CN=Americas IT Consultants,OU=Distribution Lists,OU=Exchange,OU=US,DC=AM,DC=DOMAIN,DC=COM
# refldap://,DC=MY,DC=DOMAIN,DC=com





One thought on “Using ldapsearch to get AD data

  1. Pingback: Mounting File Shares Based on AD Group Membership using Enterprise Connect | My Thoughts

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s