Configuring LDAP authentication to WolfTech
So you have an open-source or vendor product that you would like to have authenticate to WolfTech AD. Wonderous magic, you’re in the right place! This page is all about configuring an LDAP connector to our Active Directory deployment.
First things first, you will need to create a service account to serve as the “bind account” to query LDAP attributes about your users. Typically, LDAP connectors will use the individual’s credentials to authenticate and then use a separate “bind account” to retrieve LDAP attributes and group membership to determine authorization.
If you are going to do any sort of group-based authorization, you will need to request that your service account be added to the “NCSU-Read Group Memberships” group. This group has permissions to… read group memberships! Submit your request to activedirectory_policy@help.ncsu.edu.
Next, you’ll likely need to configure some information in whatever product you happen to have. Below is a listing of common information you should have handy while setting up your LDAP connector.
| Host | ldaps.wolftech.ad.ncsu.edu |
| Port | 636 |
| LDAPS | true (if applicable) |
| Base DN | DC=wolftech,DC=ad,DC=ncsu,DC=edu |
| Groups base DN | OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu |
The “Groups Base DN” you use is implementation-specific. The rule above will allow for ANY group in the “NCSU” OU to be used for authorization. That’s NOT to say that this controls who is authorized to your system. It’s just a “search path” of sorts; for groups. For example, if you only wanted to allow groups in your own OU, specify the DN to your OU.
Lastly, many implementations will offer to auto-create accounts linked to remote LDAP users and will do attribute mapping for common things like User Identity, Name and Email address. Here are the attributes you should use for these things:
| Username | sAMAccountName |
| First Name | givenName |
| Last Name | sn |
| Email Address |
For usernames, it is critically important to use sAMAccountName, which is guaranteed unique across the domain. If you follow directions from the internet and use an attribute like “uid”, then it is technically possible (though certainly punishable) to do nefarious things like create an account similar to your Unity ID but off by one character (e.g. Your account is “user1” and they create “user2”). The sAMAccountName for this user will be “user2”, but they can change their “uid” to “user1”.
Use sAMAccountName…
That’s all… if you run into anything not capture here, add it to the page or ping the #windows channel on https://ncstateit.slack.com.