# cannot su as root after configuring for openldap

## bernieb

I have recently configured a box to authenticate through openldap for user logins.

It was working fine before the configuration, and afterwards I was able to login to it and even have home directories created automatically if the user logged in to the machine for the first time.

However, I have recently noticed that I can not 'su' as root, even as a member of the wheel group.

Here's output of 'groups':

 *Quote:*   

> 
> 
> wheel cron audio cdrom games cdrw users portage plugdev Domain Admins vmware
> 
> 

 

When I try to 'su' in,  I get this error message:

 *Quote:*   

> 
> 
> su: Permission denied
> 
> Sorry.
> ...

 

Output of messages log file when this occurs:

 *Quote:*   

> 
> 
> Jun 21 08:00:36 venice su[23583]: pam_authenticate: Permission denied
> 
> Jun 21 08:00:36 venice su[23583]: FAILED su for root by bernie
> ...

 

I can login as root just fine, from both local console and remotely via ssh.

Here's my pam.d/system-auth file (the only pam config I changed):

```

#%PAM-1.0

auth       required     pam_env.so

auth       sufficient   pam_unix.so likeauth nullok

auth       sufficient   pam_ldap.so use_first_pass

auth       required     pam_deny.so

account    required     pam_unix.so

account    sufficient   pam_ldap.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3

password   sufficient   pam_unix.so nullok md5 shadow use_authtok

password   sufficient   pam_ldap.so use_authtok

password   required     pam_deny.so

session    required     pam_limits.so

session    required     pam_unix.so

session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0022

session    optional     pam_ldap.so

```

My nsswitch.conf file entries for passwd, shadow, and group:

```

passwd:      compat db ldap

shadow:      compat db ldap

group:       compat db ldap

```

I can not think of anything else as far as configuration is concerned.  If I missed anything, please suggest what I should check/modify.

Any assistance with this will be appreciated, thank you in advance.

----------

## smerf

show me your /etc/pam.d/su

----------

## bernieb

Hey, sorry about the long time for the reply, but here's the pam configuration for su:

```

auth       sufficient   pam_rootok.so

auth       required     pam_wheel.so use_uid

auth       include              system-auth

account    include              system-auth

password   include              system-auth

session    include              system-auth

session    required     pam_env.so

session    optional             pam_xauth.so

```

Here's the config for system-auth, which has been working fine for logins, ssh, etc.

```

auth       required     pam_env.so

auth       sufficient   pam_unix.so likeauth nullok

auth       sufficient   pam_ldap.so use_first_pass

auth       required     pam_deny.so

account    required     pam_unix.so

account    sufficient   pam_ldap.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3

password   sufficient   pam_unix.so nullok md5 shadow use_authtok

password   sufficient   pam_ldap.so use_authtok

password   required     pam_deny.so

session    required     pam_limits.so

session    required     pam_unix.so

session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0022

session    optional     pam_ldap.so

```

On a slightly related note, I've also noticed log timeouts-- even for root-- if we lose dns or otherwise loose connection to the ldap server.  Is there a way I can configure pam to prefer a local machine over ldap?  In other words, is it possible to have pam not try to query the ldap server is the user tries to login using an account that is configured on the machine locally (such as root)?

Thanks for your assistance.

----------

## smerf

Your PAM configuration is sane.

Are you using sys-libs/nss-db?.  If not, remove 'db' from nsswitch.conf.

Show me entire /etc/nsswitch.conf (especially hosts entry).

Do you have root in LDAP? (post 'getent passwd root' output)

Service lookup process is defined in nsswitch.conf. Read 'man nsswitch.conf' for more info.

You can tune LDAP connection properties inside /etc/ldap.conf

(timelimit, bind_timelimit, bind_policy, nss_connect_policy, idle_timelimit)

----------

## depontius

 *bernieb wrote:*   

> I have recently configured a box to authenticate through openldap for user logins.

 

I'd be curious to hear more about how you did this. 

There used to be a Gentoo HowTo for LDAP authentication, but it's been deprecated. Every now and then I fool with LDAP authentication for my home network, but never really have the time to finish before the real world demands my time. Last time the newest release of OpenLDAP wouldn't even start, but I hadn't gotten around to deleting the old database, or trying to migrate it.

What did you use for documentation?

What version of OpenLDAP are you using? (x86, ~x86, or other?)

Are you using OpenLDAP?

Are you also using OpenSSL, SASL, etc?

I'd be interested in hearing how you got this far, no doubt others would, too.

Thanks.

----------

## sgao

I saw the same problem after enabling "ssl start_tls" in /etc/ldap.conf. Though tls part works fine, su no longer works. 

There seems to be some problem related to pam_ldap or pam su module. Copying similar config files (su, system-auth pam modules) does not solve the problem.

Simon

----------

## smerf

depontius: there still is Gentoo OpenLDAP howto, http://gentoo-wiki.com/HOWTO_LDAPv3

sgao: start slapd with -d 255 and watch output while trying to su

----------

## sgao

I have filed a bug, [Bug 186026] sys-auth/pam_ldap-183 tls setup breaks su.

In my case, su command does not fail until either SSL or TLS is enabled in /etc/ldap.conf. Even after enabling SSL/TLS, pam_ldap and nss_ldap still works on the client, ie. user can log into the client remotely via ssh.  But root user can't su to a user nor a user su to root.

For the time being, Gentoo client must use unencrypted connections to ldap server (port 389, which means password is passed cleartext across network) to keep su working. This is very undesirable.

If I set OpenLDAP server to reject unencrypted requests, then the Gentoo clients without TLS/SSL enabled stopped working. 

Simon

----------

## sgao

Here is what being logged:

```
Jul 21 13:26:57 desktop1 su[14570]: Successful su for joe by root

Jul 21 13:26:57 desktop1 su[14570]: + tty1 root:joe

Jul 21 13:26:57 desktop1 su(pam_unix)[14570]: session opened for user joe by (uid=0)

Jul 21 13:26:57 desktop1 su(pam_unix)[14570]: session closed for user joe

Jul 21 13:27:33 desktop1 su[14574]: Successful su for joe by root

Jul 21 13:27:33 desktop1 su[14574]: + tty1 root:joe

Jul 21 13:27:33 desktop1 su(pam_unix)[14574]: session opened for user joe by (uid=0)

Jul 21 13:27:33 desktop1 su(pam_unix)[14574]: session closed for user joe

Jul 21 13:40:48 desktop1 su[14622]: Successful su for joe by root

Jul 21 13:40:48 desktop1 su[14622]: + tty1 root:joe

Jul 21 13:40:48 desktop1 su(pam_unix)[14622]: session opened for user joe by (uid=0)

Jul 21 13:40:48 desktop1 su(pam_unix)[14622]: session closed for user joe

```

Simon

----------

## smerf

for me su (su - user as root and su - as user@wheel) works fine (both SSL and TLS) with openldap-2.3.30-r2 (-sasl)

----------

## sgao

Have you tried with OpenLDAP-2.3.36, pam-_ldap-183 and nss_ldap-253?

Simon

----------

## depontius

 *smerf wrote:*   

> depontius: there still is Gentoo OpenLDAP howto, http://gentoo-wiki.com/HOWTO_LDAPv3
> 
> sgao: start slapd with -d 255 and watch output while trying to su

 

Thanks for pointing that out. When I get some more spare  minutes to rub together I'll give it a go.

One question(s) about it... Typically LDAPv3 seems to suggest integrated LDAP/Kerberos, and that HowTo does include Kerberos support in the schema. But the Kerberos itself is left as a ToDo. Is this actually done, and is the documentation a ToDo, or is the actual work the ToDo? Which Kerberos, MIT, Heimdal, or either? If Heimdal, does Kerberos store its keys in LDAP? (On MIT Kerberos V 1.6, it will gain the ability to store keys in LDAP, as well.)

----------

## sgao

After rebuilding system with 2007.0, the problem I had is gone. It must be some issue with build options. Now su works fine under TLS/SSL with Openldap-2.3.35 and latest pam_ldap and nss_ldap.

Simon

----------

