openldap-technical February 2010

openldap-technical@openldap.org

59 participants
64 discussions

nss_map_attribute gidNumber problem
by Liam Gretton 11 Feb '10

11 Feb '10

I have user accounts for various systems within an OpenLDAP db (OpenLDAP 2.4.12 on openSUSE 11.1). Clients are running the same version on the same OS. As accounts have different requirements depending on which host is being logged into, I've created a custom schema which implements the following custom attributes: loginShellSYS1 homeDirectorySYS1 gidNumberSYS1 ...and so on for multiple SYSn systems. On the client using nss_ldap side I am mapping these to the plain attributes as so in /etc/ldap.conf: nss_map_attribute loginShell loginShellSYS1 nss_map_attribute homeDirectory homeDirectorySYS1 nss_map_attribute gidNumber gidNumberSYS1 Everything works perfectly EXCEPT for the gidNumber mapping. If that's in place then 'getent group' does not return the LDAP groups. The logs on the LDAP server suggest that the correct information has been requested, and it does indeed churn out all the expected results, but the client seems to be failing in doing the mapping at the last step. ldapsearch on an account from the client returns all the expected attributes including the gidNumberSYSn ones. The LDAP accounts also have a normal gidNumber attribute, and if I remove the mapping and use that, then getent group returns the expected results. In fact, checking the LDAP server logs, it seems that when gidNumber is mapped, getent is requesting 'cn' instead of 'gidNumber' from the record. Without the mapping, it correctly requests the gidNumber attribute. It's entirely likely that I've done something plain silly which is causing this problem, but is there any special behaviour regarding group mapping that I should have taken into account? -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

1 0

Strange nisMapEntry
by David LEROUX 10 Feb '10

10 Feb '10

Hi all, I have in my ldifs, whatever the way I do them (slapcat ldapsearch -LLL...) some strange entry, like if it was hashed. Here is a sample: nisMapEntry:: LXJ3LHRjcCxpbnRyLHJzaXplPTMyNzY4LHdzaXplPTMyNzY4LHRpbWVvPTUwLHJldHJhbnM9MTAgeWFrMjA6L3VzcjIvdXNlcnMvJiA= Which should be: nisMapEntry: -rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10 yak20:/usr2/users/& If I re import them from a fresh "normal" ldif generated from my nis automount maps, it does the same, it's alway the same affected entries... In phpldapadmin I can see it well, but not in my ldifs and its a bit annoying for me... Any idea ? Thanks, -- David Leroux

4 4

OpenLDAP 2.4 replicated to 2.3?
by Jakov Sosic 10 Feb '10

10 Feb '10

