openldap-technical

openldap-technical@openldap.org

9897 discussions

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

Re: Failing consumers over to second mirror master provider
by Quanah Gibson-Mount 08 Sep '17

08 Sep '17

--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>

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 9:55 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > I think that's a good example why an ID should be different from the > user's common (sur)name. If you have jdoe as memeber of some groups, > youll have some additional fun unless LDAP is smart enough to adjust > those... Sure, it was purely an example. There are plenty of cases where subtree renames may be required. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

08 Sep '17

Hey, I have, what I hope is, a vanilla mirror-master setup, There is a load balancer in between the providers and consumers, that ensures that the writes will consistently be written to a single provider, until it becomes unavailable - at which point writes will failover to the hot-stand by. With regards to replication for the consumers - currently they all have a single provider explicitly defined within their configuration and I'm trying to understand what options are available with which the failover from one provider to the other would best be handled if the master was to die? 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? Thanks in advance -- Tim tim(a)yetanother.net

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