Working with Group Managed Service Accounts (gMSA)

Group Managed Service Accounts (gMSAs) provide automatic password management for AD domains. You can find more information in the Group Managed Service Accounts Overview.

gMSA support in Server Suite lies in the following aspects: 

  • Zone user profile management

  • Automatic Kerberos keytab renewal

  • Automatic Kerberos ticket renewal

Managing Zone User Profiles for gMSAs

You can use gMSAs for the following tasks, just as you would use AD users: 

  • Create and manage *NIX user profiles for gMSAs in the zone hierarchy.

  • Assign roles to gMSAs in the zone hierarchy, either directly or indirectly via group memberships.

    You don't need *NIX user profiles and role assignments in Auto Zone. For more information, see Using Workstation Mode and Auto Zone.

  • Manage gMSAs with the adquery, dzinfo, and adobjectrefresh commands.

  • Look up and enumerate gMSAs: 

    • Via standard Name Service Switch (NSS) APIs.

    • Via command line NSS utilities like 'getent' and 'id', etc.

    • From the password.byname and password.byuid derived maps provided by Delinea Network Information Services (adnis).

    • Via RFC 2307 compatible LDAP searches against Delinea LDAP proxy.

    • Via the Delinea Samba proxy (adbindproxy).

    • Via the Delinea DB2 plug-in.

Renewing Kerberos Keytabs Automatically

You can configure Server Suite to automatically synchronize a gMSA's password from AD into the local Kerberos keytab. This way, Kerberized services running under this gMSA don't have to manage the password and always have it available to handle Kerberos application requests (AP-REQ).

To enable this functionality, ensure the following prerequisites are met: 

  • The current domain-joined *NIX computer account must have permission to read the gMSA's password.

    For more information, see Getting Started with Group Managed Service Accounts.

  • Encrypt LDAP traffic.

    For more information, see adclient.ldap.packet.encrypt.

  • Ensure the gMSA is visibile in the zone, meaning it can be returned in NSS lookups.

Relevant configuration parameters: 

  • adclient.gmsa

  • <gmsa>.krb5.keytab: <file_path>

  • <gmsa>.krb5.keytab.upn.realm

Configuration Examples

Suppose a gMSA runs the Kerberized services with the following attributes:

  • The User Principal Name (UPN) uses serviceXYZ@domain.com.

  • The SamAccountName uses serviceXYZ$.

  • The msDS-supportedEncryptionTypes supports 0x1c (RC4, AES128 and AES256).

  • The Service Principal Name (SPN) has two values: serviceXYZ/host.domain.com and serviceXYZ-2/host.domain.com.

  • The corresponding *NIX user profile has NAME as serviceXYZ, UID as 11111, and GID as 22222.

Add the following configurations in centrifydc.conf:

Copy 
adclient.gmsa: serviceXYZ
serviceXYZ.krb5.keytab: /secure/path/to/serviceXYZ.keytab

Adclient will automatically pull serviceXYZ's latest password from AD and update it into /secure/path/to/serviceXYZ.keytab.

Alternatively, system administrators can also run the adkeytab command (with -G/--gmsa option) to trigger the keytab creation. Refer to the adkeytab's main page for more details.

Specifically, this keytab file will have

  • Permission bits as 0600 (only readable and writable by owner)

  • Owner uid as 11111 and gid as 22222

  • 3 encryption types * 4 principals (1 UPN + 2 SPN + 1 SamAccountName) = 12 key entries for each KVNO

Adclient keeps the last 3 Key Version Numbers (KVNOs) by default, so the services should still be able to handle AP-REQs encrypted using the previous keys.

Renewing Kerberos Tickets Automatically

Some applications might want to use a gMSA's identity when accessing other Kerberized services.

Administrators can configure Server Suite to automatically create and refresh Kerberos tickets for gMSAs.

The prerequisites for this functionality are the same as those for the Automatic Kerberos keytab renewal functionality.

Related configuration parameters:

Configuration Example

Suppose the Kerberized client application wants to use a gMSA to authenticate to other Kerberized services. The corresponding *NIX user profile for this gMSA has the following attributes:

  • User name: gmsa_client

  • UID: 11111

  • GID: 22222

Add the following configurations in centrifydc.conf:

Copy 
adclient.krb5.cache.infinite.renewal.gmsa: gmsa_client

Adclient will periodically refresh the Kerberos tickets in the local Kerberos credential caches for this gMSA, or create one if it does not already exist.

Alternatively, system administrators can also run the adreload command to trigger Kerberos ticket renewal for gMSAs.

Specifically, the Kerberos credential caches will possess a uid of 11111 and a gid of 22222.