openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Using multi-value attributes for ACLs
by Andrew Heagle 08 Feb '13

08 Feb '13

Hi, At my work, we use LDAP as the backend for Puppet node definitions. Each host would have an LDAP entry specifying things like which puppet classes to apply, host specific variables, environment (which git branch to use for puppet manifests and a few other things. There are different teams that would like to be able to manage these attributes when deploying software. For example, DBA should be able to manage DB servers while QA need to be able to configure their hosts to test different software. Any hosts that DBA can manage has a role=DBA applied and likewise an QA hosts has role=QA set. Since role is multi-valued, a QA DB can have role=DBA and role=QA set on it, since both QA and DBAs might need to be able to make changes to the host. Our slapd.conf has these ACLS access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=DBA) attrs=puppetclass,puppetvar,environment by group/groupOfUniqueNames/uniqueMember="cn=dba,ou=groups,dc=example,dc=info" write by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write by * read access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=QA) attrs=puppetclass,puppetvar,environment by group/groupOfUniqueNames/uniqueMember="cn=qa,ou=groups,dc=example,dc=info" write by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write by * read let say a LDAP host entry looks like this: dn: cn=qadb1.int.example.info ,ou=QAServers,dc=tor,ou=hosts,dc=example,dc=info objectClass: puppetClient objectClass: device objectClass: exampleHost objectClass: dNSDomain2 cn=qadb1.int.example.info role: DBA role: QA environment: qa datacenter: tor aRecord: 10.10.12.53 dc: qadb1.int.example.info if a DBA wants to edit this entry, it hits the first ACL, sees the DBA user in the dba group and allows the change. If a QA person wants to edit the entry, it hits the first ACL, sees role=DBA, and checks the DBA group, but the QA user is not in the DBA group and rejects the change, even though the next ACL would have allowed the change, it just doesn't hit it. Is it possible to somehow use the ACLs above without have to make lots of ACL rules that combine all the possible combos, such as role=DBA, role=QA, role=DBAQA, role=DBADEV, role=DBABI, etc...? Such as adding a third entry (eg, this would work, but would like to find a more elegant solution): access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=DBAQA) attrs=puppetclass,puppetvar,environment by group/groupOfUniqueNames/uniqueMember="cn=dba,ou=groups,dc=example,dc=info" write by group/groupOfUniqueNames/uniqueMember="cn=qa,ou=groups,dc=example,dc=info" write by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write by * read Thanks, Andrew

2 2

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

08 Feb '13

Mmmm.. the fact is that is *in the consumer* that I had to disable ldaps, not on the provider, the provider is now supporting ldap and ldaps; if I enable ldaps in the consumer, replication does not start, even when specifying provider=ldap://provider-host:389.. One more thing that results strange to me is that if I put a wrong configuration under syncrepl on the consumer, the server does not start and logs some messages, but If the configuration is fine, the server starts but the replication does not, and nothing gets logged, in the consumer nor in the provider.. thanks! 2013/2/6 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Wednesday, February 06, 2013 6:33 PM -0200 paler cryptkeeper < > paler.cryptkeeper(a)gmail.com> wrote: > > >> 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! >> > > Likely it couldn't negotiate the SSL connection. I would guess you failed > to set the cert options in the syncrepl line. Since you provide no detail > into your configuration, all I can do is guess. > > --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 > -- Cuando crees que ya has llegado al piso y que no puedes caer mas bajo, descubres que hay un subsuelo...

1 0

Enforce TLS?
by Patrick Lists 07 Feb '13

07 Feb '13

Hi, I've gone through slapd.access a couple of times but I can't wrap my head around the mountain of information. IMHO that man page could do with a few more examples for us mere mortals :-) FYI: I was not able to find what ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, sasl_ssf=<n> mean and which possible values (+ meaning of those values) I can set them too. Missing info? Goal: allow 127.0.0.1 and ::1 non-TLS access and all other connections must use TLS. Anyone perhaps have an example that can get me started? Thanks! Patrick

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical