openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

questions to differences between RFC2253 & RFC4514
by Peter Marschall 19 Sep '12

19 Sep '12

Hi, I am currently in the process of updating the DN parsing routines of perl-ldap and found some differences on border cases between RFC 2253 & RFC 4514 As you are more knowledgeable than I in LDAP (you wrote the specs ;-), could you please give me your opinion on the test cases below and whether my interpretations are correct. Thanks in advance for your help Peter <OU=Sales+CN=J. Smith;O=Widget Inc.;C=US> * illegal in RFC 4514 [I guess this is wrong;-] * in RFC 2253 [ { 'CN' => 'J. Smith', 'OU' => 'Sales' }, { 'O' => 'Widget Inc.' }, { 'C' => 'US' } ]; <OU="Sales"+CN=J. Smith,O=Widget Inc.,C=US> * illegal in RFC 4514 * in RFC 2253 [ { 'CN' => 'J. Smith', 'OU' => 'Sales' }, { 'O' => 'Widget Inc.' }, { 'C' => 'US' } ]; <OU="Sales+CN=J. Smith",O=Widget Inc.,C=US> * illegal in RFC 4514 * in RFC 2253 [ { 'OU' => 'Sales+CN=J. Smith' }, { 'O' => 'Widget Inc.' }, { 'C' => 'US' } ]; <cn=J.\20Smith\+ou=Sales,O=Widget\20Inc.,C=US> * in RFC 4514 [ { 'CN' => 'J. Smith+ou=Sales' }, { 'O' => 'Widget Inc.' }, { 'C' => 'US' } ]; * illegal in RFC 2253 <cn=Clif Harden+IDNumber="a0125589 ",ou=tiPerson,ou=person,o=ti,c=us> * illegal in RFC 4514 * in RFC 2253 [ { 'CN' => 'Clif Harden', 'IDNUMBER' => 'a0125589 ' }, { 'OU' => 'tiPerson' }, { 'OU' => 'person' }, { 'O' => 'ti' }, { 'C' => 'us' } ]; <Cn=" Graham Barr ",OU=person,O=vc,C=us> * illegal in RFC 4514 * in RFC 2253: [ { 'CN' => ' Graham Barr ' }, { 'OU' => 'person' }, { 'O' => 'vc' }, { 'C' => 'us' } ]; <cn=" Graham \20Barr\20 ",OU=person,O=vc,C=us> * illegal in RFC 4514 * in RFC 2253: [ { 'CN' => ' Graham Barr ' }, { 'OU' => 'person' }, { 'O' => 'vc' }, { 'C' => 'us' } ]; <cn=123=345,o=xxx> * in RFC 4514: [ { 'CN' => '123=345' }, { 'O' => 'xxx' } ]; * illegal in RFC 2253 -- Peter Marschall peter(a)adpm.de

1 0

Monitoring using cn=config
by Arturo Borrero 19 Sep '12

19 Sep '12

