Chapter 8. Configuring smart card authentication with the web console for centrally managed users
Chapter 8. Configuring smart card authentication with the web console for centrally managed users You can configure smart card authentication in the RHEL web console for users who are centrally managed by: Identity Management Active Directory which is connected in the cross-forest trust with Identity Management Prerequisites The system for which you want to use the smart card authentication must be a member of an Active Directory or Identity Management domain. For details about joining the RHEL 9 system into a domain using the web console, see Joining a RHEL system to an IdM domain using the web console . The certificate used for the smart card authentication must be associated with a particular user in Identity Management or Active Directory. For more details about associating a certificate with the user in Identity Management, see Adding a certificate to a user entry in the IdM Web UI or Adding a certificate to a user entry in the IdM CLI . 8.1. Smart card authentication for centrally managed users A smart card is a physical device, which can provide personal authentication using certificates stored on the card. Personal authentication means that you can use smart cards in the same way as user passwords. You can store user credentials on the smart card in the form of a private key and a certificate. Special software and hardware is used to access them. You insert the smart card into a reader or a USB socket and supply the PIN code for the smart card instead of providing your password. Identity Management (IdM) supports smart card authentication with: User certificates issued by the IdM certificate authority. User certificates issued by the Active Directory Certificate Service (ADCS) certificate authority. Note If you want to start using smart card authentication, see the hardware requirements: Smart Card support in RHEL8+ . 8.2. Installing tools for managing and using smart cards Prerequisites The gnutls-utils package is installed. The opensc package is installed. The pcscd service is running. Before you can configure your smart card, you must install the corresponding tools, which can generate certificates and start the pscd service. Procedure Install the opensc and gnutls-utils packages: Start the pcscd service. Verification Verify that the pcscd service is up and running 8.3. Preparing your smart card and uploading your certificates and keys to your smart card Follow this procedure to configure your smart card with the pkcs15-init tool, which helps you to configure: Erasing your smart card Setting new PINs and optional PIN Unblocking Keys (PUKs) Creating a new slot on the smart card Storing the certificate, private key, and public key in the slot If required, locking the smart card settings as certain smart cards require this type of finalization Note The pkcs15-init tool may not work with all smart cards. You must use the tools that work with the smart card you are using. Prerequisites The opensc package, which includes the pkcs15-init tool, is installed. For more details, see Installing tools for managing and using smart cards . The card is inserted in the reader and connected to the computer. You have a private key, a public key, and a certificate to store on the smart card. In this procedure, testuser.key , testuserpublic.key , and testuser.crt are the names used for the private key, public key, and the certificate. You have your current smart card user PIN and Security Officer PIN (SO-PIN). Procedure Erase your smart card and authenticate yourself with your PIN: The card has been erased. Initialize your smart card, set your user PIN and PUK, and your Security Officer PIN and PUK: The pcks15-init tool creates a new slot on the smart card. Set a label and the authentication ID for the slot: The label is set to a human-readable value, in this case, testuser . The auth-id must be two hexadecimal values, in this case it is set to 01 . Store and label the private key in the new slot on the smart card: Note The value you specify for --id must be the same when storing your private key and storing your certificate in the step. Specifying your own value for --id is recommended as otherwise a more complicated value is calculated by the tool. Store and label the certificate in the new slot on the smart card: Optional: Store and label the public key in the new slot on the smart card: Note If the public key corresponds to a private key or certificate, specify the same ID as the ID of the private key or certificate. Optional: Certain smart cards require you to finalize the card by locking the settings: At this stage, your smart card includes the certificate, private key, and public key in the newly created slot. You have also created your user PIN and PUK and the Security Officer PIN and PUK. 8.4. Enabling smart card authentication for the web console To use smart card authentication in the web console, enable this authentication method in the cockpit.conf file. Additionally, you can disable password authentication in the same file. Prerequisites You have installed the RHEL 9 web console. For instructions, see Installing and enabling the web console . Procedure Log in to the RHEL 9 web console. For details, see Logging in to the web console . Click Terminal . In the /etc/cockpit/cockpit.conf , set the ClientCertAuthentication to yes : Optional: Disable password based authentication in cockpit.conf with: This configuration disables password authentication and you must always use the smart card. Restart the web console to ensure that the cockpit.service accepts the change: 8.5. Logging in to the web console with smart cards You can use smart cards to log in to the web console. Prerequisites A valid certificate stored in your smart card that is associated to a user account created in a Active Directory or Identity Management domain. PIN to unlock the smart card. The smart card has been put into the reader. You have installed the RHEL 9 web console. For instructions, see Installing and enabling the web console . Procedure Log in to the RHEL 9 web console. For details, see Logging in to the web console . The browser asks you to add the PIN protecting the certificate stored on the smart card. In the Password Required dialog box, enter PIN and click OK . In the User Identification Request dialog box, select the certificate stored in the smart card. Select Remember this decision . The system does not open this window time. Note This step does not apply to Google Chrome users. Click OK . You are now connected and the web console displays its content. 8.6. Enabling passwordless sudo authentication for smart card users You can configure passwordless authentication to sudo and other services for smart card users in the web console. As an alternative, if you use Red Hat Enterprise Linux Identity Management, you can declare the initial web console certificate authentication as trusted for authenticating to sudo , SSH, or other services. For that purpose, the web console automatically creates an S4U2Proxy Kerberos ticket in the user session. Prerequisites Identity Management installed. Active Directory connected in the cross-forest trust with Identity Management. Smart card set up to log in to the web console. See Configuring smart card authentication with the web console for centrally managed users for more information. Procedure Set up constraint delegation rules to list which hosts the ticket can access. Example 8.1. Setting up constraint delegation rules The web console session runs host host.example.com and should be trusted to access its own host with sudo . Additionally, we are adding second trusted host - remote.example.com . Create the following delegation: Run the following commands to add a list of target machines a particular rule can access: To allow the web console sessions (HTTP/principal) to access that host list, use the following commands: Enable GSS authentication in the corresponding services: For sudo, enable the pam_sss_gss module in the /etc/sssd/sssd.conf file: As root, add an entry for your domain to the /etc/sssd/sssd.conf configuration file. Enable the module in the /etc/pam.d/sudo file on the first line. For SSH, update the GSSAPIAuthentication option in the /etc/ssh/sshd_config file to yes . Warning The delegated S4U ticket is not forwarded to remote SSH hosts when connecting to them from the web console. Authenticating to sudo on a remote host with your ticket will not work. Verification Log in to the web console using a smart card. Click the Limited access button. Authenticate using your smart card. Alternatively: Try to connect to a different host with SSH. 8.7. Limiting user sessions and memory to prevent a DoS attack A certificate authentication is protected by separating and isolating instances of the cockpit-ws web server against attackers who wants to impersonate another user. However, this introduces a potential denial of service (DoS) attack: A remote attacker could create a large number of certificates and send a large number of HTTPS requests to cockpit-ws each using a different certificate. To prevent such DoS attacks, the collective resources of these web server instances are limited. By default, limits for the number of connections and memory usage are set to 200 threads and 75 % (soft) or 90 % (hard) memory limit. The example procedure demonstrates resource protection by limiting the number of connections and memory. Procedure In the terminal, open the system-cockpithttps.slice configuration file: Limit the TasksMax to 100 and CPUQuota to 30% : To apply the changes, restart the system: Now, the new memory and user session lower the risk of DoS attacks on the cockpit-ws web server. 8.8. Additional resources Configuring Identity Management for smart card authentication . Configuring certificates issued by ADCS for smart card authentication in IdM . Configuring and importing local certificates to a smart card .
dnf -y install opensc gnutls-utils systemctl start pcscd systemctl status pcscd pkcs15-init --erase-card --use-default-transport-keys Using reader with a card: Reader name PIN [Security Officer PIN] required. Please enter PIN [Security Officer PIN]: pkcs15-init --create-pkcs15 --use-default-transport-keys --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123 Using reader with a card: Reader name pkcs15-init --store-pin --label testuser --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478 Using reader with a card: Reader name pkcs15-init --store-private-key testuser.key --label testuser_key --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name pkcs15-init --store-certificate testuser.crt --label testuser_crt --auth-id 01 --id 01 --format pem --pin 963214 Using reader with a card: Reader name pkcs15-init --store-public-key testuserpublic.key --label testuserpublic_key --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name pkcs15-init -F [WebService] ClientCertAuthentication = yes [Basic] action = none systemctl restart cockpit ipa servicedelegationtarget-add cockpit-target ipa servicedelegationtarget-add-member cockpit-target --principals=host/host.example.com@EXAMPLE.COM --principals=host/remote.example.com@EXAMPLE.COM ipa servicedelegationrule-add cockpit-delegation ipa servicedelegationrule-add-member cockpit-delegation --principals=HTTP/host.example.com@EXAMPLE.COM ipa servicedelegationrule-add-target cockpit-delegation --servicedelegationtargets=cockpit-target [domain/example.com] pam_gssapi_services = sudo, sudo-i auth sufficient pam_sss_gss.so systemctl edit system-cockpithttps.slice change existing value TasksMax= 100 add new restriction CPUQuota= 30% systemctl daemon-reload systemctl stop cockpit