openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

RE: openldap-technical Digest, Vol 105, Issue 2
by Kruger, P (Justid) 03 Aug '16

03 Aug '16

You could check fort he logfiles. But to get logging detailed, you need to set the loglevel. You can save ldap logging to a separate logfile and added logging level. Below is what I've done under Linux to achieve this (nano is the editor, which could also be vi). mkdir /var/log/ldap/ touch /var/log/ldap/ldap.log chown ldap.ldap /var/log/ldap -R nano /etc/rsyslog.conf Add the following rule tot his file # Save LDAP messages to /var/log/ldap/ldap.log local4.* /var/log/ldap/ldap.log Add log rotation to prevent an ever growing log file. nano /etc/logrotate.d/ldap.log /var/log/ldap/ldap.log { missingok } service rsyslog restart Met vriendelijke groet, Peter Kruger Adviseur IT-beheer .................................................................................. Ministerie van Justitie Justitiële Informatiedienst Technologie/IT-beheer Egbert Gorterstraat 6 | 7607 GB | Almelo | 2.15 Postbus 337 | 7600 AH | Almelo .................................................................................. T 088 99 89060 M 06 511 016 92 p.kruger(a)justid.nl www.justid.nl .................................................................................. werkt op: ma, di, wo, do .................................................................................. Van: Côme Chilliet [mailto:come@opensides.be] Verzonden: dinsdag 2 augustus 2016 15:32 Aan: openldap-technical(a)openldap.org Onderwerp: Modification of objectClass failing: how can I get details? Hello, I'm trying to modify an LDAP node to change its objectClasses: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx cn: canon-c5250 description:: Q2Fub24gSVIgQURWIEM1MjUwIA== labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:12:12:12:12:12 objectClass: top objectClass: gotoPrinter I want to remove gotoPrinter objectClass which is flagged as OBSOLETE and instead use fdPrinter, ipHost and ieee802Device. I try with an ldif with the following content: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: modify replace: objectClass objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top I get: ldapadd -D cn=admin,dc=xxx,dc=xxx -f modify.ldif -W ldap_modify: Object class violation (65) How can I get more information? I don't know which violation that could be, as I am able to insert a second object with no problem which looks like what I want: dn: cn=test-print,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: add cn: test-print description: test labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:22:12:12:22:22 objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top Here are the classes definitions: objectclass (1.3.6.1.4.1.10098.1.2.1.31 NAME 'gotoPrinter' DESC 'GOto - Gonicus Terminal Concept, objectclass' SUP top STRUCTURAL OBSOLETE MUST ( cn ) MAY ( labeledURI $ description $ l $ gotoPrinterPPD $ macAddress $ ipHostNumber $ gotoUserPrinter $ gotoUserAdminPrinter $ gotoGroupPrinter $ gotoGroupAdminPrinter $ printerWindowsInfFile $ printerWindowsDriverDir $ printerWindowsDriverName) ) objectclass ( 1.3.6.1.4.1.38414.16.2.5 NAME 'fdPrinter' DESC 'FusionDirectory printer class' MUST ( cn ) MAY ( labeledURI $ fdPrinterWindowsInfFile $ fdPrinterWindowsDriverDir $ fdPrinterWindowsDriverName $ fdPrinterUsers $ fdPrinterAdminUsers)) Côme

1 0

Re: password policies not functioning properly
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

Just found the problem and the solution to the problem that policies were not working. It occurred that there was also a (probably mistakenly) second config module activated. The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded. After correcting this, all seems to work as expected.

1 0

password policies not functioning as expected
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

Just found the problem and the solution. It occurred that there was also a (probably mistakenly) second config module activated. The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded. After correcting this, all seems to work as expected. -----Oorspronkelijk bericht----- Van: openldap-technical [mailto:openldap-technical-bounces@openldap.org] Namens openldap-technical-request(a)openldap.org Verzonden: donderdag 28 juli 2016 14:00 Aan: openldap-technical(a)openldap.org Onderwerp: openldap-technical Digest, Vol 104, Issue 21 Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org To subscribe or unsubscribe via the World Wide Web, visit http://www.openldap.org/lists/mm/listinfo/openldap-technical or, via email, send a message with subject or body 'help' to openldap-technical-request(a)openldap.org You can reach the person managing the list at openldap-technical-owner(a)openldap.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openldap-technical digest..." Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." Today's Topics: 1. Re: need to recover slapd password and upgrade openldap (Dan Hyatt) 2. Re: Antw: Intermediate certificates not being sent (Nat Sincheler) 3. Re: sizelimit (Maily Peng) 4. Missing user entries after restoring a backup ldif (Matt Spaulding) 5. password policies not functioning properly (Kruger, P (Justid)) 6. Re: sizelimit (Dieter Kl?nter) 7. Re: Antw: Intermediate certificates not being sent (Ulrich Windl) ---------------------------------------------------------------------- Message: 1 Date: Tue, 26 Jul 2016 12:15:00 -0500 From: Dan Hyatt <dhyatt(a)dsgmail.wustl.edu> To: Aaron Richton <richton(a)nbcs.rutgers.edu>, dhyatt(a)wustl.edu Cc: openldap-technical(a)openldap.org Subject: Re: need to recover slapd password and upgrade openldap Message-ID: <b5a9dc49-8420-ef20-0779-d65ddfcdcad7(a)dsgmail.wustl.edu> Content-Type: text/plain; charset=windows-1252; format=flowed So, a more simple question... Can I install a current version of OpenLDAP on a current RedHat/Centos server (specially built for this purpose. Then use slapcat to export the information from the old server, import it to the new server, where the admin password is not corrupt. Can I import the schemas or are there likely substantial changes to the schemas across versions? My goals are to create a new LDAP server running Centos/Redhat, transfer 20 users and allow them to keep their existing passwords, allow them to access my servers, and allow them authentication to samba. and create an LDAP slave (or cluster) not sure if syncrepl is the current way to go. I have root to the server, but I do not have the admin password to the Openldap 2.2 as it became corrupted somehow. On 07/24/2016 09:15 PM, Aaron Richton wrote: > On Fri, 22 Jul 2016, Dan Hyatt wrote: > >> My admin openLDAP 2.2 password became corrupt in the last week and I >> cannot > [...] >> I found some instructions which seem simple risky and no backout >> strategy. Simply running >> http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/ >> > > That link (apparently from 2011) doesn't apply to your software from > 2003. There's no back-config in OpenLDAP 2.2. So don't try that... @(#) $OpenLDAP: slapd 2.2.13 (Nov 26 2010 07:45:22) $ mockbuild@x86-003.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > > [...] >> Having the LDAP on two separate hyper visors (with local disks) to >> avoid the storage/authentication chicken/egg >> Is there a better upgrade plan > > Are you saying that your one and only LDAP server uses itself for its > own A&A? Authentication and Authorization? The server provides authentication and authorization for my group. The server only does LDAP and home dirs. I want to upgrade it to Centos 6.8 or Centos 7 (that is equal to redhat 6.8 or redhat 7) on a hypervisor with a slave running the current favored release. > > [...] >> I have the log files, is there a way to backout to last week without >> the admin password (which became corrupt last week). > > I'm not sure what you're referring to by "log files." The general-case > OpenLDAP backup tool is slapcat(8). Hopefully you have been running it > routinely. The resulting LDIF can be easily inspected; if you have > enough backups, you might even be able to find one without corruption. We took over responsibility the LDAP in December, there was not a happy handoff... no documenation..just the password and had to move it to the new VLAN. ------------------------------ Message: 2 Date: Tue, 26 Jul 2016 08:20:14 -0700 From: Nat Sincheler <fai1107(a)macrotex.net> To: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>, openldap-technical(a)openldap.org Subject: Re: Antw: Intermediate certificates not being sent Message-ID: <991f77f9-fd05-eb9b-7f07-f350c4a7bc68(a)macrotex.net> Content-Type: text/plain; charset=windows-1252; format=flowed On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 25.07.2016 um 19:06 in > Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7(a)macrotex.net>: >> We have an OpenLDAP server that is listening on port 636 over ldaps. >> When I run >> >> openssl s_client -showcerts -connect ldap-server:636 >> >> I only see the host certificate. The intermediate and root certificates >> do *not* come through. > > If I di that on one of outr servers, I get: > Root CA > Intermediate CA > Server Certificate > > ... > New, TLSv1/SSLv3, Cipher is AES256-SHA > Server public key is 2048 bit > >> >> For this server I have in the file slapd.d/cn=config.ldif the setting >> >> olcTLSCACertificatePath: /etc/ssl/certs > > Hi! > > Here it works with these settings: > olcTLSCACertificatePath: /etc/ssl/certs > olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem > olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key > > Could it be a permissions problem? Did you try to check the certificate chain with openssl (preferrable as LDAP user)? When I run the openssl s_client command I get no errors, but I also get no intermediate or root certificates sent. I see this in the output: "No client certificate CA names sent". It appears that OpenLDAP is not sending the intermediate or root certificates. However, if I put all the intermediate and root certificates into a single file and point olcTLSCACertificateFile at this file, those intermediate certificates _are_ sent. So, it appears that olcTLSCACertificateFile sends the certificates but but olcTLSCACertificatePath does not. Am I misunderstanding the purpose olcTLSCACertificatePath? Thanks. > > Regards, > Ulrich > >> >> I checked and all the intermediate and root certificates are in >> /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., >> >> lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> >> /etc/ssl/certs/incommon-usertrust-2024.pem >> >> Any idea why the intermediate and root certificates do not get sent to >> the LDAPS client? Is there something in the LDAP log that might give me >> a clue as to what is going on? > > > > ------------------------------ Message: 3 Date: Tue, 26 Jul 2016 19:47:27 +0200 From: Maily Peng <mpeng(a)keyyo.com> To: Frank Swasey <Frank.Swasey(a)uvm.edu> Cc: openldap-technical(a)openldap.org Subject: Re: sizelimit Message-ID: <6fedd3fe-f1c4-9897-0eae-3c77159add6d(a)keyyo.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hello Frank, Nope, the limits directive are unlimited on the provider. First of all, I need to have access to all of the entries on the consumers , in order to check EntryCSN between provider and consumers. I use the python script : check_syncrepl_extended that needs to bind provider and consumer via the same dn. That's why I could not use rootdn . ( not the same between slapd servers) . thank you Le 26/07/2016 ? 19:09, Frank Swasey a ?crit : > You have shown us what the syncrepl, sizelimit and limits look like on > your consumer. Have you got that limits directive also set up on your > provider? It is the provider that needs to allow your replication DN > to obtain unlimited entries. > >

1 0

In-Reply-To: AdHrvUgXFwns0ylwRzawJ6D0CewYvg==
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

1 0

password policies not functioning as expected
by Kruger, P (Justid) 01 Aug '16

01 Aug '16

I've set password policies on my OpenLDAP 2.4. Unfortunately things do not work as expected and although extensively searched on forums and Google, I cannot get the proper results. What am I missing in what I did or should have done? What goes wrong: - Password policies seem not to be validated or I do get a failure message The failures depend on pwdinHistory setting to zero (no failure) to > 0 failure like given below 5798c94a <= acl_access_allowed: granted to database root 5798c94a bdb_modify_internal: replace userPassword 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 5798c94a hdb_modify: modify failed (20) 5798c94a send_ldap_result: conn=1000 op=18 p=3 5798c94a send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" 5798c94a send_ldap_response: msgid=62 tag=103 err=20 ber_flush2: 61 bytes to sd 15 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists ldap_write: want=61, written=61 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists 5798c94a conn=1000 op=18 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists 5798c94a slap_graduate_commit_csn: removing 0x7f8a0c107960 20160727144634.392449Z#000000#000#000000 This makes, as far as I tested, no difference with just using a default policy or when using a default and specific policy with pwdPolicySubentry attribute in the user. I've used ACL's on my LDAP schema. My purpose: Use a default policy which basically says to use no policy Add a specific policy for users in a subtree. Below are the steps and LDAP LDIF files used to build the OpenLDAP. Included here are the LDIF files for: config, base and sub part of tree, replication ou and user, application users (service accounts), ldap managers ou, ACL's, OU's needed for application specific content, policy. Excluded here (but done) are the LDIF files for: enable logging, replication, TLS/SSL. The LDIF files first line contains the LDIF filename and the command used to apply them # ldapadd -Y EXTERNAL -H ldapi:/// -f 01_addrootpw.ldif dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}hashhashhashhashhashhash # ldapadd -Y EXTERNAL -H ldapi:/// -f 02_root-base.ldif # change olcRootPW to your Root password # change domain parts to your domain dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" read by * none dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA} hashhashhashhashhashhash dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 03_ldap-manager.ldif dn: dc=example,dc=nl objectClass: top objectClass: dcObject objectclass: organization o: example nl dc: example dn: ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalUnit ou: ldapbeheerders dn: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalRole cn: Manager description: Directory Manager # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 04_replication_user.ldif dn: ou=replicatie,dc=example,dc=nl objectclass: organizationalUnit ou: replicatie description: replicatie groep dn: cn=replicator,ou=replicatie,dc=example,dc=nl cn: replicator sn: user objectClass: person userPassword: passwordincleartext # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 05_applications.ldif # Create ou generic application scheme dn: ou=applicaties,dc=example,dc=nl objectclass: organizationalUnit ou: applicaties # Aanmaak ou APP1 applicatieschema dn: ou=APP1,dc=example,dc=nl objectclass: organizationalUnit ou: APP1 # Aanmaak ou APP2 applicatieschemas dn: ou=APP2,dc=example,dc=nl objectclass: organizationalUnit ou: APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 06_ServiceAccounts.ldif dn: ou=ServiceAccounts,dc=example,dc=nl objectclass: organizationalUnit ou: ServiceAccounts description: Service Accounts Applicaties #Service account APP1 dn: cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP1 sn: user objectClass: person userPassword: {SSHA}hashedpassword description: Service Account APP1 #Service account APP2 dn: cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP2 sn: user objectClass: person userPassword: {SSHA} hashedpassword description: Service Account APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 07_ACL.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: to attrs=userPassword by anonymous auth by self write by * break olcAccess: to dn="ou=replicatie,dc=example,dc=nl" by self write by * none olcAccess: to * by dn.base="cn=replicator,ou=replicatie,dc=example,dc=nl" read by * break olcAccess: to dn.subtree="cn=default,ou=policies,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ldapbeheerders,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ServiceAccounts,dc=example,dc=nl" by self search by * none olcAccess: to dn.subtree="ou=applicaties,dc=example,dc=nl" by dn.children="ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP1,dc=example,dc=nl" by dn.base="cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP2,dc=example,dc=nl" by dn.base="cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.children="dc=example,dc=nl" by * read olcAccess: to dn.children="dc=nl" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 08_Add-testusers.ldif dn: uid=APP1_1,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_1 cn: APP1_1 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: uid=APP1_2,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_2 cn: APP1_2 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: cn=APP2_1,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_1 cn: APP2_1 gebruiker sn: gebruiker dn: cn=APP2_2,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_2 cn: APP2_2 gebruiker sn: gebruiker dn: cn=APP2_3,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_3 cn: APP2_3 gebruikercat sn: gebruiker dn: cn=APP2_4,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_4 cn: APP2_4 gebruiker sn: gebruiker Below is the part where the password policies are configured. # ldapadd -Y EXTERNAL -H ldapi:/// -f P01_ppolicymodule.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: ppolicy.la olcModulePath: /usr/lib64/openldap # ldapadd -Y EXTERNAL -H ldapi:/// -f P02_ppolicyoverlay.ldif dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=nl olcPPolicyUseLockout: TRUE olcPPolicyHashCleartext: TRUE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P03_default_ppolicy.ldif dn: ou=policies,dc=example,dc=nl objectClass: top objectClass: organizationalUnit ou: policies dn: cn=default,ou=policies,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicyChecker objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 8 pwdMinLength: 8 pwdMaxFailure: 5 pwdFailureCountInterval: 1800 pwdCheckQuality: 1 pwdMustChange: TRUE pwdGraceAuthNLimit: 0 pwdMaxAge: 7776000 pwdExpireWarning: 1209600 pwdLockoutDuration: 900 pwdLockout: TRUE pwdSafeModify: FALSE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P04_APP1_ppolicies.ldif dn: ou=policies,ou=APP1,dc=example,dc=nl ou: policies objectClass: top objectClass: organizationalUnit dn: cn=default,ou=policies,ou=APP1,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckQuality: 0 pwdExpireWarning: 374400 pwdFailureCountInterval: 1800 pwdGraceAuthNLimit: 5 pwdInHistory: 12 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 2592000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: FALSE

1 0

Directory management best practices?
by John Lewis 01 Aug '16

01 Aug '16

Are there any best practices on managing directories? For Instance, I want to authenticate trusted UNIX users and untrusted Django users in the same directory? What if I made completely different directory to manage contact information, but I want to replicate shards of it and give priority based on geographic location?

1 0

Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Howard Chu 30 Jul '16

30 Jul '16

Paul B. Henson wrote: >> From: Quanah Gibson-Mount >> Sent: Friday, July 22, 2016 10:40 AM >> >> Also see ITS 8448. > > Ah, thanks much for the heads up on these additional issues. Perhaps it > would be safest for me to stick with 2.4.41 until a 2.4.45 is officially > released with fixes for both the replication loop and possible fallout from > its fix :). We've been pretty lucky with 2.4.41, knock on bits, it's been > very stable with no issues or problems that I've seen while we've been > running it. The bug noted in ITS#8460 is not present in 2.4 at all. Quanah is also running experimental backports of features from 2.5 and forgets to mention that sometimes. This particular issue is from 2.5 (and is now fixed in git). Most likely it's the same issue as #8448. You can disregard both of these. >> --On Thursday, July 21, 2016 5:47 PM -0700 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> I would note that I've opened up two new ITSes for problems that only >>> occur on systems that have the ITS8432 fix. Still waiting on fixes for >>> those, which is why I haven't pushed the fix into RE24 yet. >>> >>> ITSes 8460 and 8462. >>> >>> --Quanah >>> >>> --On Thursday, July 21, 2016 2:59 PM -0700 "Paul B. Henson" >>> <henson(a)acm.org> wrote: >>> >>>>> From: Howard Chu >>>>> Sent: Thursday, July 21, 2016 3:36 AM >>>>> >>>>> The fix for #8432 only prevents the redundant mod from being >> processed >>>>> on a particular node. If other nodes are still accepting the redundant >>>>> op >>>> then yes, >>>>> it will continue to propagate. So yes, you need the patched code on > all >>>>> nodes. >>>> >>>> Okay, thanks for the clarification. I usually stage updates to avoid a >>>> complete outage at any given time. It's interesting though that I had >>>> never seen this problem running 2.4.41 until I introduced a 2.4.44 > system >>>> into the mix, and then it went away once I reverted that system back to >>>> 2.4.41. I wonder why that combination caused it to pop up suddenly. > I'll >>>> have to schedule a downtime window and update them all at once and >> see >>>> what happens. >>>> >>>> By any chance have you had the time to look at ITS 8444? The reporter >>>> says he sees a similar circular replication issue when the memberOf >>>> overlay is enabled, which we also use. >>>> >>>> Thanks much. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 4

