Hi List,
Quick question (maybe not the right one for this list). Is there any alternative for netgroups in Linux? I mean netgroups are tightly bound to NIS which is insecure piece of crap so I wonder if there is any new alternative which should (can) be used in any new deployment.
Thanks! Ondrej
On Thu, Nov 08, 2012 at 10:41:28AM +0100, Ondrej Valousek wrote:
Hi List,
Quick question (maybe not the right one for this list). Is there any alternative for netgroups in Linux? I mean netgroups are tightly bound to NIS which is insecure piece of crap so I wonder if there is any new alternative which should (can) be used in any new deployment.
Thanks! Ondrej
HBAC is the best solution, I think.
Other than that, access control can be also set per service and per host in LDAP, see ldap_user_authorized_service or ldap_user_authorized_host.
On 11/08/2012 04:55 AM, Jakub Hrozek wrote:
On Thu, Nov 08, 2012 at 10:41:28AM +0100, Ondrej Valousek wrote:
Hi List,
Quick question (maybe not the right one for this list). Is there any alternative for netgroups in Linux? I mean netgroups are tightly bound to NIS which is insecure piece of crap so I wonder if there is any new alternative which should (can) be used in any new deployment.
Thanks! Ondrej
HBAC is the best solution, I think.
Other than that, access control can be also set per service and per host in LDAP, see ldap_user_authorized_service or ldap_user_authorized_host. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub jumped to conclusion that this is for access control but it might be better to ask: what is the use case?
IPA provides a host grouping mechanism but no software other than SSSD understands hosts and host groups yet. So what do you want to accomplish?
Netgroups can also come over LDAP, this is what IPA is capable of. You are not required to use NIS server and protocol for netgroups.
I would like to get a similar functionality as for netgroups - i.e. who can login where and from where using which mechanism. HBAC only offers possibility to control who can login where, I suppose, right?
If I wanted to also control the from where and which mechanism (i.e. ssh/telnet/nfs) then only netgroups will help me right?
Thanks, Ondrej
On 11/08/2012 10:05 PM, Dmitri Pal wrote:
Jakub jumped to conclusion that this is for access control but it might be better to ask: what is the use case?
IPA provides a host grouping mechanism but no software other than SSSD understands hosts and host groups yet. So what do you want to accomplish?
Netgroups can also come over LDAP, this is what IPA is capable of. You are not required to use NIS server and protocol for netgroups.
On Fri, Nov 09, 2012 at 10:56:21AM +0100, Ondrej Valousek wrote:
I would like to get a similar functionality as for netgroups - i.e. who can login where and from where using which mechanism. HBAC only offers possibility to control who can login where, I suppose, right?
If I wanted to also control the from where and which mechanism (i.e. ssh/telnet/nfs) then only netgroups will help me right?
HBAC also covers the mechanism (in HBAC it is called service). To alos get the 'from where' you have to set ipa_hbac_support_srchost in sssd.conf. Please note that determine the source host is not reliable and depends on the PAM clients (sshd, telnetd, nfsd...).
HTH
bye, Sumit
Thanks, Ondrej
On 11/08/2012 10:05 PM, Dmitri Pal wrote:
Jakub jumped to conclusion that this is for access control but it might be better to ask: what is the use case?
IPA provides a host grouping mechanism but no software other than SSSD understands hosts and host groups yet. So what do you want to accomplish?
Netgroups can also come over LDAP, this is what IPA is capable of. You are not required to use NIS server and protocol for netgroups.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri 09 Nov 2012 05:10:10 AM EST, Sumit Bose wrote:
On Fri, Nov 09, 2012 at 10:56:21AM +0100, Ondrej Valousek wrote:
I would like to get a similar functionality as for netgroups - i.e. who can login where and from where using which mechanism. HBAC only offers possibility to control who can login where, I suppose, right?
If I wanted to also control the from where and which mechanism (i.e. ssh/telnet/nfs) then only netgroups will help me right?
HBAC also covers the mechanism (in HBAC it is called service). To alos get the 'from where' you have to set ipa_hbac_support_srchost in sssd.conf. Please note that determine the source host is not reliable and depends on the PAM clients (sshd, telnetd, nfsd...).
I just want to note that source-host rules with netgroups are unreliable as well for the same reasons. PAM has no secure way of verifying that the rhost field is populated with accurate data and there is also no universal standard for what form the contents must take (DNS hostname vs IP address, etc.). Thus, it's never safe to rely on origin. That's the reason we stopped supporting this by default in SSSD.
On 11/09/2012 08:11 AM, Stephen Gallagher wrote:
On Fri 09 Nov 2012 05:10:10 AM EST, Sumit Bose wrote:
On Fri, Nov 09, 2012 at 10:56:21AM +0100, Ondrej Valousek wrote:
I would like to get a similar functionality as for netgroups - i.e. who can login where and from where using which mechanism. HBAC only offers possibility to control who can login where, I suppose, right?
If I wanted to also control the from where and which mechanism (i.e. ssh/telnet/nfs) then only netgroups will help me right?
HBAC also covers the mechanism (in HBAC it is called service). To alos get the 'from where' you have to set ipa_hbac_support_srchost in sssd.conf. Please note that determine the source host is not reliable and depends on the PAM clients (sshd, telnetd, nfsd...).
I just want to note that source-host rules with netgroups are unreliable as well for the same reasons. PAM has no secure way of verifying that the rhost field is populated with accurate data and there is also no universal standard for what form the contents must take (DNS hostname vs IP address, etc.). Thus, it's never safe to rely on origin. That's the reason we stopped supporting this by default in SSSD.
Yes exactly. We wanted to use the source host but it turned to be a nightmare. So you might be better off restricting access via firewall rules and allow ssh access only from a subset off systems. This is a much more reliable way of controlling the source of the connection.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org