openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: I can't seem to find the answer to these olcAccess questions
by Quanah Gibson-Mount 12 Sep '17

12 Sep '17

--On Tuesday, September 12, 2017 1:38 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Mon, Sep 11, 2017 at 04:18:20PM -0500, Nick Gray wrote: >> With this config,.shouldn't this work as well >> >> ldapsearch -x -W -D cn=Manager,dc=local,dc=bob,dc=com -b cn=config >> olcDatabase=\* > > The rules on your config database are: > > olcAccess: {0} to * by > dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage > olcAccess: {1} to * by dn="cn=Manager,dc=local,dc=bob,dc=com" manage > > The first matches everything (*), so the second is never consulted. Which is specifically noted in the slapd.access(5) man page: The optional field <control> controls the flow of access rule application. It can have the forms stop continue break where stop, the default, means access checking stops in case of match. So as noted in the man page, ACL processing stops at the first matching access rule. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Invalid credentials problem
by Quanah Gibson-Mount 12 Sep '17

12 Sep '17

--On Tuesday, September 12, 2017 2:34 PM +0000 JC <lovecraftesque(a)yahoo.com> wrote: > > > > Thanks. I now know. Perhaps OpenLDAP might return a somewhat less > misleading error diagnostic in situations like this? It is not misleading, it is as per RFC. The issue is more, being new to LDAP, you're not aware of what the message means. ;) Also, please keep replies on the -technical list. More specifically, invalid credentials simply means some part of the credentials supplied is incorrect. In your case it was the DN. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP taker a long time (90s+) to shutdown
by Alexandre Rosenberg 12 Sep '17

12 Sep '17

Hello, I run into a issue where OpenLDAP would not shutdown within 90s. Sometimes shutdown is fast and sometimes not. This concern production server getting a fair amount of traffic. The reason I am mentioning 90s is because this is the default timeout for sytemd service. After that time it sends SIGKILL to the process. I am running latest OpenLDAP (2.45) with MDB database (~1GB). The server is a consumer of another OpenLDAP Server. Maybe more importantly following directive are present under the MDB database configuration. dbnosync checkpoint 500 5 I was wondering what is the expected time for OpenLDAP to shutdown. Also I am unsure if the checkpoiont setting could be related. Best, Alex

1 0

Re: Controls answers, OID unicity
by Howard Chu 12 Sep '17

12 Sep '17

Côme Chilliet wrote: > Hello, > > As some may know I’m working toward supporting controls in php-ldap. > > I’m facing two questions regarding controls to help me build the API: > - Is it possible to have several controls with the same OID in a request or response? (if not it would allow me to parse the answer to a control hash with oid as keys) > -> I tried to put twice the same control with «LDAP_CONTROL_PRE_READ» and got the error "preread control: specified multiple times", but I do not know if this is specific to preread or if it’s a rule. Not possible, no. > - Is the critical field of controls used in responses? It seems openldap server let it to false always (or I’m failing to parse it). RFC4511 section 4.1.11 is quite explicit here - the critical field in responses is always false. > > I could not find information about these subjects in RFC 2251, if there is an other RFC on this subject bringing more information do not hesitate to point me to it :-) > > Côme > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Controls answers, OID unicity
by Côme Chilliet 12 Sep '17

12 Sep '17

Hello, As some may know I’m working toward supporting controls in php-ldap. I’m facing two questions regarding controls to help me build the API: - Is it possible to have several controls with the same OID in a request or response? (if not it would allow me to parse the answer to a control hash with oid as keys) -> I tried to put twice the same control with «LDAP_CONTROL_PRE_READ» and got the error "preread control: specified multiple times", but I do not know if this is specific to preread or if it’s a rule. - Is the critical field of controls used in responses? It seems openldap server let it to false always (or I’m failing to parse it). I could not find information about these subjects in RFC 2251, if there is an other RFC on this subject bringing more information do not hesitate to point me to it :-) Côme

1 0

Re: pwdAccountLockedTime not in ppolicy.ldif
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Monday, September 11, 2017 3:01 PM +0200 Jacques Loonen <j.loonen(a)ru.nl> wrote: Hi Jacques, > We use cn = config, so we load ppolicy.ldif. pwdaccountlockedtime is not > included in this file. It is not included in ppolicy.schema or ppolicy.ldif. It is a hard-coded part of the ppolicy overlay. My guess is that while you included the ppolicy overlay in your slapd.conf configuration, you failed to properly load it when using cn=config. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Invalid credentials problem
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Sunday, September 10, 2017 12:19 AM +0000 JC <lovecraftesque(a)yahoo.com> wrote: > rootdn "uid=root,ou=People,dc=owns4,dc=com" ># ldapwhoami -x -H ldap://myipaddress -D "dc=owns4,dc=com" -w xyzabc > ldap_bind: Invalid credentials (49) What makes you believe that "dc=owns4,dc=com" is a valid identity to bind as? It certainly doesn't match the rootdn you configured. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Using TLS connecting to a AD server. openldap2.4.42
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Sunday, September 10, 2017 2:25 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I thought you have to set LDAP_OPT_X_TLS_NEWCTX to 0 *after* setting all > TLS-related options to let libldap reinitialize the client's SSL context. > Doesn't that work as expected? Well, my point was, he's doing: ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); when instead you have to do: ldap_set_option (NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); and then set up a new TLS context. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

pwdAccountLockedTime not in ppolicy.ldif
by Jacques Loonen 11 Sep '17

11 Sep '17

Hello all, We are trying to migrate our LDAP servers from eDirectory to OpenLDAP. We have replication and replication of pwdaccountlockedtime and pwdfailuretime working. Our provisioning system (Dell Quest) has trouble filling the pwdaccountlockedtime attribute. The reason for this is that this attribute is not present in the schema. We use cn = config, so we load ppolicy.ldif. pwdaccountlockedtime is not included in this file. In ppolicy.schema, pwdaccountlockedtime has been identified, but this is for the slapd.conf variant. How can we load pwdaccountlockedtime in the schedule using the cn = config method? Can anyone provide us with more information about this? Thanks in advance! We are useing openldap-2.4.44.-5.el7.x86_64 - In 2.4.45 pwdaccountlockedtime seems also not included in ppolicy.ldif Kind regards, Jacques Loonen Radboud University Nijmegen - The Netherlands Met vriendelijke groet, Jacques Loonen http://jloonen.ruhosting.nl/@59B6:7AC1/ -- ICT-Specialist - Radboud Universiteit Nijmegen - http://www.ru.nl/ ICT Servicecentrum - http://www.ru.nl/isc/ Geert Grooteplein-Zuid 41, 6525 GA Nijmegen E-mail: j.loonen(a)ru.nl <mailto:j.loonen@ru.nl> - Tel.: +31(0)24-36 17828

1 0

Re: pcache overlay, caching DNs
by Howard Chu 11 Sep '17

11 Sep '17

Roel van Meer wrote: > Hi list! > > I've been figuring out how to get the pcache overlay to work, but I'm stuck > with one thing: caching of DNs. > > Take this example config: > > overlay pcache > pcache bdb 10000 2 500 100 > directory /var/lib/ldap/cache > > pcacheAttrset 0 * > pcacheAttrset 1 uid > > pcacheTemplate (uid=) 0 300 > pcacheTemplate (uid=) 1 300 > > This works for queries like: > > ldapsearch "uid=foo" '*' > > or > > ldapsearch "uid=foo" 'uid' > > but NOT for: > > ldapsearch "uid=foo" 'dn' > > Can anyone tell me if it is at all possible to use pcache for caching DNs? > > > Things I have tried so far: > > - adding 'dn' as a pcacheAttrset, but then slapd fails to start > with the error "line 63: attribute type undefined". That should have told you already, you're barking up the wrong tree. DN is not an attribute. > - adding 'distinguishedName' as a pcacheAttrset, and then the > result is cached when I request the distinguishedName > attribute, but not when the dn is requested. > > I've tried openldap 2.4.40 and 2.4.44 (specifically, the version from Debian > jessie and the version from jessie-backports). > > Thanks a lot, > > Roel > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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