openldap-technical

openldap-technical@openldap.org

10 participants
9969 discussions

openldap library and LDAP_OPT_X_KEEPALIVE_IDLE
by Fred MAISON 30 Apr '10

30 Apr '10

Hello, Could someone tell which openldap library version first included keepalive paches giving acces to following options : LDAP_OPT_X_KEEPALIVE_IDLE LDAP_OPT_X_KEEPALIVE_PROBES LDAP_OPT_X_KEEPALIVE_INTERVAL I have submitted a patch on freeradius for the rlm_ldap module for using those options to solve firewall/load-balancers LDAP session timeout by generation regular tcp keepalive packets ont LDAP sockets, and I see my current linux distros does not seems to have fresh-enough openldap library version to support this. debian squeeze libldap2-dev 2.4.17 CentOS 5.4 openldap-devel-2.3.43-3.el5 2.3.43 Best regards Fred MAISON

2 1

_ldap.so: undefined symbol: gnutls_alert_send
by Jean-Sébastien Mansart 29 Apr '10

29 Apr '10

Hi. I've got this error with a Zope/Plone site : Traceback (most recent call last): File "/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py", line 56, in ? run() File "/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py", line 21, in run starter.prepare() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py", line 102, in prepare self.startZope() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py", line 278, in startZope Zope2.startup() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/__init__.py", line 47, in startup _startup() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/App/startup.py", line 45, in startup OFS.Application.import_products() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py", line 686, in import_products import_product(product_dir, product_name, raise_exc=debug_mode) File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py", line 709, in import_product product=__import__(pname, global_dict, global_dict, silly) File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/__init__.py", line 22, in ? from Products.LDAPMultiPlugins.LDAPMultiPlugin import addLDAPMultiPluginForm File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/LDAPMultiPlugin.py", line 29, in ? from Products.LDAPUserFolder import manage_addLDAPUserFolder File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/__init__.py", line 20, in ? from Products.LDAPUserFolder.LDAPUserFolder import LDAPUserFolder File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPUserFolder.py", line 47, in ? from Products.LDAPUserFolder.LDAPDelegate import filter_format File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 19, in ? import ldap File "/home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/ldap/__init__.py", line 22, in ? from _ldap import * ImportError: /home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/_ldap.so: undefined symbol: gnutls_alert_send I have install gnutls1.3, recompiled openldap, python-ldap, and so on, but nothing works. Anyone could help me ? Thanks. -- *Jean-Sébastien Mansart *- Développeur Web Email : jean-sebastien.mansart(a)bayard-service.com <mailto:jean-sebastien.mansart@bayard-service.com> Tel : 04 79 26 28 29 *Bayard Service Edition * Savoie Technolac - House Boat BP308 - 73377 Le Bourget du Lac Cedex www.bayardserviceweb.com <http://www.bayardserviceweb.com>

3 2

Slow problem after some time
by Marco Pizzoli 28 Apr '10

28 Apr '10

Hi list, I have a problem with my openldap 2.4.22 deployment. Today I upgraded my architecture from 2-way openldap2.4.20 to 3-way openldap.2.4.22, but I continue to have the same problem of slowlyness after some time my systems came up. One of them in particular but I'm aware of our balancing system heavily prefer this one. The symptom is that every search, even the same simple search executed repeteadly, cause a cpu-burst and will be served in a enormous time, sometimes 1m30s even after a cold start the same query is served in less than a second. My user database is accessed for linux, AIX, DB2 and Oracle authentication. I have repeatedly the same searches fired against my openldap instancies. I suspect to have a problem in the way I configured the memory to be allocated My data on the user_db are quite static, but I have an accesslog writing very much. Retaining 3 days of history, my db dir grow to about 11/12GB. I'm using 4 different disk (and scsi controller) for userdb, logdb, transactionlog and OS. Following information about my environment. I can send others if necessary. My user database is quite little: 1.5MB slapcat ldif database hdb suffix "dc=lancse,dc=csebo.it" rootdn "cn=Manager,dc=lancse,dc=csebo.it" rootpw {SSHA}mySecret directory /srv/ldap/db_utenti index cn eq index ou eq index objectClass eq index uid eq index gidNumber eq index uidNumber eq #index member pres,eq index memberUid eq index entryCSN eq index entryUUID eq index userPassword pres index uniqueMember eq limits dn="cn=Manager,dc=lancse,dc=csebo.it" size=unlimited # cachesize: numero di entry del db da tenere in cache. # Ad oggi (2010-04-20) nel database degli utenti ne abbiamo cachesize 2000000 # dncachesize: indica il numero di dn da tenere in memoria. # Il valore di 0 indica nessun limite #dncachesize 2000000 dncachesize 0 # idlcachesize: index-data-lookup cache. Indica il numero di slot dell'indice tenuti in memoria idlcachesize 2000000 # cachefree: indica quante entry alla volta liberare quando viene saturata cachefree 10 # checkpoint ogni 1MB di scritte eseguite e/o 30 minuti di tempo checkpoint 1024 30 [root@ldap01 db_utenti]# ls -lhtr *.bdb -rw------- 1 ldap ldap 44K Apr 26 18:09 uid.bdb -rw------- 1 ldap ldap 40K Apr 26 18:09 gidNumber.bdb -rw------- 1 ldap ldap 8.0K Apr 27 09:07 uniqueMember.bdb -rw------- 1 ldap ldap 28K Apr 27 12:32 uidNumber.bdb -rw------- 1 ldap ldap 40K Apr 27 12:32 ou.bdb -rw------- 1 ldap ldap 32K Apr 28 11:04 memberUid.bdb -rw------- 1 ldap ldap 36K Apr 28 16:14 userPassword.bdb -rw------- 1 ldap ldap 164K Apr 28 16:14 objectClass.bdb -rw------- 1 ldap ldap 72K Apr 28 16:14 entryUUID.bdb -rw------- 1 ldap ldap 260K Apr 28 16:14 dn2id.bdb -rw------- 1 ldap ldap 32K Apr 28 16:14 cn.bdb -rw------- 1 ldap ldap 64K Apr 28 17:34 entryCSN.bdb -rw------- 1 ldap ldap 2.0M Apr 28 17:39 id2entry.bdb The DB_CONFIG is this: # Uso 256MB di cache splittato in 2 file set_cachesize 0 268435456 2 # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 # IMPOSTO LA DIR DEI TLOGS IN UN FileSystem DEDICATO set_lg_dir logs # PARAMETRI DI TUNING DEI LOCK set_lk_max_objects 3000 set_lk_max_locks 3000 set_lk_max_lockers 3000 # IMPOSTO LA RIMOZIONE AUTOMATICA DEI LOG set_flags DB_LOG_AUTOREMOVE ------------------------------------------------------------------------------------- This is the accesslog db dir database hdb suffix "cn=log01,dc=csebo.it" rootdn "cn=Manager,cn=log01,dc=csebo.it" rootpw mySecret directory /srv/ldap/db_log index entryUUID eq index reqStart eq index reqEnd eq index objectClass eq index reqType eq index reqDN eq index reqAuthzID eq index reqEntries eq index reqAttr eq index reqResult eq index reqFilter pres,eq #index reqEntries eq #index reqSession eq #index reqResult eq #index reqScope eq #index reqDerefAliases eq #index reqAttrsOnly eq #index reqFilter eq,approx #index reqTimeLimit eq,approx #index reqSizeLimit eq,approx limits dn="cn=Manager,cn=log01,dc=csebo.it" size=unlimited # cachesize: numero di entry del db da tenere in cache. cachesize 150000 # dncachesize: indica il numero di dn da tenere in memoria. # Il valore di 0 indica nessun limite dncachesize 300000 # idlcachesize: index-data-lookup cache. Indica il numero di slot dell'indice tenuti in memoria # Per i backend bdb e' suggerito essere uguale a "cachesize" # Per i backend hdb e' suggerito essere uguale ad almeno 3 volte "cachesize" idlcachesize 450000 # cachefree: indica quante entry alla volta liberare quando viene saturata cachefree 10 # checkpoint ogni 4MB di scritte eseguite e/o 30 minuti di tempo checkpoint 4096 30 [root@ldap01 db_log]# ls -lhtr total 7.8G drwx------ 2 ldap ldap 16K Feb 26 11:54 lost+found lrwxrwxrwx 1 ldap ldap 26 Feb 26 12:11 logs -> ../transactionlogs/db_logs -rw-r--r-- 1 ldap ldap 1.3K Apr 28 17:40 DB_CONFIG -rw------- 1 ldap ldap 2.3M Apr 28 17:40 __db.004 -rw------- 1 ldap ldap 321M Apr 28 17:40 __db.003 -rw------- 1 ldap ldap 16M Apr 28 17:40 __db.002 -rw------- 1 ldap ldap 24K Apr 28 17:40 __db.001 -rw-r--r-- 1 ldap ldap 2.0K Apr 28 17:40 alock -rw------- 1 ldap ldap 32K Apr 28 17:40 __db.006 -rw------- 1 ldap ldap 2.5M Apr 28 17:40 __db.005 -rw------- 1 ldap ldap 1.3M Apr 28 18:27 reqEntries.bdb -rw------- 1 ldap ldap 21M Apr 28 18:27 reqFilter.bdb -rw------- 1 ldap ldap 12M Apr 28 18:27 reqAttr.bdb -rw------- 1 ldap ldap 1.7M Apr 28 18:27 reqType.bdb -rw------- 1 ldap ldap 106M Apr 28 18:27 reqStart.bdb -rw------- 1 ldap ldap 1.2M Apr 28 18:27 reqResult.bdb -rw------- 1 ldap ldap 105M Apr 28 18:27 reqEnd.bdb -rw------- 1 ldap ldap 6.3M Apr 28 18:27 reqDN.bdb -rw------- 1 ldap ldap 5.7M Apr 28 18:27 reqAuthzID.bdb -rw------- 1 ldap ldap 4.6M Apr 28 18:27 objectClass.bdb -rw------- 1 ldap ldap 6.0G Apr 28 18:27 id2entry.bdb -rw------- 1 ldap ldap 163M Apr 28 18:27 entryUUID.bdb -rw------- 1 ldap ldap 1.1G Apr 28 18:27 dn2id.bdb This is the DB_CONFIG file # one 0.25 GB cache set_cachesize 0 268435456 1 # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 # IMPOSTO LA DIR DEI TLOGS IN UN FileSystem DEDICATO set_lg_dir logs # Dimensione dei log --> 60MB set_lg_max 62914560 #set_lg_max 41943040 # PARAMETRI DI TUNING DEI LOCK set_lk_max_objects 3000 set_lk_max_locks 3000 set_lk_max_lockers 3000 My system has 15 GB of RAM. This is an example of my RAM situation when the problem arises [root@ldap01 db_log]# free -m total used free shared buffers cached Mem: 14799 8009 6790 0 924 3160 -/+ buffers/cache: 3924 10875 Swap: 6143 8 6135 top -H PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP DATA COMMAND 9008 ldap 25 0 4806m 3.8g 346m S 0.0 26.5 0:10.69 880m 4.0g slapd2.4 9151 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 0:11.23 880m 4.0g slapd2.4 9152 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:37.42 880m 4.0g slapd2.4 9153 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 3:20.29 880m 4.0g slapd2.4 9154 ldap 15 0 4806m 3.8g 346m S 0.3 26.5 3:02.49 880m 4.0g slapd2.4 9155 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:23.49 880m 4.0g slapd2.4 9156 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:14.86 880m 4.0g slapd2.4 9157 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:44.86 880m 4.0g slapd2.4 9158 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:03.71 880m 4.0g slapd2.4 9163 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:06.05 880m 4.0g slapd2.4 9164 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:46.38 880m 4.0g slapd2.4 9165 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:25.31 880m 4.0g slapd2.4 9170 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:12.04 880m 4.0g slapd2.4 9171 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:17.15 880m 4.0g slapd2.4 9172 ldap 18 0 4806m 3.8g 346m R 98.1 26.5 2:06.54 880m 4.0g slapd2.4 9173 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:39.32 880m 4.0g slapd2.4 9174 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:25.64 880m 4.0g slapd2.4 9175 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:33.29 880m 4.0g slapd2.4 With dstat I can see that I *don't* have disk reading, only writings due to the accesslog ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- ------memory-usage----- run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| used buff cach free 2 0 2|3932M 926M 3178M 6764M| 0 0 | 0 559k| 246 445 | 24 0 75 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 464k| 200 333 | 24 0 76 0 0 0|3932M 926M 3178M 6764M 1 0 2|3933M 926M 3178M 6764M| 0 0 | 0 408k| 213 309 | 24 1 75 0 0 0|3933M 926M 3178M 6764M 3 0 0|3932M 926M 3178M 6764M| 0 0 | 0 420k| 205 280 | 23 0 75 1 0 0|3932M 926M 3178M 6764M 3 0 0|3932M 926M 3178M 6764M| 0 0 | 0 376k| 210 349 | 23 0 77 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 900k| 233 373 | 24 0 75 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 356k| 208 446 | 22 1 77 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 440k| 213 389 | 22 0 76 1 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 403k| 200 306 | 23 1 75 1 0 0|3932M 926M 3178M 6764M 3 0 4|3932M 926M 3178M 6764M| 0 0 | 0 648k| 196 365 | 24 1 74 1 0 0|3932M 926M 3178M 6764M 2 0 0|3932M 926M 3178M 6764M| 0 0 | 0 572k| 246 287 | 22 2 75 0 0 0|3932M 926M 3178M 6764M 1 0 2|3932M 926M 3179M 6763M| 0 0 | 0 552k| 197 256 | 25 1 73 1 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 368k| 210 259 | 23 1 75 0 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 4228k| 203 272 | 24 1 73 2 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 440k| 218 346 | 23 1 76 0 0 0|3932M 926M 3179M 6763M 4 0 0|3932M 926M 3179M 6763M| 0 0 | 0 499k| 215 359 | 24 0 75 1 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 348k| 215 313 | 25 0 74 1 0 0|3932M 926M 3179M 6763M 1 0 0|3932M 926M 3179M 6763M| 0 0 | 0 360k| 166 245 | 24 0 75 1 0 0|3932M 926M 3179M 6763M 2 0 7|3933M 926M 3179M 6762M| 0 0 | 0 432k| 225 393 | 25 3 71 0 0 0|3933M 926M 3179M 6762M 2 0 0|3933M 926M 3179M 6762M| 0 0 | 0 508k| 206 353 | 24 1 75 0 0 0|3933M 926M 3179M 6762M 1 0 2|3933M 926M 3179M 6762M| 0 0 | 0 716k| 254 342 | 25 1 75 0 0 0|3933M 926M 3179M 6762M 2 0 0|3933M 926M 3179M 6762M| 0 0 | 0 436k| 252 361 | 24 0 75 0 0 0|3933M 926M 3179M 6762M 1 0 0|3933M 926M 3179M 6762M| 0 0 | 0 456k| 226 359 | 24 0 75 1 0 0|3933M 926M 3179M 6762M I have also password_policy with forwarding of operational attributes and auditlog overlay. Thanks in advance Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

1 0

How to correctly escape search filters
by Jeremiah Martell 27 Apr '10

27 Apr '10

I've been trying to research how to correctly escape search filters, and I can't find any single reliable source that makes sense. I look at RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt) section 2.4, and this IBM webpage ( http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzah… ), and they both seem to suggest that you need to escape (for example) the '+' sign. But when I escape a search filter like this: (&(objectclass=person)(facsimileTelephoneNumber=+1234)) to this: (&(objectclass=person)(facsimileTelephoneNumber=\+1234)) it results in a bad filter. My hunch is that perhaps DNs, attribute names, and attribute values are all escaped different. Is there a simple explanation online on how to escape search filters? Thanks, - Jeremiah

2 1

Re: openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu 27 Apr '10

27 Apr '10

On Tue, Apr 27, 2010 at 3:43 PM, repudi8or repu <repudi8or(a)gmail.com> wrote: > Thanks for the response Masarati, > > I have setup with mode=self, but still the same error. > > Maybe im having a conceptual issue here. What i am trying to do is ensure > the backend functions prior to looking at the configuring the frontend > correctly. I am configuring the solaris openldap slapd with back-ldap and > pcache and am expecting to be able to simulate a fronted authentication > process using ldapsearch to the solaris openldap proxy. The backend ldap > service is AD @ backendldap.core.dir.mycompany.com. the proxy box i will > refer to as openldapproxy (openldapproxy.core.dir.mycompany.com)" > > my database ldap section now looks like this :- > backendldap.core.dir.mycompany.com" > > database ldap > uri "ldap://backendldap.core.dir.mycompany.com" > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" > idassert-bind > bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" > mode=self > > i am testing by running ldapsearch on the openldapproxy host itself in the > following manner :- > # /usr/local/bin/ldapsearch -x -h localhost -b > ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com employeeID=12345678 > > the proxied bind goes out to the backend AD as i have shown in the below > discussion. The response returned is :- > # filter: employeeID=12345678 > # requesting: ALL > # > # search result > search: 2 > result: 48 Inappropriate authentication > # numResponses: 1 > > Running slapd in diag mode i see the following in the debug output :- > do_bind: v3 anonymous bind > connection_get(11) > connection_get(11): got connid=1014 > connection_read(11): checking for input on id=1014 > ber_get_next > ber_get_next: tag 0x30 len 105 contents: > op tag 0x63, time 1272346583 > ber_get_next > conn=1014 op=1 do_search > ber_scanf fmt ({miiiib) ber: > >>> dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com> > => ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com,0) > <= ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > <<< dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com>, > <ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com> > SRCH "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" 2 0 0 0 > 0 > ber_scanf fmt ({mm}) ber: > filter: (?=undefined) > ber_scanf fmt ({M}}) ber: > attrs: > ==> limits_get: conn=1014 op=1 self="[anonymous]" > this="ou=people,ou=eprofile,dc=core,dc=dir,dc=telstra,dc=com" > send_ldap_result: conn=1014 op=1 p=3 > send_ldap_result: err=48 matched="" text="" > send_ldap_response: msgid=2 tag=101 err=48 > Note the anonymous bind, I need this to be a simply authenticated bind > using the idassert binddn and credentials > Note the "self="[anonymous]"............... I was expecting that it should > have been self=[USERID_THAT_RAN_THE_LDAPSEARCH] > > Regards Rep > On Tue, Apr 27, 2010 at 1:55 PM, <masarati(a)aero.polimi.it> wrote: > >> > Hi Folks, >> > >> > I am having troubles configuring openladp to my requirements. >> > >> > I am setting up an openldap server running on solaris 10 x86 to use as >> > a ldap proxy authentication server. >> > >> > My issue is that i cant get it to send authenticated simple binds to the >> > backend ldap system. I am running wireshark and when i ldapsearch direct >> > to >> > the backend ldap i see a bind which looks like this :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) >> > "cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com >> > authentication: simple (0) >> > simple: 384174656C73747261316732 >> > >> > However when i initiate an ldapsearch to my local solaris slapd and >> > capture >> > the proxied backldap bind to the backend ldap system it looks like this >> :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) "<ROOT>" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > authentication: simple (0) >> > simple: <MISSING> >> > >> > I am having trouble working out from the documentation if it should be >> > acl-bind or idassert-bind or some other option which influences the >> > backend >> > bind. I have tried both those to no avail. >> > Here is the "database ldap" section from my slapd.conf >> > >> > ####################################################################### >> > # ldap database definitions >> > ####################################################################### >> > database ldap >> > uri "ldap://backendldap.core.dir.mycompany.com" >> > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" >> > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" >> > acl-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> > idassert-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> >> The relevant directive is "idassert-bind", since you appear to be looking >> for an identity assertion. I hope what you posted was screwed up by the >> mailer: continuation lines must start with whitespace. What is missing >> above is the "mode=self" parameter to "idassert-bind". Try something like >> >> idassert-bind bindmethod=simple >> binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> credentials="password" >> mode=self >> >> p. >> >> > overlay pcache >> > proxycache bdb 400 1 50 1200 >> > directory /var/openldap-data >> > cachesize 10000 >> > index cn,sn,uid pres,eq,sub >> > index objectclass eq >> > >> > proxycachequeries 400 >> > proxyattrset 0 uid mail cn sn givenName >> > proxytemplate (uid=) 0 600 >> > proxytemplate (mail=) 0 600 >> > proxytemplate (&(uid=)(mail=)) 0 600 >> > >> > Any help would be greatly appreciated >> > >> > Regards Rep >> > >> >> >> >

2 1

openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu 26 Apr '10

26 Apr '10

Hi Folks, I am having troubles configuring openladp to my requirements. I am setting up an openldap server running on solaris 10 x86 to use as a ldap proxy authentication server. My issue is that i cant get it to send authenticated simple binds to the backend ldap system. I am running wireshark and when i ldapsearch direct to the backend ldap i see a bind which looks like this :- Lightweight-Directory-Access-Protocol LDAPMessage bindRequest(1) "cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com authentication: simple (0) simple: 384174656C73747261316732 However when i initiate an ldapsearch to my local solaris slapd and capture the proxied backldap bind to the backend ldap system it looks like this :- Lightweight-Directory-Access-Protocol LDAPMessage bindRequest(1) "<ROOT>" simple messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: authentication: simple (0) simple: <MISSING> I am having trouble working out from the documentation if it should be acl-bind or idassert-bind or some other option which influences the backend bind. I have tried both those to no avail. Here is the "database ldap" section from my slapd.conf ####################################################################### # ldap database definitions ####################################################################### database ldap uri "ldap://backendldap.core.dir.mycompany.com" suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" rootdn "dc=core,dc=dir,dc=mycompany,dc=com" acl-bind bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" idassert-bind bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" overlay pcache proxycache bdb 400 1 50 1200 directory /var/openldap-data cachesize 10000 index cn,sn,uid pres,eq,sub index objectclass eq proxycachequeries 400 proxyattrset 0 uid mail cn sn givenName proxytemplate (uid=) 0 600 proxytemplate (mail=) 0 600 proxytemplate (&(uid=)(mail=)) 0 600 Any help would be greatly appreciated Regards Rep

2 1

Schema-aware and OBSOLETE (was: (ITS#6151) Update cosine.schema to RFC 4524)
by Michael Ströder 26 Apr '10

26 Apr '10

Kurt, following-up on openldap-technical since this is off-topic in ITS#6151. Kurt Zeilenga wrote: > > On Apr 22, 2010, at 2:58 PM, Michael Ströder wrote: > >> Kurt Zeilenga wrote: >>> One additional note, I generally would advise that a schema-aware client >>> not alter it's update behavior of elements based upon whether said elements >>> are active or inactive (OBSOLETE) in the schema. >> >> I disagree especially for cases when new data is added. > > I think you're trying to make the client far smarter than it really ought > to be. This general statement is pretty blurry without speaking about certain use-cases. > If the clients configured to place say place element of data in attribute > x, it shouldn't try to put it elsewhere. It should fail. > While certainly one could design a client such as it could be configured > with fallbacks for attributes, and fallback for fallbacks, etc., this is an > unnecessarily complication IMO. Who said that my or any other client is doing anything like this in case of OBSOLETE schema elements? It would certainly be non-sense. The only thing I'm trying to achieve is to guide the user in the UI not to get frustrated by trial-and-error. > Also, note that were a client to attempt the above, it could still fail due > to an element being marked inactive between the time it read the schema and > the time it tried the DIT update. A client always have to implement proper error control even if the UI is guiding the user along the subschema information. >>> Instead, they should just >>> try the update and, if it fails, report it as they normally would. >> >> Modifying existing data I first have to think about... >> >>> Handling the inactive condition locally hides the error from the directory >>> administrator, who is likely relying on directory server logs to find >>> applications which using inactive schema. >> >> Hmm, that's not the case with a schema-aware client anyway which guides the >> user *not* to use OBSOLETE schema elements. > > I generally assume the user is not selecting which attribute to store some > piece of information into. I assume the client been programmed to collect > a piece of information and configured (or programmed) where to store it. With web2ldap it's a mix of both: One can pre-configure HTML templates per object class for input forms with which the web2ldap admin specifies the descriptive labels around an input field. With this you can hide which LDAP attribute the data is stored into. But the user can also switch to table and LDIF input fields (and back to tempating) when editing the data. In the template and table input forms I'd like to grey out input fields where the user's input would lead to a schema violation (OBSOLETE). E.g. it does not make sense to present OBSOLETE object classes in the object class select form when adding/modifying entries. It's similar to use slapo-allowed to only display editable input fields of attributes a user is allowed to write to. On the other hand web2ldap always trys to respect what's already present in the entries. The paradigm is to be minimal invasive: Don't change anything while modifying existing entries if the user did not explicitly change it. > The client you refer to is what I would call an application-neutral LDAP > directory administration tool. For such a tool, it might be reasonable to > warn the user (whose generally an "administrator" of some sort as opposed > to a "normal" user). Even such a tool can have customization. The categories are not that sharp... ;-) >> You're likely talking about >> detecting pre-configured applications with hard-coded use of OBSOLETE object >> classes and attribute types. >> Most times these are not schema-aware at all. > > Well, pre-configured applications may be schema-aware but maybe not as > fully as an LDAP directory administration tool might be. They might check > that the element they were configured to use is appropriate for that use by > examining its specification in the subschema. Yes, there are things like this in web2ldap too for certain use-cases (e.g. determining whether it works with MS AD while setting password attribute etc.). But I was especially interested in discussing what's appropriate in case of OBSOLETE schema descriptions. Ciao, Michael.

1 0

[Fwd: Support for ordering matching rules in extensible match filters?]
by deepee＠gmx.net 25 Apr '10

25 Apr '10

Hi, first of all, please excuse me if I've hit the wrong openldap mailinglist. My question below is related to section 4.1 of RFC4517 which says: Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion syntax of the matching rule is the same as the value syntax of the attribute. Could someone please explain to me why openldap currently doesn't support for example 'caseIgnoreOrderingMatch' (which is listed in section 4.2 of RFC4517) in extensible match filters? Of course I've seen the two SHOULDs above - I just don't understand the openldap related technical/design decision regarding the missing support and would be very happy if someone could please explain this to me. Another more common question but also related to my previous mail (below): could someone please also tell me the RFC(s) in which the evaluation of ordering matching rules (especially when used in extensible match filters) is specified? Thanks again! Betreff: Support for ordering matching rules in extensible match filters? Datum: Thu, 22 Apr 2010 11:18:35 +0200 Von: Daniel <deepee(a)gmx.net> An: openldap-technical(a)openldap.org Hi, why doesn't slapd support ordering matching rules in extensible match filters? Does the small code enhancement for slapd's generalizedTimeOrderingMatch() would make sense into the direction to support ordering matching in extensible filters (in this particular case)? Thanks a lot! static int generalizedTimeOrderingMatch( int *matchp, slap_mask_t flags, Syntax *syntax, MatchingRule *mr, struct berval *value, void *assertedValue ) { struct berval *asserted = (struct berval *) assertedValue; ber_len_t v_len = value->bv_len; ber_len_t av_len = asserted->bv_len; /* ignore trailing 'Z' when comparing */ int match = memcmp( value->bv_val, asserted->bv_val, (v_len < av_len ? v_len : av_len) - 1 ); Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n", value->bv_val, asserted->bv_val, match); if ( flags & SLAP_MR_EXT ) { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0); if ( match == -1 ) match = 0; else if ( match == 0 ) match = 1; } else { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0); if ( match == 0 ) match = v_len - av_len; } Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n", value->bv_val, asserted->bv_val, match); *matchp = match; return LDAP_SUCCESS; }

2 2

N-Way Replication noob questions
by Siddhartha Jain 25 Apr '10

25 Apr '10

Hi, First, kudos to OpenLDAP team for the progress they have made with 2.4. I am returning to use OpenLDAP after nearly a decade and it is heartening to see all the new features even when going from 2.3 to 2.4 (As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x. RedHat might do it to push their own DS over OpenLDAP but why CentOS)? 1. From the OpenLDAP guide, I see that replication is setup to replicate both - config and information trees. a. With each master having a unique "ServerID", does it mean that config replication won't overwrite certain attributes like ServerID? b. How are multiple "ServerID" values handled when the replication config is introduced? c. What about credentials used for rootDN of various databases? Do they get sync-ed too? 2. What is the best way to setup a new master with empty databases? Slapcat from an existing one and Slapdadd to the new one? Or, let replication take care of it? Network traffic issues aside, my point is how does timestamp matching work for non-existant objects (in the new master vs existing). Or, put differently, how is deletion vs new/empty database differentiated? Why wouldn't replication consider the non-existence of databases in the new master as all databases having been deleted? 3. From 18.2.2.3 of the Guide "Arguments against Multi-Master replication". 4. " If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem" Care to expand on this, please? 5. " If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider" How so? If all masters are sync-ed with NTP tighly, then shouldn't this issue take care of itself when a partitioned master(s) comes back online and reconnect. Thanks, - Siddhartha

2 1

ppolicy in back_ldap?
by Tyler Gates 22 Apr '10

22 Apr '10

Hey guys, I currently have a multi-master system setup with a back_ldap proxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters. After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it. It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature." If I remove ppolicy overlay I don't see any of the values. I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong? Thanks for any help, Tyler -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

2 8

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