On 10/25/2012 04:14 PM, Jakub Hrozek wrote:
On Thu, Oct 25, 2012 at 01:48:49PM +0200, Tomas Brandysky wrote:
On 10/25/2012 11:36 AM, Sumit Bose wrote:
On Thu, Oct 25, 2012 at 10:36:05AM +0200, Tomas Brandysky wrote:
Hello,
we're upgrading from Centos 5.8 to Centos 6.3 and have realized few things have changed in the system.
We're using LDAP authentication (nss_ldap package) on our Centos 5.8 servers and have different PAM ldap configuration files configured to be used for specific PAM services at the moment.
Here is the example of our setup:
/etc/pam.d/service1: auth sufficient pam_ldap.so config=/etc/ldap_service1.conf
/etc/pam.d/service2: auth sufficient pam_ldap.so config=/etc/ldap_service2.conf
Thus we can use specific LDAP filters for various different services as not all users having access to one service also have access to other services on the same server.
Now we're facing the problem to manage the same functionality with System Security Services Daemon (SSSD) which was newly presented with RHEL 6.
We didn't find out so far how to specify custom sssd configuration file (or specific part of the configuration section/domain) in PAM service configuration. According to documentation only these options can be specified when using pam_sss module: [forward_pass] [use_first_pass] [use_authtok].
None of them can be used to make a difference in a ldap filter to be used.
Is there a way how to configure specific search filters depending on PAM service ?
Thank you for any suggestion
I think what you are looking for is covered in https://fedorahosted.org/sssd/ticket/1021.
yes, that's exactly what I miss in sssd. I'm surprised such a feature isn't supported yet as the same goal could be accomplished in RHEL4/5 releases with older methods. I see this as a step back. Is there some real possibility to have this feature in some later release which could come as update in RHEL 6 ?
I don't think we are tracking this feature request for RHEL6. If you need the functionality in RHEL6, feel to propose it through the support.
If you only want to allow/deny access for specific users to specific service you can add an attribute to the user objects in the LDAP server listing the allowed PAM services and use ldap_user_authorized_service. See sssd-ldap man page for details.
I know about ldap_user_authorized_service but I need to specify a combination of service and host access. I can't effort to grant users access to ssh service globaly when they can access ssh only on some of dozens servers we have.
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
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.
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.
sssd-users@lists.fedorahosted.org