Hi to all! I've set up Zimbra LDAP (2.4) as master, and I want to use RHEL v5 LDAP (2.3) as a slave. This is relevant part of my slapd.conf on LDAP 2.3: # syncrepl directives syncrepl rid=101 provider=ldap://192.168.1.86 bindmethod=simple binddn="uid=zimbra,cn=admins,cn=zimbra" credentials=PASSword searchbase="dc=company,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog # Refer updates to the master updateref ldap://192.168.1.86 Replication works OK, when I first start LDAP, it populates automatically. But after that initial data, it just doesn't pull anything anymore. I have to restart it, or it won't pull data from Master :( Problem is, when I add user to Zimbra LDAP (master), it does not propagate immediately data to slave LDAP. I don't even know what the interval is, I've never seen it happen in a few minutes after the Master LDAP is updated... Am I missing something? Shouldn't "refreshAndPersist" do it without any delay (or with minimal delay)? Should I run someting on zimbra LDAP side, or is the sync from LDAP 2.4 to LDAP 2.3 impossible? Would it be better to set something like: type=refreshOnly interval=00:00:00:01 but this just seems like a bruteforce to me :( I repeat, after I restart slave LDAP, all the new enteries appear magically. I'm really confused. Ideas? -- | Jakov Sosic | ICQ: 28410271 | PGP: 0x965CAE2D | ================================================================= | start fighting cancer -> http://www.worldcommunitygrid.org/ |

3 3

(no subject)
by Mark Beavis 09 Feb '10

09 Feb '10

I've setup an OpenLDAP server to use MySQL as a backend - and everything works wonderfully. When I add a new record to the table, I can see the new record in an LDAP browser immediately. However, when I insert a record into the database using JDBC (via a hello world-ish java app), the record does not appear in my LDAP browser. I can see the record in the DB so the data is there - it just doesn't appear in the LDAP browser. That is, until, I restart the LDAP server, then the new record (inserted via JDBC )appears OK in my LDAP browser... Would anyone have any idea as to why this is happening? Thanks - This email may contain privileged and confidential information intended only for the use of the intended recipient. If you are not the intended recipient of this message, any use, dissemination, distribution or reproduction of this message is prohibited. Any views expressed in this message are for those of the individual sender and may not necessarily reflect the views of RHE Group.

1 0

slapd dying, what next?
by Bryan J. Maupin 09 Feb '10

09 Feb '10

A few weeks ago, we upgraded to OpenLDAP 2.4.19. All seemed well, for about 4 weeks, and then within the last few days (starting Jan 14), slapd has been dying on our replica servers. It doesn't seem to follow any pattern, and the system seems fine when slapd dies; it isn't out of memory, and doesn't show any load spikes. In our logs we get messages like: Jan 14 22:18:34 slapd[7940]: ch_malloc of 14698087920909635104 bytes failed (from ldap.log) Jan 15 16:58:03 kernel: slapd[22663] general protection rip:2ac667af65cc rsp:4659d970 error:0 Jan 16 15:42:34 kernel: slapd[10272] general protection rip:2b71f6c6d9c4 rsp:45441980 error:0 Jan 16 17:20:01 kernel: slapd[7538] general protection rip:2aec51954ae0 rsp:449518d0 error:0 Jan 19 13:38:46 kernel: slapd[2821] general protection rip:2aeac3070ae0 rsp:4918f8d0 error:0 (from /var/log/messages) from another replica server: Jan 16 20:56:15 kernel: slapd[17948] general protection rip:2aedf150d9c4 rsp:4154f980 error:0 Jan 18 01:42:46 kernel: slapd[9446] general protection rip:2ae369401ae0 rsp:454c08d0 error:0 Jan 19 13:04:29 kernel: slapd[25339] general protection rip:2b9803877ae0 rsp:4b6bc8d0 error:0 We're running on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k, Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), libunwind 0.99 (for Google tcmalloc), Google tcmalloc 1.3. 1. Is there any useful information that can be obtained from these log entries, or do we simply need to change to a more verbose log level and wait for slapd to die again? 2. If we need to change our log level, what is a suggested level? Right now we're using "loglevel sync stats". Would it be wise to change the log level to -1 (any)? These are production servers, and I imagine that'd be a huge performance hit. 3. Also, we're logging asynchronously at the moment. Should we disable this while debugging? Thanks!

3 13

accesslog overlay - filter by ip addresses (advise)
by Aravind Gottipati 09 Feb '10

09 Feb '10

Hi, I'd like to extract successful bind operations and filter them based on the connection's originating ip address. From the docs, it looks like enabling and querying the accesslog database is a good way to go. Unfortunately, it looks like the ip addresses for the operations aren't recorded in the accesslog db. Is this information recorded in the accesslog at all? I dumped the db with a slapcat and couldn't find it there. Are there some configuration options that I could enable to record this information. My worst case scenario would be to log this into the ldap log file and scrape that. Is there a better way to do this? Thanks in advance, Aravind.

1 0

LDAP and DNS-SRV: questions
by Keutel, Jochen 09 Feb '10

09 Feb '10

Hello, we are trying to use the DNS-SRV backend of OpenLDAP. This gets difficult when ldaps is used. I'm not sure whether we do this correctly - so I'd like to ask the following questions: 1. If I run an LDAP server (administrative point: dc=keutel,dc=de) with both ldap and ldaps enabled: Is it right that I should put *two* lines into DNS? Like: _ldaps._tcp.keutel.de IN SRV 10 0 636 ldap.keutel.de _ldap._tcp.keutel.de IN SRV 10 0 389 ldap.keutel.de Or, when using non-default ports: _ldaps._tcp.keutel.de IN SRV 10 0 1636 ldap.keutel.de _ldap._tcp.keutel.de IN SRV 10 0 1389 ldap.keutel.de 2. If there is another LDAP server, e.g. ldap.abcdefg.hi , configured using DNS-SRV backend: If I search this server like: ldapsearch -H ldaps://ldap.abcdefh.hi/ -b dc=keutel,dc=de sn=meier Then I would expect that this requested is chained (using back-meta) to ldaps://keutel.de:1636/ with search base dc=keutel,dc=de . Is this understanding correct? 3. If yes: I think that OpenLDAP code currently doesn't handle this correctly: a) independent on the original request (ldap or ldaps): Always the _ldap._tcp DNS record is used (never _ldaps._tcp) b) independent on the original request (ldap or ldaps): Always ldap URLs are returned (never ldaps://...) c) the search base is omitted in the chained request: So keutel.de is searched with empty search base See ITS 6462 and 6463 for details. I think fixing b) and c) is not that difficult: Just dnssrv_back_referrals() has to be changed. I'll try to send a patch. Fixing a) seems more difficult because ldap_domain2hostlist() isn't used only in the DNS SRV backend but also in the tools (ldapsearch etc.) and the NSS overlay. Best regards, Jochen.

1 0

LDAP w/mysql as backend
by Radosław Antoniuk 09 Feb '10

09 Feb '10

Hi, I need a pointer please. I need to configure an LDAP server that presents (only read!) data from a mysql database. I have found some nice article for ndb configuration but I think that's not what I need, because this scenario is bi-directional, i.e. It assumes a clean mysql database and r/w access via LDAP that uses mysql as backend per say. What I want to do is to treat LDAP just as an "interface" to mysql database (or even one table). Can anybody point me to a good direction of reading? Thanks. -- Best regards, Radek Antoniuk

4 3

nssov overlay and hostservice
by ben thielsen 08 Feb '10

08 Feb '10

hi i'm experimenting with the nssov overlay, and am trying to get the hostservice approach working as described in man 5 slapo-nssov. i'm using slapd 2.4.18 and the 0.6.11 nss-pam-ldapd stub libraries, both via ubuntu packages. the nss side of things appears to be working as desired, but in my testing with sshd and pam, authentication succeeds even when the user is in a group that's denied the compare operation for the authorizedservice attribute. testing a bit with ldapcompare seems to indicate my acls are working as expected, and i see compare references in slapd's log when running ldapcompare, but not during ssh authentication. i'm relatively confident the authentication is not occurring via another mechanism (like nss/shadow) - if i remove the auth line that references pam_ldap from the pam config for sshd, authentication fails. i've included a few snippits below that will hopefully help illustrate things. overlay config: >ldapsearch -xLLLWH 'ldaps://ldap.groundnoise.net' -D 'cn=admin,cn=config' -b 'olcOverlay={6}nssov,olcDatabase={2}bdb,cn=config' -s base Enter LDAP Password: dn: olcOverlay={6}nssov,olcDatabase={2}bdb,cn=config objectClass: olcNssOvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {6}nssov olcNssMap: group uniquemember member olcNssPam: authz2dn hostservice olcNssPamSession: sshd olcNssPamSession: login acls: >ldapsearch -xLLLWH 'ldaps://ldap.groundnoise.net' -D 'cn=admin,cn=config' -b 'olcDatabase={2}bdb,cn=config' -s base olcaccess Enter LDAP Password: dn: olcDatabase={2}bdb,cn=config olcAccess: {0}to dn.base="" by * read olcAccess: {1}to attrs=userPassword by self =dxw by anonymous auth by * none olcAccess: {2}to dn.base=cn=under.groundnoise.net,ou=hosts,dc=groundnoise,dc=net attrs=authorizedservice by set="[cn=directory_administrators,ou=general,ou=users,ou=groups,dc=groundnoise,dc=net]/member* & user" manage by set="[cn=ssh,ou=all_servers,ou=servers,ou=users,ou=groups,dc=groundnoise,dc=net]/member* & user" compare by set="[cn=ssh,ou=under,ou=servers,ou=users,ou=groups,dc=groundnoise,dc=net]/member* & user" compare by * =dxrs olcAccess: {3}to * by self write by set="[cn=directory_administrators,ou=general,ou=users,ou=groups,dc=groundnoise,dc=net]/member* & user" manage by users read by * none related group membership: >ldapsearch -xLLLWH 'ldaps://ldap.groundnoise.net' -D 'cn=admin,dc=groundnoise,dc=net' -b 'dc=groundnoise,dc=net' '(cn=ssh)' member Enter LDAP Password: dn: cn=ssh,ou=under,ou=servers,ou=users,ou=groups,dc=groundnoise,dc=net member: uid=alien,ou=people,ou=users,ou=accounts,dc=groundnoise,dc=net member: uid=lisa,ou=people,ou=users,ou=accounts,dc=groundnoise,dc=net dn: cn=ssh,ou=all_servers,ou=servers,ou=users,ou=groups,dc=groundnoise,dc=net member: uid=rwetzel,ou=people,ou=users,ou=accounts,dc=groundnoise,dc=net entry for the host running sshd: >ldapsearch -xLLLWH 'ldaps://ldap.groundnoise.net' -D 'cn=admin,dc=groundnoise,dc=net' -b 'cn=under.groundnoise.net,ou=hosts,dc=groundnoise,dc=net' -s base Enter LDAP Password: dn: cn=under.groundnoise.net,ou=hosts,dc=groundnoise,dc=net objectClass: device objectClass: top objectClass: ipHost objectClass: authorizedServiceObject cn: under.groundnoise.net ipHostNumber: 192.168.1.1 authorizedService: sshd authorizedService: login getent for the host entry: >getent hosts under.groundnoise.net 192.168.1.1 under.groundnoise.net nsswitch config: >egrep -v '(^[[:space:]]*#|^[[:space:]]*$)' /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap hosts: files dns ldap networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis ldapcompare test: >ldapcompare -vxWH 'ldaps://ldap.groundnoise.net' -D 'uid=luna,ou=people,ou=users,ou=accounts,dc=groundnoise,dc=net' 'cn=under.groundnoise.net,ou=hosts,dc=groundnoise,dc=net' 'authorizedservice:login' ldap_initialize( ldaps://ldap.groundnoise.net:636/??base ) Enter LDAP Password: DN:cn=under.groundnoise.net,ou=hosts,dc=groundnoise,dc=net, attr:authorizedservice, value:login Compare Result: Insufficient access (50) UNDEFINED pam config for sshd: >egrep -v '(^[[:space:]]*#|^[[:space:]]*$)' /etc/pam.d/sshd auth required pam_env.so # [1] auth required pam_env.so envfile=/etc/default/locale auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so account required pam_nologin.so account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required pam_permit.so session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so session optional pam_ldap.so no_warn session optional pam_motd.so # [1] session optional pam_mail.so standard noenv # [1] session required pam_limits.so password required pam_passwdqc.so min=disabled,16,12,7,6 max=256 password [success=2 default=ignore] pam_unix.so obscure md5 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass password requisite pam_deny.so password required pam_permit.so ssh test: >ssh luna(a)under.groundnoise.net hostname --fqdn luna(a)under.groundnoise.net's password: under.groundnoise.net i'm hoping someone can point out what i'm missing or what i might be doing wrong. thanks, -ben

2 1

Re: nssov overlay and hostservice
by ben thielsen 06 Feb '10

06 Feb '10

On Feb 05, 2010, at 11.59, Kyle Robinson wrote: > On Thu, Feb 4, 2010 at 7:26 PM, ben thielsen <btb(a)bitrate.net> wrote: > >> hi >> >> i'm experimenting with the nssov overlay, and am trying to get the >> hostservice approach working as described in man 5 slapo-nssov. i'm using >> slapd 2.4.18 and the 0.6.11 nss-pam-ldapd stub libraries, both via ubuntu >> packages. >> ... >> >> ssh test: >>> ssh luna(a)under.groundnoise.net hostname --fqdn >> luna(a)under.groundnoise.net's password: >> under.groundnoise.net >> >> i'm hoping someone can point out what i'm missing or what i might be doing >> wrong. >> >> thanks, >> -ben > > > Turn on debug for pam_unix and pam_ldap in the auth section and check syslog > to make sure it isn't actually pam_unix doing the auth via nss passwd hash. i'm fairly confident that auth isn't happening via pam_unix / nss passwd hash. if i remove the auth line for pam_ldap from the pam config (leaving only pam_unix), authentication fails (other users in local passwd/shadow flat files still work). i also see, in the logs, a pam_unix failure "sshd[10978]: pam_unix(sshd:auth): authentication failure;" prior to success by the ldap module each time authentication occurs. the debug option for the pam_ldap stub library from nss-pam-ldapd is ignored, according to the man page, and adding either debug or audit to pam_unix didn't seem to generate any additional log data. there is plenty of activity in the slap log file, just not the compare operations that i was expecting to see, based on my interpretation of the man page for slapo-nssov.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2010