Enabling FIPS-Compliant Encryption

The Federal Information Processing Standard 140-2 (FIPS 140-2) describes US Federal government requirements that IT products should meet for sensitive, but unclassified use. The standard is published by the National Institute of Standards and Technology (NIST) and is required by all non-military agencies of the United States Government. This standard is also widely used by many other organizations outside of the government.

The standard defines the security requirements that must be satisfied by a cryptographic module used to secure unclassified information. There are four levels of security: from Level 1 (lowest) to Level 4 (highest). These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules might be deployed. The security requirements cover areas related to the secure design and implementation of a cryptographic module.

The Delinea Agent can be configured to use FIPS-compliant encryption so that a managed computer can successfully join a domain that is FIPS 140-2, Level 1, compliant.

Verifying the Windows Environment

Before you configure the Delinea Agent to use FIPS-compliant encryption, you should verify that the Active Directory domain meets the minimum requirements for FIPS compliance. For a Delinea-managed computer to join a FIPS 140-2 Active Directory domain, the Active Directory domain must meet the following basic requirements:

  • The domain must be at domain functional level Windows Server 2008, or later.

  • The forest must have a global catalog computer that is running at domain functional level Windows Server 2008, or later.

  • The domain must have at least one Windows Server 2008 R2, or later, domain controller.

  • Any trusted domains you plan to access must be at domain functional level Windows Server 2008, or later.

Although a managed computer can successfully join a domain that has trust relationships to domains at a lower functional level, it cannot access users in those trusted domains, for example, to add user profiles or roles to a zone.

Using Group Policy for FIPS Compliance

If your Active Directory forest meets the minimum requirements and you have configured the Windows environment with the local or group “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” security policy, you can make Delinea managed computers FIPS-compliant by enabling and applying the Delinea “Use FIPS compliant algorithms for encryption, hashing and signing” group policy. You should not use the equivalent Windows group policy to configure FIPS compliant communications for Linux and UNIX computers. The Delinea “Use FIPS compliant algorithms for encryption, hashing and signing” group policy is specifically designed to support Active Directory domains that are configured for FIPS 140-2 compliance.

The Delinea “Use FIPS compliant algorithms for encryption, hashing and signing” group policy is defined in a separate XML (centrifydc_fips.xml) or ADM (centrifydc_fips.adm) template file. The template file is included in the Delinea group policy extension. You must add one of these templates to a Group Policy Object to make a Delinea-managed computer FIPS-compliant mode. For information about adding template files and enabling group policies, see the Group Policy Guide. After you enable the policy, it takes effect at the next group policy update interval. To have the policy applied immediately, run the adgpdupdate command.

Using the XML Template Group Policy

If you use the XML group policy template to enable FIPS mode, the policy verifies that each computer is joined to a domain at the domain functional level Windows Server 2008, or later. If a domain controller does not meet this minimum domain functional level, the policy issues a warning that allows you to skip enabling of FIPS mode for that computer.

The XML group policy template also verifies all computers to which the policy applies are running a supported operating system. On the computers that are running a supported operating system, the policy sets the fips.mode.enable configuration parameter to true and automatically stops and restarts the adclient process. After the restart, the computers where the policy was applied are FIPS-compliant.

If the computer is not running a supported platform, the XML policy leaves the fips.mode.enable configuration parameter set to false, and does not stop and restart adclient. The computer remains joined and the current encryption and hashing algorithms remain in force.

Modifying the Agent Configuration File

The Delinea “Use FIPS compliant algorithms for encryption, hashing and signing” group policy sets the fips.mode.enable parameter in the Delinea configuration file to true. By default, this parameter is set to false until the group policy is applied and the computer is updated at the next group policy update interval. You can also manually modify this parameter setting directly in the agent configuration file (centrifydc.conf), then restart the adclient process to enable FIPS mode. In most cases, however, you should use the group policy to set the configuration parameter to enable FIPS mode rather than manually editing the fips.mode.enable parameter on individual computers.

Applying the Group Policy to a Domain

In most cases, you should apply the “Use FIPS compliant algorithms for encryption, hashing and signing” group policy to a Windows Server 2008, or later, domain to enable FIPS mode. If the group policy is applied to the domain, then the computer will be enabled for FIPS mode automatically when it joins the domain.

Agent Requirements for FIPS-Compliant Encryption

You can only configure FIPS mode for Delinea Agents, version 5.0.2, or later. In addition, FIPS mode is only supported on specific distributions of Linux and Mac OS X operating systems. For a complete and up-to-date list of the platforms that Delinea supports in FIPS mode, see the NIST validation entry for Delinea FIPS mode.

NTLM Authentication

The Delinea Agent does not support NTLM authentication through SMB or SMB2 when configured to use FIPS-compliant encryption. FIPS mode only allows NTLM pass-through authentication over SChannel. Note that NTLM pass-through authentication requires a Windows Server 2008 R2, or later, domain controller.

Non-Compliant Operations

When configured to run in FIPS mode, the agent uses non-FIPS compliant hash and key-hash algorithms, as follows:

  • MD4, MD5 and HMAC-MD5 are used to support NTLM pass through authentication (including using NLTM for PAM authentication).

  • MD4 is used to generate the managed computer password hash for use in setting up AES NetLogon Secure Channel. AES NetLogon Secure Channel is used for NTLM pass-through authentication as well as for updating operating system version attributes.

  • MD5 is used to generate the UNIX password hash to verify against the MD5 password hash that is stored in the cache during disconnected mode login.(This is for backward compatibility support; this happens when you upgrade from a DirectControl version that does not support the SHA256 password hash.)

When configured to run in FIPS mode, the agent uses a non-FIPS compliant encryption algorithm, as follows:

  • Non-FIPS compliant encryption will be used in encrypting secret information for internal communication through a UNIX domain socket.

  • A non-FIPS compliant random number generator is used in generating the Initialization Vector used in the encryption.

Configuring the Encryption Types for Trusted Domains

Inter-realm keys for the AES256-CTS and AES128-CTS encryption types must be established between any trusted domains to enable Active Directory users from these domains to log on to the joined computer. You can use the ksetup utility, installed by default on the domain controller, to set up the inter-realm keys.

To configure the inter-realm keys

  1. On the domain controller, open a Command Prompt window.

  2. Type the following commands:

    C:\>ksetup.exe /SetEncTypeAttr trustedDomain AES256-CTS-HMAC-SHA1-96

    C:\>ksetup.exe /SetEncTypeAttr trustedDomain AES128-CTS-HMAC-SHA1-96

    Note: If you are using pre-validated Active Directory users, you must enable these users for Kerberos AES 128- and 256-bit encryption. You can do so by editing user accounts in Active Directory or by setting attributes for the users in ADSI Edit. For more information, seeEnabling required encryption types for pre-validated users.

Manually Granting Write Permissions for a Computer Account

If the domain that the managed computer is joining does not have at least one Windows Server 2008 R2 domain controller, you must manually grant write permission for the Operating System Version and msDS-supportedEncryptionTypes attributes to the computer account of the joined computer.

To grant write permission for required attributes to the computer account

  1. Open Active Directory Users and Computers or ADSI Edit.

  2. Expand the Computers container and select the computer that is joining the domain, right-click, then click Properties.

  3. Click the Security tab, then click Advanced.

  4. Click Add.

  5. In the “Enter the object name to select” field, type SELF and click OK.

  6. Click the Properties tab, select This object only from the Apply to list, then scroll down and click Allow for the following attributes:

    • Write msDS-supportedEncryptionTypes

    • Write Operating System Version

  7. Click OK in each dialog box to close the dialog and save the new permissions.

Manually Granting Write Permissions for a User Account

If the domain that the managed computer is joining does not have at least one Windows Server 2008 R2 domain controller, you must manually grant write permission for the Operating System Version and msDS-supportedEncryptionTypes attributes to the user account used to join the computer to the domain.

  1. Open Active Directory Users Computers or ADSI Edit.

  2. Expand the Computers container and select the computer that is joining the domain, right-click, then click Properties.

  3. Click the Security tab, then click Advanced.

  4. Click Add.

  5. In the “Enter the object name to select” field, type the name of the Active Directory user who will join the computer to the domain and click OK.

  6. Click the Properties tab, select This object only from the Apply to list, then scroll down and click Allow for the following attributes:

    • Write msDS-supportedEncryptionType

    • Write Operating System Version attributes

  7. Click OK in each dialog box to close the dialog and save the new permissions.

Enabling Required Encryption Types for Pre-Validated Users

If you are using pre-validated Active Directory users, you must enable Kerberos AES 128- and 256-bit encryption for these users. You can do so by editing the user accounts in Active Directory Users and Computers or by setting attributes for the users in ADSI Edit.

To enable encryption for pre-validated users by using Active Directory Users and Computers

  1. On the domain controller, open Active Directory Users and Computers.

  2. Navigate to the domain and select Users.

  3. Select the pre-validated user, right-click, then click Properties.

  4. Click the Account tab, then select the following Account options:

    • This account supports Kerberos AES 128 bit encryption.

    • This account supports Kerberos AES 256 bit encryption.

  5. Click OK to save the updated account information.

To enable encryption for pre-validated users by using ADSI Edit

  1. On the domain controller, open ADSI Edit.

  2. Navigate to the domain and select CN=Users.

  3. Select the user, right-click, then click Properties.

  4. In the Attribute Editor tab, select the msDS-supportedEncryptionTypes attribute and select Edit.

  5. Type 0X18 to set the hex value for the attribute and click OK.

    You should see that the value shows:

    0x18=(AES128-CTS-HMAC-SHA1-96 | AES256-CTS-HMAC-SHA1-96)

  6. Click OK to save the new setting.

How Delinea FIPS Mode Affects Other Encryption Settings

If you enable FIPS mode, you cannot specify the Data Encryption Standard when joining the domain. The adjoin --des option is not supported. Only AES authentication is supported.

If you have specified multiple types of encryption for the computer by setting the adclient.krb5.permitted.encryption.types parameter in the centrifydc.conf configuration file, only aes256-cts and aes128-cts encryption type keys are generated and saved to the keytab file. However, if arcfour-hmac-md5 encryption is specified, the MD4Hash of the computer password is generated and saved to the keytab file.

In addition, depending on how your environment is configured, you can choose whether to remove any non-AES encryption keys for service principal names (SPNs) from the computer's keytab file by setting the adclient.krb5.clean.nonfips.enctypes parameter in the centrifydc.conf configuration file. If you set this parameter to true, adclient scans the keytab file and removes any non-AES encryption keys for SPNs during startup. This parameter is false by default.

Restarting the Agent After Enabling FIPS Mode

If you use the ADM group policy template, which does not perform validation checks, or if you manually enable FIPS mode by setting the fips.mode.enable parameter in the agent configuration file, the adclient process will not start if the domain functional level is below Windows Server 2008.

If you attempt to start adclient and the domain functional level is below Windows Server 2008, you will see the following error message:

Cannot start adclient in FIPS Mode as machine is joined to domain with PreWindows 2008 Domain Functional Level!

To restart the agent, you must disable FIPS mode by setting the fips.mode.enable parameter to false or the “Use FIPS compliant algorithms for encryption, hashing and signing” group policy to Not configured. After disabling FIPS mode, you can continue working at your current domain functional level in non-FIPS mode by restarting the agent:

/usr/share/centrifydc/centrifydc restart

If you want to enable FIPS mode, leave the current domain, update your domain functional level, then join a Windows Server 2008, or later, domain.