openldap-technical

openldap-technical@openldap.org

10 participants
9969 discussions

rewriting (invalid) bindDN ?
by g-openldap-technical-list＠lachenal.net 11 May '10

11 May '10

Hi list, I've just set up a ldap proxy on witch I wish users may bind with their cn instead of dn. Some reading let me say it's possible - slapo-rwm (5) - http://blogs.turmzimmer.net/2008/06/26#ldap-3 - http://www.openldap.org/lists/openldap-software/201004/msg00065.html and some more I run slapd 2.4.11 from Debian Lenny. Here is slapd.conf : slapd.conf> ################################################################## slapd.conf> # Global Directives: slapd.conf> disallow bind_anon slapd.conf> require authc slapd.conf> include /etc/ldap/schema/core.schema slapd.conf> include /etc/ldap/schema/cosine.schema slapd.conf> include /etc/ldap/schema/nis.schema slapd.conf> include /etc/ldap/schema/inetorgperson.schema slapd.conf> pidfile /var/run/slapd/slapd.pid slapd.conf> argsfile /var/run/slapd/slapd.args slapd.conf> loglevel -1 slapd.conf> modulepath /usr/lib/ldap slapd.conf> moduleload back_ldap slapd.conf> moduleload rwm slapd.conf> sizelimit 500 slapd.conf> tool-threads 1 slapd.conf> ################################################################## slapd.conf> # Specific Directives for database #1 slapd.conf> slapd.conf> database ldap slapd.conf> suffix "o=MyO" slapd.conf> uri "ldap://MyLDAP" slapd.conf> readonly on slapd.conf> overlay rwm slapd.conf> rwm-rewriteEngine on slapd.conf> rwm-rewriteContext bindDN slapd.conf> rwm-rewriteRule "(.*)" "cn=$1,ou=SubOU,ou=OU,o=MyO" ":" When trying to bind from Thunderbird as client with just "MyCN", connection fail with "invalid dn". I expected some info about rwm rewriting syslog> slapd[11027]: conn=5 op=0 do_bind syslog> slapd[11027]: >>> dnPrettyNormal: <MyCN> syslog> slapd[11027]: conn=5 op=0 do_bind: invalid dn (glachenal) syslog> slapd[11027]: send_ldap_result: conn=5 op=0 p=3 syslog> slapd[11027]: send_ldap_result: err=34 matched="" text="invalid DN" syslog> slapd[11027]: send_ldap_response: msgid=1 tag=97 err=34 syslog> slapd[11027]: conn=5 op=0 RESULT tag=97 err=34 text=invalid DN When trying to bind with a valid DN, rwm works as expected. (And of course bind failed because of unexistent rewritten DN) syslog> slapd[11135]: >>> dnPrettyNormal: <cn=MyCN,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: <<< dnPrettyNormal: <cn=MyCN,ou=SubOU,ou=OU,o=MyO>, <cn=MyCN,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: conn=1 op=0 BIND dn="cn=MyCN,ou=SubOU,ou=OU,o=MyO" method=128 syslog> slapd[11135]: do_bind: version=3 dn="cn=MyCN,ou=SubOU,ou=OU,o=MyO" method=128 syslog> slapd[11135]: [rw] bindDN: "cn=MyCN,ou=SubOU,ou=OU,o=MyO" -> "cn=cn=MyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO" syslog> slapd[11135]: >>> dnPrettyNormal: <cn=cn=MyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO> syslog> slapd[11135]: <<< dnPrettyNormal: <cn=cn\3DMyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO>, <cn=cn\3DMyCN,ou=SubOU,ou=OU,o=MyO,ou=SubOU,ou=OU,o=MyO> So, why isn't rwm not used when supplying an invalid dn ? Regards, -G.-

3 2

OpenLDAP: contextCSN check across mirrors
by rahul.manchanda＠bt.com 10 May '10

10 May '10

