openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Cannot authenticate with user/password
by Nicholas Syrotiuk 13 Jul '10

13 Jul '10

Dear OpenLDAP users, We have downloaded OpenLDAP 2.4.22 from Sunfreeware.com and installed it. We have successfully imported the LDAP data from another server. We are using the *simple* authentication method. I can authenticate as rootdn but not as a user. Is there something wrong with my access control list: ----------------------- access to * by self write by users read by anonymous none ------------------------- I have tried running slapd with debugging switched on but could not diagnose the problem. Any ideas on how to troubleshoot this? Cheers, Nick -- N Syrotiuk | Mimas | University of Manchester | Manchester M13 9PL

4 4

Adding replicant with ppolicy after the fact
by G.Pitman 12 Jul '10

12 Jul '10

Hi, I have a openldap installation that we recently implemented ppolicy and we have come to the point of using it in production. I am in the process of putting in a dedicated ldap replicant(punching bag) and I am having trouble importing the directory due to the ppolicy extended attributes not being modifiable. Is there a way to preserve the password ages and other pwd related history to the new replicant? I reckon I could copy the entire contents of /var/lib/ldap/ from an old replicant to the new, and cross my fingers but that doesn't seem like the correct path. Redhat EL 5.5 openldap-servers-2.3.43-12.el5 Thanks for listening,

2 1

How to best handle DN+String and DN+Binary in OL?
by Andrew Bartlett 12 Jul '10

12 Jul '10

I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed). Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of: #define DSDB_SYNTAX_BINARY_DN "1.2.840.113556.1.4.903" http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx #define DSDB_SYNTAX_STRING_DN "1.2.840.113556.1.4.904" http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx #define DSDB_SYNTAX_OR_NAME "1.2.840.113556.1.4.1221" http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules. Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs). What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? (Additionally, even when just use deref with normal DNs, I'm not getting a the control response, but I need to get more info before I can pin the details down) Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc.

4 11

Attribute type is operational
by Stuart Cherrington 12 Jul '10

12 Jul '10

Hi, I'm running Openldap 2.4 on Rhel5. I've got the basics working, user accounts etc, but have tried adding some new schemas which I'm getting problems with. I followed a VERY helpful Blog at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.ht… which allowed me to install some Oracle OID schema's so we can move away from Oracle OID. This Blog is a little out of date and I have some attributetypes which I need to add-in to the schema. I've added the following 2 lines: attributetypes ( 2.16.840.1.113894.1.1.37 NAME 'orclGuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributetypes ( 2.16.840.1.113894.1.1.1000 NAME 'orclnormdn' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) I took these from the current 10.2.0 OID installation so wasn't 100% sure they were correct but they are similar in construct the others found on the blog. When I restart ldap2.4 I get error: service ldap2.4 restart Checking config file /etc/openldap2.4/slapd.conf: [FAILED] /etc/openldap2.4/schema/oidbase.schema: line 27 attributetypes: "2.16.840.1.113894.1.1.37" is operational slaptest2.4: bad configuration file! Having Googled it, I found this to mean that the attributetype had already been declared but I cannot find where, I checked in my current schemas and the defaults under /usr/share/openldap2.4/schema but found nothing. Anyone help here? Thanks, Stuart Cherrington. _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

3 2

Access control for multiple admins
by Luiz Marcelo 10 Jul '10

10 Jul '10

Hello everyone! Good, I have a scenario where two directors write on the same basis, eg "cn=admin1,dc=domain,dc=com" and "cn=admin2,dc =domain,dc=com" In a general scope, both have written permission from the base. However, assuming the user admin1 adds the entry: "uid=john,ou=people,dc=domain,dc=com", only the admin1 user can modify this entry, so each admin should only modify their own entries created in any part of the base. Someone would have any idea how I could create an access control list for this Thanks!

4 3

Re: LDAP Master hangs from time to time
by Cloud Strife 10 Jul '10

