Ineffective pam_authz_search filter

[Craig White]

No problem logging into server though the filter in nslcd.conf should block access (according to man page)

/etc/nslcd.conf (comments & blank lines removed)
----------------------
uid nslcd
gid nslcd
uri ldap://raid3.ttinet
base dc=ttinet,dc=local
rootpwmoddn cn=admin,dc=ttinet,dc=local
ssl start_tls
tls_reqcert demand
tls_cacertfile /etc/ssl/nxpc/cacert.pem
tls_cert /etc/ssl/nxpc/ldap.pem
tls_key /etc/ssl/nxpc/ldap.key
pam_authz_search (&(objectClass=posixAccount)(uid=$username)(|(host=$hostname)(host=$fqdn)(host=\\*)))

root@nxpc:~# /etc/init.d/nslcd restart
 * Restarting LDAP connection daemon nslcd [ OK ]
root@nxpc:~# /etc/init.d/nscd restart
 * Restarting Name Service Cache Daemon nscd [ OK ]

# /etc/init.d/nslcd status
 * nslcd running (pid 4643)

# ldapsearch -x '(uid=cwhite)' host
# extended LDIF
#
# LDAPv3
# base <dc=ttinet,dc=local> (default) with scope subtree
# filter: (uid=cwhite)
# requesting: host
#

# cwhite, people, ttinet.local
dn: uid=cwhite,ou=people,dc=ttinet,dc=local
host: equinox.ttinet
... snipped ...
# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

root@nxpc:~# ldapsearch -x '(uid=cwhite)' host | grep nxpc
root@nxpc:~#

Thus 'host' (neither hostname nor fqdn) cannot be found in ldap. Still have no problem logging in to nxpc

[Craig White (craig-white)]

duh - this info probably would be useful

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS"

root@nxpc:~# dpkg -l libnss-ldapd libpam-ldapd nslcd
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-===========================================-===========================================-======================================================================================================
ii libnss-ldapd 0.8.4 NSS module for using LDAP as a naming service
ii libpam-ldapd 0.8.4 PAM module for using LDAP as an authentication service
ii nslcd 0.8.4 Daemon for NSS and PAM lookups using LDAP

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Arthur de Jong (adejong)]

Can you include the contents of your /etc/pam.d/common-account file?

Also, does
  getent shadow yourusername
output any information?

Lastly, it would be really helpful to have the output of nslcd -d while you try a login.

Thanks.

[Craig White (craig-white)]

# getent shadow cwhite
cwhite:*:15245::::::0

# cat /etc/pam.d/common-account
#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
#

# here are the per-package modules (the "Primary" block)
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

# /etc/init.d/nslcd stop
 * Stopping LDAP connection daemon nslcd [ OK ]

FINALLY, after shutting down nslcd daemon...

root@nxpc:~# nslcd -d
nslcd: DEBUG: add_uri(ldap://raid3.ttinet)
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,2)
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_CACERTFILE,"/etc/ssl/nxpc/cacert.pem")
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_CERTFILE,"/etc/ssl/nxpc/ldap.pem")
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_KEYFILE,"/etc/ssl/nxpc/ldap.key")
nslcd: version 0.8.4 starting
nslcd: DEBUG: unlink() of /var/run/nslcd/socket failed (ignored): No such file or directory
nslcd: DEBUG: setgroups(0,NULL) done
nslcd: DEBUG: setgid(137) done
nslcd: DEBUG: setuid(125) done
nslcd: accepting connections
nslcd: [8b4567] DEBUG: connection from pid=20642 uid=0 gid=0
nslcd: [8b4567] <sess_c="cwhite"> DEBUG: nslcd_pam_sess_c("cwhite","sshd",12345)
nslcd: [7b23c6] DEBUG: connection from pid=22634 uid=0 gid=0
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: myldap_search(base="dc=ttinet,dc=local", filter="(&(objectClass=ipHost)(ipHostNumber=10.x.x.x))")
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_initialize(ldap://raid3.ttinet)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_rebind_proc()
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [7b23c6] <host=10.x.x.x> DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
nslcd: [7b23c6] <ho...

[Arthur de Jong (adejong)]

On Tue, 2012-05-01 at 19:57 +0000, Craig White wrote:
> # getent shadow cwhite
> cwhite:*:15245::::::0
>
> # cat /etc/pam.d/common-account
[...]
> account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
> account [success=1 default=ignore] pam_ldap.so

This is the pam config from libpam-ldap, not libpam-ldapd (at least not
0.8.4). If you have ldap as primary you need to disable shadow lookups
to ldap in /etc/nsswitch.conf.

I can't find an upgrade scenario that would leave your config like this.
Did you have libpam-ldap installed before? Can you check if
dpkg-reconfig libpam-ldapd changes /etc/pam.d/common-account and what
the contents of /usr/share/pam-configs/ldap is?

> root@nxpc:~# nslcd -d
> nslcd: accepting connections
> nslcd: [8b4567] DEBUG: connection from pid=20642 uid=0 gid=0
> nslcd: [8b4567] <sess_c="cwhite"> DEBUG: nslcd_pam_sess_c("cwhite","sshd",12345)
> nslcd: [7b23c6] DEBUG: connection from pid=22634 uid=0 gid=0
> nslcd: [7b23c6] <host=10.x.x.x> DEBUG: myldap_search(base="dc=ttinet,dc=local", filter="(&(objectClass=ipHost)(ipHostNumber=10.x.x.x))")
> nslcd: [3c9869] DEBUG: connection from pid=22634 uid=0 gid=0
> nslcd: [3c9869] <shadow="cwhite"> DEBUG: myldap_search(base="dc=ttinet,dc=local", filter="(&(objectClass=shadowAccount)(uid=cwhite))")
> nslcd: [334873] DEBUG: connection from pid=22634 uid=0 gid=0
> nslcd: [334873] <sess_o="cwhite"> DEBUG: nslcd_pam_sess_o("cwhite","sshd","ssh","10.x.x.x","")
>
> the only ip address it seemed to log was the origination ip address (my
> workstation) which I replaced with 10.x.x.x

The host=10.x.x.x lookup is just the reverse hostname lookup that sshd
does on every connection (it doesn't have anything to do with
pam_authz_search). sshd doesn't ask for authentication (I'm assuming you
do key-based authentication here) and skips authorisation (account)
altogether.

If changing /etc/nsswitch.conf or fixing your PAM stack doesn't help,
can you send output of nslcd -d without nscd (or unscd) running?

--
-- arthur - <email address hidden> - http://people.debian.org/~adejong --

[Craig White (craig-white)]

yes, was upgrade from libpam-ldap and probably made even more confusing because I deploy using puppet (which is currently not running on this client so it doesn't much with all the manual changes that I've been making to this test server). Thus nsswitch.conf, ldap.conf (both padl & openldap files), pam.d/common-password, pam.d/common-session are all deployed by puppet. /etc/pam.d/common-account is not however so that was obviously put there at the original install of 10.04 & pam-ldap. It is certain that I am not running things like dpkg-reconfigure libpam-ldap(d) nor pam-auth-update as I have been asserting the contents of pam.d/common-* via puppet

clearly this fixed it as after running dpkg-reconfigure libpam-ldapd I was indeed 'blocked' from access (and yes, it was with a pre-shared key).

Then after adding the hostname back into my LDAP profile, I was indeed allowed to access so it would appear that this is workable (though I will have to sort through pam.d/common-* to see what changes as I did have some customizations.

I didn't change nsswitch to remove ldap from shadow and it didn't seem to matter and I'm unclear what the difference is either way.

Thanks - I suppose you can close this as notabug but rather excessive customization interference by end user

[Arthur de Jong (adejong)]

Sadly, I have no idea how to close bugs on Launchpad but I'm glad it's fixed.

In case you're interested if shadow information is exposed pam_unix will check that information as well. Since 0.8.4 nslcd will ensure that correct data is returned to pam_unix whether shadow information is exposed or not. Also, since 0.8.3 nslcd will check the shadow properties if they are present in LDAP even if shadow information isn't exposed through nsswitch.