Very clever. That would not prevent local logins should one if my users manage to get into our DC. Not going to happen but just something I thought about. pam_groupdn would not let me authorize a single user to a single host if needed either; example: I need to allow a single developer access to a single machine in the group allocated for production hosts. That developer is already in the "dev" group which has access to the development hosts but is not in the "prod" group that has access to the production hosts. If I add the developer to the prod group he will now have access to all of the production hosts. What would you do in that case? Thank you in advance for your input. On May 11, 2010, at 2:16 PM, Edward Capriolo wrote: > There are other options... > > 3) > ssh logingroup. Create supplementary posix groups, assign users to > those groups, tell the ssh server only to allow those groups. > > pam_filter <filter> > Specifies a filter to use when retrieving user > information. The > user entry must match the attribute value > assertion of > (pam_login_attribute=login_name) as well as any filter > specified > here. There is no default for this option. > > pam_groupdn <groupdn> > Specifies the distinguished name of a group to which a > user must > belong for logon authorization to succeed. > pam_member_attribute > <attribute> Specifies the attribute to use when > testing a user?s > membership of a group specified in the pam_groupdn > option. > > I used pam_groupdn. Very effective. I had a default login group > that my kickstart creates. Then cluster by cluster i could create > other objects for specific login groups > > > > 2010/5/11 Brandon Price <bprice at wimba.com> > I have found 2 methods for allowing individual users, or groups > access to certain hosts via the directory server. (document link) > > 1. the host attribute > setup: > on server: the host attribute can be defined after adding a user, it > must list each host by fqdn that the user has access to > on client: configure to check for the host attribute in the ldap.conf > > pros: > +simple > cons: > -does not scale, if we add a host we then have to go and add that > host to each allowed user, management would be time consuming as > users, or hosts grow > > > 2. define groups of users, and systems in directory server by using > nisNetgroupTriple attribute > setup: > on server: definition of the host, and user groups in the ldap > server via nisNetgroupTriple > on client: configure pam in /etc/pam/system-auth to check if user > belongs to approved user group & system belongs to approved system > group > on client: configure pam_group module in /etc/security/group.conf > > pros: > +scales > cons: > -not as simple, uses an old beast (NIS) > -NIS adds an additional layer of complexity and points of failure > -doesn't allow me to grant a single user auth on a single system > (if even temporarily) > > > Is there a third better option? Any suggestions or links to > documentation would be highly appreciated. Thank you for your time. > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100511/1bdb73bf/attachment.html
