openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank 13 Mar '11

13 Mar '11

I've found an interesting issue with delta-sync replication in which the ContextCSN on my consumers, is higher than the contextCSN on my provider. I believe this is causing some other problems with bringing up brand new consumers. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=1001+uidNumber=1010,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So we can see that the two consumers have matching: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ContextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 The providers CSN is smaller: contextCSN: 20110313041653.709140Z#000000#000#000000 Now I will search cn=accesslog on the Provider: These are the last two entries: # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z # search result search: 2 result: 0 Success As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Is this intended? An issue I've experienced with this is when bringing up a brand new consumer. It gets stuck in a loop trying to add that last entry. I'm guessing this has something to do with it using the wrong ConextCSN? - Yuri

2 1

ldapsearch and extended server controls?
by Brian Reichert 11 Mar '11

11 Mar '11

I have a case where I'm trying to replicate some other application's search against Active Directory. A deconstruction of a packet capture of that app's conversation shows it's making use of a control that I don't know how to specify using any combination of ldapsearch(1) or ldap.conf(5). Specifically, I see this coming over the wire as a control on the search: http://msdn.microsoft.com/en-us/library/aa366989%28v=vs.85%29.aspx 1.2.840.113556.1.4.417 LDAP_SERVER_SHOW_DELETED_OID Research shows there lots these sorts of extended control; yay, I learned something new! Is there a way of utilizing these sorts of controls via ldeapsearch? Thanks for any advice you may have... -- Brian Reichert <reichert(a)numachi.com> 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large

2 2

Re: LDAP browsers and cn=config
by Gervase Markham 11 Mar '11

11 Mar '11

Hi Torsten, Thanks for your help! On 07/03/11 17:37, Torsten Schlabach (Tascel eG) wrote: > Take a look at the olcAccess attribute values of your cn=config database. > This should tell you who's allowed to read it or not. I did add a value to try and make this work (see below), but perhaps I haven't done all that's necessary. > It depends where your cn=config data comes from, but in many examples you > will find an olcAccess attribute granting write access to a DN called > cn=admin,cn=config. You need to have that object in your cn=config database > then and it should have the password attribute set. > > Post the olcAccess sections of your LDIF here, I think this may help. Here is my olcDatabase={0}config.ldif, with some comments: dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break # This one added by me recently: olcAccess: {0}to * by dn.exact=cn=admin,cn=config manage by * break structuralObjectClass: olcDatabaseConfig entryUUID: 9dfea13e-dd1c-102f-8cc4-2fe95e0d0dbe creatorsName: cn=config createTimestamp: 20110307153755Z entryCSN: 20110307153755.993390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20110307153755Z # These two added by me recently: oldRootDN: cn=admin,cn=config olcRootPW: config So it looks like I just need to make sure I have the cn=admin,cn=config object in my database. And I think I can probably add it using the magic -Y EXTERNAL method and ldapadd. However, I don't know how to construct it - what objectClass should it have? Gerv

5 9

Simple Bind pass-through to SASL/PLAIN
by Zach Schimke 11 Mar '11

11 Mar '11

Is there any trick to this? I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly with my ldap server. What I want to get working is the authentication pass-through. From what I can gather, it appears that LDAP should be able to authenticate a simple bind, take a look at the userPassword attribute (which contains '{SASL}username@REALM) and perform a SASL/PLAIN from there. We want to avoid maintaining two separate passwords (LDAP and Kerberos V) although some applications (like phpLDAPAdmin, Drupal, etc) do not allow the use of Kerberos natively. /etc/sasl2/slapd.conf (using CentOS): pwcheck_method: saslauthd Here's a snippet of my openldap.log during a simple bind: Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from IP=149.169.147.254:56106 (IP=0.0.0.0:636) Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS established tls_ssf=256 ssf=256 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND dn="cn=test account,ou=people,o=mars" method=128 Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009 op=0 p=3 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97 err=49 text= Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying conn=2009 sd=39 for close Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed (connection lost) Anything I should double-check, modify, etc? -- Zach Schimke Mars Space Flight Facility

4 10

php ldap binding problems
by Bram Cymet 11 Mar '11

11 Mar '11

Hi, Has anyone had to problem using php_ldap where the bind to ldap will work find but will unbind right away so any attempt to search the tree fails? If so were you able to fix it? -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

4 3

Null Search Base
by ldap＠mm.st 10 Mar '11

10 Mar '11

A security scanner was run against our ldap severs and came back with a warning stating "The remote LDAP server supports search requests with a null, or empty, base object. This allows information to be retrieved without any prior knowledge of the directory structure. Coupled with a NULL BIND, an anonymous user may be able to query your LDAP server using a tool . . ." I'm not overly concerned with the warning, but I was a little confused what the scanner was reffering to. I used the following search in an effort to somewhat duplicate what the scanner was sending and what information is retrieved and was hoping someone could commet if I was ontrack. I assume the warning is due to the namingContext attribute and if desired an acl could be setup to stop the retrival on the information. This is on a RH5 openlap 2.3 server. ldapsearch -x -s base -b '' -H ldap://my.lapdap.server "(objectClass=*)" "*" + I got back this: # dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=mydomain supportedControl: 1.3.6. ..... . . . . supportedControl: 1.3.6. ..... supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema

3 2

Remove/Cleanup pwdHistory attribute.
by Meghanand Acharekar 10 Mar '11

10 Mar '11

Hi, Is it possible to change/remove pwdHistory attribute from an individual entry. I'm trying to change/remove using following ldif. dn: uid=user1,ou=People,dc=example,dc=com changetype: modify replace: pwdHistory pwdHistory: 0 and dn: uid=user1,ou=People,dc=example,dc=com changetype: delete delete: pwdHistory Both the tries gives following error. ldapmodify: Constraint violation (19) additional info: pwdHistory: no user modification allowed Thanks in advance. Regards, Meghanand N. Acharekar ------------------------------------------ The gates in my computer are AND, OR and NOT; they are not Bill..

1 0

JLDAP question
by PhilNad214 PhilNad214 10 Mar '11

10 Mar '11

Hi, we've had JLDAP enbedded in our project for 3-4 years and it's been easy to maintain (actually no maintenance required!). I now need to extend it and need to find out a few things - I must confess to not knowing much about LDAP and what its query language is capable of, so if I ask the question here I'm sure if it cannot be answered easily then someone will recommend a good web resource :-) Our first issue, currently we use LDAPConnection.search() to retrieve all the users that are members of a group in a particular OU. This has always been fine with small setups where admins have happily made (manually) the users part of the group. However in larger LDAP setups, where the users may already be in one of several groups, it 's a lot of extra work (potentially) to manage them (making them all members also of our group). What we'd ideally like is for the admins to be able to add those existing groups themselves to our group. This is possible of course, but when we are iterating over the search results, we get all the existing individually added members, but when it comes to an added group, we get just the group entry (no real surprise). So my question is, can the search be written in a way that if the search results was to include a group, all the members of that group are actually returned in the results? (Sort of like 'auto-expand' groups.) If that isn't possible then I assume we'll have to refactor our code to automatically do another search within the search if we encounter a group entry within the results? BTW here is a trimmed-down version of the search code: String aGroupname = "bob"; int searchScope = LDAPConnection.SCOPE_SUB; String attrs[] = { "msDS-UserAccountDisabled", "ms-DS-UserAccountAutoLocked", "msDS-UserPasswordExpired", "isDeleted", "CN", "sAMAccountName", "distinguishedName", "givenName", "middleName", "sn", "memberOf", "mail", "name", "employeeID"}; boolean attributeOnly = false; String searchDN = "OU=...."; String searchFilterA = "(memberOf=CN="+aGroupname+","+searchDN + ")"; String searchFilterB = "(memberOf=sAMAccountName="+aGroupname+","+searchDN + ")"; String searchFilter = "(|" + searchFilterA + searchFilterB + ")"; LDAPSearchConstraints cons = new LDAPSearchConstraints(); cons.setTimeLimit(10000); LDAPSearchResults searchResults = _lc.search(searchDN, // container to search searchScope, // search scope searchFilter, // search filter attrs, // "1.1" returns entry name only attributeOnly, // no attributes are returned cons); // time out value while (searchResults.hasMore()) .... etc .... Cheers, Phil

1 0

syncrepl with with multiple subordinate databases
by Dieter Kluenter 09 Mar '11

09 Mar '11

Hi, I am facing a severe problem with the replication of subordinate databases and a log database. The initial replication of the subordinate databases is successful but afterwards slapd crashes, A backtrace and a momory map can be found here http://pastebin.de/15919 the provider slapd.conf can be found here http://pastebin.de/15920 the consumer slapd.conf can be found here http://pastebin.de/15922 -Dieter -- Dieter Klünter | Systemberatung sip: 7770535(a)sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

2 1

[Solved] Poor performance on Solaris
by Juergen.Sprenger＠swisscom.com 09 Mar '11

09 Mar '11

Hi, first I wish to thank all those who supplied helpful hints to solve the problem, especially Quanah Gibson-Mount and Howard Chu. My performance issue was solved by switching from memory mapped keys to shared memory keys for hdb as suggested by Quanah and Howard. Putting 'shm_key 10' into slapd.conf and restart of slapd solved the problem. Performance improvement was about factor 10 on the Solaris box. As the problem was gone connection logging was switched off, which additionally doubled throughput as Solaris sylog can't do asynchronous logging. During further tests slapd stopped responding when many concurrent connections were active. This behaviour was caused by default settings in /etc/system. Adding two lines to /etc/system and reboot solved the problem: set rlim_fd_max = 16368 set rlim_fd_cur = 8192 Should be enough for about 8000 connections. Performance before: box1: hardware: Sun Microsystems sun4v SPARC Enterprise T5120 memory:32 GB RAM os: Solaris 10 s10s_u9wos_14a searches (avg/second): 1521 Performance after: box1: hardware: Sun Microsystems sun4v SPARC Enterprise T5120 memory:32 GB RAM os: Solaris 10 s10s_u9wos_14a searches (avg/second): 37000 My next step will be tuning network parameters. Juergen Sprenger

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical