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
labdomain trusts users and hosts from theproductiondomain. -
The
productiondomain does not trust users and hosts from thelabdomain.
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.
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.comdomain. -
You have root permissions that are required to run the
adclicommand, and to modify the/etc/sssd/sssd.confconfiguration file.. -
(Optional) You have the
krb5-workstationpackage installed, which includes theklistdiagnostic utility.
Procedure
Create an MSA for the host in the
production.example.comAD domain.[root@client ~]# adcli create-msa --domain=production.example.comDisplay 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)
Open the
/etc/sssd/sssd.conffile 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 areldap_sasl_authid,ldap_krb5_keytab, andkrb5_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 areldap_sasl_authid,ldap_krb5_keytab, andkrb5_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
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-workstationpackage installed, which includes theklistdiagnostic utility.
Procedure
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)Update the password for the MSA in the
production.example.comAD domain.[root@client ~]# adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0
Verification
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 namemyhostreceives an MSA with the following specifications:Specification Value Common name (CN) attribute
myhost!A2cNetBIOS name
myhost!A2c$sAMAccountName
myhost!A2c$Kerberos principal in the
production.example.comAD domainmyhost!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-fqdnor 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.keytabis 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.
