OpenLDAP as an anonymous bind proxy for Active Directory
by jjeffery＠sp.com.au
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
valid credentials.
Eg:
1. Start slapd
/usr/local/libexec/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.
My slapd.conf:
==== BEGIN slapd.conf ====
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
loglevel 256
monitoring on
defaultsearchbase "dc=example,dc=com"
database ldap
suffix "dc=example,dc=com"
uri "ldap://adserver.example.com"
# Not sure why, but when this is not set, the JDK LDAP browser
# will not connect anonymously about one time in four.
chase-referrals no
# 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)
rebind-as-user yes
acl-bind bindmethod=simple
binddn="cn=username,ou=Accounts,dc=example,dc=com"
credentials="secret"
idassert-bind bindmethod=simple
binddn="cn=username,ou=Accounts,dc=example,dc=com"
credentials="secret"
mode=none
flags=non-prescriptive
overlay rwm
# 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 ====
13 years, 8 months
Unable to retrieve the authFilterId attribute from the openldap server
by Navin
Hi,
I am new to LDAP. Hence kindly do excuse if any of my terminology is
different.
Issue:
-----
I installed the openldap server through debian package. ie. did NOT
get the source.
Was able to add the record and display them.
ie. the slaptest worked fine and also could able to search the
database with ldapsearch
command also.
Also able to start and stop the daemon.
But i am having an issue regarding the retrieval of authFilterId
attribute stored in
the LDAP database.
Is authFilterId and FilterId attribute same?? Tried to retrieve both
of them but unable to get
the values of the attribute.
Added a schema by name auth.schema in the slapd.conf. This file was
not present in the default
installation of the openldap.
The below are the details of the configuration:
openldap server version: OpenLDAP: slapd 2.4.9
Operating System: Ubuntu 8.04
slapd.conf:
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
#auth.schema added by me. Did not get installed by default
include /etc/ldap/schema/auth.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
# Read slapd.conf(5) for possible values
loglevel none
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database hdb
# The base of your directory in database #1
suffix "dc=example,dc=com"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=admin,dc=example,dc=com"
rootpw secret123
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts. They do NOT override existing an existing DB_CONFIG
# file. You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Indexing options for database #1
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=nodomain" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=nodomain" write
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=nodomain" write
# by dnattr=owner write
#######################################################################
end of slapd.conf
Auth.schema File
Auth.schema: Manually included by me in the slapd.conf. This schema file
added by me. It did not come in the default installation.
This is required as my proprietary ldap client needs it.
I am not sure of its exact use. but i guess its related to radius.
attributetype ( 1.3.6.1.4.1.3317.4.3.1.9
NAME ( 'authFilterId' )
DESC 'radiusSchema: authFilterId'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
objectclass ( 2.16.840.1.113730.3.2.222
NAME 'auth'
DESC 'Authentication database'
SUP top
STRUCTURAL
MUST (
uid $ userPassword $ authFilterId))
########################################################
end of auth.schema
LDAP ldif file: init.ldif
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organizationalUnit
dc: example
ou: Example Dot Com
dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword: secret123
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people
dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups
dn: uid=fsmith,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: radiusprofile
uid: fsmith
sn: Smith
givenName: Fred
cn: Fred Smith
displayName: Fred Smith
uidNumber: 1001
gidNumber: 1001
userPassword: secret123
gecos: Fred Smith
loginShell: /bin/bash
homeDirectory: /home/fsmith
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
mail: fsmith(a)example.com
authFilterId: fsmith
initials: FS
Added the above records using the command:
$ slapadd -l init.ldif
Added successfully no errors on the command line.
When i searched the database using the command
$ ldapsearch -xLLL -b "dc=example,dc=com" '(objectclass=*)'
I was able to see all the details present in the init.ldif file
except the FilterId field:
authFilterId: fsmith
When i issue the command,
$ ldapsearch -xLLL -b "dc=example,dc=com" '(objectclass=*)' '(authFilterId=*)'
then also it does not display the authFilterId attribute.
The slaptest when run in the debug level 16783 does not show any errors.
The tail message of the slaptest o/p is:
....
slaptest startup: initiated.
backend_startup_one: starting "cn=config"
config_back_db_open
config_build_entry: "cn=config"
config_build_entry: "cn=module{0}"
config_build_entry: "cn=schema"
config_build_entry: "cn={0}core"
config_build_entry: "cn={1}cosine"
config_build_entry: "cn={2}nis"
config_build_entry: "cn={3}inetorgperson"
config_build_entry: "cn={4}auth"
config_build_entry: "olcDatabase={-1}frontend"
config_build_entry: "olcDatabase={0}config"
config_build_entry: "olcDatabase={1}hdb"
backend_startup_one: starting "dc=example,dc=com"
hdb_db_open: "dc=example,dc=com"
hdb_db_open: database "dc=example,dc=com": dbenv_open(/var/lib/ldap).
config file testing succeeded
slaptest shutdown: initiated
====> bdb_cache_release_all
slaptest destroy: freeing system resources.
Kindly do suggest of how to retrieve the authFilterId attribute value.
have a nice day,
navin
13 years, 8 months
Max number of failed attempts to connect
by Sergiy Milko
Hi guys,
Is anyone aware of a configuration parameter (in slapd.conf or
OpenLDAP back-end database) that specifies a maximum number of
unsuccessful attempts to connect to the LDAP before any further
attempts are blocked? Is there a possibility to impose this logic at
all? I am using JNDI library to bind to the LDAP using 'Simple'
authentication.
I would appreciate any related information!
Many thanks!
Sergiy
13 years, 8 months
how to get the source of jldap
by owen nirvana
I can't login cvs of openldap-jdap by anonymous in cvsnt, and I have
not account of openldap
how to get the source of jldap
gtalk:freeespeech@gmail.com
13 years, 8 months
Re: how to get the source of jldap
by Michael Ströder
Please stay on the mailing list (Cc:-ed again).
owen nirvana wrote:
> cvs -d :pserver@cvs.openldap.org:/repo/JLDAP login
> or cvs -d :pserver@cvs.openldap.org:/repo/OpenLDAP-JLDAP login
> password: OpenLDAP
>
> error : No Such Repository
> gtalk:freeespeech@gmail.com
What's the reason you don't do *exactly* what I've posted?
Please have a closer look at the commands I sent since before answering
your question I've spend my spare time to test it.
Basically you're using the wrong CVSROOT.
Ciao, Michael.
>> 2009/7/3 Michael Ströder <michael(a)stroeder.com>:
>>> owen nirvana wrote:
>>>> I can't login cvs of openldap-jdap by anonymous in cvsnt, and I have
>>>> not account of openldap
>>>>
>>>> how to get the source of jldap
>>> The description on this web page works for me at least on Linux:
>>>
>>> http://www.openldap.org/software/repo.html#AnonCVS
>>>
>>> $ export CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP"
>>> $ cvs login
>>> Password: (enter OpenLDAP)
>>> $ cvs co openldap-jldap
>>>
>>> I don't have cvsnt though. Can you please elaborate on the specific
>>> problem you see? Probably it's just a cvsnt usage issue.
>>>
>>> Ciao, Michael.
13 years, 8 months
Proxying AD : troubles with the comma character
by Emmanuel Lesouef
Hello,
I'm new to openldap's meta backend and I get a strange issue.
I'm able to proxy active directory via openldap using meta backend. It
works well except that in my user's DN, I have a comma character which
is translated with the following "\2C".
How can I handle that ?
Thanks.
--
Emmanuel Lesouef
13 years, 8 months
Prb: UID Fields Over 7 Chars - add transaction hangs
by David.CTR.Muench＠faa.gov
All,
I have a problem with a new OpenLDAP configuration that is likely my own
doing, but I am unable to discern the cause.
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
I installed the OpenLDAP software from the stable release at the
openldap.org site. After some basic configuration and very basic tests, I
did the "full" slapd.conf and DB_CONFIG configurations using various
resources, including the Admin Guide and the FAQ-o-matic.
All seemed to be going well until I tried to add (ldapmodify -a w/ldif
files) some new "person" entries based on data I want to migrate. The
first one was OK, but subsequent ones never completed. When the problem
occurs, there's no return from the ldapmodify command and likewise any
"db_stat" commands that I attempt. When I look at the log (local4.debug)
entries, the last entry is for the "ADD dn="uid=DCM...". The daemon is
*not* looping, there's just never a response. [I need to break to get my
prompt back.] When I attempt to stop the daemon, I get "waiting for 1
operations/tasks to finish" and I have to kill the daemon to get it to
stop. When I restart, it goes through DB recovery and everything is as it
was before the ldapmodify -a started.
A colleague suggested something that seems to be an indicator:
- an add of "dn: uid=DCM11,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM1123,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM11234,ou=People,o=USNS" does *not* work
So it seems that "uid" values with lengths over 7 characters fail. Yeah,
this seems plenty odd to me, but I've created\tested\deleted DBs multiple
times over and this still happens consistently.
I have tried multiple levels of "debug", down to "488" anyway, but still
no message that seems like an error.
Not wanting to swamp anyone, here's some basic config extracts:
===DB_CONFIG===
set_cachesize 0 67108864 1
set_lg_bsize 2097152
set_lg_max 10485760
set_lg_regionmax 262144
===
===slapd_t10.conf=== [obviously stripped]
...
backend bdb
database bdb
suffix "o=XXXX"
checkpoint 128 15
index objectClass eq
index uid pres,eq [Have tried taking this
out & re-creating - no difference]
lastmod on
monitoring on
...
===
Anyone have any ideas? I have spent many hours looking at this, but I'm
willing to believe it's something simple I can't see.
Thanks in advance for you help.
DCM
13 years, 8 months
Re: TLS init def ctx failed: -1
by gruntler-ldap＠yahoo.com
--- On Thu, 7/2/09, Howard Chu <hyc(a)symas.com> wrote:
> From: Howard Chu <hyc(a)symas.com>
> Subject: Re: TLS init def ctx failed: -1
> To: "François Mehault" <Francois.Mehault(a)netplus.fr>
> Cc: "openldap-technical(a)openldap.org" <openldap-technical(a)openldap.org>
> Date: Thursday, July 2, 2009, 7:02 AM
> François Mehault wrote:
> >
> > |*openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout
> > server.pem -days 365*|
>
> This is a terrible way to generate a server certificate.
> Instead you should generate a CA, following the steps in
> (the current) section 4.2.
What document is being referred to here? It can't be
http://www.openldap.org/doc/admin/
because section 4.2. there is "Prerequisite software".
Thanks,
Ken
13 years, 8 months
TLS init def ctx failed: -1
by François Mehault
Hi all
I contact you because I don't succeed to configure my OpenLDAP with TLS.
First I create self signed certificate server.pem like I read on this page http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#5.1.1 in /usr/local/etc/openldap/tls.
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 365
Then I add this line in slapd.conf :
TLSCertificateFile /usr/local/etc/openldap/tls/server.pem
TLSCertificateKeyFile /usr/local/etc/openldap/tls/server.pem
TLSCACertificateFile /usr/local/etc/opendldap/tls/server.pem
TLSVerifyClient never
Then I restart slapd. /usr/local/etc/rc.d/slapd stop , start.
And in my /var/log/debug.log I have
Jul 2 12:18:39 labobe2 slapd[97816]: main: TLS init def ctx failed: -1
Jul 2 12:18:39 labobe2 slapd[97816]: slapd destroy: freeing system resources.
Jul 2 12:18:39 labobe2 slapd[97816]: syncinfo_free: rid=001
Jul 2 12:18:39 labobe2 slapd[97816]: slapd stopped.
I use FreeBSD 7.
If someone can help me, I appreciate, thanks in advance
Regards,
François
13 years, 8 months
