openldap-technical December 2010

openldap-technical@openldap.org

82 participants
96 discussions

Cannot ID LDAP User On LDAP Client
by Anton Chu 03 Dec '10

03 Dec '10

I've setup an Ubuntu 10.10 LDAP Client to authenticate off my LDAP server. I've install the following: sudo apt-get install libpam-ldap libnss-ldap nss-updatedb libnss-db nscd ldap-utils pam_ccreds Here's my /etc/nsswitch.conf: passwd: files ldap [NOTFOUND=return] db > > group: files ldap [NOTFOUND=return] db > > shadow: files ldap > > hosts: files dns > networks: files > > protocols: db files > services: db files > ethers: db files > rpc: db files > I can nss_updatedb ldap succssfully: # nss_updatedb ldap passwd... done. group... done. I can getent passwd, getent passwd shadow, getent group just fine and they all show all my ldap users. However, I cannot do an id ldapuser ex: $ id tony id: tony: No such user Here's my auth.log: Dec 1 21:08:17 webdev120 sshd[14765]: pam_unix(sshd:auth): check pass; user > unknown > Here's my syslog: sshd[14648]: Libgcrypt warning: missing initialization - please fix the > application > Here's my /etc/pam.d/commoun-auth: auth [success=4 default=ignore] pam_unix.so nullok_secure > auth [success=3 default=ignore] pam_ldap.so use_first_pass > auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 > action=validate use_first_pass > auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update > # here's the fallback if no module succeeds > #auth requisite pam_deny.so > # prime the stack with a positive return value if there isn't one already; > # this avoids us returning an error just because nothing sets a success > code > # since the modules above will each just jump around > #auth required pam_permit.so > # and here are more per-package modules (the "Additional" block) > auth optional pam_ccreds.so minimum_uid=1000 action=store > # end of pam-auth-update config > Here's my /etc/pam.d/common-account: # here are the per-package modules (the "Primary" block) > account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so > account [success=1 default=ignore] pam_ldap.so > # here's the fallback if no module succeeds > account requisite pam_deny.so > # prime the stack with a positive return value if there isn't one already; > # this avoids us returning an error just because nothing sets a success > code > # since the modules above will each just jump around > account required pam_permit.so > # and here are more per-package modules (the "Additional" block) > # end of pam-auth-update config > ID works just fine with my local users on my local machine so somehow it's not able to read the ldap users. Any insights appreciated.

3 7

last login time
by Nick Folino 03 Dec '10

03 Dec '10

I saw some old list traffic from 2005 about implementing last login time into the password policy. Was this idea scrapped? Nick

1 0

MemberOf out of sync on consumer[s]
by Yuri Bank 03 Dec '10

03 Dec '10

Hello, I've been putting this off for a while, but this is happening frequently enough that I think its time to ask for opinions on the bug I'm running into with OpenLDAP and the MemberOf overlay. Version: 2.4.23 Configuration: Single Provider, with 4 Consumers. It seems that when I add a new users on my provider, the MemberOf attribute disappears randomly for some users, on some ( not all ) consumer nodes. Everything in the DIT is in tact, and the changes made on my provider are replicated to the consumers correctly. The only issue here is with the memberof attribute. The only way for me to remedy this problem is to shutdown slapd on the affected consumer node, delete everything in /var/sun/slapd, and then start slapd again which then fully syncs with my provider with all memberof attributes in tact. My testing shows that this is triggered by making changes to to my LDAP groups/users on the provider node, but that is all I can find. Nothing in the logs gives me any clues as to what is happening. Has anyone experienced similar problems? Thanks, -Yuri

1 0

slap-hdb dirtyread
by CHIROSSEL, Olivier 03 Dec '10

03 Dec '10

Hi Someone kwon the status of this option ? "dirtyread Allow reads of modified but not yet committed data. Usually transactions are isolated to prevent other operations from accessing uncommitted data. This option may improve perforâ[m mance, but may also return inconsistent results if the data comes from a transaction that is later aborted. In this case, the modified data is discarded and a subsequent search will return a different result." For me this should be associate with the use of DB_READ_UNCOMMITTED flag .... Regards, Olivier

1 0

passwd fails
by Holger Schier 02 Dec '10

02 Dec '10

Hi guys, my ldapserver works fine now, but the first users are arriving. The normal user should change their own password. So, everyone thinks of passwd in the shell. But: LDAP password information update failed: Insufficient access Must supply old password to be changed as well as new one Here is my ACL: olcAccess: {0} to attrs=pwdChangedTime,pwdAccountLockedTime,pwdFailureTime,pwdH istory,pwdGraceUseTime,pwdReset by * none olcAccess: {1}to attrs=userPassword by self write by * auth olcAccess: {2}to attrs=shadowLastChange by self write by dn.base="cn=BINDUSER,dc=MY,dc=DC" read by users read by * auth olcAccess: {3}to attrs=userPKCS12 by self read by * none olcAccess: {4}to * by dn.base="cn=BINDUSER,dc=MY,dc=DC" read by * none I tried the same with olcAccess: {4}to * by * read and allowing anonymous binds, but same error. passwd seems to try to bind with the binduser and then to read and to write the userPassword, but only has auth access. Has anyone an idea how to enable this? Thanks a lot. Holger

3 2

memory leak when chasing referrals?
by Arthur de Jong 02 Dec '10

02 Dec '10

Hello list, I'm not 100% sure that this is a bug in OpenLDAP or in my code so I'll post here first. I run into a memory leak when running the code below on a server that contains referrals. The code itself is the minimal representation I could make that triggers the leak. The referral I used is something like: dn: ou=ref,ou=people,dc=test,dc=tld objectClass: referral objectClass: extensibleObject dc: subtree ref: ldap://otherserver/ou=morepeople,dc=test2,dc=tld ou: ref When I run the code through "valgrind --leak-check=full" I get: ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) ==30395== by 0x40650A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x4065EB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x8048871: main (test.c:28) Is there something wrong with my code (except for the complete lack of error handling that I stripped out to improve readability)? Should I free something in the LDAP_RES_SEARCH_REFERENCE case? Thanks. -----8<-- test.c --8<----- #include <stdio.h> #include <errno.h> #define LDAP_DEPRECATED 1 #include <ldap.h> int main(int argc,char *argv[]) { char *base="dc=test,dc=tld"; char *filter="(objectClass=posixAccount)"; char *attrs[] = { "uid", NULL }; int i; LDAP *ld; LDAPMessage *msg=NULL; int msgid; char **values; /* set up connection */ ldap_initialize(&ld,"ldap://localhost"); i=3; ldap_set_option(ld,LDAP_OPT_PROTOCOL_VERSION,&i); ldap_simple_bind_s(ld,NULL,NULL); /* start search and handle results */ ldap_search_ext(ld,base,LDAP_SCOPE_SUB,filter,attrs, 0,NULL,NULL,NULL,LDAP_NO_LIMIT,&msgid); while (1) { switch (ldap_result(ld,msgid,LDAP_MSG_ONE,NULL,&msg)) { case LDAP_RES_SEARCH_ENTRY: /* we have a normal search entry, print some attribute values */ values=ldap_get_values(ld,msg,attrs[0]); for (i=0;values[i]!=NULL;i++) fprintf(stderr,"%s=%s\n",attrs[0],values[i]); ldap_value_free(values); break; case LDAP_RES_SEARCH_RESULT: /* end of results */ ldap_msgfree(msg); ldap_unbind(ld); return 0; case LDAP_RES_SEARCH_REFERENCE: break; /* just ignore search references */ default: /* we have some error condition, bail out */ return -1; } ldap_msgfree(msg); } } -----8<-- test.c --8<----- -- -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org --

1 0

Readonly user for translucent proxy
by Christoph Berkemeier 02 Dec '10

02 Dec '10

Greetings, i am using an translucent proxy over here on Debian Lenny 64-bit in version 2.4.11-1+lenny2. The proxy is working fine when i am using the rootdn configured in my translucent proxy conf. But when i configure a readonly dn like below, i get only parts of my upstream server. The readonly is configured like this: access to * by dn="cn=admin,dc=hq,dc=example,dc=com" write by dn="uid=tlc,ou=user,dc=example,dc=com" read by * read With this config it should not even be necessary to configure an additional user, should it? The overlay is configured like this: overlay translucent translucent_local memberUid lastmod off uri ldaps://ldap.example.com acl-bind binddn="uid=tlc,ou=user,dc=example,dc=com" credentials="verysecret" Every authenticated dn uses the same binddn and credentials for the upstream ldap server ldap.example.com, right? Best Regards, Christoph Berkemeier

1 0

OpenLDAP on T2000
by Nick Folino 02 Dec '10

02 Dec '10

I'm evaluating OpenLDAP on various platforms and am having trouble getting the tools (slapadd, slapindex, etc) to perform well on Sun's T2000 servers. For example slapadd is running at about 50k/s. On an x86 server importing the same ldif yields over 1M/s. Using Berkeley DB 4.8 backend. I'm assuming the problem is related to CPU speed and threads. Can anyone give me some tips to increase the performance on this platform? Nick

4 3

Programmatically creating users
by Juan Pablo Romero Méndez 02 Dec '10

02 Dec '10

Hello, I'm trying to programmatically call useradd to create an ldap user on opensuse 11.2. The problem is that calling useradd -m --service ldap -D "cn=Administrator,dc=tkm,dc=com,dc=mx" testuser requests the ldap admin password in a way which I find difficult to handle programmatically. I thought that setting rootbinddn in /etc/ldap.conf and the password in /etc/ldap.secret would prevent useradd to ask the password but this is not the case. Is it possible to accomplish this? (i.e. configure useradd/passswd to not to ask passwords in the command line?) Regards, Juan Pablo

2 1

synrepl sends wrong rid cookie?
by Marc Patermann 02 Dec '10

02 Dec '10

Hi, on the provider server there are 3 databases glued together with one sync provider in the top level database: ... overlay glue overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 one consumer replicates two of the three database, each to a database, each database has its own synrepl statement with an own searchbase to get only the entries of this tree/database from the provider. Each database has its own rid: 401 and 402. When something changes in database 1 ou=humans, rid=401, the change is replicated. When something changes in database 2 ou=linux, rid=402, it is not. Only after a restart of the consumer changes apply. Now I saw this in the log: 1. change in ou=humans (rid=401) 2. change in ou=linux (rid=402) 3. change in ou=linux (rid=402) Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=402 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=402 NEW_COOKIE: rid=402,csn=20101201165315.347441Z#000000#000#000000 Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=401 cookie=rid=401,csn=20101201165315.347441Z#000000#000#000000 Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 be_search (0) Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 employeeNumber=0,ou=humans,ou=foo Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 be_modify employeeNumber=0,ou=humans,ou=foo (0) ... Dec 1 17:53:28 tfas099 slapd[12318]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:28 tfas099 slapd[12318]: do_syncrep2: rid=401 NEW_COOKIE: rid=401,csn=20101201165328.955051Z#000000#000#000000 ... Dec 1 17:53:42 tfas099 slapd[12318]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:42 tfas099 slapd[12318]: do_syncrep2: rid=401 NEW_COOKIE: rid=401,csn=20101201165342.175128Z#000000#000#000000 As you can see, on all three changes rid=401 is mentioned, never rid=402. When I restart, I can see this: Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 inserted UUID 9cd2cfc4-9005-102f-9517-d54a6b53d2d0 Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 be_search (0) Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 ou=accounts,ou=linux,ou=steuer,o=landesverwaltung niedersachsen,c=de Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 be_modify ou=accounts,ou=linux,ou=steuer,o=landesverwaltung niedersachsen,c=de (0) Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=402 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=402 cookie=rid=402,csn=20101201165342.175128Z#000000#000#000000 I get the rid=402 changes! Is this a configuration error on my side? Provider is 2.4.23, consumer is 2.4.20. Marc

2 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2010