openldap-technical

openldap-technical@openldap.org

11 participants
9877 discussions

Using memberOf overlay with groups that contain uids, not DNs
by Oliver Beattie 02 Apr '11

02 Apr '11

Hi, I realise the documentation for slapo-memberof indicate that this isn't possible, but I thought it worthwhile asking here anyway — is it possible to use the memberOf overlay with groups that use memberUid as their membership attributes, rather than user DNs? We have a large existing LDAP database that has thousands of groups like this, and would very much like to use slapo-memberof. Any pointers (positive or negative) much appreciated — just so I know for definite. —Oliver

2 1

adding a second node
by Friedrich Locke 01 Apr '11

01 Apr '11

Hi folks, i am begining to study ldap and have a doubt. In my tree i have a node a=b inserted below c=d,e=f, i.e., a=b,c=d,e=f exists. What happens if i try to insert a "new" a=b below c=d,e=f ? Thanks in advance. Gustavo.

2 1

Re: Antwort: Re: RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Quanah Gibson-Mount 01 Apr '11

01 Apr '11

--On Friday, April 01, 2011 6:05 AM +0100 Markus Moj <MMoj(a)timocom.com> wrote: > > Hi, > > due to update and security policies in my company we are using the stable > version of the delivered build in openLDAP from Red Hat. Hi Markus, While I understand this is often the case with companies, this policy is short sighted. If you want to have a stable, secure, and functional LDAP server, then you need to be able to build OpenLDAP from source. If you insist on using RedHat's outdated and flawed packages, then you need to contact RedHat support to fix any bugs you find with it, as the advice from upstream will always be for you to build and install the current OpenLDAP version to verify whether or not any bugs you find actually exist in a current release. I would suggest you read over the change logs since OpenLDAP 2.4.19 was released to get an idea of the numerous issues that have been fixed since that release went out. --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

1 0

Dealing with BDB Crash
by ldap＠mm.st 01 Apr '11

01 Apr '11

A while ago I posted that we were having what we thought were random bdb backend crashes with the following in our log: bdb(o=example.com): PANIC: fatal region error detected; run recovery. This was on a on our RH5 openldap servers (2.3.43) that we were rebuilding: It appears that the crashes were caused by a vulnerability scanner that was hitting the server (still testing), even though it was suppose to be safe. We'll have to investigate what is causing it, maybe we will need an acl to stop whatever the scanner is doing. Once we stopped the automated scan, the servers seem to be running as expected. But, this brought up another issue. When the bdb backend failed, the slapd process continued run and listen on the ldap ports and clients still tried to connect to the failed server for authentication. The server accepted and established the connection with the client. Of course the client could not authenticate since the backend db was down. The client will not fail over to the other server that is listed in it's ldap.conf file since it thinks it has a valid connection. If the slap process is not running then the fail over works fine since no ports are there for the client to connect to. I'm thinking that bdb failures will be rare once we solve the scanner issue, but on a network that relies heavily on ldap, a failed bdb backend with a running slapd would cause significant issues. Just trying to restart the slapd service doesn't fix the issue, a manual recovery is required (slapd_db_recover). I was curious if anyone has put something in place to deal with this potential issue? Maybe run slapd_db_status via cron and if it errors due a bdb corruption, just stop slapd and let the admin know. At least the clients would be able to failover to the other ldap servers. I guess an automated recovery is possible via a script, but I'm not sure if that's a good idea. Maybe dealing with this type of failure is not really required, I was hoping that some of you that have been do this for a while would have some insight.

8 9

issue with slapadd
by Judith Flo Gaya 01 Apr '11

01 Apr '11

Hello, I'm using openldap-server 2.4.19-15 in a Red Hat 6 box (x86_64), rpm installation. This is the very first time I use ldap and I'm having some issues with the configuration. I read that the slapd.conf file should not be use, instead the slapd.d directory is the new system that is meant to be. As I don't know how this exactly works, I've been reading and folowing the tutorial in the openldap page. Specifically I read the Administration guide and I copy and adapt the config.ldif file to suit my needs. After a while I manage to run the command: slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif with no problems. I thought that once this was done the slapd should start smoothly, but instead I'm having an slaptest error saying that my configuration FILE is wrong. As the slapd.conf doesn't exists, I don't know where this error comes from. I tried #slaptest -v -d1 -F ../slapd.d/ [......] ldif_back_add: "olcDatabase={-1}frontend,cn=config" oc_check_required entry (olcDatabase={-1}frontend,cn=config), objectClass "olcDatabaseConfig" oc_check_required entry (olcDatabase={-1}frontend,cn=config), objectClass "olcFrontendConfig" oc_check_allowed type "objectClass" oc_check_allowed type "olcDatabase" oc_check_allowed type "olcAddContentAcl" oc_check_allowed type "olcLastMod" oc_check_allowed type "olcMaxDerefDepth" oc_check_allowed type "olcReadOnly" oc_check_allowed type "olcMonitoring" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 slaptest: bad configuration directory! Since the directory structure was built by the slapadd command, where is the problem? I'm sure I'm doing something wrong but I can't find it ;( Permissions are ok (at the beginning I had issues with the include core.ldif part of my config.ldif, I ended pasting the contents in the config.ldif) Thanks in advance for your help, hope you can shed some light on this. j -- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo(a)imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472 Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org

2 2

importing ldap database for a BDC
by deconya 01 Apr '11

01 Apr '11

Hi list Im preparing a BDC server using samba with ldap and I start to import the database. At first I commented and error with the suffix but not was the last of my problems, Im importing and appears: <= str2entry: str2ad(sambaLogonTime): attribute type undefined slapadd: could not parse entry (line=81) _ 0.09% eta 01m elapsed none spd 64.8 k/s Closing DB... What Im making bad? First I copied all inside /etc/ldap/schema/ to the BDC, and I prepared with slapcat a bckup from PDC. I installed samba and copied smb.conf modifying the role. When I go to execute the slapadd -l backup.ldif appears the error. Any idea? Thanks And Best Regards

3 3

Regexp in rootdn and set-resolving of monitor attr
by Kilian Röhner 01 Apr '11

01 Apr '11

Hey, i have two questions: 1. Is it possible to specify a regexp as rootdn? 2. In an access-rule, i have a set like: by set="(user + ([cn=Current,cn=Time,cn=Monitor]/monitorTimestamp)) & (this/modifiersName + this/createTimestamp)" write But it seems, that the Monitor-Part isn't resolved correctly (returns empty and thus empty for the whole set). What am i doing wrong here? Thanks! Regards, Kilian

3 7

overlay ppolicy not found
by sarath chandra 01 Apr '11

01 Apr '11

Hi, I'm getting this error: ------------------------------------------Mar 31 18:03:50 if-sr-000033 slapd[2170]: @(#) $OpenLDAP: slapd 2.4.23 (Feb 21 2011 03:15:19) $ root@IF-SR-000033:/root/ldap/openldap-2.4.23/servers/slapd Mar 31 18:03:50 if-sr-000033 slapd[2170]: overlay "ppolicy" not found Mar 31 18:03:50 if-sr-000033 slapd[2170]: slapd stopped. Mar 31 18:03:50 if-sr-000033 slapd[2170]: connections_destroy: nothing to destroy. ------------------------------------------ The slapd.conf file has these entries also: modulepath /usr/local/lib moduleload /usr/local/lib/ppolicy.la overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=uaeexchange,dc=com ppolicy_use_lockout ------------------------------------------ The o/s is CentOS release 5. Can anybody suggest a solution for this? TIA Sarath

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical