openldap-technical February 2013

openldap-technical@openldap.org

68 participants
72 discussions

Error from MOD referral containing spaces
by Chris Palmer 05 Feb '13

05 Feb '13

I am having trouble processing referred MOD requests where the DN contains spaces. It always fails with error 32 (not found). Instance A is the master. Instance B is a replica, type refreshAndPersist, and contains "updateref ldap://instanceA:389" following the syncrepl. Both A and B are openldap 2.4.33 with identical configuration apart from the sync and referral settings. Updates to A replicate immediately and correctly to B (including those with spaces in the DN). Updates to B, without spaces in the DN, are referred to A, processed correctly on A, and replicated correctly to B. But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated. The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed). A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=..... The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32. I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help? Many thanks Chris

3 4

Can't contact server for syncrepl but can ldapsearch
by Carlo Santos 04 Feb '13

04 Feb '13

Hi guys, I have the following problem: I have two servers, ldap1 and ldap2 that I am trying to sync both ways using syncrepl. However, when I was entering an 8mb data into ldap1 using ldapadd, the changes were not propagated or was not retrieved by ldap2. What's worse is ldap2 syncrepl gets a "Can't contact server error." However, when doing an ldapsearch from the ldap2 terminal to ldap1, the results are displayed. Additionally, I was doing an ldapsearch in ldap2 while the syncing was going on. Does this have any effect? Below is the olcDatabase={2}bdb.ldif files from both ldap1 and ldap2. dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 15 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: ou pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 3c9dde1a-f65f-1031-92f3-ef68fd07464c creatorsName: cn=config createTimestamp: 20130119083743Z olcSuffix: dc=myorganization,dc=org olcRootDN: cn=admin,dc=myorganization,dc=org olcRootPW: password olcAccess: {0}to attrs=employeeType by dn="cn=sssd,dc=myorganization,dc=org" read by self read by * none olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {2}to dn.base="" by * none olcAccess: {3}to * by dn="cn=config" write by dn="cn=sssd,dc=myorganization,dc=org" read by self write by * none olcSyncrepl: {0}rid=001 provider=ldaps://ldap1.myorganization.orgbinddn="cn=admin,dc=myorganization,dc=org" bindmethod=simple credentials=password searchbase="dc=myorganization,dc=org" type=refreshOnly interval=00:00:05:00 retry="5 5 300 5" timeout=1 olcSyncRepl: {2}rid=002 provider=ldaps://ldap2.myorganization.orgbinddn="cn=admin,dc=myorganization,dc=org" bindmethod=simple credentials=password searchbase="dc=myorganization,dc=org" type=refreshOnly interval=00:00:05:00 retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE The ldap1 logs show nothing and the ldap2 logs display the following lines: do_syncrep2: rid=001 (-1) Can't contact LDAP server do_syncrepl: rid=001 rc -1 retrying (4 retries left) I have tried rebooting both the servers but the problem persists. I am using OpenLDAP v2.4.23 on a CentOS 6.3 VM. -- Carlo Santos

2 3

can rwm map operational attributes ?
by Benin Technologies 04 Feb '13

04 Feb '13

Hi I have a back-relay server with rwm, and I was wondering if it was possible to map operational attributes. Let's say I have (in my hdb backend): DN: cn=John Doe,ou=Accountancy,dc=company,dc=com cn:John Doe gn:John sn:Doe I'd like clients accessing my back-relay to get the OU, like this : DN :cn=John Doe,ou=Accountancy,dc=company,dc=com cn:John Doe gn:John sn:Doe *ou:Accountancy* Do I have to add an "ou" attribute to each entry in my hdb backend, or can rwm do the job of extracting the ou from the entryDN ? I tried this: dn: olcOverlay={0}rwm,olcDatabase={2}relay,cn=config changetype:modify add:olcRwmMap olcRwmMap: {2} attribute ou entryDN If it had worked I would have had something like : "ou:cn=John Doe,ou=Accountancy,dc=company,dc=com" Second step would then have been to transform that into a plain "ou:Accountancy" But even the first step didn't work, it seem rwm cannot map operational attributes like entryDN. Or am I missing something ? Thanks Ben

1 0

Re: TLS problem
by devzero2000 04 Feb '13

04 Feb '13

On Tue, Jan 29, 2013 at 7:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Tuesday, January 29, 2013 10:22 AM +0200 Chris <chris(a)flamengro.co.za> > wrote: > > Hi >> >> I am running Openldap 2.4.23 on RHEL6. I can telnet to the server on both >> 389 636 ports. >> I can do a ldapsearch and ldapadd without any errors. I get this error >> when I start the slapd daemon. >> > > In addition to the issue noted by Rich, I would note that you are using an > ancient release with numerous known issues that is not suitable for a > production LDAP server. I would strongly advise you to use a current > OpenLDAP release. If you do not feel comfortable building OpenLDAP > yourself, there are packages available at <http://ltb-project.org/wiki/** > download#openldap <http://ltb-project.org/wiki/download#openldap>> that > should meet your needs. > Yes, probably it is the best thing to do. BUT have you recently looked to the bugfix openldap backport from RED HAT ? Or from other commercial distro ? New feature is a point, but old bugfix are another. JMHO. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

client server connection to LDAP/Kerberos
by Asmaa Ahmed 04 Feb '13

04 Feb '13

Hello, I recently added Kerberos authentication to my LDAP server, and I am trying to connect the other servers to it.I have a server running Davical shared calendar, and I hope to get it working with my LDAP server again after Kerberos integration. Here is my configuration which was working before the integration and my source is "http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication" $c->authenticate_hook['config'] = array( 'host' => 'ldap.domain.com', //host name of your LDAP Server 'port' => '389', //port// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request to this server (if required)// 'passDN' => 'password', //Password of request bind 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for valid user 'filterUsers' => 'objectClass=*', //filter which must validate a user according to RFC4515, i.e. surrounded by brackets 'protocolVersion' => 3, // important for simple auth (no sasl)// 'startTLS' => true, // securing your LDAP connection 'i_use_mode_kerberos' => "i_know_what_i_am_doing", My slapd error logs:Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from IP=203.28.247.193:56887 (IP=0.0.0.0:389)Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text=Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid modifyTimestamp cn mailJan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND My OLC configuration:root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"dn: cn=configobjectClass: olcGlobalcn: configolcArgsFile: /var/run/slapd/slapd.argsolcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1 ,ou=people,dc=domain,dc=comolcLogLevel: statsolcPidFile: /var/run/slapd/slapd.pidolcSaslRealm: DOMAIN.COMolcToolThreads: 1 dn: olcDatabase={1}hdb,cn=configobjectClass: olcDatabaseConfigobjectClass: olcHdbConfigolcDatabase: {1}hdbolcDbDirectory: /var/lib/ldapolcSuffix: dc=domain,dc=comolcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by * no neolcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou =krb5,domain,dc=com" read by * noneolcAccess: {2}to attrs=loginShell,gecos by self write by users read by * noneolcAccess: {3}to dn.base="" by * readolcAccess: {4}to * by users read by * noneolcLastMod: TRUEolcRootDN: uid=admin,ou=people,domain,dc=com Any suggestion to fix the binding and get my search working again with kerberos authentication ? Thanks.

2 4

Access control
by Philip Colmer 04 Feb '13

04 Feb '13

I'm trying to get access control for writing to groups as automated as possible, in as much as I would like LDAP to be able to determine who is able to write based on other attributes. I've been able to successfully do this if I only need to grant access to one or a few individuals, by specifying their DN as a value to an attribute, and then using this ACL: add: olcAccess olcAccess: {2}to dn.sub="ou=groups,dc=example,dc=com" by dnattr="owner" write by users read by * none That works really well - I just add the owner attribute to an object, specify the owner's DN and they can then write to the object. However, for larger scale permissions, I need to be able to use the membership of a group. Now I've read http://www.openldap.org/faq/data/cache/52.html and seen that you can specify: access to <what> by group/<objectclass>/<attributename>=<DN> <access> However, that would require me to explicitly set the DN of the group in the access control itself. What I want/need to be able to do is for LDAP to read the DN of the group that has permission, in the same what that it does with dnattr. I thought that I had read something about this being possible with sets, but slapd.access says that "The statement set=<pattern> is undocumented yet." so I'm not clear if that is the most appropriate way to proceed. Can someone please advise on how this might be accomplished? Thanks. Philip

2 5

configure ldap + cyrus sasl on debian 6
by Benin Technologies 03 Feb '13

03 Feb '13

Hi, I tried to install OpenLDAP with Cyrus SASL support on Debian. I'm running Debian 6.0.4, and until now I was using an 2.4.23 installation, from debian packages. First attempt : installation of OpenLDAP 2.4.33 with default configure options. After installation, I converted slapd.conf to cn=config Then I dropped the database, and tried to rebuild a new one by loading a ldif file (like I'm used to do with my previous installation, from Debian packages) ldapadd -Y EXTERNAL -H ldapi:/// -f myfile.ldif ldapadd: not compiled with SASL support Second attempt I installed Cyrus-SASL-2.1.26 (with default configure options) Then I installed OpenLDAP, "--with-cyrus-sasl" This time, I got the following message: ldapadd -Y EXTERNAL -H ldapi:/// -f myfile.ldif ldap_sasl_interactive_bind: Can't contact LDAP server (-1) What step did I miss ? B.

2 4

problem with ldap group check in squid
by Fuhrmann, Marcel 03 Feb '13

03 Feb '13

Hello, i'm trying to to configure squid to use a ldap (ADS 2008) group check to give access to the internet. The squid mailing list couldn't help me. Maybe you can. /usr/lib64/squid/squid_ldap_group -d -v3 -b 'ou=OU3,ou=OU2,ou=OU1,dc=DOMAIN,dc=LOCAL' -f \ '(&(sAMAccountName=%v)(memberOf=cn=%a,ou=USERGRUPPEN,dc=DOMAIN,dc=LOCAL))' -D cn=LDAP,cn=USERS,dc=DOMAIN,dc=LOCAL \ -w PASSWORT -h DOMAINCONTROLLER testuser internet Connected OK group filter '(&(sAMAccountName=testuser) (memberOf=cn=internet,ou=USERGROUPS,dc=DOMAIN,dc=LOCAL))', searchbase 'ou=OU3,ou=OU2,ou=OU1,dc=DOMAIN,dc=LOCAL' ERR The user TESTUSER is in OU3. The group INTERNET is in a OU called USERGROUPS. TESTUSER is member of INTERNET. But it doesn't work. Can somebody give me advice? Thanks a lot -- Marcel

1 1

Hello!!
by Bob Fitch 02 Feb '13

02 Feb '13

http://www.bellacroquercreations.com/components/com_content/yaid352.php Bob Fitch 2/3/2013 5:35:12 AM _____

1 0

slapd-meta and tls_reqcert=allow
by Jim Vanes 01 Feb '13

01 Feb '13

I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS. Here is my meta config: database meta suffix "dc=virtual,dc=local" rootdn "cn=root,dc=virtual,dc=local" rootpw password # Local uri ldap://localhost/dc=ds1,dc=virtual,dc=local suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local" idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password #Remote AD server uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local tls start suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local" idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow" It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead. Another thing I noticed was that adding tls_crlcheck="none" to my idassert-bind line causes slaptest to fail..not sure if this is related or not. /etc/openldap/slapd.conf: line 68: "idassert-bind <args>": unable to parse field "tls_crlcheck=none". slaptest: bad configuration file! I must be misunderstanding the docs. Any help would be appreciated.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2013