11.0 - ldap authentication broken (with AD anyway)

English Network/Internet
#1

Hey everyone,

Try to bear with me, this is an odd/complex issue. If this isnt the correct area for this post, please move it :slight_smile:

Upgraded my workstation here @ the office to 11.0 from 10.3. I authenticate against Active Directory, and that was working just dandy before the upgrade. I ended up doing a clean re-install. Some strange issues are afoot utilizing the same packages and configuration as before.

FYI, I disabled the firewall just incase that was causing issues. I also disabled nscd to see if it was the culprit, no dice.

I’m able to get a kerberos ticket just fine, but nss_ldap appears to be having issues. I’m able to getent passwd just fine, and it lists all ldap users.


dolemite:/export/home # getent passwd |grep ashinn
ashinn:*:10020:3000:Andrew Shinn:/home/ashinn:/bin/bash

Filesystem even appears to know the UID/GID correctly! IE:


dolemite:/export/home # ls -la
total 4
drwxr-xr-x  3 root   root            19 Jun 19 16:45 .
drwxr-xr-x  3 root   root            17 Jun 19 16:45 ..
drwx------ 40 ashinn UnixAdmins_GG 4096 Jun 19 16:45 ashinn

What’s not working is nss authentication, or utils like id. Here is a snip from strace of me trying to use id:


stat64("/etc/ldap.conf", {st_mode=S_IFREG|0600, st_size=669, ...}) = 0
geteuid32()                             = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(29262), sin_addr=inet_addr("10.6.66.118")}, [16]) = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("10.10.10.1")}, [16]) = 0
poll(

And it just hangs there forever… that IP is correct for the domain controller.

My /var/log/messages shows these-


un 19 17:09:25 dolemite id: nss_ldap: reconnected to LDAP server ldap://removed after 1 attempt
Jun 19 17:18:12 dolemite id: nss_ldap: reconnected to LDAP server ldap://removed after 1 attempt

Here are my configuration files, with edits for obvious reasons:


**ldap.conf:**
base    ou=prod,dc=cd,dc=ent,dc=corp
uri     removed
binddn  removed
bindpw  removed
scope   sub
ssl     no
bind_policy soft
pam_filter      objectClass=User
nss_base_passwd OU=Standard,OU=Accounts,OU=PROD,DC=cd,DC=ent,DC=corp?sub
nss_base_shadow OU=Standard,OU=Accounts,OU=PROD,DC=cd,DC=ent,DC=corp?sub
nss_base_group  OU=Security,OU=Groups,OU=PROD,DC=cd,DC=ent,DC=corp?sub
nss_map_objectclass     posixAccount user
nss_map_objectclass     shadowAccount user
nss_map_objectclass     posixGroup group
nss_map_attribute       gecos cn
nss_map_attribute       homeDirectory unixHomeDirectory
nss_map_attribute       uniqueMember member

**common-auth:**
auth    required        pam_env.so
auth    sufficient      pam_unix2.so
auth    sufficient      pam_krb5.so
auth    required        pam_deny.so

**nsswitch.conf:**
passwd: files ldap
group:  files ldap

hosts:          files dns
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files

Any help or advice is appreciated! This is a total show stopper for me, I have to revert back to 10.3 if this isnt something “simple”.

Means I can’t upgrade any of our boxes to 11.0 either :frowning:

#2

On Thu, 2008-06-19 at 22:26 +0000, Gimpster wrote:
> Hey everyone,
>
> Try to bear with me, this is an odd/complex issue. If this isnt the
> correct area for this post, please move it :slight_smile:
>
> Upgraded my workstation here @ the office to 11.0 from 10.3. I
> authenticate against Active Directory, and that was working just dandy
> before the upgrade. I ended up doing a clean re-install. Some strange
> issues are afoot utilizing the same packages and configuration as
> before.
>
> FYI, I disabled the firewall just incase that was causing issues. I
> also disabled nscd to see if it was the culprit, no dice.
>
> I’m able to get a kerberos ticket just fine, but nss_ldap appears to be
> having issues. I’m able to getent passwd just fine, and it lists all
> ldap users.

This may not be the answer, but make sure to disable mdns with
mdns off
inside of /etc/host.conf

Of course, if you were having the above problem, I’d expect some
other things to not be working right either.

#3

Tried that, and no dice as you figured.

I’m reverting back to 10.3. I’ll look into posting this issue on the development mailing list or something … can’t believe that I’m the only poor sucker out here authenticating w/this method :slight_smile:

#4

Hi !
I have the same problem.

Trying configurations, I solve the problem mapping atributes. On the opensuse 11, we need uidNumber and gidNumber maps to work.

#============================================
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group

nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber XXXXXXX
nss_map_attribute gidNumber XXXXXXX
nss_map_attribute gecos cn
#============================================

but, what AD attributes map to uidnumber and gidNumber ??

thanks in advance, and sorry for my english ! :wink:

justo

#5

And be carefull !!

If you map uidnumber or gidnumber to non integer attributes, a “Segmentation fault” can be raised !! (nss bug !?!?)

thanks in advance and sorry for my english

justo

#6

Justo, sorry for a long reply. I kinda gave up checking my thread since people seem to be more interested in GNOME/other silly junk :slight_smile:

I’m sure you figured this all out now

Assuming you’re using Windows 2003 R2 as your directory, the standard uidNumber and gidNumber are what AD uses. When R2 was released, they went to standard RFC2307 attributes. The original Windows 2003 used the weird/oddball SFU (services for UNIX) attributes.

This is all set via the UNIX Attributes tab in user manager.

#7

justo_alonso, if you ever see this, THANK YOU.

The key to “fixing” the issue was:

nss_map_attribute uid sAMAccuontName

Sooooooooooooo game on! Glad to see a fix/workaround for this as I needed to start QA’ing 11.0 for production use.