10 Jul '10

Hi Sir Edward, It does not have a pattern when it will hang, no specific time or day. The solution we always do is just restart the application and then its ok. We're still investigating the cause of this hanging. We'll look up at your suggestions. Thanks for your help On Fri, Jul 9, 2010 at 10:15 PM, Edward Capriolo <edlinuxguru(a)gmail.com>wrote: > On Fri, Jul 9, 2010 at 2:16 AM, Cloud Strife <tipidpc.ataman(a)gmail.com> > wrote: > > Hello, > > > > We have noticed that our Master LDAP hangs every month; i.e. it stopped > > processing requests. We're using openldap-2.3.43-3.el5 for LDAP master > and > > slave machines. Does this version have a known bug? Unfortunately, > upgrading > > the version in not an option right now, though we're considering it for > the > > future. Do you have any suggestion/recommendations besides upgrading? > > > > Thanks! > > > > As a guy who played FF7 for 99:99:60 hours and then some, I feel I am > obligated to help. It is rather strange for a piece of software to > fail once a month. Is it always on the same day or the same time. If > so look in /etc/cron.d and see if any process could be causing this > (faulty log roll-over, something that uses a lot of resources). > > You have not included any information that can let people help you. > Are you logging? Are there any messages in your slapd log? How about > /var/log/messages or /var/log/dmesg? Is there a memory leak? Are you > trending CPU/MEMORY/DISK activity over time using a monitor or SAR. > Have you tried capturing network traffic with tcpdump to try and > determine if there is a burst of traffic at that time? >

1 0

Segmentation Fault
by Paul Harvey 09 Jul '10

09 Jul '10

On 07/09/2010 05:48 PM, Quanah Gibson-Mount wrote: > --On Thursday, July 08, 2010 1:32 PM +0200 Paul Harvey > <pharvey(a)cern.ch> wrote: > >> Does anyone have any suggestions, and what more information do i need to >> provide. > > Well, the version of OpenLDAP you are using would be useful. Given > that without that, we can't even tell you of any fix(es) that may have > occurred since what you are running. Also, whether or not you built > OpenLDAP yourself, or if it is provided by an OS distribution, and if > it is from an OS distribution, what that is as well. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration Hi, You may have guessed that i am new to this... @(#) $OpenLDAP: slapd 2.4.21 (Apr 26 2010 11:07:14) $ buildd@rothera:/build/buildd/openldap-2.4.21/debian/build/servers/slapd Think that this says it all, simply got it from the repo at wget http://staff.telkomsa.net/packages/OpenLDAP.repo -O /etc/yum.repos.d/OpenLDAP.repo

3 2

Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
by Licause, Al 09 Jul '10

09 Jul '10

