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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
