We added an entitlement for all those users that need access to certain systems, but should not be able to access other systems ... We use the eduPerson schema, but I'll just give the basics ... On the users ldap record, add the entitlement hostEntitlement: hostname.company.com This is a multi-valued attribute, so a person can have a host entitlement to multiple systems. In your ldap.conf, add the entitlement lookup to your filter .. pam_filter &(objectclass=posixAccount)(hostEntitlement=hostname.company.com) This allows to to control who has access to the systems directly from ldap. Add the entitlement and they have access. Remove the entitlement and their access is revoked. My $0.02 CDN Terry On 10-02-02 01:55 PM, Morris, Patrick wrote: > Sean Carolan wrote: >>> You can either continue as usual with an authorized_keys file in their >>> home directories, or look at the LPK patch available for OpenSSH that >>> allows storing public keys in LDAP. >>> >>> Having the users in LDAP has absolutely no effect on how key-based >>> logins work with SSH, but it does open up some other options. >>> >> >> So the easiest route to take might be to dis-allow ssh logins for >> everyone except my few authorized users via the /etc/security/access >> file? And then to allow exceptions on a case by case basis using this >> file as well? >> > > /etc/security/access is definitely an option, as would be putting them > all in a group and using "AllowGroups [your group]" in the sshd_config, > among other possibilities. > > Doing something group-based is typically pretty easy to manage. > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- Terry Soucy, Systems Analyst Integrated Technology Services University of New Brunswick, Fredericton Campus http://www.unbf.ca/its Voice: 506.447.3018 Fax: 506.453.3590 E-mail: tsoucy at unb.ca ** ITS is a scent-reduced workplace - www.unbf.ca/its/policies **
