openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Ldapsearch not working.
by karthik kumar 28 Sep '10

28 Sep '10

Hi, There are a few entries in the LDAP, its not showing-up in ldapsearch. But I could see the entry in the dump (ldif) file.. I ve compared with some other entries also. Some of them are showing up in the ldapsearch and some are not. Any ideas please ..How do I start debugging this ? Please advice if you need more information. Thanks Karthik

2 3

Searched Attr=1.1
by Marco Pizzoli 28 Sep '10

28 Sep '10

Hi list, I found some entries in my OL logs about searches for attribute "1.1". I've seen that the requester is the user used for the replication (syncrepl). Can anyone explain to me what this kind of attribute is this? *conn=0 op=3 SRCH attr=1.1 * Thanks in advance Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

5 8

Replication process slapd 2.4.23 (value #* provided more than once)
by Nicolas Greneche 28 Sep '10

28 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I tried to setup replication on two ldap servers : a master and a slave. The master is configured like this (slapd.conf) : database hdb suffix "dc=test,dc=fr" rootdn "cn=root,dc=test,dc=fr" [...] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 The slave is configured like this (slapd.conf). I tried to make a very simple setup : syncrepl rid=001 provider=ldap://my-master:389/ searchbase="dc=test,dc=fr" bindmethod=simple binddn="cn=root,dc=test,dc=fr" credentials=password type=refreshAndPersist retry="5 +" When I restart my slave I got this error in logfiles : Sep 24 11:08:37 kyo slapd[2296]: syncrepl_message_to_entry: rid=001 mods check (postalAddress: value #0 provided more than once) And replication stops. Master and slaves are installed from debian squeeze packages : root@kyo:/var/lib/ldap# slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Sep 13 2010 07:04:08) $ @borges:/home/devel/openldap/trunk/debian/build/servers/slapd libbdb version is 4.8.30. Replication works well with a 2.3.20 slave, so i think i missed something on 2.4.23 slave configuration. Thanks for your help, - -- Nicolas Greneche - RSSI et Sysadmin Centre de Ressources Informatiques (CRI) Doctorant au sein du projet SDS - www.sds-project.fr Mail : nicolas.greneche_(at)_univ-orleans.fr GPG : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5FEBD0EF Universite d'Orleans Web : http://blog.garnett.fr Batiment 3IA - 2e etage Tel : 02 38 49 25 26 6 rue Leonard de Vinci BP 6102 45061 ORLEANS Cedex 2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyccGoACgkQTx/Y+1/r0O/gzgCfVb5pl0aH5tjhJkf3uDRjgVVr 9fIAniXYZboWSQuBPFcQBa4KNXU7ZXEJ =L9D2 -----END PGP SIGNATURE-----

2 3

OpenLDAP in Fedora with Mozilla NSS for crypto
by Rich Megginson 28 Sep '10

28 Sep '10

The Fedora Project, with Fedora 14 and later, is building OpenLDAP with Mozilla NSS for crypto instead of OpenSSL. There will be a Fedora Test Day on October 14, 2010 to test as many different applications with as many different combinations of TLS/SSL settings as possible. https://fedoraproject.org/wiki/Test_Day:2010-10-14_OpenLDAP/NSS Please Help! You folks are the OpenLDAP experts, with experience developing and using OpenLDAP in a wide variety of settings and applications. We would appreciate any testing, test suggestions, bug reports, etc.

1 0

MoNSS support in openldap
by Silvan Marco Fin 28 Sep '10

28 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Is there any magic to be cast upon openldap to enable the MozNSS support when compiling it? Perhaps I'm missing something, but there doesn't seem to be a configure switch to enable NSS, like with Gnutls or OpenSSL. Kind regards, Silvan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyc3wAACgkQ9s/B3wYT4543twCfcdYTtJyeKbtiJoT8yFZblvDb 8DQAmwfZpxpoaHic1ZIpovUeH+jqzo1d =ih5n -----END PGP SIGNATURE-----

4 7

Adding entries to cn=config
by Angel L. Mateo 28 Sep '10

28 Sep '10

Hello, I'm migrating from an old openldap 2.3.30 to a 2.4.21 running in an ubuntu server, so I'm new with cn=config database. The problem I have is that I want to create a user under cn=config, so I could configure the server without providing the password for cn=config (I want to restrict the IPs from that user could be used). So I'm trying to add an entry like: dn: cn=myuser,cn=config changetype: add objectClass: organizationalRole objectClass: simpleSecurityObject cn: myuser userPassword: mypassword but I'm getting the error: Object class violation (65). In the server's log I get: Sep 27 12:52:04 canis10 slapd[10564]: conn=1018 op=2 ADD dn="cn=myuser,cn=config " Sep 27 12:52:04 canis10 slapd[10564]: slap_queue_csn: queing 0x7f47bc1d8f10 2010 0927105204.422891Z#000000#001#000000 Sep 27 12:52:04 canis10 slapd[10564]: conn=1018 op=2 RESULT tag=105 err=65 text= I have tried to add it with the server running in debug mode, and then I get: >>> dnPrettyNormal: <cn=myuser,cn=config> => ldap_bv2dn(cn=myuser,cn=config,0) <= ldap_bv2dn(cn=myuser,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myuser,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myuser,cn=config)=0 <<< dnPrettyNormal: <cn=myuser,cn=config>, <cn=myuser,cn=config> conn=1002 op=2 ADD dn="cn=myuser,cn=config" daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero => access_allowed: add access to "cn=myuser,cn=config" "entry" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) <= acl_access_allowed: granted to database root oc_check_required entry (cn=myuser,cn=config), objectClass "organizationalRole" oc_check_required entry (cn=myuser,cn=config), objectClass "simpleSecurityObject" oc_check_allowed type "objectClass" oc_check_allowed type "cn" oc_check_allowed type "userPassword" oc_check_allowed type "structuralObjectClass" => access_allowed: add access to "cn=config" "children" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) conn=1002 op=2: config_add_internal: DN="cn=myuser,cn=config" no structural objectClass in configuration table but organizationalRole is an structural object class. I have tried with other objectclasses like person or inetOrgPerson, but I get the same result. Could anybody help me? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

3 7

Including schema in directory based config?
by Will Dowling 28 Sep '10

28 Sep '10

Hi Guys, Hope this is the right list for this, haven't been lurking here previously so I don't have a feel for things yet. I'm upgrading our OpenLDAP servers to use directory based configuration under Ubuntu/Lucid and am having some problems including the provided Cosine and iNetOrgPerson schemas. It appears that if I symlink the LDIF files from /etc/ldap/schema/ into /etc/ldap/slapd.d/cn=config/cn=schema/ slapd will not start. Running slapd in debug mode gives me the following output: ldif_read_file: read entry file: "/etc/ldap/slapd.d//cn=config/cn=schema/cosine.ldif" => str2entry: "# RFC1274: Cosine and Internet X.500 schema <snip contents of the LDIF file being read in> => ldap_bv2dn(cn=cosine,cn=schema,cn=config,0) <= ldap_bv2dn(cn=cosine,cn=schema,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=cosine,cn=schema,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=cosine,cn=schema,cn=config)=0 <<< dnPrettyNormal: <cn=cosine,cn=schema,cn=config>, <cn=cosine,cn=schema,cn=config> <= str2entry(cn=cosine,cn=schema,cn=config) -> 0xb9124344 => test_filter PRESENT => access_allowed: search access to "cn=cosine,cn=schema,cn=config,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 : config_add_internal: DN="cn=cosine,cn=schema,cn=config,cn=schema,cn=config" not child of DN="cn=schema,cn=config" config error processing cn=cosine,cn=schema,cn=config,cn=schema,cn=config: send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=32 matched="" text="" The DN specified in the LDIF file is as follows: dn: cn=cosine,cn=schema,cn=config But it looks like when it's reading in the file, it's postpending cn=schema,cn=config (presumably from the configuration directory path), as opposed to using the fully qualified DN. Is there a way to fix this? I'm using packages to deploy software configurations, and it doesn't make sense for us to inject this schema with ldapadd (what seems to be the prescribed way) of adding schema to get around this DN problem (and handing adding/removing it when upstream updates the defintions - however infrequent/unlikely this is). We also roll out our own schema definitions, but these have been converted to LDIF and it's no big deal to have the DN: line set to whatever will make slapd happy. I hope this makes sense and that someone is able to help me understand directory based configuration a little better. Cheers :) Will Dowling T: +61 (08) 6364 4880 F: +61 (08) 6364 4881 E: will(a)autodeist.com

5 9

id: No such userroot@garion:~# ldapsearch -x uid=connor # extended LDIF # # LDAPv3 # base <dc=muncc, dc=loc> (default) with scope subtree # filter: uid=connor # requesting: ALL # # connor, People, muncc.loc dn: uid=connor,ou=People,dc=muncc,dc=loc uid
by Cole 28 Sep '10

28 Sep '10

Hello all, I have an LDAP server that I can use for authentication. On this server I can authenticate as these users locally and ldapsearch them, whatever. On any of the LDAP clients, however, I can see them using an ldapsearch, but an id or su will return no such user. Example: root@garion:~# ldapsearch -x uid=connor # extended LDIF # # LDAPv3 # base <dc=muncc,dc=loc> (default) with scope subtree # filter: uid=connor # requesting: ALL # # connor, People, muncc.loc dn: uid=connor,ou=People,dc=muncc,dc=loc uid: connor cn: connor objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1002 gidNumber: 100 gecos: connor,,, homeDirectory: /shared/home/connor # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 root@garion:~# id connor id: connor: No such user Now, I'm pretty sure that this must be an NSS or PAM problem, but the files on the clients and the server seem to be configured the same. I can't seem to pinpoint exactly what is wrong. Any suggestions? Thanks in advance. -- Cole Gleason ---------------------- Student, Marmion Academy Email: cg(a)colegleason.com Website: colegleason.com

2 1

Re: id: No such userroot@garion:~# ldapsearch -x uid=connor # extended LDIF # # LDAPv3 # base <dc=muncc, dc=loc> (default) with scope subtree # filter: uid=connor # requesting: ALL # # connor, People, muncc.loc dn: uid=connor,ou=People,dc=muncc,dc=loc
by Cole 28 Sep '10

28 Sep '10

Sorry about the subject. I think I hit paste by accident. On Mon, Sep 27, 2010 at 5:30 PM, Cole <colewashere(a)gmail.com> wrote: > Hello all, > > I have an LDAP server that I can use for authentication. On this server I > can authenticate as these users locally and ldapsearch them, whatever. On > any of the LDAP clients, however, I can see them using an ldapsearch, but an > id or su will return no such user. > Example: > root@garion:~# ldapsearch -x uid=connor > # extended LDIF > # > # LDAPv3 > # base <dc=muncc,dc=loc> (default) with scope subtree > # filter: uid=connor > # requesting: ALL > # > > # connor, People, muncc.loc > dn: uid=connor,ou=People,dc=muncc,dc=loc > uid: connor > cn: connor > objectClass: account > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > shadowMax: 99999 > shadowWarning: 7 > loginShell: /bin/bash > uidNumber: 1002 > gidNumber: 100 > gecos: connor,,, > homeDirectory: /shared/home/connor > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > root@garion:~# id connor > id: connor: No such user > > > Now, I'm pretty sure that this must be an NSS or PAM problem, but the files > on the clients and the server seem to be configured the same. I can't seem > to pinpoint exactly what is wrong. Any suggestions? > > Thanks in advance. > -- > Cole Gleason > ---------------------- > Student, Marmion Academy > Email: cg(a)colegleason.com > Website: colegleason.com > > -- Cole Gleason ---------------------- Student, Marmion Academy Email: cg(a)colegleason.com Website: colegleason.com

1 0

help, how to manage the ACL dynamic by C api???
by wu johnson 27 Sep '10

27 Sep '10

null

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical