Sign PM for Windows Settings

The Endpoint Privilege Management for Windows settings may be digitally signed. Endpoint Privilege Management for Windows can either enforce or audit the loading of signed settings.

Installation mode parameters

Endpoint Privilege Management for Windows verifies the certificate on any signed settings that it loads, regardless of where those settings originate. The verification process includes:

• Checking that the contents of the settings have not been altered
• Establishing a chain of trust
• Checking the certificate used to sign the settings contains the Endpoint Privilege Management for Windows configuration Signing OID in its Enhanced Key Usage extension
• Checking for revocation where network connectivity allows

Should the signature verification process fail for any reason, the course of action to take depends on the mode of operation. There are three modes of operation in Endpoint Privilege Management for Windows. The mode is set via a command line option during installation:

Example

To install the client MSI package silently in Certificate Warning Mode, use the following command line (the syntax must be copied exactly):

MSIEXEC.exe /i PrivilegeManagementForWindows_x64.msi /qn CERT_MODE=1

or

MSIEXEC.exe /i PrivilegeManagementForWindows_x86.msi /qn CERT_MODE=1

Example

To install the client executable silently in Certificate Warning Mode, use the following command line (the syntax must be copied exactly):

PrivilegeManagementForWindows_x64.exe /s /v" /qn CERT_MODE=1"

or

PrivilegeManagementForWindows_x86.exe /s /v" /qn CERT_MODE=1"

Create a PFX file

The Endpoint Privilege Management for Windows settings console requires access to a certificate and private key to digitally sign XML configuration. They must be contained in a PFX or PKCS#12 format file, and the certificate must specifically be designated as suitable for signing Endpoint Privilege Management for Windows XML configuration. This is done via the Enhanced Key Usage extension when generating certificates.

This approach provides another means of ensuring configuration cannot be created and signed by rogue users with access to a digital signature certificate intended for a different purpose.

BeyondTrust has defined the following OID that should be added to the Enhanced Key Usage extension:

1.2.826.0.1.6538381.1.1.1 (Avecto Privilege Guard - Configuration - XML Configuration Signing)

ℹ️

Note

The Endpoint Privilege Management for Windows settings console does not check for the existence of this key usage. The checks are performed when verifying digital signatures in the Endpoint Privilege Management for Windows service. A configuration that is signed with a key that does not contain the specified Enhanced Key Usage extension always fails signature verification checks.

The following sections provide details of two methods that can be used to generate a suitable PFX file, but it should be possible to use any Certification Authority to produce certificates with the appropriate Enhanced Key Usage extension.

Generate a certificate

MakeCert is a certificate generation tool available from Microsoft that can be used to generate certificates for testing purposes.

Example

The following makecert command line can be used to generate a certificate suitable for signing Endpoint Privilege Management for Windows configuration:

makecert -r -pe -n "CN=BeyondTrust Signed XML Configuration" -sky signature -eku 1.2.826.0.1.6538381.1.1.1 -ss my

The parameters can be changed as required. The example above generates a self-signed certificate with an exportable private key, and adds it to the calling user’s local certificate store. The certificate must then be exported to a PFX file along with the private key in the usual way.

The important parameter in the example is the addition of the Endpoint Privilege Management for Windows Configuration Signing OID to the Enhanced Key Usage extension (-eku 1.2.826.0.1.6538381.1.1.1)

If a self-signed certificate is used to sign the Endpoint Privilege Management for Windows settings, the certificate must be distributed to all clients for a chain of trust to be established and for signature verification to be successful.

Use certificate template in a certificate request

Once the certificate template is issued, the template can be used during advanced certificate requests via the certsrv web interface.

Once the certificate is issued, it must be installed by the user before it can be exported to a PFX file in the usual way.

ℹ️

Note

The private key must be exported to the PFX file as well.

Microsoft Certificate Services

Microsoft Certificate Services is a useful way for organizations to run their Certification Authority. In its enterprise editions, Certificate Services integrates with Active Directory to publish certificates and Certificate Revocation Lists to a location that is accessible to all computers in the Active Directory domain.

Custom certificate templates can only be managed using enterprise CAs, therefore the following procedure is only possible on Enterprise Editions of Windows 2008 R2.

Create a configuration certificate template

The easiest way to create a certificate with the BeyondTrust Endpoint Privilege Management for Windows Configuration Signing Enhanced Key Usage extension is to create a new certificate template. Certificate templates allow the content and format of certificates to be defined so users can request a certificate using a simple template rather than having to generate a complex certificate request.

To create a certificate template, an existing template must be duplicated and then modified.

To create a new version 2 or 3 certificate template:

1. Open the Certificate Templates snap-in.
2. In the details pane, right-click an existing certificate to serve as the starting point for the new certificate, and select Duplicate Template.
3. Choose whether to duplicate the template as a Windows Server 2003–based template or a Windows Server 2008 R2–based template.
4. On the General tab, enter the Template display name and the Template name, and click OK.
5. Define any additional attributes for the newly created certificate template.

The template must then be edited to make it suitable for signing Endpoint Privilege Management for Windows configuration. This is done by adding the BeyondTrust Endpoint Privilege Management for Windows Configuration Signing OID as an application policy for the template.

The Configuration Signing OID must first be defined.

To define an object identifier:

1. Open the Certificate Templates snap-in.
2. In the details pane, right-click the certificate template you want to modify, and then click Properties.
3. On the Extensions tab, click Application Policies, and then click Edit.
4. In the Edit Application Policies Extension dialog box, click Add.
5. In Add Application Policy, ensure the Endpoint Privilege Management for Windows Configuration Signing policy that you are creating does not exist, and then click New.
6. In the New Application Policy dialog box, provide the name and OID for the new application policy, and then click OK.

Now that the application policy is defined, you can associate it with the certificate template.

To associate the application policy with the certificate template:

1. Open the Certificate Templates snap-in.
2. In the details pane, right-click the certificate template you want to change, and then click Properties.
3. On the Extensions tab, click Application Policies > Edit.
4. In Edit Application Policies Extension, click Add.
5. In Add Application Policy, click the application policy, and then click OK.

Issue and distribute the certificate

Once the certificate template is created in the Certificate Templates snap-in and has replicated to all domain controllers in the forest, it can now be published for deployment. The final task for publishing the certificate template is to select it for the Certification Authority (CA) to issue.

Issue the certificate

To define which certificate templates are issued by a CA:

1. In Administrative Tools, click Certification Authority.
2. In the console tree, expand the CAName (where CAName is the name of your enterprise CA).
3. In the console tree, select the Certificate Templates container.
4. Right-click Certificate Templates, and then click New > Certificate Template to Issue.
5. In the Enable Certificate Templates dialog box, select the Endpoint Privilege Management for Windows Configuration certificate template you want the CA to issue, and then click OK.

Distribute public keys

For signature verification to be successful at every client that reads signed Endpoint Privilege Management for Windows settings, a chain of trust must be established. For this to be done, a suitable trust point must be distributed to each client that receives the Endpoint Privilege Management for Windows settings. This should be done automatically when using a Microsoft enterprise CA.

Alternatively, public keys can be distributed using Group Policy.

ℹ️

Note

If you rely on third party providers for certificates, for example, not internal PKI, you will succeed by asking for a "key signing ceremony" that allows you to specify the certificate parameters such as custom "extended key usage" values as described in this appendix.

📘

For more information on distributing public keys using Group Policy, see Distribute Certificates to Client Computers by Using Group Policy.

Create and edit signed settings

To digitally sign Endpoint Privilege Management for Windows settings, a PFX file containing an appropriate certificate and private key must be supplied, alongside the corresponding password for the PFX file.

ℹ️

Note

To correctly sign settings, the certificate must have an OID that is specific to BeyondTrust Endpoint Privilege Management for Windows. The chain of trust and revocation status is also checked by Endpoint Privilege Management for Windows. If the settings have been tampered with since signing, the settings also fail the signing check.

To digitally sign the Endpoint Privilege Management for Windows settings:

1. Select the BeyondTrust Settings node.
2. Right-click and select Digitally Sign.
3. The Digitally sign your BeyondTrust Settings wizard appears.
4. Check the Sign the settings with the following private key option.
5. Click the Select key button and browse for the PFX file that contains the digital certificate.
6. Enter the password for the PFX file.
7. Click Finish.

To remove the digital signature from the Endpoint Privilege Management for Windows settings:

1. Select the Endpoint Privilege Management Settings node.
2. Right-click and click Digitally Sign.
3. The Digitally sign your Endpoint Privilege Management Settings wizard appears.
4. Select the Do not sign the settings option.
5. Click Finish.

Once the Endpoint Privilege Management for Windows settings are digitally signed, the Endpoint Privilege Management Policy Editor prompts the administrator for the corresponding PFX password when the settings are opened.

To modify the signed settings, you must enter a valid password for the PFX. Alternatively, you can select to remove the certificate from the settings, or open the settings in Read Only mode. Canceling this prompt automatically opens the settings in Read Only mode.

📘

For more information about creating certificates suitable for use with Endpoint Privilege Management for Windows, see Create a PFX file.

Behavior when Policy Certificate Verification Fails

When using signed Endpoint Privilege Management for Windows settings, timely certificate revocation enforcement may be desired. This scenario is most common for clients unable to reach the CRL source since they are off the corporate network for extended periods of time.

By default, Endpoint Privilege Management for Windows allows certificates whose revocation may not be confirmed with Microsoft Crypto APIs from either cached information, or directly from the CRL source.

ℹ️

Note

If agent protection is configured, you must first disable agent protection on the machine before you can change settings in the Registry Editor.

The following registry configuration may be used to change the default behavior:

HKEY_LOCAL_MACHINE\SOFTWARE\Avecto\Privilege Guard Client\ DWORD "CRLNetworkErrorFailOpen" = 0

Failure to retrieve CRL is deemed an error and policy is not loaded.

DWORD "CRLNetworkErrorFailOpen" = 1

Failure to retrieve CRL is deemed a warning and policy is still loaded. This is the default behavior if this registry setting has not been configured.

The CRL is cached when downloaded and honored until its Time To Live (TTL) has expired (standard Microsoft CryptoAPI behavior). The Certificate Authority may be configured according to requirements. Microsoft Group Policy provides centralized configuration in this area. Security and usability need to be balanced according to your organization's risk tolerance.

ℹ️

Note

Prior settings from the same source type (GPO, HTTP, etc) is deleted before the newly acquired settings are verified. This could lead to no policy in effect on the endpoint in the case that invalid settings are delivered, and no valid settings from other sources are in place.