From 9171c6ccf7c48c73068e72fe4e5f7ed110b888f4 Mon Sep 17 00:00:00 2001 From: Ngairangbam Mili Date: Tue, 16 Jul 2024 09:40:50 +0000 Subject: [PATCH] Procedure to add LDAP users to Linux groups using pam configuration Change-Id: I6e35e6124231744b454601cd36d507cf34e3c8e5 Signed-off-by: Ngairangbam Mili --- ...s-using-pamcconfiguration-d31d95e255e1.rst | 141 +++++++++++ .../kubernetes/create-ldap-linux-accounts.rst | 15 ++ .../manage-local-ldap-39fe3a85a528.rst | 7 + .../overview-of-system-accounts.rst | 1 + .../kubernetes/sssd-support-5fb6c4b0320b.rst | 232 ------------------ 5 files changed, 164 insertions(+), 232 deletions(-) create mode 100644 doc/source/security/kubernetes/add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1.rst diff --git a/doc/source/security/kubernetes/add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1.rst b/doc/source/security/kubernetes/add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1.rst new file mode 100644 index 000000000..d1a843598 --- /dev/null +++ b/doc/source/security/kubernetes/add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1.rst @@ -0,0 +1,141 @@ +.. WARNING: Add no lines of text between the label immediately following +.. and the title. + +.. _add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1: + +====================================================== +Add LDAP Users to Linux Groups Using PAM Configuration +====================================================== + +The Linux pam_group module enables binding/mapping of |LDAP| users/groups to a +specified list of one or more Linux groups. The mapping will occur after the +|SSSD| service has discovered the |LDAP| users and groups and cached them on the +host. + +The mapping between the discovered |LDAP| users and their group membership to the +local Linux groups works for all Linux groups, including system groups, such as +``sudo`` and ``root``. + +.. note:: + + The procedure described in this section applies to all the |LDAP| users, both local + OpenLDAP and |LDAP| users in the remote Windows Active Directory servers. + +.. rubric:: |proc| + +Perform the following |PAM| configuration on all the hosts after the system is installed: + +#. To configure pam_group module, add the following line to the top of the + ``/etc/pam.d/common-auth`` file after the comments. + + .. code-block:: + + auth required pam_group.so use_first_pass + +#. Update ``/etc/security/group.conf`` with |LDAP| groups mapping to Linux groups. + + For each |LDAP| group mapping to a local Linux group(s), the following line + needs to be added to the bottom of the ``/etc/security/group.conf`` file + using the format ``services;ttys;users;times;groups``: + + .. code-block:: + + *;*;%;Al0000-2400; + + Where, ``Al0000-2400`` stands for times. It is used to indicate when these + groups are available to the user. The times format is a logical list + of day/time-range entries. ``Al`` stands for all seven days of the week. + + Each day/time-range can be prefixed with a `!` to indicate `anything but`. + + The time-range part is two 24-hour times HHMM separated by a hyphen + that indicates the start and finish time. More information on the line format + can be found in the file ``/etc/security/group.conf``. + + For example: + + .. code-block:: + + *;*;%pvtest@wad.mydomain.com;Al0000-2400;sys_protected,root,sudo + + The example above can be read as: For all services and all ttys, members(%) + of ``pvtest@wad.mydomain.com`` group, for all days and times (Al0000-2400), + add these users to the following local Linux groups:  ``sys_protected``, + ``root``, and ``sudo``. + + .. note:: + + The pam_group configuration will enforce the |LDAP| group membership in Linux + groups, after a |LDAP| mapped group member is successfully authenticated in the + platform, either with |ssh| or direct login. + +After the login of a |LDAP| user that is part of a mapped |LDAP| group, you can +view the new membership to Linux groups. The |LDAP| user memberships and +privileges set with the above example mapping gives a user the following sudo +privileges: + +|WAD| user example: + +.. code-block:: + + Last login: Mon Jul 8 12:53:12 2024 from 10.10.10.1 + pvtest1@wad.mydomain.com@controller-0:~$ source /etc/platform/openrc + [pvtest1@wad.mydomain.com@controller-0 ~(keystone_admin)]$ sudo su + Password: + root@controller-0:/var/home/wad.mydomain.com/pvtest1# groups + root + root@controller-0:/var/home/wad.mydomain.com/pvtest1# exit + exit + [pvtest1@wad.mydomain.com@controller-0 ~(keystone_admin)]$ groups + eng@wad.mydomain.com root sudo sys_protected pvtest@wad.mydomain.com + +Local OpenLDAP user example: + +Add the line ``;%managers;Al0000-2400;sys_protected,root,sudo`` in +``/etc/security/group.conf`` to map users of the local OpenLDAP group +``managers`` to linux groups: ``sys_protected``, ``root`` and ``sudo``. + +Log in with user ``johndole`` from ``managers`` group and check the user's +group memberships and privileges. + +.. code-block:: + + johndole@controller-0:~$ id + uid=10007(johndole) gid=100(users) groups=100(users),0(root),27(sudo),345(sys_protected),10001(managers) + johndole@controller-0:~$ source /etc/platform/openrc + [johndole@controller-0 ~(keystone_admin)]$ kubectl config get-contexts + CURRENT NAME CLUSTER AUTHINFO NAMESPACE + * kubernetes-admin@kubernetes kubernetes kubernetes-admin + + [johndole@controller-0 ~(keystone_admin)]$ groups + users root sudo sys_protected managers + [johndole@controller-0 ~(keystone_admin)]$ + + [johndole@controller-0 ~(keystone_admin)]$ sudo -l + Password: + Matching Defaults entries for johndole on controller-0: + env_reset, mail_badpass, + secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, + lecture=never, + secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin, + lecture=never, + secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin, + passprompt="Password: " + + User johndole may run the following commands on controller-0: + (ALL : ALL) ALL + (ALL) ALL + [johndole@controller-0 ~(keystone_admin)]$ + + + + + + + + + + + + + diff --git a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst index 02af8187e..6ea881a76 100644 --- a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst +++ b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst @@ -82,6 +82,13 @@ For convenience, identify the user's Keystone account user name in |prod-long|. Add teamadmin to sudoer list? (yes/NO): yes Successfully added sudo access for user teamadmin to LDAP + .. note:: + + There is another procedure to add ``sudo`` capabilities to a local |LDAP| + linux account. For details, see :ref:`add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1`. + It is recommended to use either of the procedures but not both to + avoid overlapping. + #. Specify a secondary user group for this |LDAP| user. For example, ``sys_protected group``. The purpose of having OpenLDAP/WAD users as a part of the ``sys_protected`` group on the |prod| @@ -98,6 +105,14 @@ For convenience, identify the user's Keystone account user name in |prod-long|. Secondary group to add user to? [sys_protected]: Successfully added user teamadmin to group cn=sys_protected,ou=Group,dc=cgcs,dc=local + .. note:: + + There is another procedure to add ``sys_protected`` capabilities to + a local |LDAP| linux account. For details, see + :ref:`add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1`. + It is recommended to use either of the procedures but not both to + avoid overlapping. + #. Change the password duration. .. code-block:: none diff --git a/doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst b/doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst index 8e6c6b258..7ed39cfc1 100644 --- a/doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst +++ b/doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst @@ -162,6 +162,13 @@ Extra-vars parameter options: Specifies the number of days before password expiration that the Local |LDAP| user is warned. +.. note:: + + There is another procedure to set ``sudo`` and ``sys_protected`` capabilities for a + local |LDAP| account. For details, see + :ref:`add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1`. + It is recommended to use either of the procedures but not both to avoid + overlapping. --------------------------------------------- Use the created composite Local LDAP accounts diff --git a/doc/source/security/kubernetes/overview-of-system-accounts.rst b/doc/source/security/kubernetes/overview-of-system-accounts.rst index 39c212f29..50e8fbc3f 100644 --- a/doc/source/security/kubernetes/overview-of-system-accounts.rst +++ b/doc/source/security/kubernetes/overview-of-system-accounts.rst @@ -54,3 +54,4 @@ For more information, refer to the following: kubernetes-cli-from-local-ldap-linux-account-login manage-local-ldap-39fe3a85a528 selectively-disable-ssh-for-local-openldap-and-wad-users-e5aaf09e790c + add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1 diff --git a/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst b/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst index 79315e0a8..4f55490c4 100644 --- a/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst +++ b/doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst @@ -330,238 +330,6 @@ The |WAD| users home directories created on the platform will not be removed after the |WAD| domain configuration is removed. It is administrator's responsibility to clean up users' home directories that are no longer used. ------------------------------------------- -SUDO Capability and Local Group Membership ------------------------------------------- - -This section describes how to enable the ``sudo`` and ``sys_protected`` privileges -for configured users in |WAD| servers. - -The Linux specification stipulates that the GUID values in the range 0 to 99 -should be statically allocated by the system and shall not be created by -applications. Therefore, a ``sudo`` group with GUID 27 and the ``root`` group -GUID 0 are special groups that cannot be created by the |SSSD| client interfacing -with the |WAD| server. - -The ``sudo`` privileges can be assigned to |WAD| users using the ``sudo rules`` mechanism. - -``Sudo rules`` are access control rules that define the users who are granted access, -the commands a user has access to, and the target hosts to which the rules -apply. - -Enable Sudo Privileges for WAD Users -------------------------------------- - -You can enable ``sudo All`` privileges for LDAP users from a remote |WAD| server. -Enabling ``sudo`` privileges allows the LDAP users to execute the following -operations: - -- ``sw_patch`` to unauthenticated endpoint -- ``docker`` and/or ``crictl`` commands to communicate with the respective daemons -- Utilities ``show-certs.sh`` and ``license-install`` (recovery only) -- IP configuration for local network setup -- Password change of local openldap users -- Access to restricted files, example: restricted logs -- Manual reboots - -Load Sudo Schema in WAD LDAP Server ------------------------------------ - -The ``sudo rules`` schema is not a part of standard |WAD| installation. For |WAD| -servers, the schema needs to be loaded and installed using the ``ldifde`` -utility. - -LDAP ``sudo rules`` schema is contained in the package ``libsss-sudo``. The -schema will be loaded in ``/usr/share/doc/sudo-ldap/schema.ActiveDirectory.gz`` -during system installation. - -Install Schema --------------- - -.. rubric:: |proc| - -#. Extract the schema from ``schema.ActiveDirectory.gz`` and copy it in a file - on the |WAD| server. - -#. Install the schema by running the following command on the |WAD| server: - - .. code-block:: none - - ldifde -v -i -f ``schema.ActiveDirectory.txt`` -j - -.. rubric:: |result| - -The following shows the successful loading of a schema: - -.. code-block:: none - - Importing directory from file ``schema.ActiveDirectory.txt`` - Loading entries - ……. - 12 entries modified successfully. - The command has completed successfully - -Create Directory Entry for Sudo Rules in WAD Server ---------------------------------------------------- - -The ``sudoers`` OU needs to be created on the domain root. This OU will hold all -the ``sudo rules`` defined using ``sudoRole`` object. - -.. note:: - - The ``sudoers`` OU directory path will be automatically set as the - ``ldap_sudo_search_base`` parameter value in the sssd configuration file - ``/etc/sssd/sssd.conf``. The ``ldap_search_base`` parameter - must be set at the same level in the domain root as shown in the following example: - - .. code-block:: none - - ldap_search_base = CN=Users,DC=domain,DC=com (set using ``system service-parameter`` command) - ldap_sudo_search_base = OU=sudoers,DC=domain,DC=com (pre-configured in sssd configuration) - -.. rubric:: |proc| - -#. Create an ``ldif`` file with the following content: - - .. code-block:: none - - dn: OU=sudoers,DC= dc=domain,DC=com - changetype: add - objectClass: top - objectClass: organizationalUnit - ou: sudoers - -#. Import the file by running the following command on the |WAD| server: - - .. code-block:: none - - ldifde -v -i -f "sudoers_ou.txt" -j - - where, ``sudoers_ou.txt`` is the ``ldif`` file created in the previous step. - -.. rubric:: |result| - -The following shows the successful loading of the ``ldif`` file: - -.. code-block:: none - - Connecting to ``ad.domain.com`` - Logging in as current user using SSPI - Importing directory from file "sudoers_ou.txt" - Loading entries - 1: OU=sudoers,DC=domain,DC=com - Entry modified successfully - -Create a Sudo Rule for a WAD User ---------------------------------- - -.. rubric:: |proc| - -#. To assign ``sudo All`` privileges to a |WAD| user with name ``techadmin``, create - and load the following ``ldif`` file content: - - .. code-block:: none - - dn: CN=techadmin,OU=sudoers,DC=domain,DC=com - changetype: add - objectClass: top - objectClass: sudoRole - cn: techadmin - distinguishedName: CN=techadmin,OU=sudoers,DC=domain,DC=com - name: techadmin - sudoUser: techadmin - sudoHost: ALL - sudoRunAsUser: ALL - sudoCommand: ALL - -#. Load the ``ldif`` file by running the following command on the |WAD| server: - - .. code-block:: none - - ldifde -v -i -f "sudo-rule.txt" -j - - where, ``sudo-rule.txt`` is the ``ldif`` file created in the previous step. - -.. rubric:: |result| - -The following shows the successful loading of the ``ldif`` file: - -.. code-block:: none - - Connecting to "ad.domain.com" - Logging in as current user using SSPI - Importing directory from file "sudo-rule.txt" - Loading entries - 1: CN=techadmin,OU=sudoers,DC=domain,DC=com - Entry modified successfully. - 1 entry modified successfully. - The command has completed successfully - -The ``sudo rules`` will be discovered by sssd service and cached in the |prod| -platform. The sssd logs in ``/var/log/sssd/sssd_ad.domain.log`` will show the -number of rules downloaded from |WAD| server that indicates that the ``sudo rules`` -were received. - -.. code-block:: none - - (2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_search_bases_ex_donee] (0x0400): Receiving data from base [OU=sudoers,DC=domain,DC=com] - (2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_load_sudoers_done] (0x0200): Received 1 sudo rules - (2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_refresh_done] (0x0400): Received 1 rules - -Verify Sudo All Privileges for the WAD Sudo User ------------------------------------------------- - -SSH to the |prod| platform using the ``sudo`` user and verify that the user has -``sudo All`` privileges. - -.. code-block:: none - - techadmin@controller-0:~$ sudo -l - Password: - Matching Defaults entries for techadmin on controller-0: - env_reset, mail_badpass, - secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, - lecture=never, - secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin, - lecture=never, - secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin, - passprompt="Password: " - - User techadmin may run the following commands on controller-0: - (ALL) ALL - techadmin@controller-0:~$ - -Creating a User in the Linux Sys_protected Group on a WAD Server ----------------------------------------------------------------- - -Create a ``sys_protected`` group in the |WAD| server and set the ``gidNumber`` to -345 to be the same as Linux ``sys_protected`` group. Add a |WAD| user (example: -techadmin) as a member in the ``sys_protected`` group. The ``sys_protected`` -LDAP group and its member will be discovered and cached in the |prod| platform -by SSSD service. - -To check if the |WAD| user has been added to the ``sys_protected`` group, SSH to -|prod| as the |WAD| user and check the groups the user is a member of. - -.. code-block:: none - - Linux controller-0 5.10.0-6-amd64 #1 SMP PREEMPT StarlingX Debian 5.10.162-1.stx.64 (2023-02-16) x86_64 - Last login: Fri Mar 10 22:20:16 2023 from 10.10.10.254 - techadmin@controller-0:~$ groups - domain users sys_protected - techadmin@controller-0:~$ - -.. note:: - - When creating a |WAD| user that will be discovered and created on the - |prod| Linux host as part of the ``users`` group, set the |WAD| user GUID value - to 100 that is the same as that of the Linux ``users`` group. The |WAD| user - UID should be set to a unique value within the Linux ``users`` group. - - When a new |WAD| user is created using the Active Directory Users and Group - Administration tool, the **User must change password at next login** - checkbox must be unchecked, otherwise the user login to the |prod| host will fail. - ------------------------------------------- Default Local OpenLDAP Domain Configuration -------------------------------------------