Samba authentication against Active Directory via LDAP

As usual, samba only accepts usernames that also exist in the unix password database (/etc/passwd) . It is also necessary to have a dedicated "bind user" account as mentioned in my previous post. The following are the samba options that need to be tweaked.

[global]
security = SERVER
obey pam restrictions = Yes
password server = name_or_ip # not sure if really needed
passdb backend = ldapsam:ldap://name_or_ip
passwd program = /usr/bin/passwd %u
log level = 3 passdb:10 auth:10 winbind:2 # set to zero if it works
domain master = No
ldap admin dn = user@domain.com
ldap group suffix = OU=company,DC=domain,DC=com
ldap suffix = DC=domain,DC=com
ldap ssl = no
ldap user suffix = OU=company,DC=domain,DC=com

If you find some redundancy you can keep it if you tell me where you found it.


HTTP authentication against Active Directory via LDAP with apache2

Used on the "free" (as in beer) side:
The LDAP server that is to be queried here will be Microsoft's Active Directory (AD). AD has a particularity: To make a query to AD one needs to authenticate with AD first (this is called bind). Therefore it is necessary to create a user within AD with restricted rights (in particular, this user must not be able to log in or do anything serious) that is used to bind to AD prior to check the name/pw combination that is supplied via the http authentication. Let this user be called
specialuser
with the password
specialpassword
and the domain that is considered is called
domain.com
while the users are stored in the organisational unit (OU)
company
then the apache2 configuration might look as follows:
<location>
AuthType Basic
order allow,deny
allow from all
AuthName "Example apache2 LDAP auth with Active Directory on domain.com"
AuthLDAPURL ldap://name_or_ip:389/OU=company,DC=domain,DC=com?sAMAccountName?sub?(objectClass=user)
AuthLDAPBindDN "specialuser@domain.com"
AuthLDAPBindPassword specialpassword
require valid-user
</location>
Keep in mind that the special bind user can introduce a security risk if not properly restricted!


This page is powered by Blogger. Isn't yours?