From 075e2cca29175e2d59d4498c7330858bfac12b8f Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Apr 18 2017 07:48:26 +0000 Subject: [PATCH 1/4] subdomain docs: Limit to 80 chars per line --- diff --git a/design_pages/subdomain_configuration.rst b/design_pages/subdomain_configuration.rst index c208827..0ce5e17 100644 --- a/design_pages/subdomain_configuration.rst +++ b/design_pages/subdomain_configuration.rst @@ -31,9 +31,9 @@ during design. Use Case 1: Filtering users from a specific OU in a trusted Active Directory domain ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ As an Administrator, I want to set a different search base for users and -groups in a trusted Active Directory domain, to filter out users from an organizational -unit that contains only inactive users, so that only active users and -groups are visible to the system. +groups in a trusted Active Directory domain, to filter out users from an +organizational unit that contains only inactive users, so that only active +users and groups are visible to the system. Use Case 2: Pinning SSSD running on IPA server only to selected Active Directory servers and/or sites ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -85,13 +85,14 @@ In the first iteration, the subdomain initialization code will read the options directly from the subdomain section, if set. As an additional improvement, the ``dp_options`` structure will be expanded -with a boolean flag that signifies whether the option is overridable or -not so the code can be made a bit more generic. This work is tracked separately +with a boolean flag that signifies whether the option is overridable or not +so the code can be made a bit more generic. This work is tracked separately with `ticket 3336 `_. How To Test ----------- -This section lists several test cases that are important for users of this feature. +This section lists several test cases that are important for users of +this feature. Test the LDAP search base configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -105,16 +106,26 @@ the user and group lookups. The steps to test this scenario are: - * Configure an IPA server and set it in a trust relationship with an Active Directory domain. - * In ``sssd.conf`` on the IPA server, add trusted domain section and redefine some of the supported search base options for this section (for example ``ldap_user_search_base``) to point to only a specific OU:: + * Configure an IPA server and set it in a trust relationship with an + Active Directory domain. + * In ``sssd.conf`` on the IPA server, add trusted domain section and + redefine some of the supported search base options for this section + (for example ``ldap_user_search_base``) to point to only a specific OU:: [domain/ipadomain.test/addomain.test] ldap_user_search_base = ou=finance,dc=addomain,dc=test * Restart SSSD on the server - * Make sure that only users from within the configured search domain are resolvable - * Please note that when restricting the group search base, it is good idea to disable the TokenGroups support, otherwise SSSD will still resolve all groups the user is a member of as the TokenGroups attribute contains a flat list of SIDs. See also `this blog post `_ for more details - * Make sure that also on a IPA client, only the users from within the configured search base are resolvable + * Make sure that only users from within the configured search domain + are resolvable + * Please note that when restricting the group search base, + it is good idea to disable the TokenGroups support, otherwise + SSSD will still resolve all groups the user is a member of as the + TokenGroups attribute contains a flat list of SIDs. See also `this blog post + `_ + for more details + * Make sure that also on a IPA client, only the users from within the + configured search base are resolvable Debugging """"""""" @@ -148,8 +159,10 @@ The steps to test this use-case are: * Restart SSSD * Resolve a user or authenticate as a user - * The SSSD debug logs can be inspected to show what AD DCs were resolved and contacted - * To make sure SSSD connects to the right AD DC, you can firewall off other DCs or modify the DNS SRV records for example + * The SSSD debug logs can be inspected to show what AD DCs were resolved + and contacted + * To make sure SSSD connects to the right AD DC, you can firewall off + other DCs or modify the DNS SRV records for example Debugging """"""""" @@ -175,7 +188,8 @@ Using short names for trusted domains also differs between clients joined directly to AD and clients in an IPA domain with a trust towards an AD domain. -For the directly joined clients, simply disable the qualified names default in the subdomains' section:: +For the directly joined clients, simply disable the qualified names default +in the subdomains' section:: [domain/win.trust.test] id_provider = ad From a91f0b464cdff6fddb5bec1f0d3e4b2c2e7616fd Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Apr 18 2017 07:59:33 +0000 Subject: [PATCH 2/4] KCM: Obey the 80-chars-per-line limit --- diff --git a/design_pages/kcm.rst b/design_pages/kcm.rst index 7a1490a..ab1503e 100644 --- a/design_pages/kcm.rst +++ b/design_pages/kcm.rst @@ -32,9 +32,18 @@ and the daemon is being referred to as a *KCM server*. Having the Kerberos credential caches managed by a daemon 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, `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 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, `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 At the moment, only the Heimdal implementation of Kerberos contains a KCM server. This design page describes adding a KCM server to SSSD as a new @@ -49,9 +58,16 @@ External links: Use cases --------- -The primary use-cases for the next SSSD upstream releases are related to containers. In particular: - * 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 - * An Administrator wants to initialize and ccache centrally and then have the ccache available in all relevant containerized applications, so that applications do not have deal with Kerberos authentication or have access to keytab separately +The primary use-cases for the next SSSD upstream releases are related to +containers. In particular: + + * 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 + * An Administrator wants to initialize and ccache centrally and then + have the ccache available in all relevant containerized applications, + so that applications do not have deal with Kerberos authentication or + have access to keytab separately Having the KCM service might also enable us to solve tickets such as: * `RFE To delete kerberos tickets once the user logs out `_ @@ -65,9 +81,13 @@ A new SSSD responder is added as part of this feature. While it's of course possible to create a completely standalone daemon that would implement a KCM server, doing so in the context of SSSD has some advantages, notably: - * We can reuse a lot of code to set up and configure the server, or parse Kerberos related data - * 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 ships with a "secrets responder" to store data at rest. It makes sense to leverage this component to store Kerberos ccaches persistently + * We can reuse a lot of code to set up and configure the server, or parse + Kerberos related data + * 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 ships with a "secrets responder" to store data at rest. It makes + sense to leverage this component to store Kerberos ccaches persistently The KCM responder is socket-activated. It should be possible to use the responder without SSSD being configured, although this feature depends on @@ -264,7 +284,8 @@ between the containers. host # mkdir /var/run/kcm -#. Configure sssd-kcm to spawn the KCM socket there. Add the following to ``/etc/sssd/sssd.conf`` on the host:: +#. Configure sssd-kcm to spawn the KCM socket there. Add the following to + ``/etc/sssd/sssd.conf`` on the host:: [kcm] socket_path = /var/run/kcm/kcm.sock @@ -273,7 +294,8 @@ between the containers. host # systemctl restart sssd.service -#. Tune the systemd ``sssd-kcm`` socket to ensure systemd will listen on the same socket KCM listens on:: +#. Tune the systemd ``sssd-kcm`` socket to ensure systemd will listen on + the same socket KCM listens on:: host # mkdir /etc/systemd/system/sssd-kcm.socket.d host # cat /etc/systemd/system/sssd-kcm.socket.d/socket_override.conf @@ -281,14 +303,24 @@ between the containers. ListenStream= ListenStream=/var/run/kcm/kcm.sock -#. Re-read the unit file and verify the ``sssd-kcm.socket`` unit file is listening to the right socket:: +#. Re-read the unit file and verify the ``sssd-kcm.socket`` unit file is + listening to the right socket:: host # systemctl daemon-reload host # systemctl restart sssd-kcm.socket host # systemctl status sssd-kcm.socket host # systemctl cat sssd-kcm.socket -#. In order for the root user in the container to be represented as a different UID to the host, we need to create a subordinate UID and GID ranges that the ID from the containers will be mapped to. This range takes a required argument, which must correspond to a user that exists in ``/etc/passwd`` (although domain users `will be supported starting with docker 1.13 `_). The subordinate ranges are created in ``/etc/subuid`` and ``/etc/subgid`` on the host. Please refer to the `docker documentation `_ for more details on Docker user namespaces. For example:: +#. In order for the root user in the container to be represented as a + different UID to the host, we need to create a subordinate UID and GID + ranges that the ID from the containers will be mapped to. This range + takes a required argument, which must correspond to a user that exists in + ``/etc/passwd`` (although domain users `will be supported starting with + docker 1.13 `_). The + subordinate ranges are created in ``/etc/subuid`` and + ``/etc/subgid`` on the host. Please refer to the `docker documentation + `_ + for more details on Docker user namespaces. For example:: host # useradd kcmtest host # grep kcmtest /etc/subgid @@ -296,19 +328,24 @@ between the containers. host # grep kcmtest /etc/subuid kcmtest:50000:65536 -#. Configure the docker daemon to use this subordinate ID namespace by changing this line in ``/etc/sysconfig/docker``:: +#. Configure the docker daemon to use this subordinate ID namespace by + changing this line in ``/etc/sysconfig/docker``:: OPTIONS='--selinux-enabled --log-driver=journald --userns-remap=kcmtest' -#. Restart the docker service. Please note that docker stores the images under a per-user-namespace directory, so you'll need to pull the images again:: +#. Restart the docker service. Please note that docker stores the images + under a per-user-namespace directory, so you'll need to pull the images + again:: host # systemctl restart docker.service -#. Start a container, bind-mounting the ``/var/run/kcm`` directory from the host to make the KCM socket accessible:: +#. Start a container, bind-mounting the ``/var/run/kcm`` directory from + the host to make the KCM socket accessible:: host # docker run -t -i -h=kcmtest1 -v=/var/run/kcm:/var/run/kcm fedora /bin/bash -#. Configure the container's Kerberos config file to use ``KCM:`` as the credential cache. Edit ``/etc/krb5.conf`` in the container:: +#. Configure the container's Kerberos config file to use ``KCM:`` as the + credential cache. Edit ``/etc/krb5.conf`` in the container:: [libdefaults] default_realm = IPA.TEST @@ -324,7 +361,10 @@ between the containers. kdc = unidirect.ipa.test } -#. Acquire Kerberos credentials for the ``admin`` IPA user. Note that despite the user's UID value in the container is 0, the UID is translated to 50000 on the host, which is what the KCM server then uses to store the credentials at:: +#. Acquire Kerberos credentials for the ``admin`` IPA user. Note that + despite the user's UID value in the container is 0, the UID is translated + to 50000 on the host, which is what the KCM server then uses to store the + credentials at:: [root@kcmtest1 /]# id uid=0(root) gid=0(root) groups=0(root) @@ -339,11 +379,14 @@ between the containers. Valid starting Expires Service principal 11/25/16 15:29:38 11/26/16 15:29:37 krbtgt/IPA.TEST@IPA.TEST -#. Start another container, bind-mounting the `/var/run/kcm` directory from the host to make the KCM socket accessible:: +#. Start another container, bind-mounting the `/var/run/kcm` directory + from the host to make the KCM socket accessible:: host # docker run -t -i -h=kcmtest2 -v=/var/run/kcm:/var/run/kcm fedora /bin/bash -#. Configure ``krb5.conf`` in the same manner and run klist (without kinit!) in the container. Note we can access the same ccache the first container acquired:: +#. Configure ``krb5.conf`` in the same manner and run klist (without + kinit!) in the container. Note we can access the same ccache the first + container acquired:: [root@kcmtest2 /]# klist Ticket cache: KCM:50000 @@ -352,7 +395,9 @@ between the containers. Valid starting Expires Service principal 11/25/16 15:29:38 11/26/16 15:29:37 krbtgt/IPA.TEST@IPA.TEST -#. root on the host cannot access the same cache by default. An interesting property of the KCM protocol is that UID 0 can list all ccaches or all other UIDs, though:: +#. root on the host cannot access the same cache by default. An interesting + property of the KCM protocol is that UID 0 can list all ccaches or all + other UIDs, though:: host # klist klist: Matching credential not found @@ -375,11 +420,18 @@ In this use-case, SSSD is running in one container and keeps track of ccaches in other containers that are completely separated from the host environment. The containers must also share the credential caches between one another. -#. Start a container that will run an SSSD instace with the KCM service. We name the container ``kcmserver`` and assign a volume called ``/kcmserver`` to this container:: +#. Start a container that will run an SSSD instace with the KCM service. We + name the container ``kcmserver`` and assign a volume called ``/kcmserver`` + to this container:: host# docker run -t -i --name=kcmserver -h=kcmserver -v=/kcmserver fedora /bin/bash -#. Install and configure sssd in the container. The configuration can be pretty minimal, but the important piece is the KCM socket in the Docker volume at ``/kcmserver/kcm.socket``. Please note that depending on your version, the domain might or might not be required - on Fedora, there is an implicit domain starting with F-26. Older versions might need to define a domain even if no remote server with users is being used actually:: +#. Install and configure sssd in the container. The configuration can be + pretty minimal, but the important piece is the KCM socket in the Docker + volume at ``/kcmserver/kcm.socket``. Please note that depending on your + version, the domain might or might not be required - on Fedora, there is + an implicit domain starting with F-26. Older versions might need to define + a domain even if no remote server with users is being used actually:: kcmserver # yum -y install sssd-kcm kcmserver # cat /etc/sssd/sssd.conf @@ -392,7 +444,8 @@ The containers must also share the credential caches between one another. [domain/local] id_provider = local -#. Tune the systemd ``sssd-kcm`` socket to ensure systemd will listen on the same socket KCM listens on:: +#. Tune the systemd ``sssd-kcm`` socket to ensure systemd will listen on + the same socket KCM listens on:: host # mkdir /etc/systemd/system/sssd-kcm.socket.d host # cat /etc/systemd/system/sssd-kcm.socket.d/socket_override.conf @@ -400,7 +453,8 @@ The containers must also share the credential caches between one another. ListenStream= ListenStream=/kcmserver/kcm.socket -#. Re-read the unit file and verify the ``sssd-kcm.socket`` unit file is listening to the right socket:: +#. Re-read the unit file and verify the ``sssd-kcm.socket`` unit file is + listening to the right socket:: host # systemctl daemon-reload host # systemctl restart sssd-kcm.socket @@ -408,16 +462,19 @@ The containers must also share the credential caches between one another. host # systemctl cat sssd-kcm.socket -#. Start another container that will represent an application. Make sure the container mounts the volume from the ``kcmserver`` instance:: +#. Start another container that will represent an application. Make sure + the container mounts the volume from the ``kcmserver`` instance:: host # docker run -t -i --name=kcmclient -h=kcmclient --volumes-from=kcmserver fedora /bin/bash -#. Observe that the container mounted the volume and the volume includes the KCM server socket:: +#. Observe that the container mounted the volume and the volume includes + the KCM server socket:: kcmclient # ll /kcmserver/kcm.socket srw-rw-rw-. 1 root root 0 Nov 29 16:21 /kcmserver/kcm.socket -#. Configure ``/etc/krb5.conf`` to use ``KCM:`` as the credentials cache and point libkrb5 to the KCM socket:: +#. Configure ``/etc/krb5.conf`` to use ``KCM:`` as the credentials cache + and point libkrb5 to the KCM socket:: kcmclient # grep default_ccache_name /etc/krb5.conf default_ccache_name = KCM: @@ -440,7 +497,10 @@ The containers must also share the credential caches between one another. host # klist klist: Matching credential not found -#. Start another container as another KCM client, configure its ``krb5.conf`` configuration file in the same manner. As long as this container runs as the same UID as the first KCM client, the credentials should be visible in this container immediatelly without having to acquire them:: +#. Start another container as another KCM client, configure its ``krb5.conf`` + configuration file in the same manner. As long as this container runs as + the same UID as the first KCM client, the credentials should be visible + in this container immediatelly without having to acquire them:: kcmclient2 # klist Ticket cache: KCM:0 From 2b1b8e120d7e157ba436fe64165c419a28dad20f Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Apr 18 2017 08:00:47 +0000 Subject: [PATCH 3/4] cert mapping: Obey the 80-chars-per-line limit --- diff --git a/design_pages/matching_and_mapping_certificates.rst b/design_pages/matching_and_mapping_certificates.rst index 9fa6337..2854eef 100644 --- a/design_pages/matching_and_mapping_certificates.rst +++ b/design_pages/matching_and_mapping_certificates.rst @@ -514,7 +514,8 @@ Future consideration *(The following section was used to discuss an alternative syntax for mapping rules. It was decided that LDAP search filter syntax is more flexible and better suited for a start)* -A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ``:``, e.g: +A mapping rule can use a similar syntax like the matching rule where the +LDAP attribute can be added with a ``:``, e.g: * ```` * ```` @@ -553,7 +554,8 @@ values are needed: * ``/regexp/replacement/`` * ``/regexp/replacement/`` -where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like:: +where "/regexp/replacement/" stands for optional sed-like substitution +rules. E.g. a rule like:: /^CN=\([^,]*\).*$/\1/ @@ -570,7 +572,11 @@ 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. -Maybe even search-and-replace are not sufficient for all cases and something like embedded lua scripts are needed. But since certificate mapping is about access control and authorization it should be always considered if adding a new attribute to the users LDAP entry which makes mapping easy and straight-forward wouldn't be the better solution. +Maybe even search-and-replace are not sufficient for all cases and something +like embedded lua scripts are needed. But since certificate mapping is +about access control and authorization it should be always considered if +adding a new attribute to the users LDAP entry which makes mapping easy +and straight-forward wouldn't be the better solution. Storing matching and mapping configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From b22f9611de088bb54098d4c8682c638195f70b4d Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Apr 18 2017 08:12:25 +0000 Subject: [PATCH 4/4] non-POSIX support: Obey the 80-characters limit --- diff --git a/design_pages/non_posix_support.rst b/design_pages/non_posix_support.rst index 010dca9..ec3de1c 100644 --- a/design_pages/non_posix_support.rst +++ b/design_pages/non_posix_support.rst @@ -27,8 +27,9 @@ Use cases 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 `_ - * As an application developer, I want to authenticate users to my application using - the `mod_authnz_pam `_ module even if + * As an application developer, I want to authenticate users to my + application using the + `mod_authnz_pam `_ module even if the users lack PAM attributes. Overview of the solution @@ -52,13 +53,13 @@ for several reasons: * 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. + 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. + 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 @@ -172,7 +173,8 @@ 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, at the moment there -is a `bug in mod_lookup_identity `_ +is a `bug in mod_lookup_identity +`_ that prevents the non-POSIX lookups from working. However, isolated testing can be performed as well. All tests expect that the @@ -185,7 +187,8 @@ https://pagure.io/SSSD/sssd/issue/3292. 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 + #. SSSD with only the ``application`` domain can be reached through + the D-Bus and PAM interfaces * Add a domain as follows:: @@ -230,7 +233,8 @@ mix of POSIX and non-POSIX groups in the mixed scenario setups. doesn't try to canonicalize the user with NSS calls like ``getpwnam()`` itself. - #. No users or groups from the application domain can be resolved through the system interfaces + #. No users or groups from the 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. @@ -238,7 +242,8 @@ mix of POSIX and non-POSIX groups in the mixed scenario setups. * 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 + #. 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:: @@ -263,25 +268,30 @@ mix of POSIX and non-POSIX groups in the mixed scenario setups. 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 + * 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. + * ``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. + 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. + * 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 + #. 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