openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Re: [Samba] ldap filter removed? - Solution
by Jarbas Peixoto Júnior 16 Jun '08

16 Jun '08

Can anybody help me about that? []s Jarbas Remy Zandwijk escreveu: > Hi Jarbas, > > Nice solution, but how do you handle ldap searches from different Samba domains? I mean, all searches will use the same filter, which will be converted to another filter. Is OpenLDAP capable of 'rewrite when search from IP number x.x.x.x' ? > > Remy > > > >> In reference at http://lists.samba.org/archive/samba/2005-August/108999.html and http://threebit.net/mail-archive/samba/msg00118.html >> >> Hi Remy, >> Hi Norbert, >> >> >> I have the similar problem e I resolved with the "overlay rwm in openldap". >> >> If in smb.conf I haved: ldap filter = (&(iufmLogin=%u)(gecos=#*)) >> >> When the new samba search by any user, the following filter in openldap is used: (&(uid=user)(objectClass=sambaSamAccount)). Then the overlay replace by filter by (&(iufmLogin=$1)(gecos=#*)) only in openldap server. >> >> My slapd.conf (only the part with overlay rwm) is: >> ... >> moduleload rwm >> overlay rwm >> rwm-rewriteEngine on >> rwm-rewriteContext searchFilter >> rwm-rewriteRule "\$&\\(uid=([a-z0-9_]+)\$\$objectClass=sambaSamAccount\$\\)" "(&(iufmLogin=$1)(objectClass=sambaSamAccount))" ":@I" >> ... >> >> This work fine to me. >> >> >

1 0

Thunderbird & OpenLDAP
by Erik Lotspeich 15 Jun '08

15 Jun '08

Hi, Is there anyone who is using Thunderbird and OpenLDAP with SSL enabled? I cannot get this combination to work -- I can only use Thunderbird with non-SSL OpenLDAP. If no one can say, definitively, that this works, I guess there must be a bug in one or both software packages. Any help would be greatly appreciated. Thanks, Erik.

2 1

slapd-passwd backend problems
by Lawrence Stewart 15 Jun '08

15 Jun '08

Hi all, I'm attempting to set up a very simple passwd database backed slapd instance and can't seem to make it work reliably. A number of hours on google and experimenting with options has not been fruitful so far. I'm running openldap 2.4.10 on FreeBSD 7.0 My slapd.conf looks like this: ############################################## include /usr/local/etc/openldap/schema/core.schema loglevel conns filter stats pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/local/libexec/openldap moduleload back_passwd moduleload back_monitor access to * by anonymous read database passwd readonly yes suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw <passwod> database monitor ############################################## I am able to successfully start slapd and I can successfully query for a user by running the following command on the server itself: ldapsearch -x -H ldap://127.0.0.1 -b 'dc=example,dc=com' 'uid=test' which correctly returns the following details about the test user already in the system's passwd database: ############################################## # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: uid=test # requesting: ALL # # test, example.com dn: uid=test,dc=example,dc=com objectClass: person objectClass: uidObject uid: test cn: test cn: Testy McTest sn: test sn: McTest description: Testy McTest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ############################################## However, attempting an identical, additional query after the first one results in an empty search being returned: ############################################## # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: uid=test # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ############################################## I have experimented with many different options in slapd.conf and have not found anything that is able to mitigate this behaviour. The only way I have found to make an additional query work successfully is to restart slapd. After a restart, I can successfully make a single query again and then it stops returning a query result. The debugging output from slapd when a query is successful looks like this: ############################################## Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: listen=7, new connection on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: added 8r (active) listener=0x0 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 fd=8 ACCEPT from IP=127.0.0.1:59836 (IP=0.0.0.0:389) Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=0 BIND dn="" method=128 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=0 RESULT tag=97 err=0 text= Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: begin get_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: end get_filter 0 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=test)" Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 6 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: connection_read(8): input error=-2 id=0, closing. Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=2 UNBIND Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: removing 8 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 fd=8 closed Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL ############################################## and for an unsuccessful query looks like this: ############################################## Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 busy Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: listen=7, new connection on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: added 8r (active) listener=0x0 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 fd=8 ACCEPT from IP=127.0.0.1:64362 (IP=0.0.0.0:389) Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=0 BIND dn="" method=128 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=0 RESULT tag=97 err=0 text= Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: begin get_filter Jun 16 13:22:21 newtcp8 slapd[11410]: EQUALITY Jun 16 13:22:21 newtcp8 slapd[11410]: end get_filter 0 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=test)" Jun 16 13:22:21 newtcp8 slapd[11410]: => test_filter Jun 16 13:22:21 newtcp8 slapd[11410]: EQUALITY Jun 16 13:22:21 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: connection_read(8): input error=-2 id=1, closing. Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=2 UNBIND Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: removing 8 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 fd=8 closed Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL ############################################## I have analysed both sets of debug output and there are no material differences except that the successful query applies a number of equality test operations (indicating it is successfully walking through the entries in the passwd file) where as the failed query only applies 1 equality test. It's like the subsequent queries are not causing a full re-walk of the passwd database to find a match, but that's pure speculation at this point. Any insights into why the passwd backend might be behaving like this would be greatly appreciated. Please let me know if additional information or more detailed debugging output would help to diagnose the issue. Thanks in advance. Cheers, Lawrence

1 0

LDAP ACL/ ADRESSBOOK Problems and more
by Sebastian Reinhardt 15 Jun '08

15 Jun '08

Hi, I have some huge (for me, but I hope not for the experts in this list) problems: First the server config: - openSuSE 10.3 (x86_64) - openldap openldap2-2.3.37-7.4 User administration, NFS and also Apache (for company intern information websites, not for "real" web) is running without problems and 5 clients (openSuSE 10.3 (x86_64 and i586), too), replication is not setup yet, but this is not the major problem. 1. Problem: I added an central adressbook into the ldap- directory. It can be edited by KAdressBook and also used by Thunderbird from every Client, but for editing the ldap-root- Login is required (no good idea, I know and I like to change) and everyone can read the hole ldap- directory (have to be changed, too). I tried to give only users of group "adressbook_write" permission to edit entries in "ou=people"- part (adressbook) of ldap and users of "adressbook_read"- group the "read"- rights. Any other should not be allowed to read or write in "ou=people" or other parts of the ldap directory. This is the section of slap.conf: ---------------------------------- access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by * auth access to attrs=shadowLastChange by self write by * read access to dn.base="ou=people,dc=LMV,dc=LMV" by group="cn=adressbook_read,dc=LMV,dc=LMV" read by group="cn=adressbook_write,dc=LMV,dc=LMV" write access to * by * read ----------------------------------------- I tried it also without "dn.base=" in front of first line (access to..), but then user- auth. was disabled. What is wrong? Can I delete "access to * by * read", without disabling Login- capability ? 2. Problem: KAddressBook can access (r/w, only by using root- access, simple auth.) the ldap- address book (ou=people). Reading is no problem, but by saving an new entry, KAddressBook shows the busy- symbol (mouse symbol) an the new entry is not shown in KAddressBook, but the entry is saved in ldap (it can be read/ edited by other applications; ldapbrowser or other). Whats the problem? KAddressBook, user read/write permissions? Or is it LDAP? To show the new entry in KAddressBook, the program has to be restarted. But KAddressBook is not crashed or frozen, the user can add new address or show/ edit old entries. 3. Problem: Is any schema available, which can handle more (3 or more) email- addresses for every entry? I can not figure out, if the mozilla- schema ( german HowTo and schema taken from: http://www.pro-linux.de/t_office/openldap-adressbuch.html ) can handle more than one email- entry per person. Is this possible or is Thunderbird unable to read more than one email address from ldap? And if so, how can store all addresses from KAdressBook in LDAP (to share it with other KAddressBook- Clients)? 4. Auto- LogIn Some Clients where used only by one person/ login. With local user management, openSuSE provides the option to login an standard user at boot. Is an automatic user login with ldap-users and ldap- user management possible? 5. file/ dir- modes Is it possible to change the default file- mode (644) and dir- mode (755) in ldap user accounts for new generated files into file: 660 and dir: 770 ? So the group- members can edit files/ dirs generated by other users of same ldap managed group ? Thanks -- Mit freundlichen Grüßen Sebastian Reinhardt

1 0

help with ldapsearch on uid
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Hello, I am using OpenLDAP 2.4.9 on CentOS 5.1 (32 bit) with a custom schema and I have added ~7500 objects and I am not able to search successfully for these objects by uid. What must I do to be able to search for these objects by uid? Sample object: # 496user, People, example.com dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user(a)nest.tld mailid: 496user(a)nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S If I search for this user by uid, I will get no results back: # ldapsearch -xZZ -b "ou=people,dc=example,dc=com" uid=496user # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=496user # requesting: ALL # # search result search: 3 result: 0 Success # numResponses: 1 Searching by mailid does work: # ldapsearch -xZZ -b "ou=people,dc=example,dc=com" mailid=496user(a)nest.tld ...<snip>... dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user(a)nest.tld mailid: 496user(a)nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 The schema is as follows (downloaded from riseuplabs.org): objectIdentifier OID 1.1 objectIdentifier ldapOID OID:2 objectIdentifier attributetypeOID ldapOID:1 objectIdentifier objectclassOID ldapOID:2 attributeType ( attributetypeOID:1 NAME 'mailAddress' DESC 'email address(es)' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) attributeType ( attributetypeOID:2 NAME 'maildrop' DESC 'Mail addresses where mail is delivered -- ie forwards' SUP mailAddress ) attributeType ( attributetypeOID:3 NAME 'mailid' DESC 'Mail addresses accepted by this account -- ie aliases' SUP mailAddress ) attributeType ( attributetypeOID:4 NAME 'mailquota' DESC 'Bytes of mail quota' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) attributetype ( attributetypeOID:5 NAME 'maildir' DESC 'where mail is stored' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) objectclass ( objectclassOID:1 NAME 'mailAccount' DESC 'users who receive mail' AUXILIARY MAY (maildrop $ mailid $ mailquota $ maildir) ) TIA, Josh Miller, RHCE

4 11

Shell script to monitor LDAP server
by Alexandre Vieira 13 Jun '08

13 Jun '08

Hello all, I have a Solaris 10 system that queries a clients openldap server to deliver a certain service and the client is complaining that my system sometimes denies services to clients. Well my system only denies service to clients if the openldap system from the customer fails to answer. In this sense I tried to write a script to monitor the openldap server and its responsiveness but ldapsearch client in Solaris 10 doesn't work as I expected :( For example, all ok: bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 01:51:53 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) version: 1 dn: namingContexts: nodeName=XXXXX 1 matches Now imagine that the ldap server goes down: bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 02:11:04 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) ldap_search: Can't connect to the LDAP server - Connection refused Now imagine that the machine hosting LDAP goes down or a problem somewhere in the network occurs or a firewall blocks traffic (timeout): bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 02:11:04 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) And it just stays here forever. The -l flag only works after the search is initiated server side. There isn't a switch for a connection timeout limit. With this behaviour I can't test this as I imagined. Maybe some of you already have a monitoring script? Thanks in advance for any tip! PS: The script I wrote initially: ############################################################## #!/bin/bash LDAP_HOST=127.0.0.1:10000 POOLING_INTERVAL=5 LOGFILE=/var/log/ldap_watchdog.log # echo "Watchdog started at `date`" >> $LOGFILE while `/bin/true`; do ldapsearch -v -b '' -s base -h $LDAP_HOST 'objectclass=top' namingContexts if [ $? -ne 0 ]; then echo "`date`: Could not establish connection to LDAP server" >> $LOGFILE fi sleep $POOLING_INTERVAL done ############################################################## Alexandre Vieira - nullpt(a)gmail.com

3 4

LDAP group memberships not working
by Doug Grantham 13 Jun '08

13 Jun '08

Hey, I'm setting up a small network with LDAP and I'm running into a little trouble. The openldap server is on a Suse linux box and the clients are on solaris 10. Currently I'm trying to configure user authentication and group memberships. So far I have the authentication working. Users can log in on any of the solaris workstations. However, when these users log in, they are not part of the correct groups. The only group that user is a member of is their default group. But when that user logs in on the linux server, things work just great and they're members of all the correct groups. For example: USER1 is part of groups AAA, BBB, and CCC with their default group as BBB. When this user logs into the linux server and performs the 'groups' command, it will show this user is part of all three groups AAA, BBB, and CCC. However, when this user logs into the solaris client and perform's the 'groups' command, they're only a member of the BBB group. The /etc/nsswitch.conf on the solaris machine is configure like: passwd: files ldap group: files ldap host: files ipnodes: files netgroup: etc... The /var/ldap/ldap_client_file on the solaris machine is configured like: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 12.12.74.122 NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=edu NS_LDAP_AUTH= simple NS_LDAP_CACHETTL= 0 NS_LDAP_CREDENTIAL_LEVEL= proxy Here is an ldapsearch command and the results: ldapsearch -b "dc=mydomain,dc=edu" -h server1 "(objectclass=groupofnames)" dn: cn=AAA,ou=group,dc=mydomain,dc=edu cn: AAA gidNumber: 601 member: uid=USER1,ou=people,dc=mydomain,dc=edu member: uid=USER2,ou=people,dc=mydomain,dc=edu member: uid=USER3,ou=people,dc=mydomain,dc=edu objectClass: top objectClass: posixGroup objectClass: groupofnames dn: cn=BBB,ou=group,dc=mydomain,dc=edu cn: BBB gidNumber: 602 member: uid=USER1,ou=people,dc=mydomain,dc=edu member: uid=USER3,ou=people,dc=mydomain,dc=edu objectClass: top objectClass: posixGroup objectClass: groupofnames dn: cn=CCC,ou=group,dc=mydomain,dc=edu cn: CCC gidNumber: 603 member: uid=USER1,ou=people,dc=mydomain,dc=edu member: uid=USER2,ou=people,dc=mydomain,dc=edu member: uid=USER4,ou=people,dc=mydomain,dc=edu objectClass: top objectClass: posixGroup objectClass: groupofnames This has been a really weird problem. The default groups are getting properly set but none of the other memberships are working. I've not found any help online and I'm pulling my hair out!

3 2

Re: Shell script to monitor LDAP server
by karim.bourenane＠orange-ftgroup.com 13 Jun '08

13 Jun '08

Hello You cal also install HOBBIT ( old name Big Brother ) freeware with server and client side. Hobbit can send you email or notification by SMS .... you have also in, MRTG graph. Regards Karim Bourenane Orange Business Services / Equant RO&SI / IBNF / ENO / GNS 112 Avenue Charles de Gaules 92200 Neuilly S/Seine Phone: +33156 76 35 52 Fax: +33156 76 35 04 http://www.equant.com "Dieter Kluenter" <dieter(a)dkluenter.de> Sent by: openldap-technical-bounces+karim.bourenane=orange-ftgroup.com(a)OpenLDAP.org 13/06/2008 10:40 To: openldap-technical(a)openldap.org cc: bcc: Subject: Re: Shell script to monitor LDAP server "Alexandre Vieira" <nullpt(a)gmail.com> writes: > Hello all, > > I have a Solaris 10 system that queries a clients openldap server to deliver a > certain service and the client is complaining that my system sometimes denies > services to clients. Well my system only denies service to clients if the > openldap system from the customer fails to answer. > > In this sense I tried to write a script to monitor the openldap server and its > responsiveness but ldapsearch client in Solaris 10 doesn't work as I expected > :( > > For example, all ok: > > bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' > namingContexts > ldapsearch: started Fri Jun 13 01:51:53 2008 You should search the monitor backend, with something like ldapsearch -b "cn=connections,cn=monitor" -s sub -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: [BSD7.0] Openldap Server - Client 2.3.41 / Unknow user UID
by karim.bourenane＠orange-ftgroup.com 12 Jun '08

12 Jun '08

Hi Karic I make modification, but the error is already here :/ Regards Karim Bourenane Orange Business Services / Equant RO&SI / IBNF / ENO / GNS 112 Avenue Charles de Gaules 92200 Neuilly S/Seine Phone: +33156 76 35 52 Fax: +33156 76 35 04 http://www.equant.com "Almir Karic" <redduck666(a)gmail.com> Sent by: openldap-technical-bounces+karim.bourenane=orange-ftgroup.com(a)OpenLDAP.org 12/06/2008 15:22 To: karim.bourenane(a)orange-ftgroup.com cc: openldap-technical(a)openldap.org bcc: Subject: Re: [BSD7.0] Openldap Server - Client 2.3.41 / Unknow user UID i solved the same error by running nscd. On Thu, Jun 12, 2008 at 2:56 PM, <karim.bourenane(a)orange-ftgroup.com> wrote: > > Hi All > > I send you my actual problem, because i cannot resolve from 1 week :/. > I've installed openldap 2.3.41 server and client on server. Ssh running fine > with sudo. But if i do SCP command from another server i have this error : > > server-without-ldap# scp kbourena@ldap-rain:/home/kbourena/toto.txt . > Password: > unknown user 1206 > > If anyone have idea. > > Best Regards > > Karim Bourenane > Orange Business Services / Equant > RO&SI / IBNF / ENO / GNS > 112 Avenue Charles de Gaules > 92200 Neuilly S/Seine > Phone: +33156 76 35 52 > Fax: +33156 76 35 04 > http://www.equant.com > > -- For far too long, power has been concentrated in the hands of "root" and his "wheel" oligarchy. We have instituted a dictatorship of the users. All system administration functions will be handled by the People's Committee for Democratically Organizing the System (PC-DOS).

2 1

How to lock user
by Gustavo Mendes de Carvalho 12 Jun '08

12 Jun '08

Hi there, Is there any way to lock user in LDAP database ? I mean, in linux, it's possible to use passwd <username> -l to lock user and -u to unlock. Is there a similar function in LDAP ? Thanks --- Gustavo Mendes de Carvalho e-mail: gmcarvalho(a)gmail.com

5 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical