Local/WAD ldap users sudo and local linux group assignment (stx 9.0)
Added "sudo" and "sys_protected" privileges support for LDAP servers accessed using SSSD service Story: 2010589 Task: 49410 Change-Id: Ia05edc04feb465c1b59a2a1e4cff26218b144788 Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili
parent
b8d3ae4f68
commit
93e265fbf3
@ -57,19 +57,46 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Enter username to add to LDAP:
|
||||
Enter username to add to LDAP: teamadmin
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Successfully added user user1 to LDAP
|
||||
Successfully set password for user user1
|
||||
Successfully added user teamadmin to LDAP
|
||||
Successfully set password for user teamadmin
|
||||
Warning : password is reset, user will be asked to change password at login
|
||||
|
||||
#. Specify whether the user should have sudo capabilities or not.
|
||||
Enabling ``sudo`` privileges allows the LDAP users to execute the
|
||||
following operations:
|
||||
|
||||
#. Specify a secondary user group for this |LDAP| user.
|
||||
- ``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
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Add teamadmin to sudoer list? (yes/NO): yes
|
||||
Successfully added sudo access for user teamadmin to LDAP
|
||||
|
||||
#. 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|
|
||||
platform is to allow them to execute the |prod| system operations via
|
||||
``source/etc/platform/openrc``. The LDAP user in the ``sys_protected`` group will be
|
||||
equivalent to the special ``sysadmin`` bootstrap user, and will have the following:
|
||||
|
||||
- Keystone admin/admin identity and credentials
|
||||
- Kubernetes ``/etc/kubernetes/admin.conf`` credentials
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Add user1 to secondary user group (yes/No):
|
||||
Add teamadmin to secondary user group? (yes/NO): yes
|
||||
Secondary group to add user to? [sys_protected]:
|
||||
Successfully added user teamadmin to group cn=sys_protected,ou=Group,dc=cgcs,dc=local
|
||||
|
||||
#. Change the password duration.
|
||||
|
||||
@ -90,6 +117,7 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Successfully modified user entry uid=teamadmin,ou=People,dc=cgcs,dc=local in LDAP
|
||||
Updating password expiry to 2 days
|
||||
|
||||
|
||||
|
||||
@ -118,6 +118,7 @@ HTTPS Certificate Management
|
||||
etcd-certificates-c1fc943e4a9c
|
||||
kubernetes-certificates-f4196d7cae9c
|
||||
starlingx-rest-api-applications-and-the-web-admin-server-cert-9196c5794834
|
||||
local-ldap-certificates-4e1df1e39341
|
||||
configure-rest-api-apps-and-web-admin-server-certs-after-inst-6816457ab95f
|
||||
configure-docker-registry-certificate-after-installation-c519edbfe90a
|
||||
oidc-client-dex-server-certificates-dc174462d51a
|
||||
|
||||
@ -0,0 +1,52 @@
|
||||
.. _local-ldap-certificates-4e1df1e39341:
|
||||
|
||||
=======================
|
||||
Local LDAP Certificates
|
||||
=======================
|
||||
|
||||
The local |LDAP| server by default serves both HTTPS on port 636 and HTTP on port 389.
|
||||
|
||||
The HTTPS server certificate is issued by cert-manager ClusterIssuer
|
||||
``system-local-ca`` and is managed internally by cert-manager. The certificate
|
||||
will be automatically renewed when the expiration date approaches. The
|
||||
certificate is called ``system-openldap-local-certificate`` with its secret
|
||||
having the same name ``system-openldap-local-certificate`` in the
|
||||
``deployment`` namespace. The server certificate and private key files are
|
||||
stored in the ``/etc/ldap/certs/`` system directory.
|
||||
|
||||
In |DC| system, the |LDAP| service runs only in the central cloud. Clients in
|
||||
the subcloud (|SSSD|, |LDAP| client tools) are configured so that they can
|
||||
access the |LDAP| services in the central cloud using HTTPS. Thus,
|
||||
``system-local-ca`` ClusterIssuer's certificate is installed in the subcloud as
|
||||
a trusted |CA| certificate.
|
||||
|
||||
The insecure HTTP service is only supported for backward compatibility with
|
||||
subclouds running older versions of |prod| that supports only HTTP. If no such
|
||||
subclouds are present, the insecure HTTP service can be disabled by system
|
||||
service parameter.
|
||||
|
||||
Run the following command to disable the insecure service:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
~(keystone_admin)]$ system service-parameter-add identity local-openldap insecure_service=disabled
|
||||
|
||||
If the service parameter already exists, run the following command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
~(keystone_admin)]$ system service-parameter-modify identity local-openldap insecure_service=disabled
|
||||
|
||||
The insecure service can be enabled if it has been disabled. Run the following
|
||||
command to enable the insecure service:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
~(keystone_admin)]$ system service-parameter-modify identity local-openldap insecure_service=enabled
|
||||
|
||||
After disabling or enabling the insecure local-openldap service, for the change
|
||||
to take effect, apply the service parameter by running the following command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
~(keystone_admin)]$ system service-parameter-apply identity --section local-openldap
|
||||
@ -7,7 +7,7 @@ SSH User Authentication using Windows Active Directory (WAD)
|
||||
By default, |SSH| to |prod| hosts supports authentication using the 'sysadmin'
|
||||
Local Linux Account and |prod| Local |LDAP| Linux User Accounts. |SSH| can
|
||||
also be optionally configured to support authentication with 1 or more remote
|
||||
|LDAP| identity providers (such as Windows Active Directory (WAD)). Internally,
|
||||
|LDAP| identity providers (such as |WAD|). Internally,
|
||||
|SSH| uses |SSSD| service to provide NSS and PAM interfaces and a backend
|
||||
system able to remotely connect to multiple different |LDAP| domains.
|
||||
|
||||
@ -56,7 +56,6 @@ The command to add |WAD| |CA| certificate:
|
||||
|
||||
system certificate-install --mode ssl_ca <AD CA certificate file>
|
||||
|
||||
|
||||
---------------------
|
||||
Add Remote WAD Domain
|
||||
---------------------
|
||||
@ -163,7 +162,7 @@ follows:
|
||||
Default WAD Domain Configuration
|
||||
---------------------------------
|
||||
|
||||
The default WAD domain configuration parameters are pre-configured. Main |SSSD|
|
||||
The default |WAD| domain configuration parameters are pre-configured. Main |SSSD|
|
||||
default configuration settings include:
|
||||
|
||||
- Offline Authentication is enabled, allowing users to still authenticate
|
||||
@ -280,19 +279,233 @@ responsibility to clean up users' home directories that are no longer used.
|
||||
SUDO Capability and Local Group Membership
|
||||
------------------------------------------
|
||||
|
||||
Support of sudo users and local linux group membership (e.g. ``sys_protected``)
|
||||
in |prod| platform is done locally after |WAD| users have been discovered by
|
||||
|SSSD|.
|
||||
This section describes how to enable the ``sudo`` and ``sys_protected`` privileges
|
||||
for configured users in |WAD| servers.
|
||||
|
||||
For example:
|
||||
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
|
||||
|
||||
# To add the WAD-discovered user "pvtest1" to the group 'sudo'
|
||||
sudo usermod -a -G sudo pvtest1@ad.wad-server.com
|
||||
Importing directory from file ``schema.ActiveDirectory.txt``
|
||||
Loading entries
|
||||
…….
|
||||
12 entries modified successfully.
|
||||
The command has completed successfully
|
||||
|
||||
# To add the WAD-discovered user "pvtest1" to the group 'sys_protected'
|
||||
sudo usermod -a -G sys_protected pvtest1@ad.wad-server.com
|
||||
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