Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups ======================================
Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/3310
Problem statement ----------------- SSSD, with its D-Bus interface is appealing to applications as a gateway to an LDAP directory where users and groups are stored. However, contrary to the traditional SSSD deployment where all users and groups either have POSIX attributes or those attributes can be inferred from the Windows SIDs, in many cases the users and groups in the application support scenario have no POSIX attributes. At the same time, SSSD especially on the back end (LDAP provider) level currently requires the presence of either an UID number or a Windows SID.
This feature tracks adding support for user and group resolution through the D-Bus interface and authn/authz through the PAM interface even for setups without UIDs or Windows SIDs present on the LDAP directory side.
Use cases --------- * As an application developer, I want to fetch user attributes for my application from an LDAP server that only uses a fairly generic LDAP objectclasses such as ``groupOfNames`` for groups or ``person`` for users. The application can either issue D-Bus calls itself or rely on Apache modules such as `mod_lookup_identity https://github.com/adelton/mod_lookup_identity/`_ * As an application developer, I want to authenticate users to my application using the `mod_authnz_pam https://github.com/adelton/mod_authnz_pam`_ module even if the users lack PAM attributes.
Overview of the solution ------------------------ On a high level, the most work is tweaking the internal LDAP searches so that they are less restrictive and match users and groups based on just the requested key (typically a name or a UPN) and the configured objectclass.
Whether SSSD will restrict the lookups to only POSIX accounts or allow even non-POSIX lookups will be controlled `at the domain level`. This is important for several reasons:
* To avoid "leaking" the non-POSIX accounts or, perhaps more importantly, their non-POSIX group memberships to interfaces such as NSS that otherwise require a complete POSIX entry. While these checks could be implemented by the POSIX interfaces as well, making the distinction at the domain level is much safer.
* To minimize the number of inconsistencies. These include:
* One interface requesting a non-POSIX user through a D-Bus call, then later a POSIX interface searching for the same user. The latter call, having a more restrictive filter, would not match the object in the domain and because we tend to treat the domain reply as authoritative, remove the cached non-POSIX users.
* Mixed POSIX and non-POSIX group memberships would require a large amount of special-casing and very careful testing to make sure requests for such hybrid user would return the correct group memberships but at the same time not remove the non-POSIX parts in all cases.
* Interfaces that serve both the POSIX and non-POSIX case such as the D-Bus interface need to know whether to return only the list of POSIX group membership if a user that has POSIX attributes is requested. The interfaces cannot assume the intent of the caller and forcing the caller to decide based on the target domain helps here.
In short, by forcing to make the distinction on the domain level, the SSSD code would be made more robust and error-prone while limiting the complexity.
A non-POSIX domain would be skipped during lookups by interfaces that require POSIX attributes, such as ``sudo`` or ``NSS``. Better distinction must be made for interfaces that support both POSIX and non-POSIX users, though and the details are discussed below.
In the simplest case, only a single domain will be defined. The tricky part are setups that must serve data to both the application from a non-POSIX domain and for the OS. For these setups, two ``[domain/]`` sections pointing to the same remote server must be defined, one marked as ``posix`` and one marked as ``application`` type (see below).
To distinguish between accounts with the same name that exist in both these domains by interfaces that support both POSIX and non-POSIX domains, a qualified name is the safest way.
In addition, the PAM responder will keep a list of application PAM services so that if an unqualified name arrives from an OS-level PAM service (such as ``ssh``), the PAM responder will know it is safe to skip the non-POSIX domains and route the PAM request to POSIX domains only. This would make life easier for accounts that both use the application and OS-level PAM services in the sense that the OS-level PAM interface will be usable even without qualified names.
For distinguishing accounts between a POSIX and a non-POSIX domain from the D-Bus inteface, a fully qualified name must be used. But since the D-Bus interface is normally used only by the application, putting the non-POSIX domain first in the ``domains`` list should be enough to avoid using qualified names from the application while still making it possible to use the POSIX domain defined as second in the list.
Implementation details and configuration changes ------------------------------------------------ A new SSSD domain option will be added. The option will be called ``domain_type`` and would support two values - ``posix`` and ``application``. The default value will be ``posix``, the non-POSIX support will be enabled by setting the ``domain_type`` to ``application``.
When the ``domain_type`` is set to ``application``, SSSD responders that are only usable on a POSIX system (currently ``nss``, ``ssh``, ``sudo``, ``kcm`` and ``secrets``) will skip over ``application`` type domains. This logic will be implemented at the ``cache_req`` level and set by the caller, which is the responder, by adding a ``cache_req`` option. In particular, the ``cache_req`` requests will include an enum with allowed values ``CACHE_REQ_POSIX`` and ``CACHE_REQ_APP`` where the POSIX responders will only use the ``CACHE_REQ_POSIX`` value. The logic that determines which value the ``ifp`` and ``pam`` responders use is described below.
The responders that are usable by both applications and the OS as well (that's ``pam`` and ``ifp``) will set a flag for the ``cache_req`` request that will instruct the ``cache_req`` domain-loop to also consider ``application`` domains.
The ``ifp`` responder will consider ``application`` domains for all requests. Therefore in order to resolve a POSIX user with only POSIX membership, the request towards the ``ifp`` interface must be qualified with the domain name.
The ``pam`` responder will gain a new option ``application_services``. This option will be empty by default. Only PAM services listed in this option will be allowed to contact the ``application`` domains. This option will be added to make sure that unqualified names can still be used in PAM conversations in case both ``posix`` and ``applications`` domains are configured for SSSD. In future, we might add a similar option (with ``UID`` of the caller of the interface as the key) to the ``ifp`` responder as well, but such option will not be added in the first iteration.
The last change needed is for Kerberos authentication. Since the Kerberos ticket returned cannot be owned by a POSIX owner in application domains, especially in cases the system would otherwise use a FILE-based ccache, we will use a temporary MEMORY-based ccache in the ``krb5_child`` process destroy the ticket when ``krb5_child`` finishes and only return the resulting error code from the child process to the Data Provider.
How To Test ----------- The best way of testing this feature is to test the "full stack" together with an application and the Apache modules.
However, isolated testing can be performed as well. All tests expect that the LDAP server is populated with entries that do not contain POSIX attributes or might contain POSIX attributes in the case of mixed setup tests. For testing PAM authn and authz, the ``pam_test_client`` binary built from SSSD sources can be used until ``sssctl`` provides a better way.
The users in the test setup should be members of non-POSIX groups, or a mix of POSIX and non-POSIX groups in the mixed scenario setups.
#. SSSD with only the ``application`` domain can be reached through the D-Bus and PAM interfaces
* Add a domain as follows::
[sssd] domains = appdomain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/appdomain.test] id_provider=ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber
* Make sure that a D-Bus call towards the SSSD interface can resolve the ``phone`` attribute of ``$user``
* Test that calling ``pam_test_client auth $user`` succeeds with the correct password. Please note that testing ``auth_provider=krb5`` is also important here to make sure the krb5 provider can deal with ccaches that cannot be owned by a POSIX owner.
#. No users or groups from an ``application domain`` can be resolved through the system interfaces
* With the setup above, make sure that ``getent passwd $user`` doesn't return the user and even doesn't contact the remote server.
* Same test should be performed for the ``ssh``, ``sudo`` and other responders.
#. A mixed setup with two domains, one ``posix`` and one ``application`` reports the proper results from all interfaces
* Modify the test domain to look like::
[sssd] domains = appdomain.test, posixdomain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber
[domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test
* Make sure the LDAP server contains a mix of POSIX and non-POSIX users and groups. The POSIX users should be members of a mix of both POSIX and non-POSIX groups.
* The tests from the first test case against a non-POSIX user should function as before
* However, retrieving the POSIX users should now hit the domain ``posixdomain.test``, so the following should work:
* ``getent passwd $posix_user`` should return the POSIX user * ``id $posix_user`` should return only POSIX groups the user is a member of and omit non-POSIX groups * ``getent group $posix_group`` should list all POSIX members of this group.
In all the above tests, the NSS responder should skip the ``appdomain.test`` domain completely.
* Since the ``appdomain.test`` domain comes first in the domain list, running ``GetUserAttr`` with an unqalified name should return non-POSIX users * Also invoking the ``GetUserGroups`` function should list their non-POSIX groups. Requests qualified to reach the ``posixdomain.test`` domain should only list POSIX groups.
#. A mixed setup with two domains, one ``posix`` and one ``application`` can be used for OS-level authentication and authorization
* Use the setup from the previous test
* Make sure that running a PAM application on the OS level (``su`` or ``ssh`` are good tests) allows the user to log in using shortname as the NSS responder would skip the ``appdomain.test`` completely when the PAM application calls ``initgroups`` and the PAM responder would skip the ``appdomain.test`` domain because the PAM service is not listed in the ``application_services`` option
How To Debug ------------ Debug messages listing the domain type must be added to the ``cache_req`` code. Then, the regular method of issuing a request and watching the logs should work. Expiring the cache and using the qualified names is recommeded.
Authors ------- * Sumit Bose * Jakub Hrozek * Simo Sorce
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
1) You can't have one domain that return both posix and non-posix users. 2) PAM is allowed to login a non-posix users for given services. 3) If CACHE_REQ_APP is used, non-posix domains are searched first then posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
Is this right? Did I miss something important?
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
Is this right? Did I miss something important?
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
On 03/07/2017 01:33 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
If find this rather complicated at least from what we talked about on irc. If I recall correctly, we leaned in a way that we always download the user whether it is posix or not and then let the caller decide if it should be returned by sssd. I.e.
if !non_posix_users_enabled(domain) then download only posix users else download user even if it is non posix
In NSS (and other posix responders) we would return ENOENT for non-posix users. In IFP we would not care (or care if we change API to select).
This wouldn't require the domain separation. What were the reasons to not use this approach?
On Tue, Mar 07, 2017 at 02:31:27PM +0100, Pavel Březina wrote:
On 03/07/2017 01:33 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
If find this rather complicated at least from what we talked about on irc. If I recall correctly, we leaned in a way that we always download the user whether it is posix or not and then let the caller decide if it should be returned by sssd. I.e.
if !non_posix_users_enabled(domain) then download only posix users else download user even if it is non posix
In NSS (and other posix responders) we would return ENOENT for non-posix users. In IFP we would not care (or care if we change API to select).
This wouldn't require the domain separation. What were the reasons to not use this approach?
The conflicts between different 'views'. Consider the case where an IFP user would request the groups of a user who is a member of both POSIX and non-POSIX groups. Then, a second later, the NSS responder calls initgroups.
What does the initgroups POSIX call on the back end level do with the non-POSIX groups, especially the leaf ones? Does it remove them? Do we add logic to ignore the non-POSIX groups? How do we tell if the groups were removed from the server if the searches match only the POSIX data in the second request?
It is really much safer to set a separate domain for the POSIX and non-POSIX world.
On 03/07/2017 03:11 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 02:31:27PM +0100, Pavel Březina wrote:
On 03/07/2017 01:33 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
If find this rather complicated at least from what we talked about on irc. If I recall correctly, we leaned in a way that we always download the user whether it is posix or not and then let the caller decide if it should be returned by sssd. I.e.
if !non_posix_users_enabled(domain) then download only posix users else download user even if it is non posix
In NSS (and other posix responders) we would return ENOENT for non-posix users. In IFP we would not care (or care if we change API to select).
This wouldn't require the domain separation. What were the reasons to not use this approach?
The conflicts between different 'views'. Consider the case where an IFP user would request the groups of a user who is a member of both POSIX and non-POSIX groups. Then, a second later, the NSS responder calls initgroups.
What does the initgroups POSIX call on the back end level do with the non-POSIX groups, especially the leaf ones? Does it remove them? Do we add logic to ignore the non-POSIX groups? How do we tell if the groups were removed from the server if the searches match only the POSIX data in the second request?
In this approach, backend is supposed to always download both posix and non-posix users. Backend should not be aware about posix attributes at all. Responder should decide whether non-posix users should be removed from the result (not from the cache) or not.
It is really much safer to set a separate domain for the POSIX and non-POSIX world.
On Wed, Mar 08, 2017 at 10:45:32AM +0100, Pavel Březina wrote:
On 03/07/2017 03:11 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 02:31:27PM +0100, Pavel Březina wrote:
On 03/07/2017 01:33 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote: > Hi, > > I prepared a design page for a new feature about fetching and > authenticating non-POSIX users: > https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html > > For your convenience, I'm also copying the .rst text below: > > Support for non-POSIX users and groups > ====================================== > > Related ticket(s): > ------------------ > https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
- PAM is allowed to login a non-posix users for given services.
- If CACHE_REQ_APP is used, non-posix domains are searched first then
posix domains. 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. 5) Non-posix domains require fully qualified name. 6) Posix users return only posix groups membership. 7) Non-posix users return both posix and non-posix membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
If find this rather complicated at least from what we talked about on irc. If I recall correctly, we leaned in a way that we always download the user whether it is posix or not and then let the caller decide if it should be returned by sssd. I.e.
if !non_posix_users_enabled(domain) then download only posix users else download user even if it is non posix
In NSS (and other posix responders) we would return ENOENT for non-posix users. In IFP we would not care (or care if we change API to select).
This wouldn't require the domain separation. What were the reasons to not use this approach?
The conflicts between different 'views'. Consider the case where an IFP user would request the groups of a user who is a member of both POSIX and non-POSIX groups. Then, a second later, the NSS responder calls initgroups.
What does the initgroups POSIX call on the back end level do with the non-POSIX groups, especially the leaf ones? Does it remove them? Do we add logic to ignore the non-POSIX groups? How do we tell if the groups were removed from the server if the searches match only the POSIX data in the second request?
In this approach, backend is supposed to always download both posix and non-posix users. Backend should not be aware about posix attributes at all. Responder should decide whether non-posix users should be removed from the result (not from the cache) or not.
This would be hugely inefficient and e.g. logins would take forever.
On Wed, 2017-03-08 at 11:39 +0100, Jakub Hrozek wrote:
On Wed, Mar 08, 2017 at 10:45:32AM +0100, Pavel Březina wrote:
On 03/07/2017 03:11 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 02:31:27PM +0100, Pavel Březina wrote:
On 03/07/2017 01:33 PM, Jakub Hrozek wrote:
On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote:
On 03/07/2017 01:16 PM, Pavel Březina wrote: > On 03/06/2017 02:49 PM, Jakub Hrozek wrote: > > Hi, > > > > I prepared a design page for a new feature about > > fetching and > > authenticating non-POSIX users: > > https://docs.pagure.org/SSSD.sssd/design_pages/non_ > > posix_support.html > > > > For your convenience, I'm also copying the .rst text > > below: > > > > Support for non-POSIX users and groups > > ====================================== > > > > Related ticket(s): > > ------------------ > > https://pagure.io/SSSD/sssd/issue/3310 > > I find this document quite hard to understand, so I want > to ensure I get > it right: > > 1) You can't have one domain that return both posix and > non-posix users. > 2) PAM is allowed to login a non-posix users for given > services. > 3) If CACHE_REQ_APP is used, non-posix domains are > searched first then > posix domains. > 4) If CACHE_REQ_POSIX is used, non-posix domains are > skipped. > 5) Non-posix domains require fully qualified name. > 6) Posix users return only posix groups membership. > 7) Non-posix users return both posix and non-posix > membership.
And 8) You can have two users, one posix, one non-posix with the same name.
In theory yes, but I don't think this would be too common. In general you could have two entries, one with objectclass user, the other with objectclass posixUser where each domain would use a different attribute for the username. But even so, I think the current scheme would protect us against these strange setups.
If find this rather complicated at least from what we talked about on irc. If I recall correctly, we leaned in a way that we always download the user whether it is posix or not and then let the caller decide if it should be returned by sssd. I.e.
if !non_posix_users_enabled(domain) then download only posix users else download user even if it is non posix
In NSS (and other posix responders) we would return ENOENT for non-posix users. In IFP we would not care (or care if we change API to select).
This wouldn't require the domain separation. What were the reasons to not use this approach?
The conflicts between different 'views'. Consider the case where an IFP user would request the groups of a user who is a member of both POSIX and non-POSIX groups. Then, a second later, the NSS responder calls initgroups.
What does the initgroups POSIX call on the back end level do with the non-POSIX groups, especially the leaf ones? Does it remove them? Do we add logic to ignore the non-POSIX groups? How do we tell if the groups were removed from the server if the searches match only the POSIX data in the second request?
In this approach, backend is supposed to always download both posix and non-posix users. Backend should not be aware about posix attributes at all. Responder should decide whether non-posix users should be removed from the result (not from the cache) or not.
This would be hugely inefficient and e.g. logins would take forever.
Inefficiency is secondary, the problem is that you would very quickly get requests to have different filters for posix users and non-posix users, and you end up adding a ton of options for the two distinct cases. It is better if the users (and groups) for an application have the filters required for that application and exactly only those filters, or you'll pretty quickly have to add filtering both in the backend and in the NSS frontend and the code becomes super-complicated == tons of bugs and regressions.
If applications want their own view they get their special domain and then everything can be tweaked as wanted w/o impacting the underlying system users and their domain settings.
Simo.
On Tue, Mar 07, 2017 at 01:16:00PM +0100, Pavel Březina wrote:
On 03/06/2017 02:49 PM, Jakub Hrozek wrote:
Hi,
I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
For your convenience, I'm also copying the .rst text below:
Support for non-POSIX users and groups
Related ticket(s):
https://pagure.io/SSSD/sssd/issue/3310
I find this document quite hard to understand, so I want to ensure I get it right:
- You can't have one domain that return both posix and non-posix users.
Yes, to avoid inconsistencies between lookups of the same user mostly.
- PAM is allowed to login a non-posix users for given services.
Yes, only for those configured with the application_services option.
- If CACHE_REQ_APP is used, non-posix domains are searched first then posix
domains.
No, only non-POSIX domains are searched.
- If CACHE_REQ_POSIX is used, non-posix domains are skipped.
Yes
- Non-posix domains require fully qualified name.
Not in general. Because whether only POSIX or only non-POSIX domains are searched is restricted by the CACHE_REQ_APP/POSIX option, the only time you need to qualify a user is when you request the user through an interface that supports both POSIX and non-POSIX lookups and at the same time there is no 'hint' that would tell you the intent of the caller.
That's basically only the IFP interface, because the PAM interface specifies the intent by selecting the right service.
The other interfaces (NSS, SSH, sudo, ..) are strictly POSIX so they would only hit the POSIX domains in the first place.
- Posix users return only posix groups membership.
Yes.
- Non-posix users return both posix and non-posix membership.
Yes, because non-POSIX groups are a superset of POSIX group (as long as all POSIX groups also have the objectclass that the non-POSIX groups have).
On Mon, 2017-03-06 at 14:49 +0100, Jakub Hrozek wrote:
[sssd]
domains = appdomain.test, posixdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber [domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test
Jakub, I am thinking we may want to make some things here slightly different.
Instead of calling them all domains, and having to sort out the differences later, I am thinking we may want to define a completely new section type called "application", this will allow us to "inherit" configuration from domain for compactness when both posix and non-posix are needed from the same domain.
Example:
[sssd] domains = domain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/domain.test] id_provider = ldap ldap_uri = ldap://server.test
[application/domain.test] inherit_from = domain/domain.test ldap_user_extra_attrs = phone:telephoneNumber
The idea is that the application domain inherits most of its parameters from the posix domain references (if any is referenced). If no difference between application domain and posix domain is needed then the application domain section could be almost completely empty (win).
I am not sure if we need to explicitly list application domains in the sssd or PAM sections, or if we should just automatically have them available by the simple fact they have been defined. One thing we may want though is to have an option that explicitly maps application domains to specific "services", for both PAM and IFP at the same time (given it makes no sense to do that independently and both need to be on the same page for this).
So move to a new section and modify the application_services parameter to take tuples: [applications] application_services = apache:domain.test myapp:other.dom \ otherapp:domain.test,other.dom,third.dom \ fooapp:ALL
The other option may be to list what services each application domain will be made available to in the application domain definition itself:
[application/domain.test] available_for = ALL
[application/other.dom] available_for = apache, otherapp, fooapp
[application/third.dom] available_for = otherapp
I think the problem will be to find the right balance to make it simple to configure which apps can get to which domains, the main trick being that we should not make application domains available to things like ssh, gdm, login by default because then NSS would fail later on and we'd waste time. Also we need to be careful in never attempting double authentication (both to the posix domain and then again via application domain for any single app, as we may cause premature account locks that way). So perhaps explicitly listing services is always needed after all, and when a service is listed then only the specific list of application domains is considered for that service and nothing else.
Just a few ideas to be able to better control what app does what. I am not sure we need different query types in the protocol either, because the above configuration will make it pretty clear what apps should get from the IFP, and backends will be of the appropriate type already so when you contact one they already know what they should return in their cache. Hope this makes sense and complements the design rather than disrupt it, it does complement it in my mind :-)
Simo.
On Tue, Mar 14, 2017 at 06:25:39AM -0400, Simo Sorce wrote:
On Mon, 2017-03-06 at 14:49 +0100, Jakub Hrozek wrote:
[sssd]
domains = appdomain.test, posixdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber [domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test
Jakub, I am thinking we may want to make some things here slightly different.
Sorry for not replying sooner, I just wanted to get the first KCM implementation to master before focusing on this.
I actually implemented most of your suggestions and opened a PR: https://github.com/SSSD/sssd/pull/215
Individual comments inline
Instead of calling them all domains, and having to sort out the differences later, I am thinking we may want to define a completely new section type called "application", this will allow us to "inherit" configuration from domain for compactness when both posix and non-posix are needed from the same domain.
Example:
[sssd] domains = domain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/domain.test] id_provider = ldap ldap_uri = ldap://server.test
[application/domain.test] inherit_from = domain/domain.test ldap_user_extra_attrs = phone:telephoneNumber
This is how it's implemented now
The idea is that the application domain inherits most of its parameters from the posix domain references (if any is referenced). If no difference between application domain and posix domain is needed then the application domain section could be almost completely empty (win).
Yes, I agree it's better.
I am not sure if we need to explicitly list application domains in the sssd or PAM sections, or if we should just automatically have them available by the simple fact they have been defined. One thing we may want though is to have an option that explicitly maps application domains to specific "services", for both PAM and IFP at the same time (given it makes no sense to do that independently and both need to be on the same page for this).
I didn't do this, mainly because it's IMO still beneficial for the admin to set the order between the POSIX and the non-POSIX domain manually. And I would prefer to enable 'auto-enablement' of domains in some systematic way, for all domains, not just the non-POSIX ones.
So move to a new section and modify the application_services parameter to take tuples: [applications] application_services = apache:domain.test myapp:other.dom \ otherapp:domain.test,other.dom,third.dom \ fooapp:ALL
This would work for PAM services, but only for PAM services. For the IFP clients, we still just look at the UID to check who's allowed to contact the IFP responder. Therefore I think it's even less confusing to keep the option in the PAM section.
The other option may be to list what services each application domain will be made available to in the application domain definition itself:
[application/domain.test] available_for = ALL
[application/other.dom] available_for = apache, otherapp, fooapp
[application/third.dom] available_for = otherapp
I think the problem will be to find the right balance to make it simple to configure which apps can get to which domains, the main trick being that we should not make application domains available to things like ssh, gdm, login by default because then NSS would fail later on and we'd waste time.
Yes, this is exactly how it's implemented now.
Also we need to be careful in never attempting double authentication (both to the posix domain and then again via application domain for any single app, as we may cause premature account locks that way). So perhaps explicitly listing services is always needed after all, and when a service is listed then only the specific list of application domains is considered for that service and nothing else.
Right, only the app services can contact the app domains and not the posix domains. And conversely, non-app-services can only contact the posix domains.
Just a few ideas to be able to better control what app does what. I am not sure we need different query types in the protocol either, because the above configuration will make it pretty clear what apps should get from the IFP, and backends will be of the appropriate type already so when you contact one they already know what they should return in their cache.
Thanks for these.
On Tue, Mar 28, 2017 at 04:18:24PM +0200, Jakub Hrozek wrote:
On Tue, Mar 14, 2017 at 06:25:39AM -0400, Simo Sorce wrote:
On Mon, 2017-03-06 at 14:49 +0100, Jakub Hrozek wrote:
[sssd]
domains = appdomain.test, posixdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber [domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test
Jakub, I am thinking we may want to make some things here slightly different.
Sorry for not replying sooner, I just wanted to get the first KCM implementation to master before focusing on this.
I actually implemented most of your suggestions and opened a PR: https://github.com/SSSD/sssd/pull/215
Individual comments inline
Instead of calling them all domains, and having to sort out the differences later, I am thinking we may want to define a completely new section type called "application", this will allow us to "inherit" configuration from domain for compactness when both posix and non-posix are needed from the same domain.
Example:
[sssd] domains = domain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/domain.test] id_provider = ldap ldap_uri = ldap://server.test
[application/domain.test] inherit_from = domain/domain.test ldap_user_extra_attrs = phone:telephoneNumber
This is how it's implemented now
The idea is that the application domain inherits most of its parameters from the posix domain references (if any is referenced). If no difference between application domain and posix domain is needed then the application domain section could be almost completely empty (win).
Yes, I agree it's better.
I am not sure if we need to explicitly list application domains in the sssd or PAM sections, or if we should just automatically have them available by the simple fact they have been defined. One thing we may want though is to have an option that explicitly maps application domains to specific "services", for both PAM and IFP at the same time (given it makes no sense to do that independently and both need to be on the same page for this).
I didn't do this, mainly because it's IMO still beneficial for the admin to set the order between the POSIX and the non-POSIX domain manually. And I would prefer to enable 'auto-enablement' of domains in some systematic way, for all domains, not just the non-POSIX ones.
So move to a new section and modify the application_services parameter to take tuples: [applications] application_services = apache:domain.test myapp:other.dom \ otherapp:domain.test,other.dom,third.dom \ fooapp:ALL
This would work for PAM services, but only for PAM services. For the IFP clients, we still just look at the UID to check who's allowed to contact the IFP responder. Therefore I think it's even less confusing to keep the option in the PAM section.
The other option may be to list what services each application domain will be made available to in the application domain definition itself:
[application/domain.test] available_for = ALL
[application/other.dom] available_for = apache, otherapp, fooapp
[application/third.dom] available_for = otherapp
I think the problem will be to find the right balance to make it simple to configure which apps can get to which domains, the main trick being that we should not make application domains available to things like ssh, gdm, login by default because then NSS would fail later on and we'd waste time.
Yes, this is exactly how it's implemented now.
Also we need to be careful in never attempting double authentication (both to the posix domain and then again via application domain for any single app, as we may cause premature account locks that way). So perhaps explicitly listing services is always needed after all, and when a service is listed then only the specific list of application domains is considered for that service and nothing else.
Right, only the app services can contact the app domains and not the posix domains. And conversely, non-app-services can only contact the posix domains.
Just a few ideas to be able to better control what app does what. I am not sure we need different query types in the protocol either, because the above configuration will make it pretty clear what apps should get from the IFP, and backends will be of the appropriate type already so when you contact one they already know what they should return in their cache.
Thanks for these.
FYI, I updated the design page to reflect the implementation. I hope the design page can now be used by users and downstream consumers to learn about the feature: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
sssd-devel@lists.fedorahosted.org