LDAP and AD connection problem with hardy

[Marco Schmidt]

Binary package hint: libnss-ldap

Hello,

I have a strange problem after upgrading from gutsy to hardy. The user identification via LDAP Microsoft AD does not work anymore.

The /etc/ldap.conf and /etc/nsswitch.conf seems to be okay. "getent password" and "getent group" delivers the info from AD I expect.

"ssh" and "id" hangs!

If I set "bind_policy soft" in /etc/ldap.conf, I get the following error:

#id user
id: result.c:112: ldap_result: Assertion `ld != ((void *)0)' failed.
uid=10039(user) gid=10147(group)Aborted

and in /var/log/auth.log I found the following:
Apr 28 16:04:36 hostname id: nss_ldap: could not search LDAP server - Server is unavailable

If I delete the "ldap" in /etc/nsswitch.conf from "group", no hangers or errors anymore, but I can only see the local groups.

Exactly the same config under gutsy (7.10) works great.

The problem occurs on a hardy upgrade and on a hardy fresh installation.

I compiled and installed openldap 2.4.8 and nss_ldap 260 on my own (with the options I founds in the Ubuntu-libnss-ldap-source package). This works as expected.

Thread in Ubuntu Forum:
http://ubuntuforums.org/showthread.php?t=772398

# lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

# apt-cache policy libnss-ldap
libnss-ldap:
  Installed: 258-1ubuntu3
  Candidate: 258-1ubuntu3
  Version table:
 *** 258-1ubuntu3 0
        500 http://mirror.switch.ch hardy/main Packages
        100 /var/lib/dpkg/status

[Jelmer Jaarsma (jelmer-jaarsma)]

I had similar problems which seemed to be caused by 1 of the groups in AD not having a GID assigned.
Try assigning a GID to every group the user is a member of, don't forget nested groups.

[sopsaare (sopsaare)]

I confirm this one.

The problem is that even thought there is this line in the ldap.conf
"nss_map_objectclass posixGroup group"

It will still recognise the AD groups which are not POSIX one's. This will lead it to error with the GID's.
I made my work-around with
"nss_base_group ou=Linux,dc=my,dc=domain,dc=com?one"

and placed all the POSIX groups under the OU named Linux at the root of our Domain.

Another work around is to give all the groups Unix attributes, but in our domain it was impossible because we are a part of a whole lot of bigger forest and we have some cross grouping in the forest.

[Marco Schmidt (kunzol)]

Great, it woks!

But I did it in a different way.

I have the SFU installed on my AD and this includes the attribute "msSFU30GidNumber", which I use for the UNIX GID. Now I set up a "nss_base_group" which filters out all groups without this attribute.

nss_base_group ou=OU_Groups,dc=my,dc=domain,dc=com?sub?&(msSFU30GidNumber=*)

Thanks again for the hint.

[Joel Cunningham (uber-leoj)]

I have encountered this bug as well.

First I ran into this bug on Hardy, which I built libnss-ldap from source to solve it. Now I'm facing the same problem on Intrepid, so it seems like something is up.

Looking at kunzol's fix, I am mapping the msSFU30GidNumber to gid as well and making a filter for the groups worked on Intrepid, but not Hardy.

[Marco Schmidt (kunzol)]

Intrepid has a different nss-ldap configuration than hardy.

There is a deamon nslcd in the package libnss-ldapd, which has its own config file /etc/nss-ldapd.conf with a different syntax (not compatible to Hardy's /etc/ldap.conf).

I use the following filter statement for the groups. I am not an ldap expert, so maybe there is a better one.

filter group (&(objectClass=group)(msSFU30GidNumber=*))

[Joel Cunningham (uber-leoj)]

Hmm, I don't have that daemon running or installed (no startup script in /etc/init.d and no /etc/nss-ldap.conf).

leoj@dart:~$ apt-cache policy libnss-ldap
libnss-ldap:
  Installed: 260-1ubuntu2
  Candidate: 260-1ubuntu2
  Version table:
 *** 260-1ubuntu2 0
        500 http://spout.ussg.indiana.edu intrepid/main Packages
        100 /var/lib/dpkg/status

[Etienne Goyer (etienne-goyer-outlands)]

slithy, kunzol above is wrong: nss-ldapd is indeed available in 8.04, but it is not default and does not supersede libnss-ldap. It is a completely different package than libnss-ldap (although it fill the same use-case). I understand this bug concern libnss-ldap, not libnss-ldap*d*.

[Joel Cunningham (uber-leoj)]

Oh, I didn't realize he was talking about a different package.

[Marco Schmidt (kunzol)]

Indeed, while writing the post, I didn't realize that these are different packages.

libnss-ldap - NSS module for using LDAP as a naming service
libnss-ldapd - NSS module for using LDAP as a naming service

They look very similar, and probably I mixed up the two packages while installing ldap support.

Sorry.