nss_map_attribute gidNumber problem
by Liam Gretton
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
13 years, 7 months
Strange nisMapEntry
by David LEROUX
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
13 years, 7 months
OpenLDAP 2.4 replicated to 2.3?
by Jakov Sosic
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/ |
13 years, 7 months
(no subject)
by Mark Beavis
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.
13 years, 7 months
slapd dying, what next?
by Bryan J. Maupin
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!
13 years, 7 months
accesslog overlay - filter by ip addresses (advise)
by Aravind Gottipati
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.
13 years, 7 months
LDAP and DNS-SRV: questions
by Keutel, Jochen
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.
13 years, 7 months
LDAP w/mysql as backend
by Radosław Antoniuk
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
13 years, 7 months
nssov overlay and hostservice
by ben thielsen
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
13 years, 7 months
Re: nssov overlay and hostservice
by ben thielsen
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.
13 years, 7 months
