openldap-technical July 2009

openldap-technical@openldap.org

68 participants
73 discussions

OpenLDAP as an anonymous bind proxy for Active Directory
by jjeffery＠sp.com.au 06 Jul '09

06 Jul '09

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 ====

1 0

Unable to retrieve the authFilterId attribute from the openldap server
by Navin 06 Jul '09

06 Jul '09

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

3 2

Max number of failed attempts to connect
by Sergiy Milko 06 Jul '09

06 Jul '09

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

2 1

how to get the source of jldap
by owen nirvana 03 Jul '09

03 Jul '09

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

5 5

Re :Re: how to get the source of jldap
by Santosh Kumar 03 Jul '09

03 Jul '09

Cheers, Santosh Kumar Sr Software Engineer Cell:09881481468 Computers can never replace human stupidity.

1 0

Re: how to get the source of jldap
by Michael Ströder 03 Jul '09

03 Jul '09

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.

1 0

Proxying AD : troubles with the comma character
by Emmanuel Lesouef 03 Jul '09

03 Jul '09

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

3 4

Prb: UID Fields Over 7 Chars - add transaction hangs
by David.CTR.Muench＠faa.gov 02 Jul '09

02 Jul '09

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

4 7

Re: TLS init def ctx failed: -1
by gruntler-ldap＠yahoo.com 02 Jul '09

02 Jul '09

--- 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

2 1

TLS init def ctx failed: -1
by François Mehault 02 Jul '09

02 Jul '09

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

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2009