On Fri, 2012-10-26 at 11:54 +0200, Tomas Brandysky wrote: > On 10/26/2012 11:41 AM, Jakub Hrozek wrote: > > On Fri, Oct 26, 2012 at 11:10:45AM +0200, Tomas Brandysky wrote: > >>> You can also use a comma-separated list in the ldap_access_order > >>> parameter of sssd.conf and then define both service and host for a user. > >>> > >> > >> this is not a solution because defining service for user in LDAP means > >> to grant user access to this service not only on a particular server but > >> on all servers the same user can access too (for example because of some > >> other services). > >> > >> This is real scenario: > >> > >> - two servers both running openvpn and ssh services - both configured to > >> authenticate users against LDAP > >> > >> - I want user "one" to have access to: > >> - openvpn service on server1 > >> - ssh service on server2 > >> > >> > >> I'm not able to manage this with sssd even though I try it with comma- > >> separated list in the ldap_access_order parameter. I don't think this > >> scenario is so rare in other companies too. This is a quite common > >> practice in larger companies maintaining dozens of servers and services > >> to grant users access to specific services on specific servers only (as > >> we can do easily with pam_ldap). > >> > >> I will be very surprised if many other companies won't request this > >> feature being present in sssd if this is a new official way how to > >> handle LDAP authentication in RHEL 6. > >> > >> > >>> For a finer-grained access control, you probably want IPA's HBAC as > >>> Sumit said. > >> > >> I got a look to at IPA's HBAC and it seems to be overkill to me. I can > >> imagine such a solution in very large enterprises where kinda more > >> sophisticated integrated security information management solution might > >> come in handy. > >> > >> I think our company(as many others) will stick with "old" pam_ldap > >> solution which was there working since RHEL4. At least until this > >> feature is integrated to sssd. > >> > >> Tomas > > > > I'm sorry the current means of access control do not work for you. > > > > Unfortunately we have finite time and resources and the next 1.10 release > > is already getting quite big. I would suggest raising a feature request > > via the usual RHEL channels to bump the priority up. > > As we have valid RHEL support paid I will try to file such a request. > > > > > Or, if you'd be willing to work with us and contribute a patch, I'll be > > glad to help with getting you up to speed and getting the patch > > accepted upstream. > > Thanks for making such a suggestion ;) but I'm not a developer not have > time for that. > > I was just confronted with sssd in RHEL/Centos 6 as IT administrator and > since I manage couple of production servers in midsize company using > LDAP authentication and because I'm recently preparing our environment > to move from Centos 5 to Centos 6 I was trying to find out how it's > supposed to work "the new way".
Tomas, you are free to choose the best methods that works for you but I think you grossly overestimated the difficulty of using FreeIPA and underestimated the advantages it would give you. I use it at home with 4 computers, and I am extremely happy because it does everything for me and I do not have to think about configuring all single pieces manually. I think you shouldn't equate FreeIPA -> Big Enterprise, because FreeIPA is built to help admins for deployments of any size. That is 'the new way' when it comes to Identity Management in deployments big and small IMHO. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
