openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: 8 principal limitation in openldap
by Srivatsav M 31 Mar '11

31 Mar '11

Hi, I was triaging this issue and I ran into another mysterious area, it doesn't look like the number (8) of principals/RDN is the problem and infact the length/size of the RDN's could be the issue. Please find the /etc/ldap.conf files attached renamed according to the AD/openldap server being configured. a. In the ad_ldap_conf_size the number of characters is around 3137 for the nss_base_<map>. On line 122, if i just make the 80 as 8 in the end of the string, the command "getent passwd" is working and it lists all the users registered in the ldap.conf file but otherwise it doesn't show any user. b. In the open_ldap_conf_size_issue the number of characters is around 3103 for the nss_base_<map>. In the end of the file if i just comment the last two lines, the "getent passwd" is working and it lists all the users registered in the ldap.conf file but otherwise it doesn't show any user. from these findings this looks more like some buffer issue, can you please help me with the following. 1. Any particular method/file that I should be looking for to check this buffer size may be even in the nss_ldap library or so 2. If there is a buffer size issue of say around 3137 characters (bytes for that), what would be the best value to increase it. appreciate any help Thanks Ramakanth On 30 March 2011 01:17, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote: > Please find below the answers to your questions: > > 1. > >> We are using OpenLDAP for authenticating users registered in a LDAP > > > >> server (Open LDAP, Active Directory). > > Which one? Or both? > > Our dev environment has openLDAP and AD servers and we have tested this issue against each of them individually and are able to reproduce it against both the types of LDAP servers > > 2. Users shouldn't be "registered in the /etc/ldap.conf file". > >> Can you please help me understand why I shouldn't be using this in the > ldap.conf file? > > 3. Please supply a full copy of your /etc/ldap.conf, or at least a > representative one, and provide the example output of 'getent passwd > username' and 'groups > > >> attached along with this mail > > username' for the user who doesn't authenticate. You may also want to supply > the relevant PAM configuration files. > > $ getent passwd > root <xxxxxxxxx> > test_user:somepwd:1002:1002:Test User:/home/testuser:/bin/bash > test_people1:*:10004:10004:Test People1:/home/test_people1:/bin/bash > > >> All external users are not able to login after adding the 8th principal/RDN > > /etc/pam.d/common-auth > > auth required pam_env.so > auth sufficient pam_ldap.so use_first_pass > auth required pam_unix2.so > > /etc/pam.d/common-account > > account required pam_unix2.so > account sufficient pam_localuser.so > account required pam_ldap.so use_first_pass > > /etc/pam.d/common-session > > > session required pam_limits.so > session required pam_unix2.so > session required pam_mkhomedir.so skel=/etc/skel/ > session optional pam_ldap.so > session optional pam_umask.so > > Also, please provide details of your LDAP client (distribution release, what versions of nss_ldap and pam_ldap you are running). > > >> openldap2-client-2.3.32-0.25 > >> nss_ldap-259-4.3 > > 4. Do we know what the actual problem is? Do we know it would be solved by > nss-ldapd? > > There might be a simple misunderstanding here, or a simple configuration problem, and switching software might not solve that. > > Additionally, the distribution in question may have a different preferred LDAP client. > > >> based on the above information, would it be possible for pointing any config. issues? , please do let me know if you need any further information. > > thanks > > Ramakanth > > > On 25 March 2011 20:23, Marco Pizzoli <marco.pizzoli(a)gmail.com> wrote: > >> Hi, >> I could be corrected if I'm wrong, but this problem is not related to >> OpenLDAP. It's a nss_ldap problem. >> nss_ldap is a client library that's used by linux vendors to achieves >> seamless integration of users against *a* LDAP server. >> >> I had a similar problem with a complex configuration and bypassed (not >> solved) the problem by modifying my client configuration. >> >> I reduced the number of ldap server configured to be accessed: from 4 to >> 3. >> I reduced the number of users defined in *nss_initgroups_ignoreusers*directive: i had about 40 listed in it... >> >> Etc... >> >> Make some tries and tell me if you can solve it. >> >> Marco >> >> >> >> On Thu, Mar 24, 2011 at 9:25 PM, Srivatsav M <srivatsav.mudumba(a)gmail.com >> > wrote: >> >>> Hi, >>> >>> We are using OpenLDAP for authenticating users registered in a LDAP >>> server (Open LDAP, Active Directory). After adding 8 principals >>> (/etc/ldap.conf), none of the users registered in the /etc/ldap.conf file >>> are able to login. >>> >>> nss_base_passwd >>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>> nss_base_shadow >>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>> nss_base_group >>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>> >>> >>> Can you please share the reason for this 7 limitation in the open ldap >>> library. or how I can fix this issue. I am looking i for the header file in >>> the source files whhich has this constant or limitation defined. >>> >>> Tried googling, but it appears that no one has encountered this issue. >>> Some customers are running into this issue and it has become a severity 1 >>> issue to fix. >>> >>> Thanks >>> Ramakanth >>> >> >> >> >> -- >> _________________________________________ >> Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. >> Jim Morrison >> > >

1 0

RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Markus Moj 31 Mar '11

31 Mar '11

Hey, We are faceing a weird problem with our LDAP running on Red Hat 6.0. When we start our OpenLDAP with the init script as "root" the ldap server starts without problems or errors and seems to be runnig ok. If you connect with an LDAP Browser like Apache Directory Studio and try to edit some parameters in cn=config you get the following error. [LDAP: error code 80 - internal error (cannot create file)] But when you start the LDAP server with "/usr/sbin/slapd -h ldap:/// -u ldap" as the init script does, everything is working just fine and you are able to make every change you need to. Someone out there who has the same problem or already a solution or workaround for this problem? Mit freundlichen Grüßen / Kind regards Markus Moj IT Infrastructure & Services TimoCom Soft- und Hardware GmbH In der Steele 2 DE-40599 Düsseldorf Tel: +49 211 88 26 80 14 Fax: +49 211 88 26 70 14 eMail: mmoj(a)timocom.com Internet: www.timocom.com Geschäftsführer: Jens Thiermann, Gunther Matzaitis Amtsgericht Düsseldorf, HRB 34489

4 3

Global configuration directive 'logfile'
by Mark 31 Mar '11

31 Mar '11

I've been trying to get the 'logfile' configuration attribute (man5/slapd.conf.5) working but can't seem to. The relevant slapd.conf entries before I define my backend look like: loglevel stats sync logfile /tmp/openldap/var/log/slapd.log and the file exists before I start slapd: $ ls -l /tmp/openldap/var/log/slapd.log -rw-r--r-- 1 me mygrp 0 Mar 30 15:58 /tmp/openldap/var/log/slapd.log SLAPD runs fine dumping information into syslog but my logfile stays zero length. How can I get my logfile to get written to also? Thank you, My setup: RedHat Enerprise Linux 4.7 (Linux host 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:46:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux) OpenLDAP 2.4.25 BerkeleyDB 4.8.30 OpenSSL 1.0.0d *Cyrus SASL *2.1.23 configured thusly: ( PATH="/tmp/openldap/bin:${PATH}"; export PATH echo "##BEG `date '+%Y/%m/%d %H:%M:%S'` - configure" CPPFLAGS="-I/tmp/openldap/include" \ CFLAGS="-g" \ LDFLAGS="-L/tmp/openldap/lib -R/tmp/openldap/lib" \ ./configure \ --without-subdir \ --enable-slapd \ --enable-modules \ --enable-wrappers \ --enable-backends=mod \ --disable-sql \ --disable-ndb \ --enable-overlays=mod \ --enable-debug \ --prefix=/tmp/openldap echo "##END `date '+%Y/%m/%d %H:%M:%S'` - configure" ) compiled and installed in /tmp/openldap $ file /tmp/openldap/libexec/slapd /tmp/openldap/libexec/slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped

1 1

Re: Antwort: Re: RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Dan White 31 Mar '11

31 Mar '11

On 31/03/11 14:29 +0100, Markus Moj wrote: >So what do you mean by specify a gid? This is not a self scripted init >script this one is 100% Red Hat we have changed nothing within the start >script. Redhat may not, but it's not uncommon for other OSs to do so. I'm assuming that the error message you are seeing is permissions related, possibly due to the fact that slapd is running under a different effective gid when you start it from the command line versus when you start it from an init script. One way to trouble shoot that is to explicitly specify a gid (-g) from your init script and your command line. -- Dan White

2 1

Infos needed to setup a ldap proxy
by Frank Bonnet 31 Mar '11

