openldap-software

openldap-software@openldap.org

2719 discussions

Password Policy pwdHistory not being checked?
by Ben Spencer 08 Feb '08

08 Feb '08

Version: 2.3.39 I am working with the policy overlay and ran into a little issue with the password history. I have pwdInHistory set to 3 in the password policy dn. When I change the password, the pwdHistory is updated, but, the policy doesn't seem to be enforced (as I can keep reusing anying of the three passwords). In the logs, I see the following: Feb 8 15:59:11 dirdev1 slapd[3947]: => bdb_entry_get: ndn: "cn=default password policy,ou=config,dc=moody,dc=edu" Feb 8 15:59:11 dirdev1 slapd[3947]: => bdb_entry_get: oc: "(null)", at: "(null)" Feb 8 15:59:11 dirdev1 slapd[3947]: bdb_dn2entry("cn=default password policy,ou=config,dc=moody,dc=edu") Feb 8 15:59:11 dirdev1 slapd[3947]: => bdb_dn2id("ou=config,dc=moody,dc=edu") Feb 8 15:59:11 dirdev1 slapd[3947]: <= bdb_dn2id: got id=0x00000004 Feb 8 15:59:11 dirdev1 slapd[3947]: => bdb_dn2id("cn=default password policy,ou=config,dc=moody,dc=edu") Feb 8 15:59:11 dirdev1 slapd[3947]: <= bdb_dn2id: got id=0x00000014 Feb 8 15:59:11 dirdev1 slapd[3947]: entry_decode: "cn=Default Password Policy,ou=config,dc=moody,dc=edu" Feb 8 15:59:11 dirdev1 slapd[3947]: <= entry_decode(cn=Default Password Policy,ou=config,dc=moody,dc=edu) Feb 8 15:59:11 dirdev1 slapd[3947]: => bdb_entry_get: found entry: "cn=default password policy,ou=config,dc=moody,dc=edu" Feb 8 15:59:11 dirdev1 slapd[3947]: bdb_entry_get: rc=0 And then it happily changes the user's password. --- slapd.conf --- [removed stuff] # Load dynamic backend modules: modulepath /opt/BENTEST/libexec/openldap moduleload back_bdb.la moduleload ppolicy.la [removed stuff] database bdb suffix "dc=moody,dc=edu" rootdn "cn=Directory Manager,dc=moody,dc=edu" rootpw fall directory /opt/BENTEST/var/openldap-data/dc=moody,dc=edu # password policy overlay ppolicy ppolicy_default "cn=Default Password Policy,ou=config,dc=moody,dc=edu" ppolicy_use_lockout --------- What am I missing? --- Benji Spencer System Administrator Ph: 312-329-2288

1 0

Re: tips in ldappasswd
by Quanah Gibson-Mount 08 Feb '08

08 Feb '08

Keep your replies to the list. I highly advise reading the man page, and understanding all the options. As the error clearly states, you failed to provide a password (hint, see the -w and -W options). --Quanah --On February 8, 2008 5:09:43 PM -0200 Gustavo Mendes de Carvalho <gmcarvalho(a)gmail.com> wrote: > Hi Quanah, > > Sorry by my mistake. I wrote wrong ldap name. > > Here is my command > > [ming@s200-189-190-106 ~]$ ldappasswd -AS -H ldaps://ldap_server/ -D > uid=ming,ou=org-unit,o=org,c=br -x > Old password: > Re-enter old password: > New password: > Re-enter new password: > ldap_bind: Server is unwilling to perform (53) > additional info: unauthenticated bind (DN with no password) > disallowed > > > [ming@s200-189-190-106 ~]$ ldappasswd -AS -H ldap://ldap_server/ -D > uid=ming,ou=org-unit,o=org,c=br -x > Old password: > Re-enter old password: > New password: > Re-enter new password: > ldap_bind: Server is unwilling to perform (53) > additional info: unauthenticated bind (DN with no password) > disallowed > > > --- > Gustavo Mendes de Carvalho > e-mail: gmcarvalho(a)gmail.com -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Server side delay for bad passwords?
by Dan White 08 Feb '08

08 Feb '08

I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously. Is there an approach to preventing a brute force attack at guessing an entry's password? I've noticed that with my configuration, when performing an ldapwhoami or ldapsearch, and when submitting an incorrect password, I receive an immediate response that the password is bad, rather than a delay which I would like to have. I'm using version 2.3.39. In other words, this is what I get today: ~# time ldapsearch -Y DIGEST-MD5 -U abrown(a)olp.net -w badpassword SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated real 0m0.015s user 0m0.012s sys 0m0.004s But I'd like to enforce a server side delay of, for example, 5 seconds. I understand that I could implement the password policy overlay to temporarily lockout an account once it's reached a certain number of bad password attempts, but I believe that only applies to simple (-x) binds. Is that correct? Thanks, - Dan White

7 11

Filtering on meberUid vs cn
by Marantz, Roy 08 Feb '08

08 Feb '08

Please excuse me if this is an off list topic. I think this may be specific to OpenLDAP so I'm trying here. I'm running OpenLDAP 2.4.7 w/ BerkeleyDB 4.6.21 on Solaris-10. I'm running OpenLDAP as a fairly standard NIS replacement. In particular I have a DIT ou=group,dc=nyc,dc=deshaw,dc=com made of objects of class posixGroup (from the supplied nis.schema file). Solaris want to get a getgrmember() (undocumented subroutine call) which does a ldap search like the first one following. This search returns nentries=0 ldapsearch -x -LLL -h 127.0.0.1 -b 'ou=group,dc=nyc,dc=deshaw,dc=com' '(&(objectClass=posixGroup)(memberUid=marantz))' conn=2354 op=1 SRCH base="ou=group,dc=nyc,dc=deshaw,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=marantz))" conn=2354 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= But this search shows at least one object that I think should match ldapsearch -x -LLL -h 127.0.0.1 -b 'ou=group,dc=nyc,dc=deshaw,dc=com' '(&(objectClass=posixGroup)(cn=www))' dn: cn=www,ou=Group,dc=nyc,dc=deshaw,dc=com objectClass: posixGroup objectClass: top cn: www userPassword:: XXXXXXXXXXXX gidNumber: XXXX memberUid: XXXXXX memberUid: marantz memberUid: XXXXXX memberUid: XXXX memberUid: XXXXXX memberUid: XXXXXX memberUid: XXX memberUid: XXXXXXXX conn=3087 op=1 SRCH base="ou=group,dc=nyc,dc=deshaw,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=www))" conn=3087 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= The only difference I can find is the Equality Matching value for the 2 attributes. I notice that cn has a Equality Matching value of caseIgnoreMatch vs. caseExactA5Match for memberUid. (at least according to http://ldap.akbkhome.com/index.php/objectclass/posixGroup.html) I don't see how, but could that be involved in my problem? Any help would be greatly appreciated. Thanks. Roy

3 2

Tuning cachesize
by Marantz, Roy 07 Feb '08

07 Feb '08

I'm using OpenLDAP 2.4.7 with BerkeleyDB 4.6 on Solaris-10 hosts. We haven't been using it in production so I don't have any real experience with the performance under load. I'll be looking into doing some simulated load tests later. Right now, I'd like to understand more about performance tuning. I'm trying to follow the instruction in the FAQ or OpenLDAP Software 2.4 Administrator's Guide section 19.4.1.1 Calculating Cachesize but can't find information that is needed to calculate the cache needed for various indexes. In particular the formula given near the end of that section talks about the "Number of hash buckets". I've found something that could be it from running db_stat -m command's output, but that seems to be a single number for the whole database not one per index. Would someone point me in the right direction? BTW, I get much larger cachesize using the Admin Guide/FAQ method vs. the method Quanah Gibson-Mount wrote about in this mailing list. (du -c -h *.bdb in the database directory) Is that expected? I assume it would be best to try to optimize the cachesize for all databases. Does this include the log database used for delta-syncrepl? Also, is it better (performance wise) to give more memory to the db cache or the entry or idl caches? I couldn't find a clear answer from the Admin Guide, FAQ, nor the mailing list. Finally, is there any difference tuning bdb vs. hdb? I would think not, but since I'm asking... Thanks. Roy

3 3

LDAP Server bug?
by openldap 07 Feb '08

07 Feb '08

Hi every OpenBSD myserver.mydomain.tld 4.2 GENERIC#375 i386 openldap-server-2.3.33p1-bdb a week ago, i introduced a new schema, the horde.schema, adding it to the new cn=config subtree using ldapadd... the corresponding entry in the cn=config subtree lookes like: dn: cn=include{21},cn=config cn: include{21} objectClass: olcIncludeFile olcInclude: /etc/openldap/schema/horde.schema sofar, no problem when using attributes and objectclasses from the horde.schema. ---------------- today i restarted the ldap-server and after that, the horde.schema was unknown to the ldap server, even if exactly the above entry still exists in the cn=config subtree, and the assigned ldif file is in the /etc/openldap/slap.d/cn=config/ directory. when i try to add an entry using the objectclass hordePerson (which is defined in the horde.schema), i get: Return Code from Bind: 21 Message: LDAP_INVALID_SYNTAX: Some part of the request contained an invalid syntax. It could be a search with an invalid filter or a request to modify the schema and the given schema has a bad syntax. MessageID: 5 DN: which is, what i usually get, when i try to use an unknown objectclass. i am aware that the take-over from the old slapd.conf configuration to the cn=config subtree is not complete yet. is this an issue not covered in the cn=config subtree story? how can i circumwent this bug? just recreating the above entry each time i restart the ldap server? suomi

3 2

problem with cleartext password setup
by Pat Riehecky 06 Feb '08

06 Feb '08

My reading the archives has lead me to believe that DIGEST-MD5 will require me to store passwords in cleartext. To evaluate the usefulness of this at my site (little point in storing them cleartext if nothing can use DIGEST-MD5) I have setup a test server, but the password keeps getting hashed I have added password-hash {CLEARTEXT} to my slapd.conf (which gave me password-hash {CLEARTEXT},{SSHA},{SMD5},{CRYPT}). That didn't do it, so I went for just password-hash {CLEARTEXT}. That also keeps getting my passwords hashed. Strangely they are not prefixed with the {HASHTYPE}. When I run ldappasswd -H ldapi:/// -D "cn=testuser,dc=iwu,dc=edu" -w Please -x -s please In LDAP I get userPassword:: cGxlYXNl I have the ppolicy overlay in place, but the behavior remains even when it is removed. The password is changing, but a log level of -1 isn't showing me why this is getting hashed. OpenLdap 2.4.7 on Debian Sid. What did I do? Pat

4 5

issues with proxycache overlay
by Thomas Seifert 06 Feb '08

06 Feb '08

Hi there, I'm trying to proxy and cache some ldap queries which would otherwise go to an IBM Tivoli Directory Server or another kind of ldap-server. Therefore I'm trying to use the pcache (proxycache) overlay in openldap 2.3.39. Is there a problem with that setup so far? Would it need special adjustments to proxy another kind of ldap server than just openldap? I'm having the problem, that I only get back on ldapsearch against the proxy --- # search result search: 2 result: 32 No such object --- which seems to get as far as getting the user authenticated as I get another error if I enter wrong credentials ;). Needless to say that everything is returned correctly if I just change the hostname to the direct ldap server. My config is as follows with is directly derived from the configuration: --- # proxycache settings database ldap suffix "o=domainname" rootdn "cn=Manager,o=domainname" uri ldap://hostname/o=domainname overlay pcache proxycache bdb 100000 1 1000 100 proxyAttrset 0 mail postaladdress telephonenumber proxyTemplate (sn=) 0 3600 proxyTemplate (uid=) 0 3600 proxyTemplate (&(sn=)(givenName=)) 0 3600 proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600 cachesize 20 directory /usr/local/openldap-proxycache/var/openldap-data/db.2.a index objectClass eq index cn,sn,uid,mail pres,eq,sub --- Any ideas about this issue? Any way to further diagnose the problem? I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly? Thanks in advance, Thomas

3 6

Upgrade to 2.3.40 -> failed index
by Paul B. Henson 05 Feb '08

05 Feb '08

