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. 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. Service Port Protocols 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 Create an MSA for the host in the production.example.com AD domain. Display information about the MSA from the Kerberos keytab that was created. Make note of the MSA name: 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 : 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 : Verification Verify you can retrieve a Kerberos ticket-granting ticket (TGT) as the MSA: In AD, verify you have an MSA for the host in the Managed Service Accounts Organizational Unit (OU). Additional resources Connecting RHEL systems directly to AD using SSSD 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 Optional: Display the current Key Version Number (KVNO) for the MSA in the Kerberos keytab. The current KVNO is 2. Update the password for the MSA in the production.example.com AD domain. Verification Verify that you have incremented the KVNO in the Kerberos keytab: 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: Specification Value Common name (CN) attribute myhost!A2c NetBIOS name myhost!A2cUSD sAMAccountName myhost!A2cUSD Kerberos principal in the production.example.com AD domain myhost!A2cUSD@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.

Commands:
adcli create-msa --domain=production.example.com
klist -k /etc/krb5.keytab.production.example.com Keytab name: FILE:/etc/krb5.keytab.production.example.com KVNO Principal ---- ------------------------------------------------------------ 2 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
[domain/ production.example.com ] ldap_sasl_authid = CLIENT!S3AUSD@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
[domain/ ad.example.com/production.example.com ] ldap_sasl_authid = CLIENT!S3AUSD@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
kinit -k -t /etc/krb5.keytab.production.example.com 'CLIENT!S3AUSD' klist Ticket cache: KCM:0:54655 Default principal: CLIENT!S3AUSD@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
klist -k /etc/krb5.keytab.production.example.com Keytab name: FILE:/etc/krb5.keytab.production.example.com KVNO Principal ---- ------------------------------------------------------------ 2 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0
klist -k /etc/krb5.keytab.production.example.com Keytab name: FILE:/etc/krb5.keytab.production.example.com KVNO Principal ---- ------------------------------------------------------------ 3 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 3 CLIENT!S3AUSD@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)