I have been attempting to configure openldap to act as a proxy for our
corporate Active Directory installation. The idea is, of course, that
users of linux workstations can use their AD credentials. While we are
also experimenting with AD integration using winbind, we also want the
option to use standard LDAP, as it means that the linux workstations do
not have to be joined to the Active Directory domain.
Many previous posts on this forum have been most helpful, (as have posts
to the openldap-software list), and I have our setup working, but there
is one strange problem. I prefer that our linux workstations can connect
to the openldap anonymously, as it means we do not have to have
credentials stored in /etc/ldap.conf. This should not be a problem
as our openldap proxy can have credentials stored for connecting
to the AD server.
But what I find is that when I start the slapd, none of the linux
workstations can connect until I first issue a query to the slapd using
1. Start slapd
2. Linux workstations cannot bind anonymously
3. Issue query against slapd
/usr/bin/ldapsearch -H ldap://localhost \
-D "cn=someuser,ou=Accounts,dc=example,dc=com" \
-w "secret" -x -s base "(objectclass=*)" namingContext
4. Linux workstations can now bind anonymously
Although there is the obvious work-around that after starting the slapd,
we issue the query above, I would kind of like to know why this is
happening. Maybe there is a better way?
I am using openldap 2.4.16, with ldap and bdb backends, and all overlays.
Operating system is CentOS 5.
Any pointers on how to improve my config would be most welcome.
==== BEGIN slapd.conf ====
# Not sure why, but when this is not set, the JDK LDAP browser
# will not connect anonymously about one time in four.
# If this is not set, the user cannot connect anonymously.
# The first connection must be bound, but subsequent connections can
# be anonymous. (More investigation required)
# Because posixAccount does not exist in the Active Directory schema, we need
# to map to an objectclass that does exist. We could use user, but at this
# time we don't have a schema for the AD 'user' objectclass. It just happens
# that organizationalPerson is defined in our AD.
rwm-map objectclass posixAccount organizationalPerson
rwm-map attribute homeDirectory unixHomeDirectory
access to dn.subtree="dc=example,dc=com"
by * read
==== END slapd.conf ====
Show replies by date