Configuring OpenLDAP as a Active Directory Proxy

Question

We try to set up an Active Directory server for company-wide authentication.

Some of the servers that should authenticate against the AD are placed in a DMZ, so we thought of using a LDAP-server as a proxy, so that only 1 server in the DMZ has to connect to the LAN where the AD-server is placed).

With some googling it was no problem to configure the slapd (see slapd.conf below) and it seemed to work when using the ldapsearch tool, so we tried to use it in apache2 htaccess to authenticate the user over the LDAP-proxy.

And here comes the problem: We found out the username in the AD is stored in the attribute 'sAMAccountName' so we configured it in .htaccess (see below) but the login didn't work.

In the syslog we found out that the filter for the ldapsearch was not (like it should be) '(&(objectClass=*)(sAMAccountName=authtest01))' but '(&(objectClass=*)(?=undefined))' which we found out is slapd's way to show that the attribute do not exists or the value is syntactically wrong for this attribute.

We thought of a missing schema and found the microsoft.schema (and the .std / .ext ones of it) and tried to include them in the slapd.conf. Which does not work. We found no working schemata so we just picked out the part about the sAMAccountName and build a microsoft.minimal.schema (see below) that we included. Now we get the more precise log in the syslog:

Jun 16 13:32:04 breauthsrv01 slapd[21229]: get_ava: illegal value for attributeType sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH base="ou=xxx,dc=int,dc=xxx,dc=de" scope=2 deref=3 filter="(&(objectClass=\*)(?sAMAccountName=authtest01))"
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH attr=sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Using our Apache htaccess directly with the AD via LDAP works though. Anyone got a working setup? Thanks for any help in advance:

slapd.conf:

allow bind_v2
include         /etc/ldap/schema/core.schema
...
include         /etc/ldap/schema/microsoft.minimal.schema
...
backend         ldap
database        ldap

suffix "ou=xxx,dc=int,dc=xxx,dc=de"
uri "ldap://80.156.177.161:389"
acl-bind bindmethod=simple binddn="CN=authtest01,ou=GPO-Test,ou=xxx,dc=int,dc=xxx,dc=de" credentials=xxxxx

.htaccess:

AuthBasicProvider ldap
AuthType basic
AuthName "AuthTest"
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?sAMAccountName?sub"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN  CN=authtest02,OU=GPO-Test,OU=xxx,DC=int,DC=xxx,DC=de
AuthLDAPBindPassword test123
Require valid-user

microsoft.minimal.schema:

attributetype ( 1.2.840.113556.1.4.221
      NAME 'sAMAccountName'
      SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
      SINGLE-VALUE )

Answer 1

You need to add mappings to your slapd.conf file:

moduleload rwm
...
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixGroup group 
rwm-map objectClass posixAccount person
rwm-map objectClass memberUid member

Then you can search for the uid attribute instead of the sAMAccountName attribute in your .htaccess file:

AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"

Answer 2

You're seeing this error message:

get_ava: illegal value for attributeType sAMAccountName

Which is caused by your definition of the sAMAccountName attribute in microsoft.minimal.schema lacking a matching rule. Simply put, OpenLDAP's schema definitions allow you say what kind of searches are allowed (presence, exact match, substring match, etc), and this definition has none.

Try this:

 attributetype ( 1.2.840.113556.1.4.221
   NAME 'sAMAccountName'
   EQUALITY caseIgnoreMatch
   SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
   SINGLE-VALUE )

Answer 3

Jonathan's answer pointed me in the right direction, getting me over the:

additional info: sAMAccountName: attribute type undefined

problem. But I realized that you need to define this attribute as a legal value for a person's entry, and you need to give each person the objectClass which is allowed to have that attribute. Just like all the attributes you can give an inetOrgPerson.

My microsoft.minimal.schema file is now:

` attributetype ( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )

attributetype ( 1.2.840.113556.1.4.146 NAME 'objectSid' SYNTAX '1.3.6.1.4.1.1466.115.121.1.40' SINGLE-VALUE )

objectclass ( 1.2.840.113556.1.5.6 NAME 'securityPrincipal' SUP top AUXILIARY MUST (objectSid $ sAMAccountName ) MAY () )

# MAY (nTSecurityDescriptor $ securityIdentifier $ supplementalCredentials $ # rid $ sAMAccountType $ sIDHistory $ altSecurityIdentities $ tokenGroups $ # tokenGroupsNoGCAcceptable $ accountNameHistory $ # tokenGroupsGlobalAndUniversal))

`

I'm replacing the MS-optional attributes with nothing so I don't have to define them.

An example user entry is like:

dn: uid=user2,ou=example,dc=aa,dc=ad,dc=example,dc=gov
uid: user2
sAMAccountName: user2
objectSid: user2
cn: User Two
displayName: User Two
givenName: User2
sn: One
objectClass: inetOrgPerson
objectClass: securityPrincipal
mail: user2@example.gov
# password from slappasswd is 'user2'
userPassword: {SSHA}sjB5fmIIPTrUUammtmonP+6DdC93+P4L