# [SOLVED] Unable to Retrieve Account Info with SASL/PAM/LDAP

## dresdn

Hello.

The current setup I have is using nss_ldap, kerberos5, sasl, and pam_krb5 for user authentication.  The problem I am having is with pam_krb5 and the account management portion.  Basically, if I try to ssh to the box with an ldap user, I get the infamous "Authentication service cannot retrieve authentication info."

I'm also using the pamtester (since it's a lot easier to debug):

```

pamtester login mbydalek acct_mgmt

pamtester: Authentication service cannot retrieve authentication info.

```

Since I'm using SASL, I have "{SASL}user@REALM.COM" for my userPassword attribute for my LDAP entry.  What's strange is that if I change that entry to {CRYPT}* (anything), using my Kerberos password works just fine.

The other odd thing is that for some client machines, we're using Red Hat, and it works perfectly.  Copying over the /etc/ldap.conf, /etc/nsswitch.conf, /etc/ssh/sshd_config, /etc/pam.d/{sshd, system-auth}, seems to not change anything on the Gentoo server.

What it seems like is that SSH on the Gentoo box is looking for the {CRYPT} password, and when it's not set, it bombs.

Here's the slapd.log for a user with a {CRYPT} userPassword, and one without - the second one doesn't do a follow up query, hence the failure:

```

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 fd=25 ACCEPT from IP=172.20.0.2:40114 (IP=0.0.0.0:389)

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 op=0 BIND dn="" method=128

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 op=0 RESULT tag=97 err=0 text=

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 op=1 SRCH base="dc=contentconnections,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=rwallace))"

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Nov 10 11:38:32 fileserver slapd[6215]: conn=1638 fd=25 closed

Nov 10 11:38:33 fileserver slapd[6215]: conn=777 op=2 SRCH base="dc=contentconnections,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1014))"

Nov 10 11:38:33 fileserver slapd[6215]: conn=777 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

Nov 10 11:38:33 fileserver slapd[6215]: conn=777 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

fileserver ~ # tail -fn0 /var/log/slapd.log

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 fd=26 ACCEPT from IP=172.20.0.2:40115 (IP=0.0.0.0:389)

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 op=0 BIND dn="" method=128

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 op=0 RESULT tag=97 err=0 text=

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 op=1 SRCH base="dc=contentconnections,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=mbydalek))"

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Nov 10 11:38:56 fileserver slapd[6215]: conn=1641 fd=26 closed

```

Does anyone have any ideas what I may be missing here?  It has to be a pam issue, but I've tried pam_krb5 1.9, 2.0, and the current stable 20030601-r1, all without success.

Thanks.

-MikeLast edited by dresdn on Fri Nov 11, 2005 8:45 pm; edited 1 time in total

----------

## dresdn

Well, it turns out the problem is with pam_unix. 

Currently, in my pam.d/system-auth, I have the following lines:

 *Quote:*   

> 
> 
> account    required     pam_unix.so
> 
> account    [default=bad success=ok user_unknown=ignore] pam_krb5.so
> ...

 

For some reason, I had to change it to this:

 *Quote:*   

> 
> 
> account    required     pam_unix.so broken_shadow
> 
> account    [default=bad success=ok user_unknown=ignore] pam_krb5.so
> ...

 

This then allowed account management for virtual users and fixed the errors.

I'm not 100% sure *why* this works, as I thought I was telling it to ignore shadows.

-Mike

----------

