Re: [389-users] Do we have any suggestions for host level access controls?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux