openldap-technical

openldap-technical@openldap.org

10001 discussions

Authenticate Mac OS X users against OpenLDAP on Debian
by Mi 07 Sep '11

07 Sep '11

We added a Mac to our network, and I would like the network users to be able to login with their existing credentials on our Debian openLDAP server. I configured the LDAP access on the Mac, and it can indeed see the users and groups from the openldap server. But when I try to login after clicking "Other...", the login window shakes around, and nothing happens. The server logs show the connection from the Mac and it's searches ( http://pastebin.com/MB2JswAa). (Logging is configured with Parse, Stats, Stats2, Sync. Is there something else I should add to logging that may be useful?) On the Mac, I didn't find anything looking helpful in the logs (http://pastebin.com/yRreFQrJ), but maybe I don't know what to look for. I found many instructions on the Internet which concentrate on mounting user homes from the server over NFS. This is NOT what we want. Users would be authenticated with openldap, but have their homes locally on the Mac, like normal users. I also saw many mentions of adding the apple schema, and I have done that. But maybe I now need to actually use parts of that schema in the user records? Thanks for any help...

3 3

Open LDAP Installation/Configuration Failed.
by vijay s sheelavantar 07 Sep '11

07 Sep '11

Hi,I am trying to configure and compile the pam_ldap and nss_ldap for MIPS architecture. for this they need ldap library. so I am trying to compile openldap code for MIPS first, but the configuration is failing. The command and options used for configuration is as follows. ./configure --host=mips CC=/opt/montavista/pro/devkit/mips/fp_be/bin/mips_fp_be-gcc LD=/opt/montavista/pro/devkit/mips/fp_be/bin/mips_fp_be-ld CFLAGS="-g -O2 -I/usr/include -I/usr/include/openssl" LDFLAGS="-L/usr/lib" --prefix=/mips/ldap --with-yielding_select=no and the errors got are as follows. hecking for sys/un.h... yes checking openssl/ssl.h usability... no checking openssl/ssl.h presence... yes configure: WARNING: openssl/ssl.h: present but cannot be compiled configure: WARNING: openssl/ssl.h: check for missing prerequisite headers? configure: WARNING: openssl/ssl.h: see the Autoconf documentation configure: WARNING: openssl/ssl.h: section "Present But Cannot Be Compiled" configure: WARNING: openssl/ssl.h: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for openssl/ssl.h... no checking gnutls/gnutls.h usability... no checking gnutls/gnutls.h presence... no checking for gnutls/gnutls.h... no checking nssutil.h usability... no checking nssutil.h presence... no checking for nssutil.h... no configure: error: MozNSS not found - please specify the location to the NSPR and NSS header files in CPPFLAGS and the location to the NSPR and NSS libraries in LDFLAGS (if not in the system location) Kindly help me to fix this error. Thank you. Regards,Vijay S.

2 1

About the information acquisition from slapd.d
by nozawat 06 Sep '11

06 Sep '11

Hi It is a question about the setting when I use slapd.d. 1.I acquire PID information in the following scripts, but will not have any problem? $config_file appoints slapd.d directory. ---- pid_file=`sed -ne \ 's/^olcPidFile:[[:space:]]\+$.\+$[[:space:]]*/\1/p' \ "$config_file"/'cn=config.ldif' 2>/dev/null` ---- 2.I am going to acquire information to use in the following scripts in ldapsearch -b. ---- for suffix in `find "$config_file"/'cn=config' -type f -name olcDatabase* -exec \ sed -ne 's/^[[:space:]]*olcSuffix:[[:space:]]\+$.\+$/\1/p' {} \;` ---- The script mentioned above is a part of a script for slapd monitoring to use it in pacemaker. Because ldap is not an expert, I want to hear the opinion of the person of the expert. Regards, Tomo

2 2

memberOf question
by Chris Jackson 06 Sep '11

06 Sep '11

Running OpenLDAP: slapd 2.4.23. My server currently returns memberOf info only when directly queried using memberOf. Is there a way to allow a base uid=me ldapsearch to return group memberships without specifying the memberOf? ldapsearch -x -h someserver.test.net -W -D cn=someuser,dc=test,dc=net -b dc=test,dc=net uid=me versus ldapsearch -x -h someserver.test.net -W -D cn=someuser,dc=test,dc=net -b dc=test,dc=net uid=me memberOf Here is the result of memberOf query: # extended LDIF # # LDAPv3 # base <dc=test,dc=net> with scope subtree # filter: uid=me # requesting: memberOf # # me, test.net dn: uid=me,dc=test,dc=net memberOf: cn=agroup,dc=test,dc=net

2 1

Re-binding to a different LDAP tree from an overlay
by Abu Marcose 06 Sep '11

06 Sep '11

I have a unique situation where we have developed a custom overlay that intercepts & processes bind requests. As part of the processing I need to bind to a different LDAP tree as a different user (with write access) and delete an object. How can I accomplish this ? Would anyone be able to point me to some sample code that would accomplish this ? Thanks in advance

1 0

Cross compilation of LDAP clients.
by vijay s sheelavantar 06 Sep '11

06 Sep '11

Hello,I want to compile pam_ldap and nss_ldap for MIPS architecture. I am getting lot of errors while doing this. it is asking for lldap and other libraries, and  ldap.h, ber.h, sasl.h header files. Kindly tell me the exact steps to follow for compiling these libraries for a particular architecture(MIPS,PPC etc). Thanks and Regards, VIJAY S.

2 1

Assigning Groups to LDAP users
by pradyumna dash 06 Sep '11

06 Sep '11

Guys, I have a query, lets take a scenario : Assume we have 2 servers "Server1" and "Server2" and 2 groups "Admin" and "ITTech", What is needed is like say when a user "bob" logging in to "Server1" he will get the group "Admin", but when he logs in to "Server2" he will get group "ITTech". Also it may vary for different users like when "Kris" logs in to Server1 he may get a group called "ITTech" and when he logs in to "Server2" he will get some other group say "Security". Can it be possible by OpenLDAP ? If this is achieved then we are planning to have SUDO files based on the grooups. It would be great if you can provide me some pointers or how-to. Regards, Neo

6 6

Re: syncrepl giving error "CSN too old, ignoring " for detla replication
by Yuri Bank 05 Sep '11

05 Sep '11

Hmm. I thought you only needed NTP time sync with N-way and MMR. But not with single Provider. I guess I never noticed an issue with this since my servers run ntp ayways. On Sat, Sep 3, 2011 at 1:57 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Saturday, September 03, 2011 1:02 AM -0700 Yuri Bank < > yuribank(a)gmail.com> wrote: > > I've seen a very similar issue (ContextCSNs being newer on my consumers), >> and I believe it was fixed in OpenLDAP (2.4.26). Do the "CSN too old, >> ignoring" error messages spam endlessly in your consumer logs? >> >> As for your other questions. You only need a single accesslog, and the >> clocks on your consumer nodes do not need to be in synch with the >> Provider (in deltasync replication). >> > > Wrong. Your clocks should *always* be tightly in sync. Particularly with > the advent of delta-sync MMR in the next release. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Slapd-meta stop at the first unreachable candidate
by Michel Gruau 05 Sep '11

05 Sep '11

Hello, It have a slapd-meta configuration as follows: database meta suffix dc=com uri ldap://server1:389/dc=suffix1,dc=com uri ldap://server2:389/dc=suffix2,dc=com uri ldap://server3:389/dc=suffix3,dc=com I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested. I have the felling this is a bug ... could you confirm ? FYI, I also tried the "'onerrr continue" config, but did not change annything Thanks in advance. Michel Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

4 6

Re:Slapd-meta stop at the first unreachable candidate
by Michel Gruau 05 Sep '11

05 Sep '11

Below is a sample configuration allowing to reproduce the problem : Three openldap data instances configured as follows: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc/openldap/schema/nis.schema include /opt/openldap/etc/openldap/schema/dyngroup.schema include /opt/openldap/etc/openldap/schema/misc.schema pidfile /opt/openldap/var/run/server1.pid argsfile /opt/openldap/var/run/server1.args loglevel stats database bdb suffix ou=orgunit,o=gouv,c=fr directory /opt/openldap/var/server1 Note: server1 is changed by server2 and server3 for other instances. Each instance contains the following data: (only 4 entries): dn: ou=orgunit,o=gouv,c=fr objectClass: top objectClass: organizationalUnit ou: orgunit dn: ou=dept1,ou=orgunit,o=gouv,c=fr ou: dept1 objectClass: top objectClass: organizationalUnit dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: user11(a)server1.com cn: User 11 uid: user11 givenName: User sn: 11 dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: user12(a)server1.com cn: User 12 uid: user12 givenName: User sn: 12 Note: user1x and dept1 are substituted in instances 2 and 3 by user2x, dept2, user3x,dept3. Data instances are launched using this command: /opt/openldap/libexec/slapd -n server1 -f /opt/openldap/etc/openldap/server1.conf -h ldap://0.0.0.0:1001/ /opt/openldap/libexec/slapd -n server2 -f /opt/openldap/etc/openldap/server2.conf -h ldap://0.0.0.0:1002/ /opt/openldap/libexec/slapd -n server3 -f /opt/openldap/etc/openldap/server3.conf -h ldap://0.0.0.0:1003/ Meta instance is configured as follows: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc/openldap/schema/nis.schema include /opt/openldap/etc/openldap/schema/dyngroup.schema include /opt/openldap/etc/openldap/schema/anais.schema include /opt/openldap/etc/openldap/schema/misc.schema pidfile /opt/openldap/var/run/meta.pid argsfile /opt/openldap/var/run/meta.args database meta suffix ou=orgunit,o=gouv,c=fr uri ldap://localhost:1001/ou=dept1,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 3 uri ldap://localhost:1002/ou=dept2,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 4 uri ldap://localhost:1003/ou=dept3,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 4 and it is launched as follows: /opt/openldap/libexec/slapd -n meta -f /opt/openldap/etc/openldap/meta.conf -h ldap://0.0.0.0:1000/ -d 256 # test with the 3 servers up /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user21,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user22,ou=dept2,ou=orgunit,o=gouv,c=fr => entries from the three servers are returned # stop server 2 (kill -INT ...) and perfom a new search: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => looks good : entries from server1 and server 3 are returned Below are the meta instance logs: conn=1001 fd=9 ACCEPT from IP=172.30.8.13:55048 (IP=0.0.0.0:1000) conn=1001 op=0 BIND dn="" method=128 conn=1001 op=0 RESULT tag=97 err=0 text= conn=1001 op=1 SRCH base="ou=orgunit,o=gouv,c=fr" scope=2 deref=0 filter="(objectClass=person)" conn=1001 op=1 SRCH attr=dn conn=1001 op=1 meta_back_retry[1]: retrying URI="ldap://localhost:1002" DN="". conn=1001 op=1 meta_back_retry[1]: meta_back_single_dobind=52 conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=4 text= conn=1001 op=2 UNBIND conn=1001 fd=9 closed => looks good as nentries=4 # perform numerous new search without changing anything: [root@pp-ae2-proxy2 log]# /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: => nothing returned Below are the corresponding logs: conn=1002 fd=9 ACCEPT from IP=172.30.8.13:55049 (IP=0.0.0.0:1000) conn=1002 op=0 BIND dn="" method=128 conn=1002 op=0 RESULT tag=97 err=0 text= conn=1002 op=1 SRCH base="ou=orgunit,o=gouv,c=fr" scope=2 deref=0 filter="(objectClass=person)" conn=1002 op=1 SRCH attr=dn conn=1002 op=1 meta_search_dobind_init[1]: retrying URI="ldap://localhost:1002" DN="". conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= conn=1002 op=2 UNBIND conn=1002 fd=9 closed => looks bad as nentries=0 => Only the first search after server2 stop is successfull. # new search but using server1 ou: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=dept1,ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr => looks good # same search as earlier i.e. using root node: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr => Looks good also. It looks like all is OK but only once a channel is opened to server1 using another manner # new search but using server3 base object: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=dept3,ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => looks good # new search but using slapd-meta base object: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => entries from server1 and server3 are returned => this confirms lookups in server1 and server3 are not performed until a channel is opened to both of them using their repective base object => another strange behavior : if search using server3 ou is performed before serach using server ou, then next search attempt using root node allows to retrieve entries from both server1 and server3 ... # new search after server2 restart: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user21,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user22,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => good, all entries are returned # new search after meta instance restart while server2 is already stopped opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: => unlike the previous test case (server2 stopped while meta instance is already running) we do not see the single successfull search. Then, behaviour is the same i.e. search on root node works again, but only once a search has been performed using ou=dept1 and ou=dept3. In addition, behaviour is slightly different adding the "conn-ttl" parameter set to 3 (3 seconds). I could expose it in a new post. Thanks for anyone who could help to identify whether it is a misconfiguration or a bug. Michel Gruau > Message du 19/08/11 13:13 > De : "Michel Gruau" > A : "openldap-technical openldap org" > Copie à : > Objet : Slapd-meta stop at the first unreachable candidate > > Hello, It have a slapd-meta configuration as follows: database meta suffix dc=com uri ldap://server1:389/dc=suffix1,dc=com uri ldap://server2:389/dc=suffix2,dc=com uri ldap://server3:389/dc=suffix3,dc=com I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested. I have the felling this is a bug ... could you confirm ? FYI, I also tried the "'onerrr continue" config, but did not change annything Thanks in advance. Michel > > Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

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