openssh and pam_ldap

[Michael Thomas]

Hi Jon,

We have a relatively small number of users (~15) and a medium number of 
hosts that need this access control (~60), so I figured maintaining the 
user <-> host mappings manually would not be too difficult.  But the use 
of netgroups seems like it would make things even simpler.  In addition 
to some standard netgroups (developers, admins), I can also define a 
separate netgroup for certain individual hosts, and maintain a list of 
additional users who are allowed to access that host via the netgroup 
defined in ldap.

Thanks for the pointer,

--Mike

Jon Miller wrote:
> At my last workplace, we used the host attribute to control access as
> well. Long story short, we saw the same problem you are describing but
> not before I left to take a new job at another company.
> 
> At my current job, I'm actually helping to roll out an LDAP
> implementation. We are using the pam_access module to control access
> to machines. What you typically do, with this module, is setup a
> netgroup in LDAP and then grant the netgroup access in your
> access.conf file which pam_acess uses. It is a more elegant solution,
> IMO.
> 
> Let's say you setup a new database server and need to permit all of
> your DBAs access. With the host attribute method, you would update
> every DBA's list of hosts. Very manual procedure which gets old quick.
> By using netgroups, you simply state that the dba's netgroup is
> allowed to log into that machine. This method has similar benefits for
> when you hire a new DBA.
> 
> -- Jon Miller
> 
> A bit off topic, but do you delegate permissions via sudo? If so, did
> you know you can specify a group of people via a netgroup? Combine
> this style of delegation with your host control and then you can
> controlling host access as well as sudo permissions by simply adding /
> removing people from a netgroup.
> 
> On 9/11/07, Michael Thomas <thomas at hep.caltech.edu> wrote:
>> I've been fighting with this problem for a couple of days now and
>> thought it was time to appeal to the experts...
>>
>> I'm using RHEL4 with pam_ldap to authenticate users who do not have
>> local accounts.  This works.  I'm also using pam_check_host_attr in
>> ldap.conf to limit who is allowed to log into a host based on their host
>> attribute in ldap.  This also works, mostly.
>>
>> When users log in using their ldap password, that is, when ssh prompts
>> them for their password, the host-based access control provided by
>> pam_check_host_attr works.  Users who don't have the proper ldap host
>> attribute are denied access.
>>
>> But as soon as a user puts a public key in ~/.ssh/authorized_keys,
>> pam_check_host_attr stops working.  Regardless of what is in their ldap
>> host attribute, openssh lets them in.  I want to allow (and encourage)
>> the use of authorized_keys files for logging into the machines, but I
>> also want to retain control of which machines they can log into by using
>> the host attribute in their ldap entry.
>>
>> I've tried changing ChallengeResponseAuthentication to 'yes', but then
>> users are always prompted for their password.  I've also tried adding
>> the 'debug' option to pam_ldap.so and directing all *.debug messages in
>> syslog to /var/log/debug, but I don't see anything appear from pam_ldap.
>>
>> Is it possible to allow ssh key-based authentication, but still prohibit
>> logins based on the ldap host attribute?
>>
>> --Mike
>>
>> sshd_config contains:
>>
>> Protocol 2
>> SyslogFacility AUTHPRIV
>> ChallengeResponseAuthentication no
>> GSSAPIAuthentication yes
>> GSSAPICleanupCredentials yes
>> UsePAM yes
>> X11Forwarding yes
>> Subsystem       sftp    /usr/libexec/openssh/sftp-server
>>
>> /etc/pam.d/system-auth contains:
>>
>> #%PAM-1.0
>> # This file is auto-generated.
>> # User changes will be destroyed the next time authconfig is run.
>> auth        required      /lib/security/$ISA/pam_env.so
>> auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
>> auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
>> auth        required      /lib/security/$ISA/pam_deny.so
>>
>> account     required      /lib/security/$ISA/pam_unix.so broken_shadow
>> account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100
>> quiet
>> account     [default=bad success=ok user_unknown=ignore]
>> /lib/security/$ISA/pam_ldap.so
>> account     required      /lib/security/$ISA/pam_permit.so
>>
>> password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
>> password    sufficient    /lib/security/$ISA/pam_unix.so nullok
>> use_authtok md5 shadow
>> password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
>> password    required      /lib/security/$ISA/pam_deny.so
>>
>> session     required      /lib/security/$ISA/pam_mkhomedir.so
>> skel=/etc/skel/ umask=0022
>> session     required      /lib/security/$ISA/pam_limits.so
>> session     required      /lib/security/$ISA/pam_unix.so
>> session     optional      /lib/security/$ISA/pam_ldap.so
>>
>> _______________________________________________
>> Pam-list mailing list
>> Pam-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pam-list
>>