sssd-devel March 2017

sssd-devel@lists.fedorahosted.org

13 participants
134 discussions

OK to just push converted docs from fedorahosted wiki to the pagure docs repo?
by Jakub Hrozek 18 Apr '17

18 Apr '17

Hi, would anyone complain if I just push converted content from fedorahosted to the docs repo w/o review as long as there are no changes OR the changes are just alingnment of 1.15 design documents with the actual implementation? As 1.15 is making its way to downstreams, there are people interested in what we've accomplished in this release and we should make sure the changes are documented. For totally new content, I think we should have at least spot-check the docs during a review.

2 4

[sssd PR#193][opened] UTIL: Use max 15 characters for AD host UPN
by lslebodn 18 Apr '17

18 Apr '17

URL: https://github.com/SSSD/sssd/pull/193 Author: lslebodn Title: #193: UTIL: Use max 15 characters for AD host UPN Action: opened PR body: """ We do not want to use host principal with AD "host/name.domain.tld(a)DOMAIN.TLD" becasue it does not work. We need to use correct user principal for AD hosts. And we cannot rely all fallback "*$" becuase of other principals in keytab. Resolves: https://pagure.io/SSSD/sssd/issue/3329 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/193/head:pr193 git checkout pr193

5 24

Design document - SSSD KCM server
by Jakub Hrozek 10 Apr '17

10 Apr '17

Hi, I was working on a KCM server for SSSD for some time already in parallel with the files provider and had some discussions with Simo as well. Of course my intent wasn't to implement a feature secretly without a design review, but to have a prototype to base a proper design on :) However it makes sense to have a peer-reviewed design page now, also because of Fedora's move towards Kerberos and KDC proxy, which leads to questions on the Fedora lists about ccache renewals and so on -- so I think it makes sense to pitch the design to Fedora at least already.. Here is the design page: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM and here is the code of the KCM responder so far: https://github.com/jhrozek/sssd/tree/kcm Time-wise, I would like to pivot to return to working on KCM now that the files provider is more or less done and tested. For your convenience, the design page text is included below as well. = KCM server for SSSD = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2887 External links: * [http://k5wiki.kerberos.org/wiki/Projects/KCM_client MIT wiki KCM documentation] === Problem statement === This design page describes adding a new SSSD responder, called `sssd_kcm`. This component would manage Kerberos credential caches and store them in SSSD's secrets storage. === Use cases === * A sysadmin needs to deploy applications in containers without worrying about applications clobbering each other's credential caches in a kernel keyring as keyrings are not namespaced * A user wants to keep having her Kerberos ticket automatically renewed regardless of the ticket being acquired through a PAM conversation with SSSD or from the command line with kinit * A system admin wants to leverage a collection-aware credentials cache for most of applications on their systems, yet enable a legacy application that can only work with a FILE-based ccache to interoperate with them === Overview of the solution === Over time, both libkrb5 and SSSD used different credential cache types to store Kerberos credentials - going from a simple file-based storage (`FILE:`) to a directory (`DIR:`) and most recently a kernel-keyring based cache (`KEYRING:`). Each of these caches has its own set of advantages and disadvantages. The `FILE` ccache is very widely supported, but does not support multiple primary caches. The `DIR` cache does, but creating and managing the directories including proper access control can be tricky. The `KEYRING` cache is not well suited for cases where multiple semi-isolated environments might share the same kernel. Managing credential caches' lifetime is not well solved in neither of these cache types automatically, only with the help of a daemon like SSSD. An interesting credentials cache that might solve the issues mentioned above is `KCM`. With KCM, the Kerberos caches are not stored in a "passive" store, but managed by a daemon. In this setup, the Kerberos library (typically used through an application, like for example, `kinit`) is a "KCM client" and the daemon is being referred to as a "KCM server". Having the Kerberos credential caches managed by a deamon has several advantages: * the daemon is stateful and can perform tasks like Kerberos credential cache renewals or reaping old ccaches. Some tasks, like renewals are possible already with SSSD, but only for tickets that SSSD itself acquired (typically via a login through `pam_sss.so`) and tracks. Tickets acquired otherwise, most notably though kinit wouldn't be tracked and renewed. * since the process runs in userspace, it is subject to UID namespacing, [http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-… unlike the kernel keyring] * unlike the kernel keyring-based cache, which is entirely dependant on UIDs of the caller and in a containerized environment is shared between all containers, the KCM server's entry point is a UNIX socket which can be bind-mounted to only some containers * the protocol between the client and the server can be extended for custom operations such as dumping a cache in a different format to a specific location. This would be beneficial for applications that only understand a certain Kerberos ccache type - for example, some legacy applications only know how to deal with a FILE-based cache, thus preventing the use of cache collections Only the Heimdal Kerberos implementation currently implements a KCM server, but both Heimdal and MIT implement the client-side operations (in libkrb5) to manage KCM-based Kerberos ccaches. This design page describes adding a KCM server to SSSD. While it's of course possible to create a completely standalone deamon that would implement a KCM server, doing so in the context of SSSD has several advantages, notably: * An easy access to the authentication provider of SSSD that already has existing and tested code to renew Kerberos credentials on user's behalf * SSSD already has a D-Bus API that could publish information about Kerberos tickets and for example emit signals that a graphical application can consume * SSSD has a 'secrets provider' to store data at rest. It makes sense to leverage this component to store Kerberos ccaches persistently === Implementation details === A new SSSD responder will be added. Since accessing the Kerberos credentials is quite an infrequent operation, the responder will be socket-activated. This responder would implement the same subset of the KCM protocol the MIT client libraries implement. Contrary to Heimdal's KCM server that just stores the credential caches in memory, the SSSD KCM server would store the ccaches in the secrets database through the sssd-secret's responder [https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-secrets.5.html public REST API]. For user credentials the KCM Server would use a secrets responder URI like `/kcm/users/1234/X` where 1234 is the user ID and X is the residual. The client then gets assigned a KRB5CCNAME of KCM:1234:X. Internally in the secrets responder we will store the credential caches under a new base DN `cn=kcm`. The secret responder's quota on secrets must be made modular to allow different number of secrets per base DN (so, different number of secrets and credentials pretty much). What to do in case the quota is reached is debatable - we should probably first remove service (non-TGT) tickets first for valid TGTs and if that's not possible, just fail. A failure in this case would be no different than a failure if a disk is full when trying to store a FILE-based ccache. The KCM responder would renew the user credentials by starting a tevent timer which would then contact the SSSD Data Provider for the given UID and principal, asking for the credentials to be renewed. Another tevent timer would reap and remove a ccache that reaches its lifetime. In the future, SSSD-specific operations such as writing out a FILE-based ccache might be added. The SSSD D-Bus interface would also be extended to publish information about credentials activity (such as - a ticket being acquired, a ticket was renewed etc) === Configuration changes === No KCM-specific configuration options will be added. The SSSD KCM responder would use the same common options like other SSSD services such as idle timeout. We can add a configurable KCM socket location later, if needed, but for the start it's fine to default to `/var/run/.heim_org.h5l.kcm-socket` mostly because that's what MIT defaults to as well. '''Q''': Should we add an option to explicitly enable ccache renewals and default to no renewals? I don't think this would any any security though, the attacker can just run 'kinit -R' on behalf of the user anyway. === How To Test === In order for the admin to start using the KCM service, the sssd-kcm responder's systemd service must be enabled. Then, libkrb5 must also be configured to use KCM as its default ccache type in `/etc/krb5.conf` {{{ [libdefaults] default_ccache_name = KCM }}} After that, all common operations like kinit, kdestroy or login through pam_sss should just work and store their credentials in the KCM server. The KCM server must implement access control correctly, so even trying to access other user's KCM credentials by setting KRB5CCNAME to `KCM:1234:RESIDUAL` would not work (except for root). Restarting the KCM server or rebooting the machine must persist the tickets. As far as automatic unit and integration testing is required, we need to make sure that MIT's testsuite passes with Kerberos ccache defaulting to KCM and SSSD KCM deamon running. In the SSSD upstream, we should write integration tests that run a MIT KDC under socket_wrapper to exercise the KCM server. === How To Debug === The SSSD KCM server would use the same DEBUG facility as other SSSD services. In order to debug the client side operations, setting the `KRB5_TRACE` variable might come handy. When debugging the setup, the admin might also inspect the SSSD secrets database (if permissable by SELinux policy) to see what credential caches have been stored by the SSSD. === Authors === * Jakub Hrozek <jhrozek(a)redhat.com> * Simo Sorce <simo(a)redhat.com>

3 7

[sssd PR#196][opened] SSSD-1.15 - config-check: Message when sssd.conf is missing
by mzidek-rh 10 Apr '17

10 Apr '17

URL: https://github.com/SSSD/sssd/pull/196 Author: mzidek-rh Title: #196: SSSD-1.15 - config-check: Message when sssd.conf is missing Action: opened PR body: """ SSSD 1.15 version for patch recently pushed to 1.14. sssctl config-check should print a message for user if no sssd.conf was found. Resolves: https://pagure.io/SSSD/sssd/issue/3330 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/196/head:pr196 git checkout pr196

2 9

[sssd PR#200][opened] Improve PAM test client
by sumit-bose 10 Apr '17

10 Apr '17

URL: https://github.com/SSSD/sssd/pull/200 Author: sumit-bose Title: #200: Improve PAM test client Action: opened PR body: """ This patch set makes the PAM test client more flexible and adds additional lookups of the user via NSS and InfoPipe. For simplicity this version uses libsss_simpleifp to access InfoPipe. A later version might use libdbus directly to reduce the number of dependencies. Related to https://pagure.io/SSSD/sssd/issue/3292 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/200/head:pr200 git checkout pr200

4 16

WIP design page: Subdomain configuration
by Michal Židek 07 Apr '17

07 Apr '17

Hi, I started working on the design page for subdomain configuration in server mode. It is located here: https://fedorahosted.org/sssd/wiki/DesignDocs/SubdomConf The implementation details and how to debug sections will be added later. For now, the design page is short but should at least set the proper expectations for the feature. Please tell me if you think something is unclear. I will add more to the page soon. Michal

3 5

[RFC] Matching and Mapping Certificates
by Sumit Bose 07 Apr '17

07 Apr '17

Hi, I've started to write a SSSD design page about enhancing the current mapping of certificates to users and how to select/match a suitable certificate if multiple certificates are on a Smartcard. My currently thoughts and idea and be found at https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates and for your convenience below as well. Comments and suggestions are welcome. Please let me know about concerns, alternatives and missing use-cases/user-stories. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mappi… === Problem statement === ==== Mapping ==== Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. ==== Matching ==== Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === ==== Mapping ==== In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed ==== Matching ==== A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. === Implementation details === ==== Matching ==== The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are * <SUBJECT>regular-expression * <ISSUER>regular-expression * <SAN>regular-expression * <EKU>extended-key-usage-list * <KU>key-usage-list and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' While <SUBJECT> and <ISSUER> are (imo) already quite flexible I can see some potential extensions for the other components. <EKU> and <KU> in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). The <SAN> component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with <SAN:O.I.D> ==== Mapping ==== Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. * <SUBJECT:ldapAttributeName> * <SAN:O.I.D.:ldapAttributeName> Currently I see no usage for <ISSUER>, <KU> and <EKU> in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add <ISSUER> based mappings. '''Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of <SUBJECT> might be tricky as discussed below. Nevertheless the following might be possible: * <SUBJECT:ldapAttributeName>/regexp/replacement/ * <SAN:O.I.D.:ldapAttributeName>/regexp/replacement/ '''where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like {{{ <SUBJECT:samAccountName>/^CN=$[^,]*$.*$/\1/ }}} '''would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. '''The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expres… g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. ''' ===== Some notes about DNs ===== The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the * X.500 order: DC=com,DC=example,CN=users,CN=Certuser or in the * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111) This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '<SUBJECT:dn>' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user(a)example.com', certtool as 'EMAIL=user(a)example.com' and certutil as 'E=user(a)example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: * CN commonName (2.5.4.3) * L localityName (2.5.4.7) * ST stateOrProvinceName (2.5.4.8) * O organizationName (2.5.4.10) * OU organizationalUnitName (2.5.4.11) * C countryName (2.5.4.6) * STREET streetAddress (2.5.4.9) * DC domainComponent (0.9.2342.19200300.100.1.25) * UID userId (0.9.2342.19200300.100.1.1) ==== About restricting or enforcing the mapping an matching any further ==== The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. ==== Storing matching and mapping configuration ==== On the IPA server a new objectclass can be created to store an matching-mapping rule pair. Both attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. ===== Examples ===== * '''certificate_rules = {<EKU>msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with * '''certificate_rules = {<EKU>1.3.6.1.4.1.311.20.2.2}''': see above * '''certificate_rules = {<ISSUER>*my-company*<SAN:rfc822Name>*(a)my-company.com$}{<SAN:rfc822Name:mail>}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. === Configuration changes === Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. === How To Test === This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. === How To Debug === Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. === Authors === Give credit to authors of the design in this section.

7 23

[sssd PR#165][opened] selinux: Do not fail if SELinux is not managed
by mzidek-rh 06 Apr '17

06 Apr '17

URL: https://github.com/SSSD/sssd/pull/165 Author: mzidek-rh Title: #165: selinux: Do not fail if SELinux is not managed Action: opened PR body: """ Previously we failed if selinux_is_managed returned 0 or -1 (not managed or error). With this patch we only fail in case of error and continue normally if selinux is not managed by libsemanage at all. Resolves: https://fedorahosted.org/sssd/ticket/3297 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/165/head:pr165 git checkout pr165

4 22

[sssd PR#219][opened] BUILD: Fix compilation of libsss_certmap with libcrypto
by lslebodn 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/219 Author: lslebodn Title: #219: BUILD: Fix compilation of libsss_certmap with libcrypto Action: opened PR body: """ CC src/lib/certmap/libsss_certmap_la-sss_cert_content_nss.lo src/lib/certmap/sss_cert_content_nss.c:25:18: fatal error: cert.h: No such file or directory #include <cert.h> ^ compilation terminated. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/219/head:pr219 git checkout pr219

2 6

Design discussion: Support for non-POSIX users and groups
by Jakub Hrozek 03 Apr '17

03 Apr '17

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

3 12

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel March 2017