Hi there. I'm using slapd 2.4.23-7.2 (from Debian Squeeze) and i'm unable to get monitoring running. Here is my config: file /etc/ldap/slapd.d/cn=config/olcDatabase\=\{2\}monitor.ldif dn: olcDatabase={2}monitor objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {2}monitor createTimestamp: 20120918124549Z olcAccess: {0}to * by peername.ip=127.0.0.1 read by peername.ipv6=::1 read by * none olcAddContentAcl: FALSE olcLastMod: TRUE olcMonitoring: FALSE olcReadOnly: FALSE olcMaxDerefDepth: 15 olcSyncUseSubentry: FALSE In file /etc/ldap/slapd.d/cn=config/olcDatabase\=\{1\}hdb.ldif [...] olcMonitoring=TRUE [...] The documentation isn't complete: www.openldap.org/devel/admin/monitoringslapd.html I try: root@server:~# ldapsearch -H ldapi:/// -Y EXTERNAL -s sub -b cn=Monitor SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=Monitor> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 So I guess the database for monitoring doesn't exist. Any idea? Best regards. -- Arturo Borrero González Departamento de Seguridad Informática, @NIS_CICA (twitter) Centro Informático Científico de Andalucía (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejería de Economía, Innovación, Ciencia y Empleo Junta de Andalucía

2 1

Replication Provider consumer
by arun.sasi1＠wipro.com 19 Sep '12

19 Sep '12

Hello Team, I have configured a set up in my infra as like below. Provider in OpenLDAP 2.4.19 Consumer in OpenLDAP 2.4.28 When I replicate the data, it all get replicate properly but when I create any entry in consumer server, it is getting writes in master LDAP server. What could be the problem. Please find the below consumer configuration file. cn\=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 9fe00430 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 6b8092fc-9667-1031-8a5a-358a8bc96075 creatorsName: cn=config createTimestamp: 20120919053426Z olcAllows: bind_v2 olcServerID: 1 ldap://gb0135embldap01.emb.slb.com olcTLSCACertificateFile: /etc/ssl/certs/Emb.slb.Com-CA.pem olcTLSCACertificatePath: /etc/ssl/certs/ olcTLSCertificateFile: /etc/ldap/emb.slb.com.cert.pem olcTLSCertificateKeyFile: /etc/ldap/emb.slb.com.key.pem olcLogLevel: -1 entryCSN: 20120919053444.175373Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20120919053444Z olcDatabase\=\{1\}hdb.ldif # CRC32 b10d01be dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=emb,dc=slb,dc=com olcLastMod: TRUE olcRootDN: cn=admin,dc=emb,dc=slb,dc=com olcRootPW:: e1NTSEF9b28vRlZuM0JnaEQzWVBDUi9OUGVPODJ0ZktrMzlPNlg= olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq structuralObjectClass: olcHdbConfig entryUUID: 6b816632-9667-1031-8a64-358a8bc96075 creatorsName: cn=config createTimestamp: 20120919053426Z olcSyncrepl: {0}rid=365 provider=ldap://gb0135embldap01.emb.slb.com bindmethod =simple binddn="cn=admin,dc=emb,dc=slb,dc=com" credentials=Bsl@121z searchbas e="dc=emb,dc=slb,dc=com" type=refreshAndPersist retry="5 5 300 5" starttls=yes olcUpdateRef: ldap://gb0135embldap01.emb.slb.com entryCSN: 20120919053435.138086Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20120919053435Z Thanks & Regards, Arun Sasi Venmalassery ------------------------------------------------------------------------------------------------------------------------------------- Sr. Engineer - Server Management (UNIX), Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com<mailto:koresh.dash@wipro.com> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

Help with ACL to allow member of groupOfNames to read their entry
by Josh Miller 18 Sep '12

18 Sep '12

I am using OpenLDAP 2.4.23 on CentOS 6 and trying to setup ACLs to allow simpleSecurityObjects who are members of a groupOfNames to read their entry (but not write) and ideally not see other member attributes in that same groupOfNames. These simpleSecurityObjects exist in various OUs and reside in the same OU as the groupOfNames that they require access to. I'm using the memberOf overlay to maintain memberOf attributes within each simpleSecurityObject (which works well). Sample simpleSecurityObject and groupOfNames: uid=josh,ou=first string,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject objectClass: top uid: josh dn: cn=group1,ou=first string,dc=example,dc=com objectClass: groupOfNames cn: group1 member: uid=josh,ou=first string,dc=example,dc=com Here is what I have so far for ACLs: dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword by anonymous auth by self write by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by * none - add: olcAccess olcAccess: {1}to dn.subtree="ou=power users,dc=example,dc=com" by anonymous auth by self write by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=power users admin,ou=service accounts,dc=example,dc=com" write by dn.exact="uid=power users readonly,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by users search by * none - add: olcAccess olcAccess: {2}to dn.subtree="ou=third string,dc=example,dc=com" by self write by anonymous auth by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=third string admin,ou=service accounts,dc=example,dc=com" write by dn.exact="uid=third string readonly,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by users search by * none - add: olcAccess olcAccess: {3}to dn.subtree="ou=second string,dc=example,dc=com" by self write by anonymous auth by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=second string admin,ou=service accounts,dc=example,dc=com" write by dn.exact="uid=second string readonly,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by users search by * none - add: olcAccess olcAccess: {4}to dn.subtree="ou=first string,dc=example,dc=com" by self write by anonymous auth by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=first string admin,ou=service accounts,dc=example,dc=com" write by dn.exact="uid=first string readonly,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by users search by * none - add: olcAccess olcAccess: {5}to dn.subtree="ou=fourth string,dc=example,dc=com" by self write by anonymous auth by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=fourth string admin,ou=service accounts,dc=example,dc=com" write by dn.exact="uid=fourth string readonly,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by users search by * none - add: olcAccess olcAccess: {6}to * by self write by anonymous auth by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=readonly,ou=people,dc=example,dc=com" read by * none I've tried placing the following ACL in various places in the list and it has failed to work each time: (re: http://www.openldap.org/doc/admin24/access-control.html) olcAccess: to attrs=member,entry by dnattr=member selfwrite by group.exact="cn=ol-admins,ou=groups,dc=example,dc=com" write by dn.exact="uid=global-ro,ou=service accounts,dc=example,dc=com" read by dn.exact="uid=readonly,ou=people,dc=example,dc=com" read by * none Any assistance would be greatly appreciated. Thanks, Josh

1 0

ldapadd long line problem
by Amol Kulkarni 18 Sep '12

18 Sep '12

Hi, I'm unable to add a long line (more than 4096 chars) in a field using ldapadd. I've openldap 2.4.30. I had 2.4.23 earlier and it used to work. So I tested again by keeping the slapd daemon of 2.4.30 but using ldapadd from 2.4.23. It works with the ldapadd from 2.4.23. Also it works in 2.4.30 if : 1. I reduce it to less than 4096. 2. I break down the long line into multiple lines. Has anyone come across this behaviour ? Is is something new added in the new version ? Thanks in advance, Amol.

1 0

Error, ldap_start_tls failed (-11)
by arun.sasi1＠wipro.com 18 Sep '12

18 Sep '12

Hello Guillaume Rousse/Team, but I can replicate with my old slave OpenLDAP servers without any issues, only changes is below. 1) Master OpenLDAP server in Ubuntu 9.04 OS and OpenLDAP version 2.4.19 2) Slave OpenLDAP servers are in Ubuntu 9.04 and OpenLDAP version 2.4.19 3) New OpenLDAP slave server in Ubuntu 12.04 and OpenLDAP Version in 2.4.28 Did we get any issue with replicattion when I replicate with old version from new slave version ? Is there any issues if I create certificate from old version OS to new version OS. Thanks -Arun Message: 2 Date: Mon, 17 Sep 2012 10:35:03 +0200 From: Guillaume Rousse <guillomovitch(a)gmail.com> To: openldap-technical(a)openldap.org Subject: Re: Error, ldap_start_tls failed (-11) Message-ID: <5056E0B7.4000909(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Le 16/09/2012 08:48, arun.sasi1(a)wipro.com a ?crit : > for 636 > Sep 16 10:47:26 ae0043app05 slapd[10982]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:636 Error, ldap_start_tls failed (-1) > Sep 16 10:47:26 ae0043app05 slapd[10982]: do_syncrepl: rid=365 rc -1 retrying Using plain ldap protocol on port 636 is bound to fail: either use ldaps on this port, or plain ldap on port 389 with start_tls. > for 389 > Sep 16 10:31:42 ae0043app05 slapd[10282]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:389 Error, ldap_start_tls failed (-11) > > I dont know how to check TLS manually... could you please help me... ldapsearch -H ldaps://your.server.tld -d 1 BTW, your problem seems to be a generic SSL issue, likely to comes from your server certificate. -- BOFH excuse #87: Password is too complex to decrypt Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

2 1

Proxy setup not caching against Active Directory
by Xavier Garcia 17 Sep '12

17 Sep '12

Dear all, I am setting up a proxy to cache queries against Active Directory, so our Postfix servers do not hammer the AD servers. To do so I am using rwm and pcache with the following configuration: overlay rwm rwm-normalize-mapped-attrs yes rwm-map attribute uid sAMAccountName rwm-map attribute mail proxyAddresses rwm-map attribute maildrop smtp rwm-map attribute mailbox imap rwm-map attribute domain msExchAcceptedDomainName rwm-map attribute * tls ldaps tls_reqcert=never overlay pcache pcache bdb 10000 1 50 900 directory /var/lib/ldap/cache cachesize 10000 #index uid,mail,maildrop,mailbox eq index uid eq index mail eq # cache configuration proxyCacheQueries 10000 pcacheAttrset 0 uid mail maildrop mailbox pcacheTemplate (uid=) 0 900 pcacheTemplate (mail=smtp:) 0 900 When running: ldapsearch -x -LLL -E pr=200/noprompt -h 127.0.0.1 \ -D "CN=username,OU=users,DC=company,DC=com" \ -w "passsssworddddd" \ -b "OU=users,DC=company,DC=com" -s sub "(mail=smtp:me@company.com)" maildrop It never gets cached. query template of incoming query = (mail=) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE I have read the pcache manual many times, but I cannot find the reason. Perhaps you can find the problem. Regards, Xavier Garcia

2 1

ShadowMax is not working
by cbulist 17 Sep '12

17 Sep '12

Hi, I have set a user with ShadowMax to 15 in order to get a expiration warning but it doesn't work and the client gets login. (I'm not using Password Policy) I read some post and them reference to pam_ldap.conf on the client, but I do not see any option about it. My openldap server version is: 2.4.23-26 Any clue with this problem? Thanks!

