Chapter 5. Accessing AD with a Managed Service Account

Active Directory (AD) Managed Service Accounts (MSAs) allow you to create an account in AD that corresponds to a specific computer. You can use an MSA to connect to AD resources as a specific user principal, without joining the RHEL host to the AD domain.

This section discusses the following topics:

5.1. The benefits of a Managed Service Account

If you want to allow a RHEL host to access an Active Directory (AD) domain without joining it, you can use a Managed Service Account (MSA) to access that domain. An MSA is an account in AD that corresponds to a specific computer, which you can use to connect to AD resources as a specific user principal.

For example, if the AD domain production.example.com has a one-way trust relationship with the lab.example.com AD domain, the following conditions apply:

  • The lab domain trusts users and hosts from the production domain.
  • The production domain does not trust users and hosts from the lab domain.

This means that a host joined to the lab domain, such as client.lab.example.com, cannot access resources from the production domain through the trust.

If you want to create an exception for the client.lab.example.com host, you can use the adcli utility to create a MSA for the client host in the production.example.com domain. By authenticating with the Kerberos principal of the MSA, you can perform secure LDAP searches in the production domain from the client host.

5.2. Configuring a Managed Service Account for a RHEL host

This procedure creates a Managed Service Account (MSA) for a host from the lab.example.com Active Directory (AD) domain, and configures SSSD so you can access and authenticate to the production.example.com AD domain.

Note

If you need to access AD resources from a RHEL host, Red Hat recommends that you join the RHEL host to the AD domain with the realm command. See Connecting RHEL systems directly to AD using SSSD.

Only perform this procedure if one of the following conditions applies:

  • You cannot join the RHEL host to the AD domain, and you want to create an account for that host in AD.
  • You have joined the RHEL host to an AD domain, and you need to access another AD domain where the host credentials from the domain you have joined are not valid, such as with a one-way trust.

Prerequisites

  • Ensure that the following ports on the RHEL host are open and accessible to the AD domain controllers.

    ServicePortProtocols

    DNS

    53

    TCP, UDP

    LDAP

    389

    TCP, UDP

    LDAPS (optional)

    636

    TCP, UDP

    Kerberos

    88

    TCP, UDP

  • You have the password for an AD Administrator that has rights to create MSAs in the production.example.com domain.
  • You have root permissions that are required to run the adcli command, and to modify the /etc/sssd/sssd.conf configuration file..
  • (Optional) You have the krb5-workstation package installed, which includes the klist diagnostic utility.

Procedure

  1. Create an MSA for the host in the production.example.com AD domain. 

    [root@client ~]# adcli create-msa --domain=production.example.com

  2. Display information about the MSA from the Kerberos keytab that was created. Make note of the MSA name: 

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
Keytab name: FILE:/etc/krb5.keytab.production.example.com
KVNO Principal
---- ------------------------------------------------------------
   2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

  3. Open the /etc/sssd/sssd.conf file and choose the appropriate SSSD domain configuration to add:

    • If the MSA corresponds to an AD domain from a different forest, create a new domain section named [domain/<name_of_domain>], and enter information about the MSA and the keytab. The most important options are ldap_sasl_authid, ldap_krb5_keytab, and krb5_keytab: 

      [domain/production.example.com]
ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
krb5_keytab = /etc/krb5.keytab.production.example.com
ad_domain = production.example.com
krb5_realm = PRODUCTION.EXAMPLE.COM
access_provider = ad
...

    • If the MSA corresponds to an AD domain from the local forest, create a new sub-domain section in the format [domain/root.example.com/sub-domain.example.com], and enter information about the MSA and the keytab. The most important options are ldap_sasl_authid, ldap_krb5_keytab, and krb5_keytab: 

      [domain/ad.example.com/production.example.com]
ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
krb5_keytab = /etc/krb5.keytab.production.example.com
ad_domain = production.example.com
krb5_realm = PRODUCTION.EXAMPLE.COM
access_provider = ad
...

