starlingx/docs
Code Issues Proposed changes

Merge "Procedure to add LDAP users to Linux groups using pam configuration"

Browse Source
This commit is contained in:
Zuul 2024-07-31 14:14:10 +00:00 committed by Gerrit Code Review
commit ba81107a9f
5 changed files with 164 additions and 232 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
doc/source/security/kubernetes/add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1.rst Normal file
View File

@ -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::
*;*;%<fully qualified wad group name>;Al0000-2400;<list of local Linux groups>
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)]$

15
doc/source/security/kubernetes/create-ldap-linux-accounts.rst
View File

@ -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 Add teamadmin to sudoer list? (yes/NO): yes
Successfully added sudo access for user teamadmin to LDAP 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``. #. 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| 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]: Secondary group to add user to? [sys_protected]:
Successfully added user teamadmin to group cn=sys_protected,ou=Group,dc=cgcs,dc=local 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. #. Change the password duration.
.. code-block:: none .. code-block:: none

7
doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst
View File

@ -162,6 +162,13 @@ Extra-vars parameter options:
Specifies the number of days before password expiration that the Local Specifies the number of days before password expiration that the Local
|LDAP| user is warned. |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 Use the created composite Local LDAP accounts

1
doc/source/security/kubernetes/overview-of-system-accounts.rst
View File

@ -54,3 +54,4 @@ For more information, refer to the following:
kubernetes-cli-from-local-ldap-linux-account-login kubernetes-cli-from-local-ldap-linux-account-login
manage-local-ldap-39fe3a85a528 manage-local-ldap-39fe3a85a528
selectively-disable-ssh-for-local-openldap-and-wad-users-e5aaf09e790c selectively-disable-ssh-for-local-openldap-and-wad-users-e5aaf09e790c
add-ldap-users-to-linux-groups-using-pamcconfiguration-d31d95e255e1

232
doc/source/security/kubernetes/sssd-support-5fb6c4b0320b.rst
View File

@ -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 after the |WAD| domain configuration is removed. It is administrator's
responsibility to clean up users' home directories that are no longer used. 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 Default Local OpenLDAP Domain Configuration
------------------------------------------- -------------------------------------------