openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Openldap password problems
by jeevan kc 16 May '15

16 May '15

Hello all,We've just noticed that when a user authenticates via LDAP, it ignores characters after the right password. For example a user jkc900 has Password Welcome1 But the user can type in Welcome1111 or Welcome12 etc and still can get into the application. Its just checking the first Welcome1 and they can type anything after that and still can log in. We've tested at least 50 users and they all have the same issues. Any clues/ solution for this? Your inputs are highly appreciated. Jeevan

8 19

How to add index for particular attribute in openldap 2.4.40
by PRATIK SINGAL 16 May '15

16 May '15

Hi Can anyone help me on how to add index for entire object class and as well as for the particular attribute of objectclass . Here am using berkerly DB(bdb).

2 1

OpenLDAP - 2.4.39 , 2-way multimaster replication freezes
by shashidhar v 15 May '15

15 May '15

Hi , I am trying to configure and use the openldap 2-WAY Multimaster Replication setup for high availability(HA), but the HA solution used to freeze very often. Using ansible tool I have automated the installation and configuration steps. I tried with manual steps too before using the ansible for the actual deployment Following are the env. details used for installation and configuration Two nodes ldap-test1 and ldap-test2 are running with base OS RHEL7 LDAP rpms installed: openldap-clients-2.4.39-6.el7.x86_64 openldap-servers-2.4.39-6.el7.x86_64 openldap-2.4.39-6.el7.x86_64 Configuration steps: 1. Added the nis, cosine schemas ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f cosine.ldif ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f nis.ldif 2. Send the new global configuration settings to slapd 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/global_config.ldif # cat global_config.ldif dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: syncprov dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,dc=example,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}vAp3OToPGMYnWEkh+76RJEVyfCIdnsDg dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/cacert.pem dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/slapdcert.pem dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/slapdkey.pem dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: -1 dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,dc=example,dc=com" read by * none dn: cn=config changeType: modify add: olcServerID olcServerID: 1 dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootDN olcRootDN: cn=admin,cn=config dn: cn=config changetype: modify dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}vAp3OToPGMYnWEkh+76RJEVyfCIdnsDg dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldaps://ldap-test1 olcServerID: 2 ldaps://ldap-test2 3. Load base.ldif ldapadd -x -w redhat7 -D cn=Manager,dc=example,dc=com -f /etc/openldap/base.ldif # cat base.ldif dn: dc=example,dc=com dc: example objectClass: top objectClass: domain dn: ou=People,dc=example,dc=com ou: People objectClass: top objectClass: organizationalUnit dn: ou=Group,dc=example,dc=com ou: Group objectClass: top objectClass: organizationalUnit 4. Load hdb_config.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/hdb_config.ldif #cat hdb_config.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,dc=example,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {{ ldap_root_password.stdout }} dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcDbIndex olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq 5. Load replication.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/replication.ldif cat replication.ldif dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=101 provider=ldaps://ldap-test1 binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=redhat7 searchbase="dc=example,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=102 provider=ldaps://ldap-test2 binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=redhat7 searchbase="dc=example,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 - replace: olcMirrorMode olcMirrorMode: TRUE dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=101 provider=ldaps://ldap-test1 binddn="cn=admin,cn=config" bindmethod=simple credentials=redhat7 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=102 provider=ldaps://ldap-test2 binddn="cn=admin,cn=config" bindmethod=simple credentials=redhat7 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - replace: olcMirrorMode olcMirrorMode: TRUE Above configuration steps 1 to 4 are executed parallely on both nodes , only step 5 ie. replication.ldif was executed serially one node after the other because parallel execution of step 5 causing the solution to freeze Parallel execution on both nodes : 1. Added the nis, cosine schemas 2. Send the new global configuration settings to slapd 3. Load base.ldif 4. Load hdb_config.ldif , executed on any one of two nodes assuming that content will replicated automatically on other node once the servers are replicated Serial execution : Executed on both nodes one after the other 5. Load replication.ldif Sometimes LDAP replication is causing the solution to freeze and it may hung during the deployment , after deployment or while executing some basic ldap operations like ldapadd/modify/delete etc 1. First thing I would like to know Is there any specific order we need to follow to avoid solution freeze or ldapadd command hung with two nodes configuring parallely ? 2. Anything wrong with the configuration attributes used ? If so what attributes I need to add/update to avoid the command/service hung during configuration or after the deployment ? 3. To verify the high availability I used to stop ldap service any one of the two nodes and send the ldap requests to other node, but sometimes the restart of the service not bringing back the two nodes in Sync. And for replication I am verifying based on number of connections established between two servers ( min. 4 , 2 for config replication and 2 for db replication ) And unittest to verify db replication by creating an ldap user on one node and search & delete operations on the other node. 4. Whenever the basic ldap commands add/modify etc hung on any one node , I used to restart the slapd service on the corresponding node, Is it the right way ? HA solution is working fine by configuring above steps in the given order, ldap services are restarted and in Sync, but sometimes the solution used to freeze when executing basic ldapadd commond on any one node There are no specific error messages in the logs to understand the reason for hung. May 15 22:20:17 ldap-test2 slapd[8538]: daemon: epoll: listen=7 active_threads=0 tvp=zero May 15 22:20:17 ldap-test2 slapd[8538]: daemon: epoll: listen=8 active_threads=0 tvp=zero Always a single restart is also not helping to bring the servers back to sync and available, sometimes the number of tcp connections are 3 instead of required 4 connections [root@ldap-test1 openldap]# netstat -a | grep ldaps tcp 0 0 ldap-test1:ldaps 0.0.0.0:* LISTEN tcp 0 0 ldap-test1:34854 ldap-test2:ldaps ESTABLISHED tcp 0 0 ldap-test1:ldaps ldap-test2:48493 ESTABLISHED tcp 0 0 ldap-test1:34856 ldap-test2:ldaps ESTABLISHED Used to restart couple of times until 4 tcp connections are established and servers are replicated properly 5. Can someone please help me to get rid of this situation ? I didn't find any clue in the archived messages etc for similar kind of problems. Thanks & Regards, Shashi

1 0

Server is unwilling to perform trying to remove an overlay
by Angel L. Mateo 15 May '15

15 May '15

Hello, I have a 2.4.31 openldap server (running in an ubuntu server 14.04) using cn=config for configuration. Now, I'm trying to remove an overlay from my database (ppolicy overlay to be specific) and whenever I run the ldapmodify deleting the entry I get ldap_delete: Server is unwilling to perform (53) I have read in older posts in this list that delete operation is not implemented in cn=config database. Is this still not implemented? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337

2 1

openldap 2.4.40 ldapserach limit
by PRATIK SINGAL 15 May '15

15 May '15

Hello can any one help me out where to increase the ldapseach size limit.In 2.4.23 there was no issue when i used to search 100000 records but in 2.4.40 it gives me a error [root@localhost ~]# ldapsearch -x -LLL -b "dc=example,dc=com" -s one "objectclass" | grep ^dn: | wc -l Size limit exceeded (4) 500

2 2

ppolicy and ACL question
by Harmandeep Kaur 13 May '15

13 May '15

Hello folks, I have a quick query, I'm using openldap with ppolicy. I'm using following ACL just to test things right, I came across the issue, for which I'm unable to find appropriate answers: ACL used: --- access to * by * manage --- 1. How to restrict ldappasswd command to clear the pwdReset flag to user's entry ? 2. Can some other users (member of group) can work rootdn (bypass ppolicy like rootdn but it should apply to their account itself) ? 3. Other question is about ACL is "What's the difference between ACL "write" and "manage" access" write =wrscdx needed to modify/rename manage =mwrscdx needed to manage I'm not able to determine what access "manage" gives over and above "write" access. I didn't find much info at openldap.org access-control section. Thank you. Regards,

2 1

Subject: Re: Fast key range iteration
by James Rouzier 13 May '15

13 May '15

Here is a faster to do way to do what you want. Just get the last key of your range and while iterating compare the data pointer of the last key to see if you reach the end instead of the it's content. As long as you are in the same transaction the data pointer of the last key should never change. (Someone correct me if I am wrong). Here is a quick example of what I mean. MDB_cursor *cursor; MDB_val first_key, key, data; MDB_val last_key1, last_key2, last_data; int rc; //Get the last key rc = mdb_cursor_get (cursor, &last_key1, &last_data, MDB_SET_RANGE); //If the current position is not equal move back one spot if (rc == MDB_SUCCESS && mdb_cmp (mdb_cursor_txn (cursor), mdb_cursor_dbi (cursor), &last_key1, &last_key2)) { rc = mdb_cursor_get (cursor, &last_key1, &last_data, MDB_PREV); } //This means that nothing is equal or greater than the last key or the last key is at the first position if (rc) { last_data.mv_data = NULL; } //Get the first key rc = mdb_cursor_get (cursor, &first_key, &data, MDB_SET_RANGE); if(rc == MDB_SUCCESS) { do { } while (mdb_cursor_get (cursor, &key, &data, MDB_NEXT) == MDB_SUCCESS && data.mv_data != last_data.mv_data); } > Hi all! > Is there a way to iterate with all key-value pairs in LMDB database, where all keys is in specified range? > I'm trying to use mdb_cursor_get() with MDB_SET_RANGE to search first pair. > Then I see only one way - use mdb_cursor_get() with MDB_NEXT and compare key by memcmp(). > But it seems absolutely not effective. > > Is there another solution for my task? > > Thanks!

3 3

Re: insert utf-8 data with c api (solved)
by yvan vander sanden 13 May '15

13 May '15

Just found out what was wrong. The code was also propagating the displayName value to gecos. We used gecos as an extra copy of displayName because of one client application which only did work with gecos. The error wasn't noticed before because now for the first time we had a user with an umlaut in his name. We could just remove gecos from the directory altogether because the program in question isn't in use any more. But isn't a gecos value supposed to hold a full name? It being unable to hold an utf8 value seems somehow wrong, no? Regards, yvan -- ==- yvan vander sanden -== * composer, programmer * >>> http://mutecode.com -* MUTE software development* >>> http://attr-x.net - *online interactive soundscape* >>> http://code.google.com/p/yse-soundengine/ - *advanced 3D sound engine* >>> http://youngmusic.org - *personal website* >>> http://www.matrix-new-music.be/componist/vander-sanden-yvan-1972 - *bio @ matrix* <http://youngmusic.org>

2 1

MMR (delta-syncrepl): CPU at 100% after replication
by Liam Gretton 12 May '15

12 May '15

I'm building a new setup with the latest OpenLDAP built from source, using mdb, MMR delta-syncrepl over TLS. I'm using very recent sources, I have two hosts and I'm finding that once the secondary host has synchronised with the first (this takes about 10 minutes for around 40000 entries), slapd on each of the peers remains at close to 100%. Replication is working though. The sync logs at this point on the first system in the set (where the original data was slapadded) is showing the following entries endlessly: 554fbe2c do_syncrep2: rid=002 CSN too old, ignoring 20131221210532.737643Z#000000#001#000000 (reqStart=20150509214300.000163Z,cn=log) contextCSN on both systems looks good. ldap1 is serverID 1, rid 1; ldap2 is serverID 2, rid 2. I guess the SID 0 comes from the original data that was imported into ldap1. # ldap1search -s base contextCSN dn: dc=example,dc=com contextCSN: 20150511090001.208713Z#000000#000#000000 contextCSN: 20150511091334.137305Z#000000#001#000000 # ldap2search -s base contextCSN dn: dc=example,dc=com contextCSN: 20150511090001.208713Z#000000#000#000000 contextCSN: 20150511091334.137305Z#000000#001#000000 On ldap2 the stats log shows very many corresponding searches of the log DB: 5550763e conn=1000 op=11653 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5550763e conn=1000 op=11653 SRCH attr=* + 5550763e conn=1000 op=11653 SEARCH RESULT tag=101 err=0 nentries=0 text= 5550763e conn=1000 op=11654 SRCH base="cn=log" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" 5550763e conn=1000 op=11654 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 5550763e conn=1000 op=11655 ABANDON msg=11655 Both systems have the host name specified in the -h option to slapd. Clocks are synchronised, DNS is working etc. I can't get to the bottom of this at all. No doubt I've made an error in my MMR config. Does anyone have a clue as to why this could be happening? I'd be very grateful for any ideas. Here's (most of) the slapd.conf file, which is identical on both. I must admit I'm not sure whether the serverID settings are global or per-database. Moving them into the mdb section doesn't change the behaviour though. # Server IDs for replication serverID 1 ldap://ldap1 serverID 2 ldap://ldap2 ############################################################# # # Access log database configuration # # This is also used for delta-syncrepl replication # # See slapd-accesslog(5) for details # ############################################################# database mdb maxsize 209715200 suffix cn=log directory /db/ldap/accesslog rootdn cn=log rootpw secret index entryCSN eq index objectClass eq index reqEnd eq index reqResult eq index reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replication,ou=special users,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Replication user can read (not write) everything access to * by dn.exact="cn=replication,ou=special users,dc=example,dc=com" read by * none break ############################################################# # # Database configuration # # see slapd-mdb(5) for details # ############################################################# database mdb monitoring on suffix dc=example,dc=com directory /db/ldap/example rootdn "cn=administrator,ou=special users,dc=example,dc=com" maxsize 209715200 # Default password hashing scheme password-hash {SSHA} # memberOf overlay provides reverse-lookups of group membership overlay memberof # sssvlv overlay provides server-side sorting # Used mainly to allow easy sorting of uidNumber/gidNumber values overlay sssvlv sssvlv-max 4 sssvlv-maxkeys 5 sssvlv-maxperconn 4 # unique overlay provides attribute uniqueness # We use this to enforce unique uidNumber/gidNumber values overlay unique unique_uri ldap:///ou=people,dc=example,dc=com?uidNumber?one? unique_uri ldap:///ou=group,dc=example,dc=com?gidNumber?one? ### CONSUMER configuration syncrepl rid=1 provider=ldap://ldap1 type=refreshAndPersist bindmethod=simple binddn="cn=replication,ou=special users,dc=example,dc=com" credentials=password syncdata=accesslog interval=00:00:00:10 retry="20 10 60 10 120 +" timeout=1 logbase="cn=log" searchbase="dc=example,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" sizelimit=unlimited timelimit=unlimited schemachecking=on starttls=yes syncrepl rid=2 provider=ldap://ldap2 type=refreshAndPersist bindmethod=simple binddn="cn=replication,ou=special users,dc=example,dc=com" credentials=password syncdata=accesslog interval=00:00:00:10 retry="20 10 60 10 120 +" timeout=2 logbase="cn=log" searchbase="dc=example,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" sizelimit=unlimited timelimit=unlimited schemachecking=on starttls=yes ### PROVIDER configuration overlay syncprov syncprov-checkpoint 5 5 syncprov-sessionlog 50 mirrormode on # Access log - used for delta-syncrepl too overlay accesslog logdb cn=log logops writes logold (objectClass=*) logsuccess TRUE logpurge 28+00:00 1+00:00 # Allow unlimited access for replication user limits dn.exact="cn=replication,ou=special users,dc=example,dc=com" size=unlimited time=unlimited -- Liam Gretton liam.gretton(a)le.ac.uk Systems Specialist http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

2 4

TLS failing?
by Albert Braden 11 May '15

11 May '15

I'm setting up new LDAP servers with replication, and I configured TLS, but I see this in my log: May 11 14:29:07 nyprldap1 slapd[8867]: conn=2572 op=1 BIND dn="cn=manager,dc=about,dc=com" method=128 May 11 14:29:07 nyprldap1 slapd[8867]: conn=2572 op=1 BIND dn="cn=manager,dc=about,dc=com" mech=SIMPLE ssf=0 Does this mean that TLS is failing and it is falling back to ssf=0? I think my master is configured to not allow unencrypted connections: disallow bind_anon require bind security simple_bind=128 Albert Braden About.com Systems Operations 1500 Broadway 6th Floor New York, NY 10036 desk: 212-204-1448 | mobile: 917-480-1090 aim:albertatabout

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical