Chapter 5. 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 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.
5.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 Active Directory Certificate Service (ADCS) certificate authority.
For details, see Configuring certificates issued by ADCS for smart card authentication in IdM.
If you want to start using smart card authentication, see the hardware requirements: Smart Card support in RHEL8+.
5.2. 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 10 web console.
For instructions, see Installing and enabling the web console.
Procedure
- Log in to the RHEL 10 web console.
- Click Terminal.
In the
/etc/cockpit/cockpit.conf
, set theClientCertAuthentication
toyes
:[WebService] ClientCertAuthentication = yes
[WebService] ClientCertAuthentication = yes
Copy to Clipboard Copied! Optional: Disable password-based authentication in
cockpit.conf
with:[Basic] action = none
[Basic] action = none
Copy to Clipboard Copied! 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:systemctl restart cockpit
# systemctl restart cockpit
Copy to Clipboard Copied!
5.3. 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 10 web console.
For instructions, see Installing and enabling the web console.
Procedure
- Log in to the RHEL 10 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 next time.
NoteThis step does not apply to Google Chrome users.
- Click OK.
You are now connected and the web console displays its content.
5.4. 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 RHEL 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 is installed.
- Active Directory connected in the cross-forest trust with Identity Management.
- Your smart card is 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 5.1. Setting up constraint delegation rules
The web console session runs host
host.example.com
and should be trusted to access its own host withsudo
. 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:
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 servicedelegationtarget-add cockpit-target # ipa servicedelegationtarget-add-member cockpit-target \ --principals=host/host.example.com@EXAMPLE.COM \ --principals=host/remote.example.com@EXAMPLE.COM
Copy to Clipboard Copied! To allow the web console sessions (HTTP/principal) to access that host list, use the following commands:
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
# 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
Copy to Clipboard Copied!
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.[domain/example.com] pam_gssapi_services = sudo, sudo-i
[domain/example.com] pam_gssapi_services = sudo, sudo-i
Copy to Clipboard Copied! Enable the module in the
/etc/pam.d/sudo
file on the first line.auth sufficient pam_sss_gss.so
auth sufficient pam_sss_gss.so
Copy to Clipboard Copied!
-
For SSH, update the
GSSAPIAuthentication
option in the/etc/ssh/sshd_config
file toyes
.
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.
5.5. 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:systemctl edit system-cockpithttps.slice
# systemctl edit system-cockpithttps.slice
Copy to Clipboard Copied! Limit the
TasksMax
to 100 andCPUQuota
to 30%:[Slice] # change existing value TasksMax=100 # add new restriction CPUQuota=30%
[Slice] # change existing value TasksMax=100 # add new restriction CPUQuota=30%
Copy to Clipboard Copied! To apply the changes, restart the system:
systemctl daemon-reload systemctl stop cockpit
# systemctl daemon-reload # systemctl stop cockpit
Copy to Clipboard Copied!
Now, the new memory and user session lower the risk of DoS attacks on the cockpit-ws
web server.