openldap-software

openldap-software@openldap.org

2719 discussions

Re: SOLVED: nssov support for group with spaces?
by Greek Ordono 29 May '09

29 May '09

Ok, thanks. Anyway I'm planning to replace nss_ldap with nssov/nss-ldapd. -- grexk --- On Fri, 5/29/09, David <admin(a)dmarkey.com> wrote: From: David <admin(a)dmarkey.com> Subject: Re: nssov support for group with spaces? To: "Howard Chu" <hyc(a)symas.com> Cc: "Greek Ordono" <grexk(a)yahoo.com>, openldap-software(a)openldap.org Date: Friday, May 29, 2009, 7:49 PM Most of the samba groups have spaces(when using smbldap-populate) eg: "Domain Users" "Domain Admins" This will stop nssov replacing nss_ldap for most samba configurations On Fri, May 29, 2009 at 2:04 PM, Howard Chu <hyc(a)symas.com> wrote: Greek Ordono wrote: is this is a known bug? ERROR: @(#) $OpenLDAP: slapd 2.4.11 (Mar 26 2009 08:14:38) $ daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) slapd starting nssov: group entry cn=Domain Admins,ou=Groups,dc=domain,dc=com contains invalid group name: "Domain Admins" -- grexk No bug, group names in POSIX are not allowed to contain spaces. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Changing password with replicat and referal do nothing
by Quanah Gibson-Mount 28 May '09

28 May '09

--On Thursday, May 28, 2009 2:27 PM +0200 paulpierre.brun(a)free.fr wrote: > Thanks for answers : > I try with (c) at service ldap start i have : > :overlay "chain" not found > > How I can load module overlay ??? > > configure parameters are : > > ./configure —prefix= —enable-overlays —enable-ppolicy —enable-rwm > —enable-bdb Hi Paul, Please keep replies on the list. Did you use the moduleload statement to load the chain module? I suggest you look at the test suite, particularly test032. You can run that test, and see the configs that are generated when it completes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

OpenLDAP API: why to use asynchronous functions?
by johnmiller＠email.it 28 May '09

28 May '09

Hi all, I am learning to use OpenLDAP API with no particular problem. Anyway I have a question: why should I use asynchronous functions? From the LDAP client point of view, do they use less memory or more? I have this concern because my code will have to work on an embedded system with not much RAM. Ciao JM

3 2

persistent query
by Guillaume Rousse 27 May '09

27 May '09

Hello list. Is there any way to perform a persistent query with ldapsearch, the same way syncrepl refreshAndPersist does ? And if not, would an ITS for it being accepted ? It would be very useful for following changes in logs managed by slapo-accesslog. -- BOFH excuse #379: We've picked COBOL as the language of choice.

2 1

Openldap 2.4.16 and OpenLDAProotDSE
by Lepoutre Lionel 27 May '09

27 May '09

Hello, I am using openldap 2.4.16 and everything seems to work (the server starts and I can add/modify/delete entries). But I had some problems to build a frontend and it seems to be linked to my RootDSE. When I make a : *ldapsearch -h myserver -x -s base -b "" +* I only get : *# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + # # search result search: 2 result: 0 Success # numResponses: 1* But when I make this same request on an old openldap instance I get the "correct" answer: *# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: ou=awl,dc=atosorigin,dc=com monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1* I have search in some schema files but I didn't find any OpenLDAProotDSE definition... Do I miss something? I am quite a newbie and I have found any information to set it. I know that I can put the definition with the "rootdse" directive in my slapd.conf but I don't know if it is the right way? Could anyone help me please? Thanks in advance for your help. Lionel

2 2

How to write config tree ??
by Pastore Annamaria 27 May '09

27 May '09

I would like to construct a memberof scenarius like test52, but when I try to add with command ldapadd a *.ldif that returns error : ldap_bind: Invalid credentials (49) What I must to do ? Someone can help me ? Internet E. Mail Confidentiality Footer ----------------------------------------------------------------------------------------------------- La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred.

1 0

synchronisation monitoring, contextCSN and operational attributes
by Guillaume Rousse 27 May '09

27 May '09

Hello list. I'm using delta-syncrepl in search-and-persist mode between my slaves and my master server. And I'm using a nagios plugin to check sync status, based on value of contextCSN attribute. But I'm often sync alerts for unknown reasons. First issue, is this an expected result to have an higher contextCSN on the slave side ? From what I've understood from contextCSN, this attribute is updated each time a write operation is performed on the server. As the slave server is not supposed not to perform any write operation, this should never happens. However, it does: [root@etoile ~]# /usr/share/nagios/plugins/check_syncrepl.py ldap://ldap1.msr-inria.inria.fr ldap://ldap2.msr-inria.inria.fr -b dc=msr-inria,dc=inria,dc=fr -v [..] 2009-05-25 13:36:49,740 - check_syncrepl.py - DEBUG - Retrieving Provider contextCSN 2009-05-25 13:36:49,741 - check_syncrepl.py - DEBUG - contextCSN = 20090520141922.274229Z#000000#000#000000 2009-05-25 13:36:49,742 - check_syncrepl.py - DEBUG - Retrieving Consumer contextCSN 2009-05-25 13:36:49,742 - check_syncrepl.py - DEBUG - contextCSN = 20090525095027.118111Z#000000#000#000000 2009-05-25 13:36:49,752 - check_syncrepl.py - INFO - Consumer NOT in SYNCH 2009-05-25 13:36:49,753 - check_syncrepl.py - INFO - Delta is -5 days, 4:28:55 Second issue, how does syncrepl sync operational attributes ? When using ppolicy, for instance, each failed bind operation result in a pwdChangedTime attribute added to the user entry. From my own attempts, the slave and the master maintain their own list separatly. As synchronisation is performed from master to slave only, it seems quite logical failed authentication on the slaves doesn't impact the user entry on the master. However, from reading slapd.conf man page, syncrepl is supposed to synchronise operational attributes too by default: The attrs list defaults to "*,+" to return all user and operational attributes, and attrsonly is unset by default. Also, the logs on the slave clearly show something happens when a failed autentication is performed on the master. Start state: Provider contextCSN = 20090525122053.257812Z#000000#000#000000 Consumer contextCSN = 20090525122053.257812Z#000000#000#000000 Logs: May 25 14:18:34 nation slapd[28717]: do_syncrep2: cookie=rid=123,csn=20090525121834.036489Z#000000#000#000000 May 25 14:18:34 nation slapd[28717]: slap_queue_csn: queing 0x93d55d8 20090525121834.036489Z#000000#000#000000 May 25 14:18:34 nation slapd[28717]: slap_graduate_commit_csn: removing 0x9450550 20090525121834.036489Z#000000#000#000000 May 25 14:18:34 nation slapd[28717]: syncrepl_message_to_op: rid=123 be_modify uid=rousse,ou=users,dc=msr-inria,dc=inria,dc=fr (0) May 25 14:18:34 nation slapd[28717]: slap_queue_csn: queing 0x9461d18 20090525121834.036489Z#000000#000#000000 May 25 14:18:34 nation slapd[28717]: slap_graduate_commit_csn: removing 0x945e640 20090525121834.036489Z#000000#000#000000 End state Provider contextCSN = 20090525122053.257812Z#000000#000#000000 Consumer contextCSN = 20090525122122.287486Z#000000#000#000000 The provider didn't increases its contextCSN value, while performing a change, and the consumer did increase its own, while not performing the change :( Here is my syncrepl configuration: syncrepl rid=123 provider=ldaps://ldap1.msr-inria.inria.fr type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XXXXXX -- Guillaume Rousse Service des Moyens Informatiques INRIA Saclay - Île-de-France Parc Orsay Université, 4 rue J. Monod 91893 Orsay Cedex France Tel: 01 69 35 69 62

3 4

Changing password with replicat and referal do nothing
by paulpierre.brun＠free.fr 26 May '09

26 May '09

Hi, I have : - a ldap referal server openldap-2.4.16 compile as ./configure —prefix= —enable-overlays —enable-ppolicy —enable-rwm —enable-bdb —enable-crypt. - a replicate openldap 2.3.27-8.el5_1.3, When I try to change a password for a customer, for te referal i have in log file May 25 10:52:38 ldap-v000 slapd[26539]: conn=0 fd=15 ACCEPT from IP=10.xxx.xx.xx:56813 (IP=0.0.0.0:389) May 25 10:52:38 ldap-v000 slapd[26539]: connection_get(15) May 25 10:52:38 ldap-v000 slapd[26539]: connection_get(15): got connid=0 May 25 10:52:38 ldap-v000 slapd[26539]: connection_read(15): checking for input on id=0 May 25 10:52:38 ldap-v000 slapd[26539]: daemon: activity on 1 descriptor May 25 10:52:38 ldap-v000 slapd[26539]: daemon: activity on: And referal do nothing else. For replicat i have in log file May 25 09:35:19 ldap-v01 slapd[5535]: daemon: listen=10, new connection on 21 May 25 09:35:19 ldap-v01 slapd[5535]: daemon: added 21r May 25 09:35:19 ldap-v01 slapd[5535]: conn=10 fd=21 ACCEPT from IP=10.xxx.xx.xx:46412 (IP=0.0.0.0:636) May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=7 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=8 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=9 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=10 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on 1 descriptor May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on: May 25 09:35:19 ldap-v01 slapd[5535]: 21r May 25 09:35:19 ldap-v01 slapd[5535]: May 25 09:35:19 ldap-v01 slapd[5535]: daemon: read active on 21 May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21) May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21): got connid=10 May 25 09:35:19 ldap-v01 slapd[5535]: connection_read(21): checking for input on id=10 May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=7 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=8 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=9 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=10 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on 1 descriptor May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on: May 25 09:35:19 ldap-v01 slapd[5535]: 21r May 25 09:35:19 ldap-v01 slapd[5535]: May 25 09:35:19 ldap-v01 slapd[5535]: daemon: read active on 21 May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21) May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21): got connid=10 May 25 09:35:19 ldap-v01 slapd[5535]: connection_read(21): checking for input on id=10 May 25 09:35:19 ldap-v01 slapd[5535]: connection_read(21): unable to get TLS client DN, error=49 id=10 May 25 09:35:19 ldap-v01 slapd[5535]: conn=10 fd=21 TLS established tls_ssf=256 ssf=256 May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=7 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=8 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=9 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=10 active_threads=0 tvp=NULL May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on 1 descriptor May 25 09:35:19 ldap-v01 slapd[5535]: daemon: activity on: May 25 09:35:19 ldap-v01 slapd[5535]: 21r May 25 09:35:19 ldap-v01 slapd[5535]: May 25 09:35:19 ldap-v01 slapd[5535]: daemon: read active on 21 May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21) May 25 09:35:19 ldap-v01 slapd[5535]: connection_get(21): got connid=10 May 25 09:35:19 ldap-v01 slapd[5535]: connection_read(21): checking for input on id=10 May 25 09:35:19 ldap-v01 slapd[5535]: ber_get_next on fd 21 failed errno=11 (Resource temporarily unavailable) May 25 09:35:19 ldap-v01 slapd[5535]: daemon: select: listen=7 active_threads=0 tvp=NULL May 25 09:35:20 ldap-v01 slapd[5535]: daemon: select: listen=8 active_threads=0 tvp=NULL May 25 09:35:20 ldap-v01 slapd[5535]: daemon: select: listen=9 active_threads=0 tvp=NULL May 25 09:35:20 ldap-v01 slapd[5535]: daemon: select: listen=10 active_threads=0 tvp=NULL May 25 09:35:20 ldap-v01 slapd[5535]: daemon: activity on 1 descriptor May 25 09:35:20 ldap-v01 slapd[5535]: daemon: activity on: the response is (Resource temporarily unavailable) The customer is waiting an answer $ passwd Changing password for user myname. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: conf file slapd.conf replicat updatedn "cn=replication_ldap,dc=mydomain,dc=mydomain2,dc=fr" updateref "ldap://10.xxx.xx.xx" conf file slapd.conf Referal replica uri=ldap://ldap-v01.mydomain:389/ binddn="cn=replication_ldap,dc=mydomain,dc=mydomain2,dc=fr" bindmethod=simple credentials=xxxxx conf file slapd.conf slapd.conf for referal and replicate are # allow the world read access access to * by dn="cn=Manager,dc=mydomain,dc=mydomain2,dc=fr" write by dn="cn=samba,dc=mydomain,dc=mydomain2,dc=fr" write by dn="cn=replication_ldap,dc=mydomain,dc=mydomain2,dc=fr" read by self write by * read # access to attrs=userPassword by dn="cn=Manager,dc=mydomain,dc=mydomain2,dc=fr" write by dn="cn=samba,dc=mydomain,dc=mydomain2,dc=fr" write by self write by * none Anybody can help me ???

2 1

Syncrepl blues
by Sandra Snan 25 May '09

25 May '09

I'm trying to write a program that listens to a server via Syncrepl. I'm working from RFC4533, man ldap_sync, and reading ldap_sync.c I'm running the library with the trace messages defined back in. As far as I understand it, the server is required to send SearchResultEntry messages with the appropriate control. But when and how do I find these messages? I've tried these variants: ldap_sync_init_refresh_and_persist(&sfrotz); while(1) { printf("Sync code:%d\n", ldap_sync_poll(&sfrotz)); sleep(7); } vs while(1) { printf("Sync code:%d\n", ldap_sync_init_refresh_only(&sfrotz)); sleep(7); } Both start of well, by giving me a SearchResultEntry message for each DN. But then, as I add or delete entries, I don't get any more SearchResultEntry messages. With the refresh_only variant, I get intermediate when I delete entries and sometimes when I add entries (but this seems flaky). Also, with the refresh_only variant, the SearchResultDone message (that I get on every call) has a different cookie when I've added or deleted entries from my server. But where are my precious SearchResultEntry messages? I want the ls_search_entry callback to trigger! It only triggers during the first init with an empty cookie. Please, help me! I'm going crazy! I fully acknowledge that the problem is probably something I've done wrong, but I don't understand what. I've worked full time on this issue for three weeks. I know I'm an idiot but I've tried reading the man pages, the RFC and the code. I know my future employer will find this e-mail and decline to hire me because of how stupid I come across. But I'm sending it anyway, that's how desperate I am. Thank you. Sandra

1 0

is there a "lazy commit equivalent" in OpenLDAP ?
by Michael Arndt 25 May '09

25 May '09

Hello *, is there an OpenLDAP equivalent to the AD "lazy commit" ? See below for description of lazy commit for clarification. TIA Micha Lazy Commit control. Used with any of the operations that modify or add entries. This control allows a client to tell AD to postpone writing the results of the operations to disk, and to just store them in cache. This control allows a client to make a large number of changes without any loss of performance due to disk writes and therefore optimizes large changes. However, if the directory server crashes before the cache is written, the changes are lost. The OID 1.2.840.113556.1.4.619 specifies this control. -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software