Re: Antw: Intermediate certificates not being sent
by Howard Chu 28 Jul '16

28 Jul '16

Nat Sincheler wrote: > > > On 7/27/2016 11:19 PM, Ulrich Windl wrote: >>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 26.07.2016 um 17:20 in >> Nachricht <991f77f9-fd05-eb9b-7f07-f350c4a7bc68(a)macrotex.net>: >> >>> >>> On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 25.07.2016 um 19:06 in >>>> Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7(a)macrotex.net>: >>>>> We have an OpenLDAP server that is listening on port 636 over ldaps. >>>>> When I run >>>>> >>>>> openssl s_client -showcerts -connect ldap-server:636 >>>>> >>>>> I only see the host certificate. The intermediate and root certificates >>>>> do *not* come through. >>>> >>>> If I di that on one of outr servers, I get: >>>> Root CA >>>> Intermediate CA >>>> Server Certificate >>>> >>>> ... >>>> New, TLSv1/SSLv3, Cipher is AES256-SHA >>>> Server public key is 2048 bit >>>> >>>>> >>>>> For this server I have in the file slapd.d/cn=config.ldif the setting >>>>> >>>>> olcTLSCACertificatePath: /etc/ssl/certs >>>> >>>> Hi! >>>> >>>> Here it works with these settings: >>>> olcTLSCACertificatePath: /etc/ssl/certs >>>> olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem >>>> olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key >>>> >>>> Could it be a permissions problem? Did you try to check the certificate >>> chain with openssl (preferrable as LDAP user)? >>> >>> When I run the openssl s_client command I get no errors, but I also get >>> no intermediate or root certificates sent. I see this in the output: "No >>> client certificate CA names sent". >> >> Hi! >> >> To me it looks like a problem with your certificates. Try to verify them >> using openssl, like this: >> openssl verify -CApath /etc/ssl/certs -verbose /etc/ssl/servercerts/slapd.pem >> /etc/ssl/servercerts/slapd.pem: OK > > % grep -R Certificate *.ldif > > olcTLSCACertificatePath: /etc/ssl/certs > olcTLSCertificateFile: /etc/ssl/certs/server.pem > olcTLSCertificateKeyFile: /etc/ssl/private/server.key > > % directory2:/etc/ldap# openssl verify -CApath /etc/ssl/certs -verbose > /etc/ssl/certs/server.pem > > /etc/ssl/certs/server.pem: OK > > So, the openssl command line can find the certificate chain. Why can't openldap? If your OpenLDAP build is not behaving the same as your OpenSSL build, then most likely your OpenLDAP was not built with OpenSSL. Otherwise, their behavior would match. You never provided essential information such as OS platform and OpenLDAP version, so nobody can give you definitive answers. -- -- 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

Intermediate certificates not being sent
by Nat Sincheler 28 Jul '16

28 Jul '16

We have an OpenLDAP server that is listening on port 636 over ldaps. When I run openssl s_client -showcerts -connect ldap-server:636 I only see the host certificate. The intermediate and root certificates do *not* come through. For this server I have in the file slapd.d/cn=config.ldif the setting olcTLSCACertificatePath: /etc/ssl/certs I checked and all the intermediate and root certificates are in /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> /etc/ssl/certs/incommon-usertrust-2024.pem Any idea why the intermediate and root certificates do not get sent to the LDAPS client? Is there something in the LDAP log that might give me a clue as to what is going on?

3 5

Multimaster syncrepl configuration
by Gurjot Kaur 28 Jul '16

28 Jul '16

Hello, I have a doubt in setting up multimaster syncrepl configuration. I just added syncrepl information for the "dn: olcDatabase={0}config,cn=config" and overlays for "dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config" in both the Master 1 and Master 2 servers. But I didn't add any syncrepl for "dn: olcDatabase={1}mdb,cn=config" for any server. While adding I got this error: modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral Nevertheless, what I am unable to understand is that my data is replicating in both the servers correctly. Is there no difference between adding syncrepl for config database or mdb database. Or adding syncrepl to config database is applicable for all the databases? Thanks, Gurjot Kaur "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

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