Server Configuration to Integrate Idenprotect for Desktop - Windows

From idenprotect Knowledge Base
Jump to: navigation, search

Introduction

The idenprotect Core Platform can be integrated to protect Windows logons and provide Single Sign-On (SSO) for secure communications and applications. This article shows you how to configure the idenprotect Core Platform, Active Directory, and Domain Controller so that a user can log in to Windows using an idenprotect identity.

Configuring idenprotect Core Platform for Windows Integration

Once an idenprotect Core Platform has been installed, there are some specific policies that must be configured on the idenprotect Core Platform Web Console to ensure a Windows device can be enrolled and the correct format of the certificate is generated that is suitable for logging into Windows. You will need to follow the steps below for configuring idenprotect Core Platform before you enroll Windows and Mobile devices. This is because the certificates generated as part of the enrollment process need to contain attributes that will be required for Windows Logon.

Configuration for Enrolling a Windows Device

To ensure a Windows device can be enrolled, the following settings should be made in the Client Configuration and User Enrollment Configuration screens.

The Client Configuration can be found in: -

Parameter in Config Tab Parameter in Properties File Requirement
Application Type policy.application.type This property should be set to SAML or BOTH to ensure the mobile app will be enabled for Windows Logon.
Mobile OTP Allowed? policy.allow.otp this property should be set to true.

The Enrollment Configuration can be found in: -

  • User Enrollment Policies section in the idenprotect Core Platform Admin Console Config Tab
  • Server file system in /etc/idenprotect/userenrolment.properties
Parameter in Config Tab Parameter in Properties File Requirement
Active Directory Certificate Required? policy.ad.certificate.required This property should be set to true to ensure the Windows Certificate is pushed to the user's Active Directory certificate attribute.
Maximum Number of User Devices policy.max.user.devices this property should be set to a value greater than 1. One for a mobile device and one for a Windows device.
Windows Enrollment File Required? policy.windows.enrollment.file.required this property should be set to true to ensure an enrollment file is sent to the user's email as part of enrollment.


Example Configuration in userenrolment.properties

policy.application.type=saml
policy.allow.otp=true
policy.max.user.devices=3
policy.windows.enrollment.file.required=true
policy.ad.certificate.required=true


Configuration for Issuing a Valid Windows Logon Certificate

A valid Windows certificate must contain the correct format of attributes that a Windows Domain Controller will be able to extract information to process a certificate-based Kerberos Windows Logon attempt.

To ensure the correct certificate format is produced, the following Extra LDAP Parameters must be set in the idenprotect Core Platform Admin Console.

The LDAP Extra Parameters section is accessible from the LDAP tab in the idenprotect Core Platform Admin Console.

The following values should be set in this section:

LDAP PARAMETER FRIENDLY NAME LDAP FIELD NAME
CSR Alt Subject userPrincipalName
CSR Subject DistinguishedName
UPN userPrincipalName

Example LDAP Extra Parameters

LDAP Extra Parameters.png


After you have setup the LDAP Extra Parameters, you need to to pull the extra parameters from Active Directory (LDAP) by requesting to sync the users. This will ensure each user will have the required parameters when enrolling a new device.

Sync users.png

Configuration of the Certificate Authority (CA)

A Certificate Authority is required to sign the certificates that will be used for Windows Logon. The full chain of the Windows certificate must be trusted by the Domain Controller, so if an external PKI Certificate Authority is used, or the internal idenprotect CA, then the certificates in the chain must be added to the trust of the domain controller. This setup is described in the section 'Configuring Domain Controller for Windows Integration'.

Information on setting up a CA Server Connection can be found in other pages:

There is no extra configuration required that is specific to Windows Integration.


Configuring Active Directory for Windows Integration

It is necessary for idenprotect to publish a Windows certificate to a user's profile on Active Directory in the Published Certificates attribute. So there needs to be a service account on Active Directory with Account Operators and Cert Publishers entitlements that the idenprotect Core Platform can use to publish to a user's Active Directory profile.

The LDAP Connection Configuration can be updated to ensure a user account is being used that has access to publish to Active Directory.

This configuration can be found in: -

  • LDAP Connection Configuration under the LDAP section in the idenprotect Core Platform Admin Console Config Tab
  • Server file system in /etc/idenprotect/ldap.properties
Parameters for LDAP
Parameter in Config Tab Parameter in Properties File Description
Authentication User ldap.auth.user LDAP service account username (if using simple or SASL authentication). Ignored if using anonymous authentication
Authentication Password ldap.auth.password LDAP service account password (if using simple or SASL authentication)

The service account referred to in authUser and authPassword requires read access to the LDAP directory to be able to make queries but it may require write access if you wish to take advantage of some of the server's other features. We recommend creating a dedicated LDAP account for idenprotect Core Platform.

Note: The Authentication User must be part of the Account Operators and Cert Publishers security groups, as described here. This is to ensure the user can read information and publish certificates to a user's Active Directory profile.


An example of a user's Active Directory profile shows the Published Certificates attribute with published Windows certificates.

AD Published Certificates.png

Configuring Domain Controller for Windows Integration

The Domain Controller is used to verify certificates in the Windows Logon process. The full chain of a Windows certificate must be trusted by the Domain Controller.

If you are using a Certificate Authority (CA) that is using a certificate that is not globally trusted, then you will need to:

  1. Import the certificate to the Trusted Root Certification Authorities group policy in Active Directory.
    1. On your Active Directory server, navigate to the Group Policy Management plug-in. For Windows Server 2016 this can be opened by navigating to Start->Administrative Tools->Group Policy Management. Expand to your domain and right-click Default Domain Policy, and click Edit.
    2. Expand the Computer Configuration section and open Windows Settings\Security Settings\Public Key.
    3. Right-click Trusted Root Certification Authorities and select Import.
    4. Follow the prompts in the wizard to import the root certificate (for example, rootCA.cer) and click OK.
    5. Close the Group Policy window.
    6. Add CA Root Certificate to AD.png
  2. Add the root certificate to the Enterprise NTAuth store in Active Directory.
    1. On a Command Prompt on your Active Directory server, use the certutil command to publish the certificate to the Enterprise NTAuth store. Make sure the Command Prompt is opened in Administrator Mode. Enter the following commands.
      1. certutil -dspublish -f CA_CertFilename.cer NTAuthCA
      2. certutil -enterprise -addstore NTAuth CA_CertFilename.cer


Retrieving the CA certificate from the idenprotect Internal CA

To perform the operations required in Configuring Domain Controller for Windows Integration you will need to extract the Internal CA's root certificate. To do this, you will need to extract the certificate from the Java Keystore file that is stored on your idenprotect Core Platform.

To determine where the Java Keystore file is located, open the Certificate Authority Stores Configuration.

The CA Keystore Path in defined in the property ca.keystore.path in /etc/idenprotect/ca.properties.
The CA Keystore Password is defined in the property ca.keystore.pass in /etc/idenprotect/ca.properties.
The CA Keystore Alias is defined in the property ca.keystore.alias in /etc/idenprotect/ca.properties.

Note: the Alias should be prefixed with 'ec' or 'rsa' to get the ECC or RSA certificate respectively.

Example CA Certificate Extraction

If the ca.properties file contains properties:
ca.keystore.path=/etc/idenprotect/
ca.keystore.pass=cakeystorepass
ca.keystore.alias=idenprotect

The Root CA certificate is contained in the file /etc/idenprotect/truststore.jks. The password to access the keystore is cakeystorepass. The alias for the ECC certificate will be ecidenprotect.

Using the keytool command line tool on the terminal console for the server that is running idenprotect, enter the following command:
keytool -exportcert -alias ecidenprotect -keystore truststore.jks -storepass cakeystorepass -rfc -file internal_ca_cert.crt

To see the PEM format of the certificate, you can view the contents:
cat internal_ca_cert.crt

Extract internal ca root cert.png


Once you have the certificate in PEM format, you can use this certificate to import into Active Directory Trust Stores.


Update Required for CRL Issues

If there are issues with the Certificate Revocation List (CRL), then the issues can be set to be ignored by setting a Registry Entry on the Domain Controller.

On your Active Directory Server, set the following Registry Entry:

[HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors = 1

Regsitry entry ignore CRL issues.png