Procedure to add LDAP users to Linux groups using pam configuration
Change-Id: I6e35e6124231744b454601cd36d507cf34e3c8e5 Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili
parent
d663b2122b
commit
9171c6ccf7
@ -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)]$
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
-------------------------------------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user