31 Mar '11

Hello Anyone could send me some pointers on documentation howto setup a proxy OpenLDAP server ? Basically I need it to have a unique LDAP server to configure all our LAN clients and have the possibility to modify the proxy server on demand to access several directory servers ( locals and distants ) Thanks

3 2

ldapsearch - CA cert without using ldap.conf
by Liam Gretton 31 Mar '11

31 Mar '11

Hi, With ldapsearch I'd like to specify on the command line the CA certificate file without having to use TLS_CACERT in ldap.conf or any other configuration file. I suspect the solution lies in either the -O or -e option to ldapsearch, but I can't find any documentation about them. I'd be very grateful to any pointers to a solution. -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

5 5

Authentication issue with syncrepl consumer
by Daniel Finn 31 Mar '11

31 Mar '11

I’ve got a strange issue going on which I believe just started happening but it’s hard to say for sure. I’ve got a small environment with a syncrepl provider and a syncrepl consumer which is placed in our DMZ. The provider is used for authentication for all of our internal linux servers and the consumer is used for authentication for all of our DMZ servers. The environment is less than 50 servers and maybe about 25 users. Both of these ldap servers are running OpenLDAP 2.3.43-12 provided by CentOS. I put this all into place about 2 months ago and everything has been working fine up until now. I’m seeing authentication failures for servers using the consumer but it’s not for all users, for example my personal user is able to authenticate fine which is what makes it hard to say when this started happening. For the most part I’m the only one logging into these servers on a regular basis. One of our web developers today let me know that he was unable to log into any servers that authenticate against the consumer but that he could log into all of the rest of our servers. I changed his password, noticed that syncrepl saw the change on the consumer and I still wasn’t able to log in as that user. I then created a new user, saw that syncrepl saw that on the consumer, and also was not able to log in as that user. Both of these users can still log into any server authenticating against the provider. On the consumer, I shut down ldap, deleted everything from under /var/lib/ldap and started from scratch using slapadd to import an ldiff that was dumped from the provider. This still didn’t fix the authentication issues. I’m not exactly sure what the relevant info is from the log so I captured a complete log that includes a failed authentication attempt with the loglevel set at 1. It can be seen here: http://pastebin.com/KY9m0CN4 The only thing I see in there that jumps out at me is: “<= bdb_index_read: failed (-30989)” It looks like I’m seeing that for every authentication failure. I found a couple old mailing posts regarding that error saything that it could either be BDB corruption or that it could just mean it’s searching for something that doesn’t exist. I was assuming that if it was BDB, that starting from scratch with the slapadd would fix it but it did not. I also did a diff against the dumps from both the provider and the consumer and when comparing the entries for a user who is failing authentication on the consumer, the only difference was the entryCSN and the modifyTimestamp. Any help would be really appreciated. Thanks, Dan Daniel Finn Linux/Storage Administrator P: 801.553.4587 M: 801.683.9147 [cid:3384344954_110196386] “Improving Oral Health Globally” Email Policy - Unauthorized review, use, disclosure, or distribution of this e-mail is strictly prohibited. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, is intended solely for the individual or individuals to whom it is specifically addressed. If the recipient of this email is not the intended recipient, do not read, copy or distribute it or any of the information it contains. Please delete it immediately and notify us by return email or by telephone 801.572.4200.

1 1

user authentication on attributes
by sim123 30 Mar '11

30 Mar '11

I have openLDAP server up and running and trying to integrate it with Confluence. My LDAP structure looks like DN :: uid=123, ou=users, dc=example, dc=com uid :: 123 mail :: bjason(a)example.com cn :: barbara sn :: jason userPassword :: test (plain test for now) I have another similar entry in another branch (su) for "confluence admin", I did LDAP configuration in confluence and tested the bind with confluence user. Now for every user authentication I am assuming LDAP should be able to bind on any attribute other than DN. however I can not do that. when I try to login from confluence using mail & password, this is what I see in my slapd.d logs : connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 48 contents: op tag 0x60, time 1301434489 ber_get_next conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <uid=234,ou=su,dc=example,dc=com> <<< dnPrettyNormal: <uid=234,ou=su,dc=example,dc=com>, <uid=234,ou=su,dc=example,dc=com> do_bind: version=3 dn="uid=234,ou=su,dc=example,dc=com" method=128 bdb_dn2entry("uid=234,ou=su,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: got id=0x1 => bdb_dn2id("ou=su,dc=example,dc=com") <= bdb_dn2id: got id=0x4 => bdb_dn2id("uid=234,ou=su,dc=example,dc=com") <= bdb_dn2id: got id=0x7 entry_decode: "uid=234,ou=su,dc=example,dc=com" <= entry_decode(uid=234,ou=su,dc=example,dc=com) do_bind: v3 bind: "uid=234,ou=su,dc=example,dc=com" to "uid=234,ou=su,dc=example,dc=com" send_ldap_result: conn=1000 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 144 contents: op tag 0x63, time 1301434489 ber_get_next conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <ou=user,dc=example,dc=com> <<< dnPrettyNormal: <ou=user,dc=example,dc=com>, <ou=user,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=1000 op=1 self="uid=234,ou=su,dc=example,dc=com" this="ou=user,dc=example,dc=com" => bdb_search bdb_dn2entry("ou=user,dc=example,dc=com") => bdb_dn2id("ou=user,dc=example,dc=com") <= bdb_dn2id: got id=0x3 entry_decode: "ou=user,dc=example,dc=com" <= entry_decode(ou=user,dc=example,dc=com) search_candidates: base="ou=user,dc=example,dc=com" (0x00000003) scope=2 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_dn2idl("ou=user,dc=example,dc=com") <= bdb_dn2idl: id=2 first=3 last=6 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 2 candidates <= bdb_equality_candidates: id=2, first=6, last=7 => bdb_equality_candidates (cn) => key_read <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 bdb_search_candidates: id=0 first=3 last=0 bdb_search: no candidates send_ldap_result: conn=1000 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 12 I guess I should be able to do LDAP_BIND with any attribute and LDAP should be able to search user's DN based on the attribute and authenticate him as I have laready provided valid DN and password (for confluence user), am I right here? Please let me know if its doable (should be) and what am I missing here ? I tried searching for this but couldn't find it on the web. Thanks for the help and support. -simon

3 6

syncrepl binds always fail the first time
by Tyler Gates 30 Mar '11

30 Mar '11

Hello, Using version 2.4.24 I have a replication server that periodically queries the provider for updates via refreshOnly. I've noticed that once slapd is started, the bind to the replicator DN on the provider always failed but subsequent do_syncrepl retries succeed. Ideally I'd like the first bind to succeed so it pulls in all the data instead of having to wait <retry> seconds. Is this normal behavior or do I have something mis-configured? slapd.conf: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/qmail.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_hdb loglevel config allow bind_anon_dn database hdb directory /var/lib/ldap suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" index objectclass,entryCSN,entryUUID eq index uid,memberUid,uidNumber,gidNumber eq cachesize 200 idlcachesize 600 checkpoint 50 5 syncrepl rid=001 provider=ldaps://directory-master.domain.com type=refreshOnly interval=00:00:10:00 retry="60 5 600 +" searchbase="dc=domain,dc=com" filter="(|(&(objectClass=posixAccount)(uid=username))(&(objectClass=posixGroup)(memberUid=username)))" scope=sub attrs="cn,sn,givenName,homeDirectory,loginShell,ou,uid,uidNumber,userPassword,memberUid,gidNumber" schemachecking=off bindmethod=simple binddn="cn=replicator,dc=domain,dc=com" credentials=secret

2 1

meta and AD disabled accounts
by Fred 30 Mar '11

30 Mar '11

Okay, new to OpenLDAP, have managed to setup a meta backend/proxy to multiple Active Directory systems that is doing everything I need with one exception. I can't figure out a reliable way to filter out disabled accounts on the AD side. I know how to query this directly against AD of course (NOT UserAccountControl:1.2.840.113556.1.4.803:=2), but after a lot of searching and head scratching I'm not sure how to implement this in my slapd.conf - or even just allow the filter (if specified by a client) to pass through: My original filter: "(&(objectclass=inetOrgPerson)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))" >From slapd debug output, after passing through the parser: "(objectClass=user)(!(!(objectClass=*)))(?=error)" As you can see, objectClass inetOrgPerson is mapped to User (and I've got some work to do on the Computer objectClass too) but the UserAccountControl bitwise flag is the part I'm hung up on right now.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical