openldap-technical

openldap-technical@openldap.org

9790 discussions

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 10 Sep '17

10 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

Invalid credentials problem
by JC 10 Sep '17

10 Sep '17

I have just installed the OpenLDAP server, version 2.4.42, in my Linux. I have done some basic configuration for a fictitious domain owns4.com. My slapd.conf has the following contents: include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/nis.schemainclude /etc/openldap/schema/own.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/libexec/openldapmoduleload back_bdb.la database bdbsuffix "dc=owns4,dc=com" rootdn "uid=root,ou=People,dc=owns4,dc=com" rootpw xyzabc directory /var/lib/openldap dbconfig set_cachesize 0 2097152 0 index objectClass eq lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=root,dc=owns4,dc=com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=root,dc=owns4,dc=com" write by * read After launching the slapd daemon with /usr/libexec/slapd -d 7 I can issue a few commands that are apparently successful: # ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -LLLdn:namingContexts: dc=owns4,dc=com # ldapwhoami -x -H ldap://myipaddressanonymous myipaddress is the IP address of the system where I am issuing the commands, which is the same as where the OpenLDAP daemon is running. However, the next command is not successful: # ldapwhoami -x -H ldap://myipaddress -D "dc=owns4,dc=com" -w xyzabcldap_bind: Invalid credentials (49) It elicits the following output from slapd: 59b4713e slap_listener_activate(7): 59b4713e >>> slap_listener(ldap:///)59b4713e connection_get(13)59b4713e connection_get(13): got connid=100159b4713e connection_read(13): checking for input on id=1001ber_get_nextldap_read: want=8, got=8 0000: 30 21 02 01 01 60 1c 02 0!...`.. ldap_read: want=27, got=27 0000: 01 03 04 0f 64 63 3d 6f 77 6e 73 34 2c 64 63 3d ....dc=owns4,dc= 0010: 63 6f 6d 80 06 78 79 7a 61 62 63 com..xyzabc ber_get_next: tag 0x30 len 33 contents:59b4713e op tag 0x60, time 1504997694ber_get_nextldap_read: want=8 error=Resource temporarily unavailable59b4713e conn=1001 op=0 do_bindber_scanf fmt ({imt) ber:ber_scanf fmt (m}) ber:59b4713e >>> dnPrettyNormal: <dc=owns4,dc=com>=> ldap_bv2dn(dc=owns4,dc=com,0)<= ldap_bv2dn(dc=owns4,dc=com)=0 => ldap_dn2bv(272)<= ldap_dn2bv(dc=owns4,dc=com)=0 => ldap_dn2bv(272)<= ldap_dn2bv(dc=owns4,dc=com)=0 59b4713e <<< dnPrettyNormal: <dc=owns4,dc=com>, <dc=owns4,dc=com>59b4713e do_bind: version=3 dn="dc=owns4,dc=com" method=12859b4713e ==> bdb_bind: dn: dc=owns4,dc=com59b4713e bdb_dn2entry("dc=owns4,dc=com")59b4713e => bdb_dn2id("dc=owns4,dc=com")59b4713e <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)59b4713e send_ldap_result: conn=1001 op=0 p=359b4713e send_ldap_result: err=49 matched="" text=""59b4713e send_ldap_response: msgid=1 tag=97 err=49ber_flush2: 14 bytes to sd 13ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... 59b4713e connection_get(13)59b4713e connection_get(13): got connid=100159b4713e connection_read(13): checking for input on id=1001ber_get_nextldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents:59b4713e op tag 0x42, time 1504997694ber_get_nextldap_read: want=8, got=0 59b4713e ber_get_next on fd 13 failed errno=0 (Success)59b4713e conn=1001 op=1 do_unbind59b4713e connection_close: conn=1001 sd=13 Isn't the argument to -w in this command supposed to be the same as the value of rootpw in slapd.conf? If so, why is this not working? What are the "ldap_read: want=8 error=Resource temporarily unavailable" and "bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found " diagnostics all about?

2 1

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

10 Sep '17

--On Friday, September 08, 2017 6:48 PM +0000 Don jessup <djessup72(a)yahoo.com> wrote: > int reqcert = LDAP_OPT_X_TLS_NEVER; > ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); > > Is there way to make this work programmatically without using the > ldap.conf? Yes. The problem is the TLS options generally have to be set globally. You might want to look at <https://github.com/quanah/openldap-scratch/commit/59dbb01122ad92ef2a6e05cc3…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS connecting to a AD server. openldap2.4.42
by Don jessup 08 Sep '17

08 Sep '17

I'm working on client program to connect to an AD server over TLS. I have found out if I set the int reqcert = LDAP_OPT_X_TLS_NEVER;ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); programmatically I'm not able to connect to the AD server over TLS. If I set the option "TLS_REQCERT never" in the /usr/local/etc/openldap/ldap.conf everything works. Is there way to make this work programmatically without using the ldap.conf? Here is example code below: #define LDAP_SERVER "ldaps://10.235.217.52:636" int main( int argc, char **argv ){ LDAP *ld; int rc; char bind_dn[100]; /* Open LDAP Connection */ if( ldap_initialize(&ld, LDAP_SERVER) ) { perror("ldap_open"); return( 1 ); } // set option telling LDAP if we need to use a cert. //int reqcert = LDAP_OPT_X_TLS_NEVER; // if (ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert) != LDAP_OPT_SUCCESS) // { // perror("ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT"); // return (1); // } int desired_version = LDAP_VERSION3; /* set the LDAP version to be 3 */ if (ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &desired_version) != LDAP_OPT_SUCCESS) { perror("ldap_set_option PROTOCOL_VERSION"); return (1); } struct timeval timeout; timeout.tv_sec = 10; timeout.tv_usec = 0; if (ldap_set_option (ld, LDAP_OPT_NETWORK_TIMEOUT, &timeout) != LDAP_OPT_SUCCESS) { perror("ldap_set_option LDAP_OPT_NETWORK_TIMEOUT"); return (1); } sprintf(bind_dn, "%s", "bigco\\bob"); printf("Connecting as %s...\n", bind_dn); /* User authentication (bind) */ rc = ldap_simple_bind_s(ld, bind_dn, "Testit123"); if( rc != LDAP_SUCCESS ) { fprintf(stderr, "ldap_simple_bind_s: %s\n", ldap_err2string(rc)); return( 1 ); } printf("Successful authentication\n"); ldap_unbind(ld); return( 0 );} ThanksDon

1 0

Re: Failing consumers over to second mirror master provider
by Tim 08 Sep '17

08 Sep '17

Perfect! Thanks guys - I was confusing syncRepl with other replication mechanisms I've had experience of and assumed that updates coming in via syncRepl would be blindly replayed to any connected consumers. Just the push I needed in the right direction. On Fri, Sep 8, 2017 at 3:09 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 08, 2017 10:37 AM -0400 Frank Swasey < > Frank.Swasey(a)uvm.edu> wrote: > > Today at 7:43am, Tim wrote: >> >> I realise that the RID has to be unique - so am I right in thinking that >>> there is no way for the failover to seamless, and replication must be >>> re-established by removing the existing syncrepl statement, on the >>> consumers, and re-adding it with the secondaries details? >>> >>> Or am I missing a trick here as to how the process could be smoother? >>> >> >> You are missing the point. >> >> You say you have a load balancer that decides which of your MMR partners >> should receive the traffic. Your consumers should be configured in such >> a way that both MMR partners will accept the connection. >> >> For example... >> >> My MMR partners are ldap7p and ldap7q. The load balanced VIP is ldap7rw. >> My consumers are set up with unique RIDs (the RID is unique for each >> consumer) and their provider is ldap7rw. It does not matter whether the >> load balancer sends the traffic to ldap7p or ldap7q - the consumer is >> talking to ldap7rw. >> > > Consumers can also be configured with > 1 syncrepl stanza, and simply talk > to both masters at the same time. There is no need for them to be > reconfigured at all. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- Tim tim(a)yetanother.net

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical