openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Antw: Q: querying accesslog with reqStart>=partial time spec
by Ulrich Windl 18 Aug '14

18 Aug '14

>>> Ulrich Windl schrieb am 18.08.2014 um 11:53 in Nachricht <53F1CD10.741 : 161 : 60728>: > Hi! > > Can anybody explain when openLDAP with bdb succeeds on a filter like >(reqStart>=X) on accesslog? > When I use "(reqStart>=2014080100)" I get "no match", but when I use >"(reqStart>=20140801000)" I get the expected matches. > (And I don't get any match when just using "reqStart>=20140801)") > I see no log messages on the server's syslog... Sorry, I was telling nonsense (my program just dropped the longer stings) due to a bad regex match. It seems I must specify the full legth date specification (20140811073600.000000Z) > > Regards, > Ulrich > >

2 1

using {CRYPT} for rootpw, using SHA512?
by Brian Reichert 18 Aug '14

18 Aug '14

I've been messing with trying to get SHA512 password hash formats in openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs. I have read the FAQ at http://www.openldap.org/faq/data/cache/1467.html - The first entry describes a third-party module; I have been using that for years on a 32-bit CentOS 5 platform, using the vendor-provided openldap-2.3.43 RPMs. My efforts to build that module for 2.4.39 seemed to build clean, but effort to bind as a user with a {SHA512} hashed password cause slapd to segfault. I didn't try very hard to track that down, as there seem to be better supported techniques. - The third entry describes a slapo-pw-sha2 overlay, but no LTB RPM provides the overlay. I tried exactly once to build this overlay, but that failed due to a configure failure. I blame me; I'll revisit this when I have the time. However, I had some luck with the second entry, using {CRYPT}. Following these instructions, I was able to create users, successfully bind, and even use ldappasswd to change the passwords: http://www.openldap.org/lists/openldap-technical/201305/msg00002.html But, when I generated a hashed password using suggestions like this: http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-pas… # python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")' $6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10 and tried to embed this rootpw in my config file; rootpw {CRYPT}$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10 I would get bind errors. Have I misunderstood how to use {CRYPT} for storing root's password? -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

8 13

what happened to the openldap toolbox project?
by Miroslaw Baran 18 Aug '14

18 Aug '14

Dear all, I don't want to sound too alarmistic, but it seems that the LTB project has disappeared from the 'net sometime this week. Would you happen to know what happened, what's going on (and perhaps if some help with the infrastructure is needed)? I've been relying on project-ltb packages for a while and would be quite unhappy to see it go; and I find the lack of information and the abrupt disappearance a bit troubling. While I know it's not strictly on-topic here, I know also that OpenLdap Toolbox folks are subscribed to this list, and ltb-project.org packages are quite widely used here – so I hope someone would be able to provide a bit of information… Kind regards – Miroslaw Baran -- » miroslaw baran » chaos monkey • pope • general nuisance » 0101010 Down with categorical imperative!

4 3

Q: querying accesslog with reqStart>=partial time spec
by Ulrich Windl 18 Aug '14

18 Aug '14

Hi! Can anybody explain when openLDAP with bdb succeeds on a filter like (reqStart>=X) on accesslog? When I use "(reqStart>=2014080100)" I get "no match", but when I use "(reqStart>=20140801000)" I get the expected matches. (And I don't get any match when just using "reqStart>=20140801)") I see no log messages on the server's syslog... Regards, Ulrich

1 0

Password Policy Questions
by Bram Cymet 18 Aug '14

18 Aug '14

Hi, It looks like the password policy overlay will do exactly what I need it to I just can't get it to work. I have applied the overlay my directory. I have a default policy set that has: pwdAttribute set to userPassword and pwdMustChange set to TRUE. However when I change a user's password either with an ldapmodify or the ldappassword command that user is still able to bind to the directory just fine. I was assuming that a bind attempt would return an error saying that the user had to change their password or is this not the expected behavior? Also I have tried adding pwdReset = TRUE to my user's object but it complains the pwdReset is not allowed in the schema. Is there a specific objectclass that I have to add to my user entries? I have also tried creating a schema with pwdReset and pwdPolicySubentry but when I add that schema it complains that these are operational attributes. I have upped the logging and when I user tries to bind I see: Aug 3 08:57:08 devauth slapd[30441]: conn=1017 fd=17 ACCEPT from IP=10.20.48.66:55519 (IP=0.0.0.0:389) Aug 3 08:57:08 devauth slapd[30441]: conn=1017 op=0 BIND dn="uid=email(a)test.com,ou=test_websales_users,dc=ls,dc=cbn" method=128 Aug 3 08:57:08 devauth slapd[30441]: => bdb_entry_get: found entry: "uid=email(a)test.com,ou=test_websales_users,dc=ls,dc=cbn" Aug 3 08:57:08 devauth slapd[30441]: => bdb_entry_get: found entry: "cn=websales_password_policy,ou=test_websales_users,dc=ls,dc=cbn" Aug 3 08:57:08 devauth slapd[30441]: => access_allowed: result not in cache (userPassword) Aug 3 08:57:08 devauth slapd[30441]: => access_allowed: auth access to "uid=email(a)test.com,ou=test_websales_users,dc=ls,dc=cbn" "userPassword" requested Aug 3 08:57:08 devauth slapd[30441]: => acl_get: [2] attr userPassword Aug 3 08:57:08 devauth slapd[30441]: => acl_mask: access to entry "uid=email(a)test.com,ou=test_websales_users,dc=ls,dc=cbn", attr "userPassword" requested Aug 3 08:57:08 devauth slapd[30441]: => acl_mask: to value by "", (=0) Aug 3 08:57:08 devauth slapd[30441]: <= check a_dn_pat: self Aug 3 08:57:08 devauth slapd[30441]: <= check a_dn_pat: * Aug 3 08:57:08 devauth slapd[30441]: <= acl_mask: [2] applying auth(=xd) (stop) Aug 3 08:57:08 devauth slapd[30441]: <= acl_mask: [2] mask: auth(=xd) Aug 3 08:57:08 devauth slapd[30441]: => slap_access_allowed: auth access granted by auth(=xd) Aug 3 08:57:08 devauth slapd[30441]: => access_allowed: auth access granted by auth(=xd) Aug 3 08:57:08 devauth slapd[30441]: conn=1017 op=0 BIND dn="uid=email(a)test.com,ou=test_websales_users,dc=ls,dc=cbn" mech=SIMPLE ssf=0 So it looks to me like the default policy has been applied but nothing happens when a password is reset by an administrator. So I think I am missing something fundamental here. I have a few questions that I think will help me to narrow down my problem though. 1) What is the best way to debug an overlay? 2) Is there a proper way for an administrator to change a password so that the pwdReset flag is set on the user (or whatever is supposed to happen so that the user needs to reset their password on their next bind) 3) Is it enough to have a password policy with just pwdAttribute and pwdMustChange set or are there other values that need to be set to make this work. 4) Are there any extra object classes that have to added to my user entries for the password policies to work? 5) I would like users to have to reset their password on first bind do I need to set something on object creation? 6) Anything else I might be missing? Any help would be awesome. Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

2 2

pwdChangedTime/authTimestamp, MMR etc.
by Michael Ströder 15 Aug '14

15 Aug '14

HI! I have a replication topology with providers running with MMR and a layer of r/o consumers.. - spread across three data centers - in two different countries (DE and foreign country) Network traffic between the countries has higher latency so consumers are only accessing providers within the same country. Write operations go nearly 100% to a single provider in Germany. All systems are using these overlays: - slapo-ppolicy (mostly for password expiry) - slapo-lastbind overlays - slapo-accesslog (yes, also on consumers) Now occasionally contextCSN values differ most times for a couple of minutes on the consumers in the foreign country from their local providers. I cannot tell exactly which conditions are causing this. But I observed that most times there was a login failure on the provider in Germany which results in 'pwdChangedTime' being set and replicated to the consumers. Most times followed by 'authTimestamp' being correctly set. So I wonder whether the differences of the contextCSN values could be caused by 'pwdChangedTime' and 'authTimestamp' being replicated to providers but not to consumers. Any clue? Thanks in advance. Ciao, Michael.

2 3

sanity check on updating from HDB backend to MDB
by Brian Reichert 14 Aug '14

14 Aug '14

I have an experiment, that may have too many moving parts to tease apart. We're exploring migrating our LDAP server from a 32-bit OS to a 64-bit OS, and I've also explored the port to the mdb back end. My first shot at this does not show the performance the write-ups on MDB would have me expect. If it matters, my old environment is a Dell R610 server, with 6G of RAM. # uname -r 2.6.18-308.13.1.el5PAE # cat /etc/redhat-release CentOS release 5.8 (Final) # rpm -qf `which slapd` openldap-servers-2.3.43-25.el5_8.1 My ldapsearch invocations on this host take ~120 seconds. I set up two Dell R610s, each with 12G or memory. One environment uses the RPM produced by the LTB project, here named 'ltb': root@ltb# uname -r 2.6.32-431.17.1.el6.x86_64 root@ltb# cat /etc/redhat-release CentOS release 6.5 (Final) root@ltb# rpm -qf /usr/local/openldap/libexec/slapd openldap-ltb-2.4.39-2.el6.x86_64 And the other uses the same OS, but uses CentOS's stock OpenLDAP RPM; here named 'stock': root@stock# rpm -qf `which slapd` openldap-servers-2.4.23-34.el6_5.1.x86_64 I migrated a database of ~360k DNs, and underwent the cache tuning, following the suggestions here: http://www.openldap.org/doc/admin24/tuning.html#Caching http://blog.monitor.us/2012/02/berkeley-db-performance-tuning/ And with those tunings, my ldapsearch command does outperform our old 32-but environment: stock# time ldapsearch -x -w XXXXX -D "cn=manager,orgid=MyOrgID" -b orgid=MyOrgID dn | grep ^dn: | wc -l 3600071 real 0m27.147s user 0m19.216s sys 0m10.585s However, my efforts to use the MDB backend yield slower responses, on the order of 175 seconds. How I set up the MDB backend: I copied my old slapd.conf over, and replaced my bdb backend with mdb settings. - I set 'tool-threads' to 2 - I set 'maxsize' to 21474836480 [ 20G = 20 * ( 1024 * 1024 * 1024 ) ] ltb# /usr/local/openldap/sbin/slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d config file testing succeeded ltb# chown -R ldap:ldap /etc/openldap/slapd.d I was apparently able to import all 360k DNs without an error: ltb# time setuidgid ldap /usr/local/openldap/sbin/slapadd \ -q -v -F /etc/openldap/slapd.d -b orgId=MyOrgID \ -l export_from_OLD.ldif >& log; echo $? real 16m46.924s user 8m52.165s sys 3m44.859s 0 ltb# ls -ld data.mdb -rw------- 1 ldap ldap 21474836480 Jul 30 20:16 data.mdb ltb# du -c -h data.mdb 6.3G data.mdb 6.3G total But, the same search looks worse here. ltb# time ldapsearch -x -w XXXXX -D "cn=manager,orgid=MyOrgID" -b orgid=MyOrgID dn | grep ^dn: | wc -l 3600071 real 2m55.482s user 0m25.459s sys 0m23.948s Both 64-bit hosts show no swapping, and minimal CPU load. Can anyone point out what I've missed? -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

6 13

CA and Intermediate Certificates
by Andrew Devenish-Meares 14 Aug '14

14 Aug '14

Hi All, We are currently assessing changing our TLS Certificate setup. We have been using a self-signed CA to issue certificates for our OpenLDAP setup, which has required us to supply the CA to anyone outside our organisation that wishes to use our OpenLDAP over TLS or SSL. We're currently starting to migrate our certificates to AusCERT, as we get a good deal as a University. As AusCERT is an intermediate CA, so we need to use a chain to get this to work. The server side works, as per the documentation, by adding the intermediate CA with the root CA in the olcTLSCertificateCAFile. This means that we need to install the intermediate certificate on clients that connect to our LDAP using SSL or TLS. Admittedly this isn't vastly different to what we need to do now in supplying our own CA. Looking at our Linux clients in particular, we need to add an appropriate TLS_CACERT directive to our openldap/ldap.conf. Is the intention, then, to point the client at the appropriate CA files? Is there a reason that OpenLDAP doesn't use the regular system CA store? Is there any reason for us not to point to the CA store that's already maintained? Cheers -- Andrew Devenish-Meares Solutions Analyst Information Technology University of New England Armidale NSW 2351 e: adevenis(a)une.edu.au p: 02 6773 4098 w: http://une.edu.au/itd

6 9

Specifying multiple password hashes
by Michael 14 Aug '14

14 Aug '14

Since both the password-hash and password-crypt-salt-format are Global options, is it possible to specify the password-hash on a per BDB backend basis? For example, I have 4 BDB backends and I'd like them all to have the CRYPT and salt listed below sans one BDB backend where it needs to be CLEARTEXT. However, when I specify this configuration in sladp.conf and bounce slapd I get the following error when trying to change a users password with the ldappasswd command. It's worth nothing that an ldapmodify to the userPassword attribute works just fine. I use security ssf=256, which is a Global option as well on a per BDB backend basis and this works just fine so I assumed this config for hashes would work as well. Error message: "Result: Constraint violation (19) Additional info: Password policy only allows one password value" Relevant config below: ## GLOBAL SETTING password-hash {CRYPT} password-crypt-salt-format $6$%.12s ### BDB DATABASE SETTING database bdb suffix "dc=testldap,dc=com" rootdn "cn=LDAPAdmin,dc=testldap,dc=com" directory /var/lib/ldap/testldap password-hash {CLEARTEXT}

2 2

How to do a case insensitive substring search on a case-sensitive field ?
by Guillermo-Nicolas Guénon Díaz 14 Aug '14

14 Aug '14

Hello, [First of all, sorry if this question has already been answered before: the search on this mailing list does not work currently so I haven't been able to check.] I need to write a filter so that when the user of my software introduces any substring of the content of a field in any case (upper, lower or mixed case), it finds the entry. It must work even if the user does not input a complete word, but just a part of a word. The field is called "supName" and it follows the DirectoryString syntax. This means that the default matching rule is exact and case sensitive ("caseExactMatch"). But according to: http://www.zytrax.com/books/ldap/apa/types.html , this syntax should allow also "caseIgnoreMatch" and "caseIgnoreSubstringsMatch" matching rules. I though I just needed to force to use the last one ("caseIgnoreSubstringsMatch"), so I tried this filter: (supName:caseIgnoreSubstringsMatch:=*somesubstring*) But this does not work. I make my tests using Apache Directory Studio, and that tool refuses to accept the above filter. It complains on the asterisks, and I don't understand why, since I am using a Substring match (and thus asterisks should be allowed). If I run the filter from command line (using ldapsearch), I get this error message: ldap_search_ext: Bad search filter (-7) Therefore this is not an issue with Apache Directory Studio. So my question is: What is the correct way of defining a case-insensitive substring filter on a field that is case-sensitive by default? Yesterday I filled a question in StackOverflow regarding this same issue. There are more details and examples in that question: http://stackoverflow.com/questions/25290494/case-insensitive-substring-ldap… Any help would be greatly appreciated ! Thank you very much. Nicolas

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