I have installed and configured the ppolicy overlay software on a Red Hat V5.4 server along with the openldap server software and the following components: openldap-servers-2.3.43-3.el5 python-ldap-2.2.0-2.1 openldap-devel-2.3.43-3.el5 checkpassword-ldap-0.01-1.2.el5.rf mozldap-6.0.5-1.el5 openldap-2.3.43-3.el5 openldap-debuginfo-2.3.43-3.el5 openldap-servers-overlays-2.3.43-3.el5 nss_ldap-253-22.el5_4 openldap-clients-2.3.43-3.el5 PROBLEM: I have notice that when an ldap users' password expires, and pwdGraceAuthNLimit is set to a non-zero value...in my case it is set to 1 for testing purposes, the user is allowed to login one time. The next login forces a password change. On the first login, allowed via pwdGraceAuthNLimit, there is no announcement sent to the user telling them that the password has expired. Nor that they will have to change their password on the next login. I have to wonder if there is also a missing announcement that might tell the user how many more logins they are permitted given the value of pwdGraceAuthNLimit It was suggested that the problem may be in the pam configuration. I am using the following /etc/pam.d/system-auth file that is autogenerated by authconfig: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so I am testing by logging into the client with ssh. I also have many of the pwd* values set fairly low for quick testing. This is the default policy in use: dn: cn=Standard,ou=Policies,dc=mydomain,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: Standard pwdAttribute: userPassword pwdLockoutDuration: 15 pwdInHistory: 6 pwdCheckQuality: 0 pwdMinLength: 5 pwdAllowUserChange: TRUE pwdMustChange: TRUE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: FALSE pwdLockout: TRUE pwdReset: TRUE structuralObjectClass: device entryUUID: 421d8558-1a33-102f-8b9e-a5541f2aaf30 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20100702143843Z pwdMinAge: 0 pwdMaxAge: 300 pwdGraceAuthNLimit: 1 pwdExpireWarning: 86400 entryCSN: 20100702154010Z#000000#00#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20100702154010Z This is the test users profile: dn: uid=ldap1,dc=mydomain,dc=com uid: ldap1 cn: ldap1 objectClass: account objectClass: posixAccount objectClass: top uidNumber: 10001 gidNumber: 150 homeDirectory: /home/ldap1 loginShell: /bin/csh gecos: ldap test user pwdPolicySubentry: cn=Standard,ou=Policies,dc=mydomain,dc=com structuralObjectClass: account entryUUID: 334312be-1a33-102f-8a83-a5541f2aaf30 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20100702143818Z pwdHistory: 20100702151010Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}BIxGPXPqBY+ 2yK6pY2i+6l7UbE/gaVhY pwdHistory: 20100702154253Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}q4inOFGO+0N c6T0q6FYiiMrPCTTUqQdr pwdHistory: 20100702183229Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}3T0Cna8AGIg X69V7zsDxGiTx/q0ceBnc userPassword:: e1NTSEF9WkZ0ekJrUWVOQVJrMDhFbDJXd0VNaU1maWlGVURaT28= pwdChangedTime: 20100702183229Z pwdGraceUseTime: 20100702184519Z entryCSN: 20100702184519Z#000000#00#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20100702184519Z I have examined various log files and enabled debugging in system-auth (now removed to show the standard autogenerated content) for any clues. I have examined various pam modules and library files with strings to see if I could get an idea as to which module may be at fault. I have to admit I am no pam expert and given the number of combinations and variations possible in the system-auth file alone, I don't feel comfortable modifying this file to any great extent. I have omitted the slapd.conf and client ldap.conf files assuming that they are not at fault and don't have any obvious omissions which could cause a warning messages to be suppressed during login, but can supply them if required. If the default system-auth file generated by the authconfig utility defeats a feature of the ldap or other system modules, we need to report this to Red Hat and have the problem corrected. Any help greatly appreciated. Al Licause

4 12

LDAP Master hangs from time to time
by Cloud Strife 09 Jul '10

09 Jul '10

Hello, We have noticed that our Master LDAP hangs every month; i.e. it stopped processing requests. We're using openldap-2.3.43-3.el5 for LDAP master and slave machines. Does this version have a known bug? Unfortunately, upgrading the version in not an option right now, though we're considering it for the future. Do you have any suggestion/recommendations besides upgrading? Thanks!

2 1

Re: Subject: So I finally upgraded from slurpd...
by Sotomayor, Vicente (ITD) 09 Jul '10

09 Jul '10

>When I start slapd on the slave I get on the slave: >=================== >18:37:50 server.foo.no slapd[7971]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 5 2010 18:35:50) $ ^Iroot@localhost:/home/kolla/openldap/openldap-2.4.23/debian>/build/servers/slapd >18:37:50 server.foo.no slapd[7972]: slapd starting >18:37:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) >18:37:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying >18:38:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) >18:38:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying Since you have 30 consumers, I believe each one needs a different syncrepl rid and the error string of "value #0 provided more than once" might be related to that, so maybe you need to change them on each consumer? Good luck

3 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