openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

import Certificate to userCertificate
by Алексей 07 Feb '13

07 Feb '13

*Hello. I have a problem with importing certificate to OPENLDAP. I had exported a Certificate from Active Directory and then tried to import it into userCertificate attribute. The system show me error because i didn't use binary in file ldif. After I had done correction of file "ldif", I received message value #0 normalization failed. When I change a SYNTAX of userCertificate from 1.3.6.1.4.1.1466.115.121.1.8 to 1.3.6.1.4.1.1466.115.121.1.40 the file was importing well, and LDAP Browser show me data in attribute userCertificate as Certificate. I could also export data from OPENLDAP. And now question: what difference between 1.3.6.1.4.1.1466.115.121.1.8 and 1.3.6.1.4.1.1466.115.121.1.40, and which of syntax is more correct to use in my case? In case if 1.3.6.1.4.1.1466.115.121.1.8 is more correct how can i understand where i make mistake? I was trying to import Certificate as base64. As example userCertificate;binary:: MIIHcjCCBxygAwIBAgIQQAAAANG9zQ1Jv2ZMAM6FJDANBgkrBgEEAZxWAQIFADCBgjETMBEGCgmSJo... * * With regards, * * Aleksey *

3 7

meta backend and bad configuration file
by francesco.policastro＠selex-es.com 07 Feb '13

07 Feb '13

Hi, I am running slapd 2.4.33 on RHEL, compiled from the sources. I successfully configured meta backend using old style slapd.conf. My aim is to browse two Active Directories in two separate forests (success) and to collect in a new group all users members of two local groups, one for each domain (not done yet). For the latter I read that the dynlist overlay is what I need and I created a hdb database. The configuration examples I found for dynlist are in the cn=config style, so I felt pushed to convert my configuration (slapd -f slapd.conf -F slapd.d). I did it, but the results are not as expected, because slapd starts, but slaptest for the new config issues an error. # slaptest -f slapd.conf 51137c4c hdb_monitor_db_open: monitoring disabled; configure monitor database to enable config file testing succeeded # slaptest 51137c5a olcDbURI: value #0: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>". 51137c5a config error processing olcMetaSub={0}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>" slaptest: bad configuration file! I assume, please tell me if I am wrong, that if you have the new cn=config files, then slapd.conf is not used. But I remove or rename it slapd does not start and the error message is the same as for slaptest. olcDbURI: value #0: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>". config error processing olcMetaSub={0}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>" slapd stopped. So I am wondering if the new config files are even read when slapd starts correctly (i.e. when called with both "-f" and "-F" flags). I know that one of the new features of version 2.4.33 is just the cn=config support for meta. Any ideas? Thanks in advance, Francesco

2 1

Delta replication don't starts if consumer supports SSL?
by paler cryptkeeper 06 Feb '13

06 Feb '13

Hi. Today I had to set up two OpenLDAP instances (2.4.33), with delta replication under SSL/TLS, something pretty common, I think. The installation (from source), initializing and TLS support setup went fine, and both, provider and consumer, started up without problems, and searches did well on both, with ldapd and ldaps. However, the replication never started. After a while (almost 2.5 hours!! and so many slapd.conf files..) I tried to start the consumer without ldaps support, only ldap, and the replication started perfectly! Is this normal? Could be something with the config? The only thing that changed between a not working state and a working one was that if 'slapd -d 256 -h "ldap:/// ldaps:///"' was used, replication didn't start, and with only 'slapd -d 256' the replication started normally.. I repeat that with the first option, beside replication, everything else worked fine, even searches using ldaps.. It's something I could not explain to or customer.. can someone explain it to me? :) Thanks! -- Cuando crees que ya has llegado al piso y que no puedes caer mas bajo, descubres que hay un subsuelo...

2 1

Re: TLS problem
by Quanah Gibson-Mount 05 Feb '13

05 Feb '13

--On Monday, February 04, 2013 9:16 AM +0200 Chris <chris(a)flamengro.co.za> wrote: > Thank you for the link. I have downloaded the newest version. Please keep replies on the list. > I get the following error message in my messages file when I start slapd > > Feb 4 09:15:53 ibm-01 slapd[25637]: [INFO] Using /etc/default/slapd for > configuration > Feb 4 09:15:53 ibm-01 slapd[25642]: [INFO] Launching OpenLDAP > configuration test... > Feb 4 09:15:53 ibm-01 nslcd[18834]: [a6c6dc] failed to bind to LDAP > server ldaps://ibm-01: Can't contact LDAP server > ldpasearch gives the following results > > ldapsearch -x -Z -b'dc=flamengro,dc=co,dc=za' uid=izak > ldap_start_tls: Protocol error (2) > additional info: unsupported extended operation Are you using startTLS (extended operation) or ldaps? These are two different things, and yet it seems you are trying to use both. --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

2 1

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 05 Feb '13

05 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical