Howto Ldap Auth
External services that authenticate users often use Ldap for authentication.
Create a service account
Many, but not all, services require a user account and password to do authentication.
pwgen 64 to generate a password. Then create your user.
samba-tool user create ps1-sa-servicename
|Security||TLS or set useTLS to True||TLS is a non-port changing encryption setting. Do not deploy with this setting off or disabled.|
|BindDN||CN=ps1-sa-serviceaccount,CN=Users,DC=ad,DC=pumpingstationone,DC=org||This is the username that the ldapclient is going to bind to ldap with|
|BindDN password||xienaiK0ohchaCao7pohv9auw2ohgaixieReeY7ahngoo1uingu9Shaokohfiej7||The password for the service account you created earlier.|
|BaseDN||CN=Users,DC=ad,DC=pumpingstationone,DC=org||This is where the user list is filtered from.|
|uid or username||sAMAccountName||Our user's difinitive username is stored in the sAMAccountName Field on the ldap object.|
|filter||(userAccountControl:1.2.840.1135220.127.116.113:=2)|| Filters on not disabled account. Sometimes this needs to be preceded with a |
|Account Suffix||@PS1||When attempting to check password, the sAMAccountName needs the suffix appeneded to it.|
|ldap field that stores the user's email address|
|Minimum password length||1||AD lets users bind to ldap with 0 length passwords. It's fscked up, but accepted.|
- Depending on how the filter is applied, you may need to put a
!in front to negate it. The current format filters on users that are not disabled.
- You almost always want to get debug info for ldap when setting up. There are a lot of things that can go wrong.
- Start without the filter field, add it later.
- When a service checks a password, it usually attempts to bind to samba as that user. To bind successfully, it needs to bind as user@PS1
- Some services apply setting different e.g. as a regex on the user, or as a template setting.
- If you try and bind to ldap with a 0 length password, it "works", sort of. There is no error, but you can't access anything substantial. This is enough to fool services into thinking that the password was correct.
ldapsearch is a handy tool that is part of open ldap. You can query some handy information out of our ldap servers as follows if you have an account to bind with:
#list laser cutter certified: ldapsearch -ZZ -v -x -H ldap://bob.ad.pumpingstationone.org -b "DC=ad,DC=pumpingstationone,DC=org" -D "PS1\myuser" -W "CN=Laser Engraver Certified" #list domain Admins ldapsearch -ZZ -v -x -H ldap://bob.ad.pumpingstationone.org -b "CN=Users,DC=ad,DC=pumpingstationone,DC=org" -D "PS1\myuser" -W "CN=Domain Admins"
The following example is useful for making members-only sites and web apps
#Very important, Don't bind in cleartext. Can't be defined as part of your location or directory block, so make sure you don't skip it. LDAPTrustedMode TLS <Location/protected> AuthName "AD Authentication" AuthType Basic AuthUserFile /dev/null AuthBasicProvider ldap #LDAP-URI will be bob.ad.pumpingstationone.org for internal apps, space.pumpingstationone.org for external apps. AuthLDAPURL "ldap://[[LDAP-URI]/cn=Users,dc=ad,dc=pumpingstationone,dc=org?sAMAccountName?sub?(objectClass=*)" #You should generate a new account per authenticated service. Just create a new user on the DC. AuthLDAPBindDN cn=[SERVICE-ACCOUNT],cn=Users,dc=ad,dc=pumpingstationone,dc=org AuthLDAPBindPassword [SERVICE-ACCOUNT-PASSWORD] #Set require where appropriate, example shows "All valid users" and "Domain admins only" (commented out) #Require ldap-group cn=Domain Admins,cn=users,dc=ad,dc=pumpingstationone,dc=org Require valid-user </Location>