Verification steps

  • Verify you can retrieve a Kerberos ticket-granting ticket (TGT) as the MSA: 

    [root@client ~]# kinit -k -t /etc/krb5.keytab.production.example.com 'CLIENT!S3A$'
[root@client ~]# klist
Ticket cache: KCM:0:54655
Default principal: CLIENT!S3A$@PRODUCTION.EXAMPLE.COM

Valid starting       Expires              Service principal
11/22/2021 15:48:03  11/23/2021 15:48:03  krbtgt/PRODUCTION.EXAMPLE.COM@PRODUCTION.EXAMPLE.COM
  • In AD, verify you have an MSA for the host in the Managed Service Accounts Organizational Unit (OU).

Additional resources

5.3. Updating the password for a Managed Service Account

Managed Service Accounts (MSAs) have a complex password that is maintained automatically by Active Directory (AD). By default, the System Services Security Daemon (SSSD) automatically updates the MSA password in the Kerberos keytab if it is older than 30 days, which keeps it up to date with the password in AD. This procedure explains how to manually update the password for your MSA.

Prerequisites

  • You have previously created an MSA for a host in the production.example.com AD domain.
  • (Optional) You have the krb5-workstation package installed, which includes the klist diagnostic utility.

Procedure

  1. (Optional) Display the current Key Version Number (KVNO) for the MSA in the Kerberos keytab. The current KVNO is 2. 

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
Keytab name: FILE:/etc/krb5.keytab.production.example.com
KVNO Principal
---- ------------------------------------------------------------
   2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

  2. Update the password for the MSA in the production.example.com AD domain. 

    [root@client ~]# adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0

Verification steps

  • Verify that you have incremented the KVNO in the Kerberos keytab: 

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
Keytab name: FILE:/etc/krb5.keytab.production.example.com
KVNO Principal
---- ------------------------------------------------------------
   3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

5.4. Managed Service Account specifications

The Managed Service Accounts (MSAs) that the adcli utility creates have the following specifications:

  • They cannot have additional service principal names (SPNs).
  • By default, the Kerberos principal for the MSA is stored in a Kerberos keytab named <default_keytab_location>.<Active_Directory_domain>, like /etc/krb5.keytab.production.example.com.

  • MSA names are limited to 20 characters or fewer. The last 4 characters are a suffix of 3 random characters from number and upper- and lowercase ASCII ranges appended to the short host name you provide, using a ! character as a separator. For example, a host with the short name myhost receives an MSA with the following specifications:

    SpecificationValue

    Common name (CN) attribute

    myhost!A2c

    NetBIOS name

    myhost!A2c$

    sAMAccountName

    myhost!A2c$

    Kerberos principal in the production.example.com AD domain

    myhost!A2c$@PRODUCTION.EXAMPLE.COM

5.5. Options for the adcli create-msa command

In addition to the global options you can pass to the adcli utility, you can specify the following options to specifically control how it handles Managed Service Accounts (MSAs).

-N, --computer-name
The short non-dotted name of the MSA that will be created in the Active Directory (AD) domain. If you do not specify a name, the first portion of the --host-fqdn or its default is used with a random suffix.
-O, --domain-ou=OU=<path_to_OU>
The full distinguished name of the Organizational Unit (OU) in which to create the MSA. If you do not specify this value, the MSA is created in the default location OU=CN=Managed Service Accounts,DC=EXAMPLE,DC=COM.
-H, --host-fqdn=host
Override the local machine’s fully qualified DNS domain name. If you do not specify this option, the host name of the local machine is used.
-K, --host-keytab=<path_to_keytab>
The path to the host keytab to store MSA credentials. If you do not specify this value, the default location /etc/krb5.keytab is used with the lower-cased Active Directory domain name added as a suffix, such as /etc/krb5.keytab.domain.example.com.
--use-ldaps
Create the MSA over a Secure LDAP (LDAPS) channel.
--verbose
Print out detailed information while creating the MSA.
--show-details
Print out information about the MSA after creating it.
--show-password
Print out the MSA password after creating the MSA.