14.4. Enforcing authentication indicators for an IdM service
The authentication mechanisms supported by Identity Management (IdM) vary in their authentication strength. For example, obtaining the initial Kerberos ticket-granting ticket (TGT) using a one-time password (OTP) in combination with a standard password is considered more secure than authentication using only a standard password.
By associating authentication indicators with a particular IdM service, you can, as an IdM administrator, configure the service so that only users who used those specific pre-authentication mechanisms to obtain their initial ticket-granting ticket (TGT) will be able to access the service.
In this way, you can configure different IdM services so that:
- Only users who used a stronger authentication method to obtain their initial TGT, such as a one-time password (OTP), can access services critical to security, such as a VPN.
- Users who used simpler authentication methods to obtain their initial TGT, such as a password, can only access non-critical services, such as local logins.
그림 14.1. Example of authenticating using different technologies
This procedure describes creating an IdM service and configuring it to require particular Kerberos authentication indicators from incoming service ticket requests.
14.4.1. Creating an IdM service entry and its Kerberos keytab 링크 복사링크가 클립보드에 복사되었습니다!
Adding an IdM service entry to IdM for a service running on an IdM host creates a corresponding Kerberos principal, and allows the service to request an SSL certificate, a Kerberos keytab, or both.
The following procedure describes creating an IdM service entry and generating an associated Kerberos keytab for encrypting communication with that service.
Prerequisites
- Your service can store a Kerberos principal, an SSL certificate, or both.
Procedure
Add an IdM service with the
ipa service-addcommand to create a Kerberos principal associated with it. For example, to create the IdM service entry for thetestserviceapplication that runs on hostclient.example.com:[root@client ~]# ipa service-add testservice/client.example.com ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Managed by: client.example.comGenerate and store a Kerberos keytab for the service on the client.
[root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com Keytab successfully retrieved and stored in: /etc/testservice.keytab
Verification
Display information about an IdM service with the
ipa service-showcommand.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Keytab: True Managed by: client.example.comDisplay the contents of the service’s Kerberos keytab with the
klistcommand.[root@server etc]# klist -ekt /etc/testservice.keytab Keytab name: FILE:/etc/testservice.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)
14.4.2. Associating authentication indicators with an IdM service using IdM CLI 링크 복사링크가 클립보드에 복사되었습니다!
As an Identity Management (IdM) administrator, you can configure a host or a service to require that a service ticket presented by the client application contains a specific authentication indicator. For example, you can ensure that only users who used a valid IdM two-factor authentication token with their password when obtaining a Kerberos ticket-granting ticket (TGT) will be able to access that host or service.
Follow this procedure to configure a service to require particular Kerberos authentication indicators from incoming service ticket requests.
When you configure a service, you must specify authentication indicators using the --auth-ind argument. Common --auth-ind values include:
- otp
- For two-factor authentication.
- radius
- For RADIUS authentication.
- pkinit
- For PKINIT, smart card, or certificate authentication.
- hardened
- For hardened passwords (SPAKE or FAST).
Prerequisites
- You have created an IdM service entry for a service that runs on an IdM host. See Creating an IdM service entry and its Kerberos keytab.
- You have obtained the ticket-granting ticket of an administrative user in IdM.
Do not assign authentication indicators to internal IdM services. The following IdM services cannot perform the interactive authentication steps required by PKINIT and multi-factor authentication methods:
host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM
Procedure
Use the
ipa service-modcommand to specify one or more required authentication indicators for a service, identified with the--auth-indargument.For example, to require that a user was authenticated with smart card or OTP authentication to retrieve a service ticket for the
testserviceprincipal on hostclient.example.com:[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Managed by: client.example.comTo remove all authentication indicators from a service, provide an empty list of indicators:
[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind '' ------------------------------------------------------ Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------ Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Managed by: client.example.com
Verification
Display information about an IdM service, including the authentication indicators it requires, with the
ipa service-showcommand.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Keytab: True Managed by: client.example.com
14.4.3. Associating authentication indicators with an IdM service using IdM Web UI 링크 복사링크가 클립보드에 복사되었습니다!
As an Identity Management (IdM) administrator, you can configure a host or a service to require a service ticket presented by the client application to contain a specific authentication indicator. For example, you can ensure that only users who used a valid IdM two-factor authentication token with their password when obtaining a Kerberos ticket-granting ticket (TGT) will be able to access that host or service.
Follow this procedure to use the IdM Web UI to configure a host or service to require particular Kerberos authentication indicators from incoming ticket requests.
Prerequisites
- You have logged in to the IdM Web UI as an administrative user.
Procedure
-
Select
or . - Click the name of the required host or service.
Under
Authentication indicators, select the required authentication method.-
For example, selecting
OTPensures that only users who used a valid IdM two-factor authentication token with their password when obtaining a Kerberos TGT will be able to access the host or service. -
If you select both
OTPandRADIUS, then both users that used a valid IdM two-factor authentication token with their password when obtaining a Kerberos TGT and users that used the RADIUS server for obtaining their Kerberos TGT will be allowed access.
-
For example, selecting
- Click at the top of the page.
14.4.4. Retrieving a Kerberos service ticket for an IdM service 링크 복사링크가 클립보드에 복사되었습니다!
The following procedure describes retrieving a Kerberos service ticket for an IdM service. You can use this procedure to test Kerberos ticket policies, such as enforcing that certain Kerberos authentication indicators are present in a ticket-granting ticket (TGT).
Prerequisites
- If the service you are working with is not an internal IdM service, you have created a corresponding IdM service entry for it. See Creating an IdM service entry and its Kerberos keytab.
- You have a Kerberos ticket-granting ticket (TGT).
Procedure
Use the
kvnocommand with the-Soption to retrieve a service ticket, and specify the name of the IdM service and the fully-qualified domain name of the host that manages it.[root@server ~]# kvno -S testservice client.example.com testservice/client.example.com@EXAMPLE.COM: kvno = 1참고If you need to access an IdM service and your current ticket-granting ticket (TGT) does not possess the required Kerberos authentication indicators associated with it, clear your current Kerberos credentials cache with the
kdestroycommand and retrieve a new TGT:[root@server ~]# kdestroyFor example, if you initially retrieved a TGT by authenticating with a password, and you need to access an IdM service that has the
pkinitauthentication indicator associated with it, destroy your current credentials cache and re-authenticate with a smart card. See Kerberos authentication indicators.
Verification
Use the
klistcommand to verify that the service ticket is in the default Kerberos credentials cache.[root@server etc]# klist_ Ticket cache: KCM:1000 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 04/01/2020 12:52:42 04/02/2020 12:52:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM 04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM