openldap-software April 2010

openldap-software@openldap.org

47 participants
48 discussions

Record last bind info?
by Erich Weiler 07 Apr '10

07 Apr '10

Hi All, My task at hand is to somehow record when a user last logged on to any of our systems, which all authenticate against OpenLDAP. Now, I've browsed the mailing lists and some folks have suggested using the accesslog backend, and only have it log 'binds', and thus I can later look back at the log DB and see when folks logged in last. While this seems to work, what concerns me is that it makes a log entry every time someone binds, so the log gets large fairly quickly, as well as load the server a bit because of all the write activity to the log DB (we have a large network with lots and lots of binds all the time). I saw that the accesslog backend has a 'logpurge' directive, but indeed I would like to only purge log entries older than a year, so the log DB will still get quite large. I was wondering if anyone knew a way to perhaps have it "log an entry, but only log it if there is already not a pre-existing entry of not more than X days old" or something like that for the uid in question...? Or maybe even something such that it logs a new entry and automatically purges all other older entries that match the same uid? Or even a better way? Thanks for any thoughts/insight! -erich

2 2

syncrepl: large datasets and expediting consumer's initialization
by Paul Fardy 05 Apr '10

05 Apr '10

I'm having trouble getting the consumer synced in reasonable time. My tests were with fewer than 20 entries in the datastore and I saw no problems. But we have 260,000 inetOrgPersons (with only a few attributes for each user: uid cn sn givenName mail userPassword). I've set up syncrepl: PROVIDER > # Indices to maintain for this database > index objectclass,entryCSN,entryUUID eq > index ou,cn,mail,surname,givenname eq,sub > index uidNumber,gidNumber,loginShell eq > index uid,memberUid eq,sub > index nisMapName,nisMapEntry eq,sub > > overlay syncprov > syncprov-checkpoint 100 1 > syncprov-sessionlog 100 > > limits dn.children="ou=replicators,dc=service,dc=utoronto,dc=ca" > size=unlimited time=unlimited (I index attributes I'm not currently using. I presume that's not the problem.) CONSUMER > syncrepl rid=123 > provider=ldap://PROVIDER:389 > type=refreshAndPersist > interval=00:00:10:00 > retry="60 10 300 +" > searchbase="dc=service,dc=utoronto,dc=ca" > filter="(objectClass=*)" > scope=sub > schemachecking=off > starttls=critical > bindmethod=simple > > binddn="uid=replicator,ou=replicators,dc=service,dc=utoronto,dc=ca" I've tried with and without slapcat/slapadd to initialize the consumer. On our slower system, slapadd took 98 minutes to rebuild the database; the faster was 35 minutes (and I have only one consumer right now). A full transfer via syncrepl is slow: 10 entries per second: > # < /var/log/daemon egrep 'bdb_add: added id=' | cut -b1-50 | uniq - > c | tail -10 > 10 Apr 1 10:57:31 ldap2 slapd[3126]: bdb_add: added > 11 Apr 1 10:57:32 ldap2 slapd[3126]: bdb_add: added > 9 Apr 1 10:57:33 ldap2 slapd[3126]: bdb_add: added > 9 Apr 1 10:57:34 ldap2 slapd[3126]: bdb_add: added > 10 Apr 1 10:57:35 ldap2 slapd[3126]: bdb_add: added > 9 Apr 1 10:57:36 ldap2 slapd[3126]: bdb_add: added > 10 Apr 1 10:57:37 ldap2 slapd[3126]: bdb_add: added > 10 Apr 1 10:57:38 ldap2 slapd[3126]: bdb_add: added > 10 Apr 1 10:57:39 ldap2 slapd[3126]: bdb_add: added > 5 Apr 1 10:57:40 ldap2 slapd[3126]: bdb_add: added With the consumer using the slapadded initial database, syncrepl seems to be reviewing every entry, 15 entries per second: > # tail -10000 /var/log/daemon | egrep 'entry unchanged' | cut - > b1-83 | uniq -c > 8 Apr 1 11:30:57 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 15 Apr 1 11:30:58 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 14 Apr 1 11:30:59 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 15 Apr 1 11:31:00 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 15 Apr 1 11:31:01 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 15 Apr 1 11:31:02 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 14 Apr 1 11:31:03 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 14 Apr 1 11:31:04 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 15 Apr 1 11:31:05 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored > 2 Apr 1 11:31:06 ldap2 slapd[3782]: syncrepl_entry: rid=123 > entry unchanged, ignored I can only hope it'll be done in 5 hours. The datastore isn't active, so the consumer is up to date, for now, but this needless work is time consuming. Is this normal? What happens when I restart the consumer? Why should I expect it to be faster restarting? I changed one entry (adding displayName to my own entry) after the slapcat, so the consumer did not have the change when the consumer started 90 minutes ago. That update has not yet propagated. Can I prime the consumer's syncrepl cookie (if that's an appropriate term)? Is that a solution? And how would I do that? Thanks for your time, Paul

4 5

Re: syncrepl: large datasets and expediting consumer's initialization
by Paul Fardy 05 Apr '10

05 Apr '10

On Apr 6, 10, at 2:44 AM, masarati(a)aero.polimi.it wrote: > If you slapadd to the consumer the output of slapcat from the > producer, > the CSNs will be consistent, and no refresh will occur. Did you by > chance > slapadd to the consumer a fresh LDIF, with no UUID/CSN information? > What > -w does is simply to set the contextCSN to the latest entryCSN found > in > the database. If you slapcat from the producer, the suffix entry will > have a valid contextCSN and -w is not needed. I'm setting up a highly available LDAP. I ran slapcat on the active LDAP server and used that as the source of slapadd for the new producer and its consumers. Every entry in the LDIF has entryUUID, creatorsName, createTimestamp, entryCSN, modifiersName, and modifyTimestamp. I expect entryUUID and entryCSN to be sufficient. The entryCSN is eq-indexed on the producer, so syncrepl a simple filter entryCSN >= consumer.contextCSN should efficiently find only new/modified entries. After "slapadd -w", it looks like the syncrepl works quickly, but the producer's log file suggests that syncrepl (since I see the replicator's DN) is visiting a lot of entries that have not changed. How do I determine which entries are actually returned to the syncrepl client? Thanks again, Paul

1 0

by users in <WHO> field
by Michael Ströder 03 Apr '10

03 Apr '10

HI! I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly? It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry. I saw that slapd.access(5) also mentions "realusers" for the <WHO> field but using this instead of "users" makes no difference. Ciao, Michael.

5 11

Syncrepl Problem
by Andrea Cirulli 02 Apr '10

02 Apr '10

Hi All, we are dealing with some problems on OpenLDAP 2.4.21 on SOLARIS 9 sparc. In particular, we have 2 Multimasters (in mirror mode) and 24 Consumer syncing 16 from one multimaster and 8 on the other. Sometimes synchronization does not work at all, starting the consumer in debug mode we saw: do_syncrep2: rid=011 LDAP_RES_SEARCH_RESULT do_syncrepl: rid=011 rc -2 retrying (9 retries left) This error (well it is not an error) happens not on all the consumer, but just on some of them randomly. Could some one explain what does this message mean? Thank you to all -- Andrea

1 0

LDAP bind using ldap_sasl_interactive_bind_s and DIGEST-MD5 fails the second time
by James Bong 01 Apr '10

01 Apr '10

I am currently using Mac OS X 10.6.2 and am attempting to use the ldap_sasl_interactive_bind_s API to do a digest-md5 authentication against Active Directory (2008, though I don't think it matters what flavor of AD is used). The bind works fine the first time. However, if I unbind and attempt to rebind as the same user, it fails with ldap_sasl_interactive_bind_s: Invalid credentials (49). If I bind with a different user, then unbind, and bind as the original user, it works. I created a simple program that illustrates the issue. When run, it binds correctly, unbinds, and then fails on the second bind after unbinding: trying ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s Done Unbinding Unbound. ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 57, v1772 Any idea why it is not possible to use the same credentials twice? Here is the test program. I tried reinitializing the sasl library with sasl_done and sasl_client_init, but that doesn't seem to make a difference. #include <ldap.h> #include <sasl/sasl.h> #include <stdio.h> typedef struct sasl_defaults { char *mech; char *realm; char *authcid; char *passwd; char *authzid; } sasl_defaults; int callback(LDAP *ld, unsigned flags, void* defaults, void *interact ) { printf("callback\n"); sasl_interact_t *in_out=(sasl_interact_t *)interact; sasl_defaults *in_defaults=(sasl_defaults *)defaults; while (in_out->id !=SASL_CB_LIST_END) { switch (in_out->id) { case SASL_CB_USER: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_AUTHNAME: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_PASS: in_out->result=in_defaults->passwd; in_out->len=strlen(in_defaults->passwd); break; case SASL_CB_GETREALM: in_out->result=""; in_out->len=strlen(""); break; } in_out++; } printf("callback done\n"); return 0; } int main (int argv, char ** argc) { printf("trying\n"); for (;;) { LDAP *ld; ldap_initialize(&ld, "ldap://dc.ad.domain.com:389"); ldap_set_option(ld,LDAP_OPT_REFERRALS,LDAP_OPT_OFF); int version=3; ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); int timelimit=5; if (ldap_set_option( ld, LDAP_OPT_TIMELIMIT, (void *) &timelimit ) != LDAP_OPT_SUCCESS ) { printf("err\n"); return -1; } sasl_defaults defaults; defaults.mech = "DIGEST-MD5"; defaults.passwd="password"; defaults.authcid="user"; defaults.realm="realm.com"; defaults.authzid="user"; printf("ldap_sasl_interactive_bind_s\n"); int rc=ldap_sasl_interactive_bind_s( ld, NULL,defaults.mech, NULL, NULL, LDAP_SASL_QUIET, callback, &defaults ); if( rc != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_sasl_interactive_bind_s" ); ldap_unbind(ld); return -1; } printf("ldap_sasl_interactive_bind_s Done\n"); printf("Unbinding\n"); ldap_unbind(ld); printf("Unbound.\n"); sleep(5); } }

1 0

reading the log file
by Itay Moav 01 Apr '10

01 Apr '10

Hi, I see under /var/lib/ldap the file log.000000001 which seems to be a binary file. How do I read it, or is there a different way to see a log of what the server does (something like the mysql.log) Thanks

5 4

built in objectClasses and atrributes
by Itay Moav 31 Mar '10

31 Mar '10

Greetings, Where can I see the list of built in objectClasses and attributes the OpenLDAP ships with? Thanks IM

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software April 2010