3 4

Message to Change Password
by Soporte Ti 17 Sep '12

17 Sep '12

Hi all, I have a question to pose, I inherited a FDS or dirsrv installation, which works without problems, but I have a single detail that I would like to ask and see if they can guide me (tell them that my experience is not much in openldap) When accounts are expiring starts giving a message like this: "Your password will expire LDAP in 2 days." the point is that the user changes the password but after that continues with the message, the password expiring after 2 days as indicated in message the question is, what is the command or statement that I use to change the password without this happening again? Best regards. Cristian

3 2

Error, ldap_start_tls failed (-11)
by arun.sasi1＠wipro.com 17 Sep '12

17 Sep '12

Hello Guillaume Rousse/team, I am getting below error from the master server when I give 636 port number in my HDB config file Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 ACCEPT from IP=163.183.2.145:43965 (IP=0.0.0.0:636) Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 closed (TLS negotiation failure) and When I gibe 389 in my HDB config, I get below message from master server. Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 fd=38 ACCEPT from IP=163.183.2.145:49242 (IP=0.0.0.0:389) Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 STARTTLS Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 RESULT oid= err=0 text= Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=443298))" Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 op=2 UNBIND Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 fd=19 closed Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349037 fd=60 closed (connection lost) but there is no much data replication happened I get below message from slave server... for 636 Sep 16 10:47:26 ae0043app05 slapd[10982]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:636 Error, ldap_start_tls failed (-1) Sep 16 10:47:26 ae0043app05 slapd[10982]: do_syncrepl: rid=365 rc -1 retrying for 389 Sep 16 10:31:42 ae0043app05 slapd[10282]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:389 Error, ldap_start_tls failed (-11) I dont know how to check TLS manually... could you please help me... Thanks & Regards, Arun Sasi Venmalassery ------------------------------------------------------------------------------------------------------------------------------------- Sr. Engineer - Server Management (UNIX), Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com ________________________________________ From: openldap-technical-bounces(a)OpenLDAP.org [openldap-technical-bounces(a)OpenLDAP.org] on behalf of openldap-technical-request(a)OpenLDAP.org [openldap-technical-request(a)OpenLDAP.org] Sent: Friday, September 14, 2012 5:30 PM To: openldap-technical(a)openldap.org Subject: openldap-technical Digest, Vol 58, Issue 12 ------------------------------ Message: 3 Date: Thu, 13 Sep 2012 14:38:20 +0200 From: Guillaume Rousse <guillomovitch(a)gmail.com> To: openldap-technical(a)openldap.org Subject: Re: Error, ldap_start_tls failed (-11) Message-ID: <5051D3BC.3020207(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Le 13/09/2012 14:16, arun.sasi1(a)wipro.com a ?crit : > Hello Team, > > I have an issue with OpenLDAP TLS based replication > > Getting below error > slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error, > ldap_start_tls failed (-11) > Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11 > retrying > > I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade > it and first I upgraded on my consumer openldap server which I migrated > to Ubuntu 12.04 and version 2.4.28. > > I have created the certificate for my consumer from existing server. but > when I go for TLS based replication, the database is not syncing and it > is synching when remove starttls=no What does the master log say, and did you try a manual connection with the same credentials from the slave to the master, using TLS ? -- BOFH excuse #166: /pub/lunch The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical