Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 3. Configuring certificates issued by ADCS for smart card authentication in IdM

You can leverage Active Directory (AD) Certificate Services (ADCS) to issue credentials for IdM smart card users. This configuration integrates AD-issued certificates within an IdM environment, utilizing a cross-forest trust to authenticate users across both domains.

3.1. Prerequisites
Copiar enlace

  • Identity Management (IdM) and Active Directory (AD) trust is installed
  • Active Directory Certificate Services (ADCS) is installed and certificates for users are generated

Configuring the Windows Server involves preparing the Certificate Authority to issue compatible credentials. You must set key lengths to at least 2048 bits and enable private key export to generate valid PKCS #12 (.PFX) files.

You must configure the following on the Windows Server:

  • Active Directory Certificate Services (ADCS) is installed
  • Certificate Authority is created
  • Optional: If you are using Certificate Authority Web Enrollment, the Internet Information Services (IIS) must be configured

The exported certificate must fulfill the following criteria:

  • Key must have 2048 bits or more
  • Include a private key

  • You will need a certificate in the following format: Personal Information Exchange — PKCS #12(.PFX)

    • Enable certificate privacy

3.3. Copying certificates from Active Directory using sftp
Copiar enlace

To enable cross-platform trust, you must transfer specific certificate files from the Windows Server to the Linux environment. You must securely copying the root CA certificate to the IdM server and the user’s private key file to the client.

To be able to use smart card authentication, you need to copy the following certificate files:

  • A root CA certificate in the CER format: adcs-winserver-ca.cer on your IdM server.
  • A user certificate with a private key in the PFX format: aduser1.pfx on an IdM client.
Note

This procedure expects SSH access is allowed. If SSH is unavailable the user must copy the file from the AD Server to the IdM server and client.

Procedure

  1. Connect from the IdM server and copy the adcs-winserver-ca.cer root certificate to the IdM server: 

    root@idmserver ~]# sftp Administrator@winserver.ad.example.com
    Copy to Clipboard Toggle word wrap 
    Administrator@winserver.ad.example.com's password:
Connected to Administrator@winserver.ad.example.com.
sftp> cd <path_to_certificates>
sftp> ls
adcs-winserver-ca.cer    aduser1.pfx
sftp>
sftp> get adcs-winserver-ca.cer
Fetching <path_to_certificates>/adcs-winserver-ca.cer to adcs-winserver-ca.cer
<path_to_certificates>/adcs-winserver-ca.cer                 100%  1254    15KB/s 00:00
sftp quit
    Copy to Clipboard Toggle word wrap

  2. Connect from the IdM client and copy the aduser1.pfx user certificate to the client: 

    [root@client1 ~]# sftp Administrator@winserver.ad.example.com
    Copy to Clipboard Toggle word wrap 
    Administrator@winserver.ad.example.com's password:
Connected to Administrator@winserver.ad.example.com.
sftp> cd /<path_to_certificates>
sftp> get aduser1.pfx
Fetching <path_to_certificates>/aduser1.pfx to aduser1.pfx
<path_to_certificates>/aduser1.pfx                 100%  1254    15KB/s 00:00
sftp quit
    Copy to Clipboard Toggle word wrap

    Now the CA certificate is stored in the IdM server and the user certificates is stored on the client machine.

The ipa-advise utility automates the configuration of Identity Management (IdM) components for ADCS integration. Generate server and client scripts to install necessary packages, configure Kerberos PKINIT, and place CA certificates in the correct system directories.

Configure your server and clients for smart card authentication by choosing one of the options:

  • On an IdM server: Prepare the ipa-advise script to configure your IdM server for smart card authentication.
  • On an IdM server: Prepare the ipa-advise script to configure your IdM client for smart card authentication.
  • On an IdM server: Apply the the ipa-advise server script on the IdM server using the AD certificate.
  • Move the client script to the IdM client machine.
  • On an IdM client: Apply the the ipa-advise client script on the IdM client using the AD certificate.

Prerequisites

  • The certificate has been copied to the IdM server.
  • Obtain the Kerberos ticket.
  • Log in as a user with administration rights.

Procedure

  1. On the IdM server, use the ipa-advise script for configuring a client: 

    [root@idmserver ~]# ipa-advise config-client-for-smart-card-auth > sc_client.sh
    Copy to Clipboard Toggle word wrap

  2. On the IdM server, use the ipa-advise script for configuring a server: 

    [root@idmserver ~]# ipa-advise config-server-for-smart-card-auth > sc_server.sh
    Copy to Clipboard Toggle word wrap

  3. On the IdM server, execute the script: 

    [root@idmserver ~]# sh -x sc_server.sh adcs-winserver-ca.cer
    Copy to Clipboard Toggle word wrap
    • It configures the IdM Apache HTTP Server.
    • It enables Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) on the Key Distribution Center (KDC).
    • It configures the IdM Web UI to accept smart card authorization requests.

  4. Copy the sc_client.sh script to the client system: 

    [root@idmserver ~]# scp sc_client.sh root@client1.idm.example.com:/root
    Copy to Clipboard Toggle word wrap 
    Password:
sc_client.sh                  100%  2857   1.6MB/s   00:00
    Copy to Clipboard Toggle word wrap

  5. Copy the Windows certificate to the client system: 

    [root@idmserver ~]# scp adcs-winserver-ca.cer root@client1.idm.example.com:/root
    Copy to Clipboard Toggle word wrap 
    Password:
adcs-winserver-ca.cer                 100%  1254   952.0KB/s   00:00
    Copy to Clipboard Toggle word wrap

  6. On the client system, run the client script: 

    [root@idmclient1 ~]# sh -x sc_client.sh adcs-winserver-ca.cer
    Copy to Clipboard Toggle word wrap

    The CA certificate is now installed in the correct format on the IdM server and client systems. The next step is to copy the user certificates onto the smart card itself.

3.5. Converting the PFX file
Copiar enlace

Smart card tools require certificates and keys in specific formats. You must convert the PKCS #12 (.PFX) file exported from Active Directory into separate PEM-formatted private key and certificate files using OpenSSL.

Prerequisites

  • The PFX file is copied into the IdM client machine.

Procedure

  1. On the IdM client, convert the file into the PEM format: 

    [root@idmclient1 ~]# openssl pkcs12 -in aduser1.pfx -out aduser1_cert_only.pem -clcerts -nodes
    Copy to Clipboard Toggle word wrap 
    Enter Import Password:
    Copy to Clipboard Toggle word wrap

  2. Extract the key into the separate file: 

    [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -nocerts -out adduser1.pem > aduser1.key
    Copy to Clipboard Toggle word wrap

  3. Extract the public certificate into the separate file: 

    [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -clcerts -nokeys -out aduser1_cert_only.pem > aduser1.crt
    Copy to Clipboard Toggle word wrap

    At this point, you can store the aduser1.key and aduser1.crt into the smart card.

Managing smart card content requires specific software utilities, such as the opensc and gnutls-utils packages. You must start the pcscd service to enable communication between the system and the smart card reader.

Prerequisites

  • You have root permissions.

Procedure

  1. Install the opensc and gnutls-utils packages: 

    # dnf -y install opensc gnutls-utils
    Copy to Clipboard Toggle word wrap

  2. Start the pcscd service. 

    # systemctl start pcscd
    Copy to Clipboard Toggle word wrap

Verification

  • Verify that the pcscd service is up and running: 

    # systemctl status pcscd
    Copy to Clipboard Toggle word wrap

With the pkcs15-init tool, you can initialize smart cards and provision them with ADCS credentials. Initialization involves erasing the card, setting PINs, and uploading the converted private key and certificate files to a new storage slot.

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

  1. Erase your smart card and authenticate yourself with your PIN: 

    $ pkcs15-init --erase-card --use-default-transport-keys
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
PIN [Security Officer PIN] required.
Please enter PIN [Security Officer PIN]:
    Copy to Clipboard Toggle word wrap

    The card has been erased.

  2. Initialize your smart card, set your user PIN and PUK, and your Security Officer PIN and PUK: 

    $ pkcs15-init --create-pkcs15 --use-default-transport-keys \
    --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
    Copy to Clipboard Toggle word wrap

    The pcks15-init tool creates a new slot on the smart card.

  3. Set a label and the authentication ID for the slot: 

    $ pkcs15-init --store-pin --label testuser \
    --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
    Copy to Clipboard Toggle word wrap

    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.

  4. Store and label the private key in the new slot on the smart card: 

    $ pkcs15-init --store-private-key testuser.key --label testuser_key \
    --auth-id 01 --id 01 --pin 963214
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
    Copy to Clipboard Toggle word wrap
    Note

    The value you specify for --id must be the same when storing your private key and storing your certificate in the next step. Specifying your own value for --id is recommended as otherwise a more complicated value is calculated by the tool.

  5. Store and label the certificate in the new slot on the smart card: 

    $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \
    --auth-id 01 --id 01 --format pem --pin 963214
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
    Copy to Clipboard Toggle word wrap

  6. Optional: Store and label the public key in the new slot on the smart card: 

    $ pkcs15-init --store-public-key testuserpublic.key \
    --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
    Copy to Clipboard Toggle word wrap 
    Using reader with a card: Reader name
    Copy to Clipboard Toggle word wrap
    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.

  7. Optional: Certain smart cards require you to finalize the card by locking the settings: 

    $ pkcs15-init -F
    Copy to Clipboard Toggle word wrap

    At this stage, your smart card contains 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.

3.8. Configuring timeouts in sssd.conf
Copiar enlace

Smart card operations can exceed default SSSD timeout values due to hardware latency or virtualization. You can extend the p11_child_timeout and krb5_auth_timeout parameters in sssd.conf to prevent premature authentication failures.

Authentication with a smart card certificate might take longer than the default timeouts used by SSSD. Time out expiration can be caused by:

  • A slow reader
  • Forwarding from a physical device into a virtual environment
  • Too many certificates stored on the smart card
  • Slow response from the OCSP (Online Certificate Status Protocol) responder if OCSP is used to verify the certificates

Prerequisites

  • You must be logged in as root.

Procedure

  1. Open the sssd.conf file: 

    [root@idmclient1 ~]# vim /etc/sssd/sssd.conf
    Copy to Clipboard Toggle word wrap

  2. Change the value of p11_child_timeout: 

    [pam]
p11_child_timeout = 60
    Copy to Clipboard Toggle word wrap

  3. Change the value of krb5_auth_timeout: 

    [domain/IDM.EXAMPLE.COM]
krb5_auth_timeout = 60
    Copy to Clipboard Toggle word wrap

  4. Save the settings.

    Now, the interaction with the smart card is allowed to run for 1 minute (60 seconds) before authentication fails with a timeout.

3.9. Creating certificate mapping rules for smart card authentication
Copiar enlace

Certificate mapping rules link a single smart card certificate to multiple user accounts across AD and IdM. Administrators configure these rules on the IdM server to enable seamless authentication in both domains using the same physical token.

If you want to use one certificate for a user who has accounts in AD (Active Directory) and in IdM (Identity Management), you can create a certificate mapping rule on the IdM server.

After creating such a rule, the user is able to authenticate with their smart card in both domains.

For details about certificate mapping rules, see Certificate mapping rules for configuring authentication.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba