openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Inconsistent duplicate attributeType: "memberOf"
by Christian Ramseyer 19 Jul '11

19 Jul '11

(sorry if this appears twice, I've posted this some time ago before I was subscribed to the list and it didn't seem to appear) I'm trying to migrate an LDAP from Solaris/OpenLDAP 2.3 to Linux/OpenLDAP 2.4, and I have an issue with a custom schema: # slaptest -f etc/slapd.conf /data/openldap/etc/schema/nxx.schema: line 10 attributetype: Inconsistent duplicate attributeType: "memberOf" Now the problem is, I have no idea where this previous definiton of memberOf comes from.... These are the included schemas: # grep include etc/slapd.conf include /data/openldap/etc/schema/core.schema include /data/openldap/etc/schema/cosine.schema include /data/openldap/etc/schema/inetorgperson.schema include /data/openldap/etc/schema/nis.schema include /data/openldap/etc/schema/nxx.schema And none of them besides nxx defines a memberOf: # grep memberOf etc/schema/* etc/schema/nxx.schema:attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' etc/schema/nxx.schema: MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) ) <end of grep output> Also, nxx defines it only once (it's pasted below). After commenting nxx and generating a config directory with slaptest, I found this in cn=schema.ldif: # grep memberOf openldap-config/cn\=config/cn\=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this? Any help appreciated. Also I know that the attribute in the custom schema had better been prefixed, but this is an installation running since 2004 and "memberOf" is in scripts all over the place, so I'd rather not rename it. Thanks Christian nxx.schema objectIdentifier NxxRoot 1.3.6.1.4.1.21654 objectIdentifier NxxLDAP NxxRoot:3 objectIdentifier NxxLDAPattributeType NxxLDAP:1 objectIdentifier NxxLDAPobjectClass NxxLDAP:2 attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # for password aging attributetype ( NxxLDAPattributeType:2 NAME 'lastLogin' DESC 'Stores the last successful login of a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( NxxLDAPattributeType:3 NAME 'passwordHistory' DESC 'Stores all password ever used by a user' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( NxxLDAPattributeType:4 NAME 'loginFailures' DESC 'Stores successives login failures for a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( NxxLDAPattributeType:5 NAME 'passwordRecoveryMailAddress' EQUALITY caseExactIA5Match DESC 'Stores mail address for self password recovery' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( NxxLDAPattributeType:6 NAME 'passwordRecoveryChallenge' DESC 'Stores challenge for self password recovery' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( NxxLDAPobjectClass:1 NAME 'OssAccount' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) ) objectclass ( NxxLDAPobjectClass:2 NAME 'OssHost' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( host ) )

2 3

Database indexing: slapindex
by openldap＠ayni.com 19 Jul '11

19 Jul '11

Hi listers Installation here: openldap-servers-2.4.15-7.fc11.i586 One master server, two backup servers (syncrepl). All authentication and mailing is managed by ldap. 1. About indexing: When i check the slapd-log, i see many <= bdb_equality_candidates: (uidNumber) not indexed <= bdb_equality_candidates: (gidNumber) not indexed In the discussion about slapd tuning http://www.openldap.org/doc/admin24/tuning.html#Indexes, however, i read that if each entry in a certain set of ldap-entries has got the candidate-attribute, it is not worth while to index the attribute, because slapd needs to read each entry in any case in order to find the requested one. this is the case for uidNumber as well as gidNumber, because both are compulsory attributes for objectClass posixAccount. My first question: is it therefore correct to disregard the above indexing requests of slapd? 2. About slapindex: When it comes to use slapindex, the docu is not clear about how to do that. Some places say, that you need to stop slapd entirely, some places say that it is sufficient to put slapd in read-only mode for the corresponding background database, which in this case would be /etc/openldap/slapd.d/cn=config/olcDatabase\=\{2\}bdb.ldif this file contains both the olcReadOnly and the olcDbIndex attributes. So i could just add the following two lines in the above file: olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq set the olcReadOnly attribute to TRUE, and restart slapd, and everything would be done automatically? Or would i need to invoke slapindex additionally with the following command slapindex -c And if i had to start slapindex additionally, would slapindex tell me, that the database is in read-only mode, so no changes are possible, not even index changes? And, if i had to start slapindex additionally, i would do it as root. the files generated by slapindex would they be owned by root (inaccessible by slapd) or by the slapd user? Would the new indexes be propagated to the backup servers by syncrepl automatically? If not, what would i have to change on the backup servers? Thank you for your attention suomi

2 1

TLS configuration with syncrepl
by Naga Chaitanya Palle 19 Jul '11

19 Jul '11

Hi, I am configuring TLS for syncrepl. But the consumer is not reading any updates from the server. Without tls the configuration was working fine. Please let me know where I am going wrong On client, my configuration files are as follows slapd.conf access to attrs=userPassword by self write by users read by anonymous auth access to attrs=shadowLastChange by self write by * auth access to * by * read moduleload syncprov.la syncrepl rid=124 provider=ldaps://smalldevonly.comverse-in.com:389 type=refreshOnly interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=top)" scope=sub attrs="cn,uidNumber" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora updateref ldaps://smalldevonly.comverse-in.com /etc/ldap.conf uri ldaps://smalldevonly.comverse-in.com ldaps://dtr98.comverse-in.com base dc=comverse-in,dc=com ssl start_tls ssl on tls_cacertfile /etc/openldap/cacerts/cacert.pem tls_cacertdir /etc/openldap/cacerts /etc/openldap/ldap.conf BASE dc=comverse-in,dc=com URI ldaps://smalldevonly.comverse-in.com/ ldaps://dtr98.comverse-in.com TLS_CACERT /etc/openldap/cacerts/cacert.pem TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow Thanks and Regards, Naga Chaitanya =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

3 3

Re: Simple Bind w/TLS without SASL/Kerberos possible to AD?
by David Mitton 18 Jul '11

18 Jul '11

1 0

raising olcSizeLimit
by E.S. Rosenberg 17 Jul '11

17 Jul '11

Are there any negative repercussions to raising the sizelimit parameter to a high number (that encompasses the whole db), is it better to tie such limits to specific accounts that need that level of access? The documentation just says that limiting is "desirable" but a lot of people both on this list and forums seem to be setting their limits to 10k or even 30k (I guess depending on the db size). Thanks, Eli

2 1

Problem with verifying replication state with contextCSN
by Liam Gretton 15 Jul '11

15 Jul '11

I have a single provider and a single consumer, both quite lightly loaded serving a few hundred clients between them for nss_ldap. I've been trying to monitor the replication state by comparing contextCSN on both systems, but I'm finding that on the consumer contextCSN is more often than not older than the most recent entryCSN value. I read contextCSN as so: ldapsearch -H ldap://ldapserver1.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715120001.914244Z#000000#000#000000 ldapsearch -H ldap://ldapserver2.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715085237.656585Z#000000#000#000000 Looking at the values of entryCSN for ldapserver2 (the consumer): ldapsearch + | grep entryCSN | sort -u ... entryCSN: 20110714154009.500299Z#000000#000#000000 entryCSN: 20110715085237.656585Z#000000#000#000000 entryCSN: 20110715120001.914244Z#000000#000#000000 It can be seen that the most recent entryCSN matches the contextCSN of the provider, but its own contextCSN is an entry behind (often its two or three entries old). The replication is up to date, but contextCSN on the consumer doesn't seem to be getting updated in all circumstances. The consumer is replicating using syncrepl refreshAndPersist. Here's the syncrepl configuration for the consumer: syncrepl rid=001 provider=ldap://ldapserver1.company.org type=refreshAndPersist interval=00:00:05:00 retry="60 +" searchbase="dc=company,dc=org" sizelimit=unlimited timelimit=unlimited binddn="cn=replication,ou=special users,dc=company,dc=org" bindmethod=simple credentials=password schemachecking=off starttls=critical I'm also using the memberOf overlay. I see in the list archives that this has been reported before, but I can't find a bug report to go with it: <http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201103/msg…> I'm using OpenLDAP 2.4.12 on 64-bit openSUSE 11.1. I haven't been able to find time to set up a test environment with the latest OpenLDAP to see if the problem exists there. Has anybody else seen this behaviour in the latest OpenLDAP? My current workaround to monitor replication status is to modify a record created for the purpose and verify that the consumer has picked it up. -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

2 1

ldapsync slapd Can't contact LDAP server
by Daniel Qian 15 Jul '11

15 Jul '11

Hi, I have a simple syncrepl setup that kind of works but every two hours there is a syncing problem from the log on the consumer side: Jul 14 01:09:57 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 01:09:57 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 03:11:12 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 03:11:12 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 05:12:26 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 05:12:26 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 07:13:41 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 07:13:41 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 09:14:55 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 09:14:55 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 11:16:10 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 11:16:10 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 13:17:24 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 13:17:24 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 15:18:39 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 15:18:39 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) Jul 14 17:19:53 ldapsync slapd[1636]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Jul 14 17:19:53 ldapsync slapd[1636]: do_syncrepl: rid=002 rc -1 retrying (29 retries left) log from the provider looks better: Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 fd=20 ACCEPT from IP=x.x.x.x:1093 (IP=0.0.0.0:389) Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 op=0 BIND dn="cn=replica,dc=mydomain,dc=com" method=128 Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 op=0 BIND dn="cn=replica,dc=mydomain,dc=com" mech=SIMPLE ssf=0 Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 op=0 RESULT tag=97 err=0 text= Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 op=1 SRCH base="dc=mydomain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Jul 14 19:18:50 ldaprov1 slapd[8459]: conn=30513 op=1 SRCH attr=* + Here is the configuration for the consumer: dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=mydomain,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=mydomain,dc=com olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=002 provider="ldap://ldaprov1.prod:389/" type=refreshAndPe rsist retry="60 30 300 +" searchbase="dc=mydomain,dc=com" bindmetho d=simple binddn="cn=replica,dc=mydomain,dc=com" credentials=mypasswor d olcMonitoring: TRUE 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 olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 And from the consumer side everything looks good if I manual ldapsearch with the replica account "cn=replica,dc=mydomain,dc=com" Can anyone shed some lights on how to troubleshoot this kind of problems? Thanks, Daniel

2 2

looking for entires with objectclass=glue
by Andreas Haubod 14 Jul '11

14 Jul '11

Hello, I've running two ldap server using N-Way multimaster replication. I want find all objects with "objectclass=glue". If I use JXEplorer to search "objectclass=glue" I get 136 entries back. If I use ldapsearch or Apache DS and do the same, no entries are found. In the slapcat backup from the ldap server the entires with objectclass: glue exists. So I turned "loglevel 256" in the slapd.conf. I got for JXEplorer and ldapsearch the same search: JXEplorer: slapd[23362]: conn=1001 op=7 SRCH base="ou=root" scope=2 deref=3 filter="(objectClass=glue)" slapd[23362]: conn=1001 op=7 SRCH attr=objectClass slapd[23362]: conn=1001 op=7 SEARCH RESULT tag=101 err=0 nentries=136 text= ldapsearch: slapd[23362]: conn=1004 op=1 SRCH base="ou=root" scope=2 deref=3 filter="(objectClass=glue)" slapd[23362]: conn=1004 op=1 SRCH attr=objectclass slapd[23362]: conn=1004 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= How can I get the glue entires via ldapsearch? Thanks Andreas

1 1

ppolicy in Solaris 10
by Wynand Jansen van Vuuren 14 Jul '11

14 Jul '11

My slapd.conf file is as follow # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload ppolicy.la # moduleload /usr/local/libexec/openldap/ppolicy.so # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la and overlay ppolicy ppolicy_default "cn=default,ou=Policies,dc=rorotika,dc=com" ppolicy_use_lockout When I start slapd in debug with d 255, I get the following "error"? ine 21 (loglevel 4) line 22 (pidfile /usr/local/var/run/slapd.pid) line 23 (argsfile /usr/local/var/run/slapd.args) line 26 (modulepath /usr/local/libexec/openldap) line 27 (moduleload ppolicy.la) loaded module ppolicy.la module ppolicy.la: null module registered line 65 (access to dn.base="" by * read) >>> dnNormalize: <> <<< dnNormalize: <> Backend ACL: access to dn.base="" by * read The line that consern me is "module ppolicy.la: null module registered", is this a problem? The ppolicy does not seen to overlay... It seems that the Solaris 10 settings is still valid, for example It seems that this policy is not activated, for example the pwdMinLength: is set to 3, but when the user changes his/her password, it seems that the Solaris policy takes over from the /etc/default/passwd file test5:/ $ ssh admin777(a)10.1.1.5 * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * * THIS SYSTEM IS RESTRICTED TO AUTHORIZED USERS FOR AUTHORIZED USE ONLY. UNAUTHORIZED ACCESS IS STRICTLY PROHIBITED AND MAY BE PUNISHABLE UNDER THE COMPUTER FRAUD AND ABUSE ACT OR OTHER APPLICABLE LAWS. IF NOT AUTHORIZED TO ACCESS THIS SYSTEM, DISCONNECT NOW. BY CONTINUING, YOU CONSENT TO YOUR KEYSTROKES AND DATA CONTENT BEING MONITORED. ALL PERSONS ARE HEREBY NOTIFIED THAT THE USE OF THIS SYSTEM CONSTITUTES CONSENT TO MONITORING AND AUDITING. * * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * * Password: Last login: Tue Jul 12 11:14:22 2011 from test5.example. Sun Microsystems Inc. SunOS 5.10 Generic January 2005 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 Sourcing //.profile-EIS..... test5:/ $ id uid=5011(admin777) gid=1000(users) groups=1000(users) test5:/ $ passwd passwd: Changing password for admin777 Enter existing login password: New Password: passwd: Password too short - must be at least 8 characters. Please try again New Password: test5:/ $ cat /etc/default/passwd #ident @(#)passwd.dfl 1.7 04/04/22 SMI # # Copyright 2004 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # MAXWEEKS=13 MINWEEKS= PASSLENGTH=8 # NAMECHECK enables/disables login name checking. Could someone point me in the right direction please?

1 0

Database indexing: use of slapindex
by anax 14 Jul '11

14 Jul '11

Hi listers Installation here: openldap-servers-2.4.15-7.fc11.i586 One master server, two backup servers (syncrepl). All authentication and mailing is managed through ldap. 1. About indexing: When i check the slapd-log, i see many <= bdb_equality_candidates: (uidNumber) not indexed <= bdb_equality_candidates: (gidNumber) not indexed In the discussion about slapd tuning http://www.openldap.org/doc/admin24/tuning.html#Indexes, however, i read that if each entry in a certain set of ldap-entries has got the candidate-attribute, it is not worth while to index the attribute, because slapd needs to read each entry in any case in order to find the requested one. this is the case for uidNumber as well as gidNumber, because both are compulsory attributes for objectClass posixAccount. My first question: is it therefore correct to disregard the above indexing requests of slapd? 2. About slapindex: When it comes to use slapindex, the docu is not clear about how to do that. Some places say, that you need to stop slapd entirely, some places say that it is sufficient to put slapd in read-only mode for the corresponding background database, which in this case would be /etc/openldap/slapd.d/cn=config/olcDatabase\=\{2\}bdb.ldif this file contains both the olcReadOnly and the olcDbIndex attributes. So i could just add the following two lines in the above file: olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq set the olcReadOnly attribute to TRUE, and restart slapd, and everything would be done automatically? Or would i need to invoke slapindex additionally with the following command slapindex -c And if i had to start slapindex additionally, would slapindex tell me, that the database is in read-only mode, so no changes are possible, not even index changes? And, if i had to start slapindex additionally, i would do it as root. the files generated by slapindex would they be owned by root (inaccessible by slapd) or by the slapd user? Would the new indexes be propagated to the backup servers by syncrepl automatically? If not, what would i have to change on the backup servers? Thank you for your attention suomi

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