openldap-software

openldap-software@openldap.org

2719 discussions

keywords "modulepath" and "moduleload" ignored?
by Paul Fardy 09 Apr '10

09 Apr '10

Apr 8 11:45:45 authn2 slapd[18074]: /local/etc/openldap/slapd.conf: line 25: keyword <modulepath> ignored Apr 8 11:45:45 authn2 slapd[18074]: /local/etc/openldap/slapd.conf: line 45: keyword <moduleload> ignored Why would these be ignored and why would slapd not give more detail? Thanks, Paul From slapd.conf: > # > # See slapd.conf(5) for details on configuration options. > # This file should NOT be world readable. > # > include /local/etc/openldap/schema/core.schema > include /local/etc/openldap/schema/cosine.schema > include /local/etc/openldap/schema/inetorgperson.schema > include /local/etc/openldap/schema/nis.schema > include /local/etc/openldap/schema/samba.schema > > # Allow LDAPv2 client connections. This is NOT the default. > allow bind_v2 > > # Do not enable referrals until AFTER you have a working directory > # service AND an understanding of referrals. > #referral ldap://root.openldap.org > > pidfile /var/run/openldap/slapd.pid > argsfile /var/run/openldap/slapd.args > #loglevel acl config conns filter packets sync > #loglevel config sync > loglevel -1 > > # Load dynamic backend modules: > modulepath /local/pkg/openldap/lib > > # modules available in openldap-servers-overlays RPM package: > > # modules available in openldap-servers-overlays RPM package: > # moduleload accesslog.la > # moduleload auditlog.la > # moduleload denyop.la > # moduleload dyngroup.la > # moduleload dynlist.la > # moduleload lastmod.la > # moduleload pcache.la > # moduleload ppolicy.la > # moduleload refint.la > # moduleload retcode.la > # moduleload rwm.la > # moduleload smbk5pwd.la > # moduleload syncprov.la > # moduleload translucent.la > # moduleload unique.la > # moduleload valsort.la > > moduleload pw-kerberos.so

2 2

Question on back-perl
by Andrea Cirulli 09 Apr '10

09 Apr '10

Just for fun I was testing the perl backend for openldap. I starting setting up an LDAP using the SampleLdap.pm perl library in the source code. My goal is to setup a consumer LDAP in synch with other LDAP (bdb backend) for keeping the mod add del etc. using the syncrepl mechanism. I want to wrap every modification in the Master LDAP and triggering some perl script. I'm very new to this approach and the first problem I'm facing is how to keep the last db state after a slapd crash or shutdown. Using SamplLdap.pm init it's just a subroutine returning 0, so after the first sync if I shutdown the slapd next time I will need a full resync. Do you know some other clever examples? I mean keeping the state of the LDAP and triggering, for example recording on files, the modifications on LDAP. I tried to add in the subroutine some operation on FILES (using standard open FILE....;print FILE "operation"; close (FILE)) it seems do not work. Many thanks to all! -- Andrea Cirulli

3 3

Bind using a user other than organizationalRole user
by Marcelo de Moraes Serpa 07 Apr '10

07 Apr '10

Hello list, I have a local OpenLDAP server with a couple of users. I'm using it for development purposes, here's the ldif: #Top level - the organization dn: dc=site, dc=com dc: site description: OneLogin LLC objectClass: dcObject objectClass: organization o: OneLogin LLC #Top level - manager dn: cn=Manager, dc=site, dc=com objectClass: organizationalRole cn: Manager #Second level - organizational units dn: ou=people, dc=site, dc=com ou: people description: All people in the organization objectClass: organizationalunit dn: ou=groups, dc=site, dc=com ou: groups description: All groups in the organization objectClass: organizationalunit #Third level - people dn: uid=celoserpa, ou=people, dc=site, dc=com objectclass: pilotPerson objectclass: uidObject uid: celoserpa cn: Marcelo de Moraes Serpa sn: de Moraes Serpa userPassword: secret_12345 mail: marcelo(a)site.com So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the 12345678 password (the local server password, setup on slapd.conf). However, I would like to bind with any user in under the people OU. In this case, I'd like to bind with: dn: uid=celoserpa, ou=people, dc=site, dc=com userPassword: secret_12345 But I'm getting a (49) - Invalid Credentials error everytime. I have tried through CLI tools (such as ldapadd, ldapwhoami, etc) and also ruby/ldap. The bind with these credentials fails with a invalid credentials error. I was suspecting that maybe OpenLDAP doesn't compare against userPassword? Or maybe some ACL configuration I am missing that is somehow affecting the read access to userPassword for the specific DN. I'm really lost here, any suggestion appreciated! Cheers, Marcelo.

6 7

Replication problem: How to sync?
by Torsten Schlabach (Tascel eG) 07 Apr '10

07 Apr '10

Hi! I have two replicas of my DIT, which unfortunately got out of sync somehow. So I can spot a particular object where one attribute has a different value on one replica than it has on the other one. What would I do to find out how that could have happened? What would I do to fix this? (Other than manually deciding which data is the right one and overwrite the other; I guess this may not even fix it for the next update.) Regards, Torsten

3 2

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

← Newer
1
...
4
5
6
7
8
9
10
...
272
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software