I've been running OpenLDAP 2.3.35 for almost a year with no problems (Gentoo Linux, w/DB 4.5). I upgraded to 2.3.40 last week, and had a meltdown this morning during an account purge. There had been some updates to the directory after upgrading, but no deletes. During my delete run, there were some index errors: ----- [successful deletes] Feb 3 03:50:36 derp idmgmt[3722]: error deleting user cjlindsay: DN index delete failed (LDAP) [successful deletes] Feb 3 03:56:55 derp idmgmt[3722]: error deleting user ddshah: DN index delete failed (LDAP) [successful deletes] Feb 3 04:00:10 derp idmgmt[3722]: error binding to directory: internal error (LDAP) ----- After the index errors, LDAP stopped working. The logs on the master showed: ----- Feb 3 03:50:36 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): file dn2id.bdb has LSN 8388745/33900185 , past end of log at 137/33937441 Feb 3 03:50:36 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): Commonly caused by moving a database fr om one transactional database Feb 3 03:50:36 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): environment to another without clearing the database LSNs, or removing Feb 3 03:50:36 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): all of the log files from a database en vironment Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): DB_ENV->log_flush: LSN of 8388745/33900 185 past current end-of-log of 137/37666668 Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): dn2id.bdb: unable to flush page: 3118 Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): txn_checkpoint: failed to flush the buf fer cache: DB_RUNRECOVERY: Fatal error, run database recovery Feb 3 04:00:10 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): PANIC: fatal region error detected; run recovery ----- I restarted slapd, resulting in: ----- Feb 3 06:55:53 fosse slapd[5129]: bdb_db_close: txn_checkpoint failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) Feb 3 06:55:53 fosse slapd[5129]: bdb(dc=csupomona,dc=edu): PANIC: fatal region error detected; run recovery Feb 3 06:55:53 fosse slapd[5129]: bdb_db_close: close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) Feb 3 06:55:53 fosse slapd[5129]: slapd stopped. Feb 3 06:56:02 fosse slapd[11055]: @(#) $OpenLDAP: slapd 2.3.40 (Jan 31 2008 21:55:32) $ portage@fosse:/var/tmp/portage/net-nds/openldap-2.3.40-r1/work/openldap-2.3.40/servers/slapd - Server is unavailable Feb 3 06:56:18 fosse slapd[11056]: hdb_db_open: unclean shutdown detected; attempting recovery. Feb 3 06:56:20 fosse slapd[11056]: slapd starting ----- I have two syncrepl slaves, both had failed at the exact same time with the exact same logs: ----- Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): DB_ENV->log_flush: LSN of 8388762/370 13381 past current end-of-log of 154/40862130 Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): Database environment corrupt; the wro ng log files may have been removed or incompatible database files imported from another environment Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): PANIC: DB_RUNRECOVERY: Fatal error, r un database recovery Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): dn2id.bdb: unable to flush page: 3118 Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): txn_checkpoint: failed to flush the b uffer cache: DB_RUNRECOVERY: Fatal error, run database recovery Feb 3 04:00:11 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): PANIC: fatal region error detected; r un recovery Feb 3 04:00:11 filmore slapd[5127]: null_callback: error code 0x50 Feb 3 06:57:41 filmore slapd[5127]: bdb_db_close: txn_checkpoint failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) Feb 3 06:57:41 filmore slapd[5127]: bdb(dc=csupomona,dc=edu): PANIC: fatal region error detected; run recovery Feb 3 06:57:41 filmore slapd[5127]: bdb_db_close: close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) Feb 3 06:57:41 filmore slapd[5127]: slapd stopped. Feb 3 06:57:49 filmore slapd[20722]: @(#) $OpenLDAP: slapd 2.3.40 (Jan 28 2008 18:22:34) $ portage@filmore:/var/tmp/portage/net-nds/openldap-2.3.40-r1/work/openldap-2.3.40/servers/slapd Feb 3 06:57:49 filmore slapd[20723]: hdb_db_open: unclean shutdown detected; attempting recovery. Feb 3 06:57:51 filmore slapd[20723]: slapd starting ----- After a restart, things seemed to be working ok. I deleted one object by hand with no problem. But then on deleting the second, I received the same index failure. Finally, I shut everything down, did a slapcat to ldif, deleted the entire DB, and then a slapadd to regenerate from scratch. So far, so good after that. I restarted my batch delete, it's been running for 20 minutes with no errors (fingers crossed). What happened? It can't be local corruption, all three servers failed exactly the same way. I didn't upgrade bdb, it's the exact same version that's been running. I didn't think I needed to rebuild the db on an upgrade from 2.3.35 to 2.3.40, was I mistaken? Should I have done a dump/reload? Was this failure possibly a bug in 2.3.40? A bug in 2.3.35 exposed by the upgrade? Any thoughts much appreciated... Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

7 21

Multiple passwords
by Adrian Overbury 05 Feb '08

05 Feb '08

Hi, I'm trying to make a system account in LDAP that has multiple passwords, one of which is time-limited. Basically, it's your run-of- the-mill posix/shadowAccount object, with your common-or-garden userPassword attribute. Everything works so far. But now I want to add a couple of new attributes, tempPassword and tempPasswordTimestamp. tempPassword will contain a long random string of characters hashed somehow (crypt, sha, md5, I don't care) generated by the service-management software my company develops. tempPasswordTimestamp is what one of its underlying systems will use to determine all tempPasswords that have expired. Now, I created the attribute tempPassword, and made it SUP userPassword, but it doesn't seem to have inherited any of userPassword's functionality, like the ability to hash the entered string with a given scheme (like if I entered {SSHA}password I'd end up with a SHA-1 hashed password) and automatic encoding to base64. I know (or, at least, I *think* that userPassword is a multi-valued attribute, so I could just enter another userPassword and let it auth off that, but that defeats the purpose, which is to create a secure password that operators in our service-management software can use to log in to this user's account at the push of a button, without having to actually *know* the user's password. The password itself will be at least 20 characters long, consisting of uppercase, lowercase, numbers and special characters, so it'll be as secure as we can make it. All of it relies on me being able to create a new password attribute and auth off it, though, so, anyone able to help? Regards, Adrian

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software