Hello, I have configured three mirrors and am using a python script (ldapSynchCheck.py) which check the sync status on retrieving the contextCSN from both Provider and consumer I tried deleting a tree from directory and checked what is the output of the script and can still see "All of them are in sync". I believe this is happening because contextCSN is not getting updated on the respective directories and hence it will showing all in sync. However sometimes I am getting below error and it seems one of the consumer changed its contextCSN while provider was synching the data and it also confirms that provider will not change the contextCSN until it completes the sync to the consumer. 2010-05-06 15:15:51,459 - ldapSynchCheck.py - INFO - Provider is: tardis03.nat.bt.com:389 2010-05-06 15:15:51,462 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis03.nat.bt.com:389 2010-05-06 15:15:51,464 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,465 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,469 - ldapSynchCheck.py - INFO - Checking if consumer tardis02.nat.bt.com:9011 is in SYNCH with provider 2010-05-06 15:15:51,470 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis02.nat.bt.com:9011 2010-05-06 15:15:51,471 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,472 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,475 - ldapSynchCheck.py - DEBUG - Retrieving Provider contextCSN 2010-05-06 15:15:51,482 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,483 - ldapSynchCheck.py - DEBUG - Retrieving Consumer contextCSN 2010-05-06 15:15:51,513 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,515 - ldapSynchCheck.py - INFO - Provider and consumer exactly in SYNCH 2010-05-06 15:15:51,516 - ldapSynchCheck.py - INFO - Checking if consumer tardis01.nat.bt.com:9022 is in SYNCH with provider 2010-05-06 15:15:51,517 - ldapSynchCheck.py - DEBUG - Connecting to ldap://tardis01.nat.bt.com:9022 2010-05-06 15:15:51,519 - ldapSynchCheck.py - DEBUG - LDAP protocol version 3 2010-05-06 15:15:51,520 - ldapSynchCheck.py - DEBUG - Binding with o=BT 2010-05-06 15:15:51,523 - ldapSynchCheck.py - DEBUG - Retrieving Provider contextCSN 2010-05-06 15:15:51,525 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141551.044268Z#000000#003#000000 2010-05-06 15:15:51,526 - ldapSynchCheck.py - DEBUG - Retrieving Consumer contextCSN 2010-05-06 15:15:51,573 - ldapSynchCheck.py - DEBUG - contextCSN = 20100506141549.755004Z#000000#003#000000 <here it goes different> Traceback (most recent call last): File "./ldapSynchCheck.py", line 258, in <module> main() File "./ldapSynchCheck.py", line 253, in main is_insynch(ldapprov, ldapcons, options.basedn, options.threshold, logger) File "./ldapSynchCheck.py", line 188, in is_insynch delta = contextCSN_to_datetime(provcontextCSN) - contextCSN_to_datetime(conscontextCSN) File "./ldapSynchCheck.py", line 155, in contextCSN_to_datetime return datetime.datetime.fromtimestamp(time.mktime(time.strptime(gentime,"%Y%m% d%H%M%S"))) File "/software/python/lib/python2.6/_strptime.py", line 454, in _strptime_time return _strptime(data_string, format)[0] File "/software/python/lib/python2.6/_strptime.py", line 328, in _strptime data_string[found.end():]) ValueError: unconverted data remains: .044268 As I know putting a frequent checkpoint will generate a large amount of checkpoint log file and will cause issues while database recovery during crash/corrupt situations. Can someone please suggest how make this more precise? Is there any other way contextCSN keeps on changing frequently? Please suggest. Many Thanks in advance!! Rahul Manchanda GS Selfcare Platform Build Team Tel: +91 02066018100 Extn: 6178 SMTP: rahul.manchanda(a)bt.com Office: Sharda Center ,6th Floor Annex Off Karve Road, Erandwana ,Pune-04

4 6

Re: LDAP/PAM First time
by zoolook 10 May '10

10 May '10

2010/5/4 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, May 04, 2010 11:01 AM +0100 Rus Foster <vaserv(a)gmail.com> >> What have I missed? > > Use the correct -b option to ldapsearch. and/or configure /etc/ldap/ldap.conf or whatever your distro uses

1 0

Encrypting passwords
by Miha Krajnc 09 May '10

09 May '10

Greetings, some time ago i saw a command (i'm guessing from the ldap-utils package) that would encrypt text into one of the encryptions supported by openldap (md5, crypt etc...) anyone know what that command is? Thanks! -- Lep pozdrav, Miha Krajnc.

3 5

ldapmodify chando password
by Márcio Luciano Donada 07 May '10

07 May '10

Hi list, I'm using ldapmodify to change the user password, but I am not able to use the MD5 it. My question is, you can use the encryption method with the ldapmodify? thanks -- Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br> Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.

1 0

Re: bdb_index_read: failed
by Chris Jacobs 07 May '10

07 May '10

Ah, hah. I admit, I hadn't read that far back and made some ass/umptions. Doh. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ----- Original Message ----- From: Howard Chu <hyc(a)symas.com> To: Chris Jacobs Cc: 'arwin(a)infopact.nl' <arwin(a)infopact.nl>; 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org> Sent: Fri May 07 01:06:15 2010 Subject: Re: bdb_index_read: failed Chris Jacobs wrote: > This was all assuming that this was an established service - and if you've > simply taken over an admin role, this could have been going on for a while > and the final 'culprit' may simply be missing indexes. There is no missing index. The index is working correctly, it was simply asked to find a value that does not exist. There's nothing abnormal about that, there's nothing to fix. This whole thread is much ado about nothing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

Re: bdb_index_read: failed
by Chris Jacobs 07 May '10

07 May '10

I'd totally forgotten to reply-to-all: Arwin, You'd have to turn log levels up, and/or restrict usage to narrow that down (classic trouble shooting, to the rescue). Personally, I'd ask your staff to start with (devs and IT) and ask what's being done different, or if there are new users of LDAP. I can understand something being done that's 'new' or 'different' could very well be some snoop, but more likely the 'culprit' is going to be something 'ok'. Moving on... See when the events occur and (and perhaps who is authenticating)turn the log levels up during that time - that'll require a restart of slapd if your config is static files (now I really see the beauty of olconfig). Start with just logging auth, whether you find a link there or not, and if you need more detail, log the queries (shudder). Oh, and you'll need some 'spare' disk and cpu if this is a modestly used service. If you get to the latter part, you'll likely crush your box. And back again... Seriously, ask around. It'll likely be easier. This was all assuming that this was an established service - and if you've simply taken over an admin role, this could have been going on for a while and the final 'culprit' may simply be missing indexes. Good luck, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ----- Original Message ----- From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org <openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org> To: Howard Chu <hyc(a)symas.com> Cc: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Sent: Wed May 05 22:33:27 2010 Subject: Re: bdb_index_read: failed Thanks Howard, thats good news. However, I would like to know what or who is causing this. I've tried different loglevels but matchting the error with the query/filter that's causing it is rather challenging to say the least... Any hints on how to find the query responsible? Thanks! Arwin. Howard Chu schreef: > Arwin wrote: >> Hi all, >> >> We are running 1 master server and a couple of slaves, all >> openldap-2.4 on Ubuntu 8.04 lts, syncrepl >> and cn=config configuration. >> The last couple of days we are getting a few of the following errors >> in the slapd logs: >> >> Apr 29 11:03:41 ldapsrvr-1 slapd[6112]: bdb_idl_fetch_key: [b49d1940] >> Apr 29 11:03:41 ldapsrvr-1 slapd[6112]:<= bdb_index_read: failed (-30990) >> Apr 29 11:03:41 ldapsrvr-1 slapd[6112]:<= bdb_equality_candidates: >> id=0, first=0, last=0 >> Apr 29 11:03:41 ldapsrvr-1 slapd[6112]: => bdb_equality_candidates >> (objectClass) >> >> Tried solving it by re-adding the index and running slapindex but the >> errors still remain. >> >> Everything seems to work ok though, replication works, we can add/edit >> entries and user >> authentication of accounts in the dit work just fine. >> >> Can anybody tell me if this (bdb_index_read: failed (-30990)) is >> something that needs to be fixed >> and if so, how? > > No. It's normal, it just means it was looking for the index of a value > that doesn't exist in your DB. > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 1

Re: LDAP_SERVER_DOWN in win32?
by Chris Jacobs 07 May '10

07 May '10

Ummm... I suspect your machine's firewall (likely built in one from Windows) might be blocking it. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org To: openldap-technical(a)openldap.org Sent: Fri May 07 00:30:26 2010 Subject: LDAP_SERVER_DOWN in win32? I try to use openldap in windows xp. there is some implentations of openldap-win32-2.4.x. I have used every one of them, and openldap for linux in debian. the same problem is i can't connect them except the server is in localhost if my client run at win32, even i try to build my client in openldap, novel cldap and winldap. init is ok, bind is ok( i'm sure bind result should be >0 ,not LDAP_SUCCESS), but it report LDAP_SERVER_DOWN when i try to do some operations like search, add ... and the problem do not exist if I run my client(build with openldap or novell cldap) in linux(debian testing ), all server is ok. I try PHPLDAPAdmin and config it use openldap running at some window host, the problem is the same , LDAP_SERVER_DOWN. thanks for help gtalk:freeespeech@gmail.com<mailto:gtalk%3Afreeespeech@gmail.com> ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

LDAP_SERVER_DOWN in win32?
by owen nirvana 07 May '10

07 May '10

I try to use openldap in windows xp. there is some implentations of openldap-win32-2.4.x. I have used every one of them, and openldap for linux in debian. the same problem is i can't connect them except the server is in localhost if my client run at win32, even i try to build my client in openldap, novel cldap and winldap. init is ok, bind is ok( i'm sure bind result should be >0 ,not LDAP_SUCCESS), but it report LDAP_SERVER_DOWN when i try to do some operations like search, add ... and the problem do not exist if I run my client(build with openldap or novell cldap) in linux(debian testing ), all server is ok. I try PHPLDAPAdmin and config it use openldap running at some window host, the problem is the same , LDAP_SERVER_DOWN. thanks for help gtalk:freeespeech@gmail.com <gtalk%3Afreeespeech(a)gmail.com>

1 0

testing bind result in slapi pluging
by Gianluigi Nigro 06 May '10

06 May '10

Hi, i'm writing a plugin for SLAPI_PLUGIN_POST_BIND_FN operation: int mia_init(Slapi_PBlock *pb) { ... ... If( slapi_pblock_set(pb, SLAPI_PLUGIN_POST_BIND_FN, (void *)mia_get) != 0) { slapi_log_error(SLAPI_LOG_PLUGIN, "mia_init", "error" ); return -1; } ... return 0; } int mia_get(Slapi_PBlock *pb) { ... int oprc = -1; ... if( slapi_pblock_get(pb, SLAPI_PLUGIN_OPRETURN, &oprc) != 0 ) { If ( oprc == 0 ) Do something else Do something else } ... } The slapi_pblock_get for SLAPI_PLUGIN_OPRETURN always return 0 even if the bind operation is failed (for example following an error 49 Invalid Credentials ). Is there a way to test if the bind operation is successful or failed ? Tanks Gianluigi Nigro gianluigi.nigro(a)passepartout.sm <mailto:gianluigi.nigro@passepartout.sm> ------------------------------ Passepartout s.a. World Trade Center - Edificio A Via Consiglio dei Sessanta, 99 - 47891 Dogana - RSM tel. 0549 978011 fax 0549 978005 www.passepartout.net <http://www.passepartout.net> -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale documento a quest'ultimo allegato puo contenere informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente agli effettivi destinatari i quali prendono atto del carattere non strettamente personale dei messaggi di risposta, che potranno essere noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di questo messaggio in mancanza di autorizzazione del destinatario. Se avete ricevuto questo messaggio per errore, vogliate cortesemente chiamarci immediatamente per telefono o fax e distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical