First notes, to be expanded later:

Using burton as the test case:  wbetts has an NIS account (with a local home directory on burton, though that's not relevant unless I'm overlooking something).

There are many users in NIS, take for instance:  wbetts, mpoat, trent, jeromel, lbland, alebedev

We want wbetts to be able to login to burton, but none of the other users in NIS should have access.

The local console case is important too, but at this hour I'm sticking with SSH to avoid getting in front of burton...


On burton, in /etc/group, add one line:

denied-users:x:500:wbetts,mpoat,trent,jeromel,lbland,alebedev

(The list of users is considerably longer than this - this is just an example.)


On burton, in /etc/security/access.conf, add the following:

+ : wbetts : ALL
- : (denied-users) : ALL

On burton, in /etc/pam.d/sshd, /etc/pam.d/login, and /etc/pam.d/gdm-password add:

account required pam_access.so nodefgroup

Now wbetts can login at the local text and GDM consoles and through ssh, but the other members of denied-users cannot.

(The idea/goal here is to have a single default denial rule in one place so we aren't just granting access to everybody everywhere, and to have exceptions (allowed logins) easily maintained and viewed over time - presumably some or all of the above would be managed through cfengine)


Things to test and questions:

1. What if X is running, but gdm is not the display manager?
2. Can the denied-users group be in NIS rather than a local group?  (a single NIS group would simplify things naturally)
3. not terribly important, but want to double check the behaviour in the case nodefgroup is not specified

Side note of tangential relevance, but  I don't want to forget it:

SKM will be fun with shared home directories beyond the OLP.  If for instance wbetts wants his home directory at burton to be over NFS from onlldap (just like the OLP), then the SKM associations "wbetts@burton.starp.bnl.gov" and "wbetts@onlldap.starp.bnl.gov" will clash.  Depending on SKM's behaviour/configuration (TBD), a couple things could happen, neither of which is good:

1. If one is revoked [granted], it will effectively revoke [grant] the other.  (I think the default SKM client behaviour will be this.)
    
2. If SKM is set to to be the exclusive controller of authorized_keys files, then SKM could ping-pong if the two associations have opposite settings, though presumably it would be in one state most of the time, only changing very briefly as SKM goes through the key updates.

Perhaps it is easiest to simply remove the wbetts@burton.starp.bnl.gov association in SKM to avoid the clash, but this will potentially make SKM more confusing for that poor wbetts guy, as well as destroy some of the "obviousness" within SKM of who has access to which hosts.