Configure the SEG V2 for KCD using the UEM console.

Prerequisites

  1. You must have installed and configured SEG.
  2. Upload a single trust certificate for KCD using the UEM console. This certificate is used to validate the client certificate. If additional certificates are needed, then they must be added manually to the SEG configuration. See the Update Secure Email Gateway v2 Configuration for Multiple Certificates Trust section in the Configure Secure Email Gateway (SEG) V2 for Kerberos Constrained Delegation (KCD) topic.
    Note: The supported certificate types are .cer and .pem.

Procedure

  1. Navigate to Email > Email Settings > Advanced.
  2. Deselect the Use Recommended Settings check box.
  3. Select Upload from the Client Certificate Chain and then click Choose File to upload the certificate chain used to issue client certificates.
    Note: The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. The supported certificate types are .cer and .pem.
  4. Click Enable from the Require Client Certificate to enable the client certificate if it is a security requirement.
  5. Click Enable to enable KCD Authentication.
  6. From the KCD Authentication menu, select Target SPN text box and enter the Target SPN in HTTP/{exchangeName} format. For example, HTTP/mobilemail.worldwide.com
  7. Select Service Account User Name and enter the name of your Service Account. For example, SVC_awseg.
  8. Select Service Account Password and enter the password for your Service Account.
  9. Select Add Domain.

    The Add Domain menu item displays the Domain and Domain Controller text boxes.

    1. Select the Domain text box and enter the domain name.
      Note: The domain name is case-sensitive and must be entered in uppercase. For example, DOMAIN-NAME.COM.
    2. Select the Domain Controller text box and enter the domain controller server name. For example, DC.DOMAIN-NAME.COM.

      The domain and domain controllers must be added in pairs and all domains must have trust with the primary domain.

  10. Click Save and restart the SEG service.
    Note: If you modify these settings after the SEG installation, you must reinstall SEG.

Configure EAS and Credential Profile

Configure EAS and Credential profile using Workspace ONE UEM console.
  1. Navigate to Devices > Profiles > List View in the UEM console. Create a new profile for Android or iOS. Assign the profile a Friendly Name. Be aware of the Assignment Type and the target users who receive this profile when you publish the profile. Make additional changes to the General Settings as per your requirement.
  2. Select the Credentials payload and then select Configure. Select Defined Certificate Authority and then select your CA and template that are configured.
  3. Select the Exchange ActiveSync payload. Enter the Exchange ActiveSync Host. The Exchange ActiveSync Host is the public DNS name of the SEG server.
  4. Select Use SSL.
  5. Set the Payload Certificate to Certificate #1.
  6. Remove any entries in the Domain and Username text boxes. Set Email Address to the desired lookup value.
  7. Select Save or Publish if you are ready to push the profile to devices.

Update Secure Email Gateway v2 Configuration for Multiple Certificates Trust

The Workspace ONE UEM console permits a single trust certificate for KCD to be uploaded although SEG v2 can support multiple certificates to trust. If additional certificates are required, see the following procedure to configure the certificates.

The SEG V2 configuration must be updated with multiple trusted certificates if there are multiple Certificate Authorities (CA) issuing client certificates for authentication with SEG. For example, when transitioning client certificates from one CA to another, or when a CA certificate is being renewed, SEG may need to trust both the certificates for a smooth transition.

You can upload a single certificate from the Workspace ONE UEM console while configuring SEG for KCD.

Note:
  • SEG can be configured to trust multiple CA certificates in PEM format or a password protected single PFX file containing multiple trsuted certificates. Both the formats cannot be used together.
  • The steps listed in the following procedure must be run separately on all the SEG nodes.
  • Perform the steps in the following procedure after upgrading SEG, as the configuration from the existing installations are not copied automatically.
  • The changes may not be retained if you are modifying the existing SEG installation, review the configuration after modification of SEG and run the following procedure.

Prerequisites

  • For SEG V2 2.18.0 on Windows and earlier, the format of the trusted certificate configured locally must be same as the format of the certificate uploaded on the Workspace ONE UEM console. The dependency on the format of the certificate is no longer applicable for SEG 2.19.0 and UAG 21.03 and later.
  • Manual configuration of multiple trusted certificates for client certificate-based authentication is supported on SEG on UAG 21.03 and later.
  • The locally configured trusted CA certificates takes precedence over the certificate uploaded on the Workspace ONE UEM console. If SEG finds a locally configured trusted CA certificate for KCD then SEG does not consider the certificate uploaded on the Workspace ONE UEM console. While configuring multiple trusted CAs, a CA certificate to be trusted must also be provided locally even if the same certificate is uploaded on the Workspace ONE UEM console.

Procedure

The following procedure describes the steps to configure multiple trusted certificates for SEG.

  1. Export the certificates of the client certificate issuing CAs and save the certificates in the file system.
  2. Convert the certificates to PEM format or PFX format as you need to configure the certificates on SEG.
  3. Copy the certificates to the /config/ssl-certs path within the install directory of the SEG.
    1. In case of UAG, copy the certificates to the /opt/vmware/docker/seg/container/config/ssl-certs folder.
  4. Navigate to the config folder of the SEG directory and edit the config.json file.
  5. Modify the clientCertTrustStorePath and clientCertTrustStorePasscode fields in the config.json file.
    1. If you use the PEM certificate, append the relative paths of all the files separated by comma for the clientCertTrustStorePath field. The clientCertTrustStorePasscode field is an empty string.
      For example:
      "clientCertTrustStorePath": "config/ssl-certs/CA01.pem, config/ssl-certs/CA02.pem", 
      "clientCertTrustStorePasscode": ""
    2. If you use the PFX certificate, set the relative path of the PFX file for the clientCertTrustStorePath field. For clientCertTrustStorePasscode field, enter the password in plain text with suffix .plaintext. SEG reads the value in plain text, encrypts the password and overwrites the config.json with the encrypted text during the subsequent service launch.
      For example:
      "clientCertTrustStorePath": "config/ssl-certs/CA-combined.pfx", 
      "clientCertTrustStorePasscode": "actual-password.plaintext"
  6. Save the changes and restart the SEG service.

Security Identity Mapping in Active Directory

During a certificate-based authentication, SEG extracts the UPN from the client certificate received from the device. The UPN is used to request a Kerberos token from the Kerberos Domain Controller (KDC) server. This token is then used for authenticating the email request at the Exchange server.

When the username or the domain values in the UPN, which are extracted from the certificate, does not match the details of the distinguished name of a user in the Active Directory, it might result in errors such as Client not found in kerberos database or Server not found in kerberos database.

To overcome the issue, you must configure the intended UPN value as the Kerberos Principal Name under Security Identity Mapping (altSecurityIdentities) for a given Active Directory user. The KDC then identifies the user with configured value and generates the token.

Use the following PowerShell command to add a Kerberos Principal Name mapping for a given Active Directory user.

Set-ADUser -Identity $ADUsername -Add @{'altSecurityIdentities'="Kerberos:USERNAME@DOMAIN.NAME"}
  • $ADUsername - Is the username of the user which has to be updated with the Kerberos name mapping in the Active Directory.
  • USERNAME@DOMAIN.NAME - Is the Kerberos Principal Name for the user. This value is used as the User Principal Name (UPN) in the client certificate that is issued to the user for the purpose of Kerberos authentication with SEG.

SEG Client Certificate Mapping for Kerberos Authentication

You can configure SEG to use client certificate mapping when the certificate either does not have a user principal name (UPN), or the available user principal name does not match the user principal name value in the Active Directory.

Typically, during a certificate-based authentication, SEG extracts the UPN from the client certificate received from the device. The UPN is used to request a Kerberos token from the Kerberos Domain Controller (KDC) server. This token is then used for authenticating the email request at the Exchange server.

SEG cannot acquire a Kerberos token when a UPN is unavailable due to the following reasons:

  • When a client certificate does not have a user principal name.
  • If the user principal name on the certificate does not match the user principal name in the Active Directory.
  • The certificate generation template cannot be modified to include the user principal name attribute.

In such cases, you can configure SEG to retrieve the UPN from the Active Directory using certificate mapping and use the retrieved UPN to obtain the Kerberos token.

When certificate mapping is enabled, certificate mapping takes precedence over any UPN in the certificate. In case the certificate mapping does not fetch a valid UPN, SEG might fall back to the UPN in the certificate, if any, to request for a Kerberos token.

To enable client certificate mapping, you must adhere to the following prerequisites:

  • Enable Kerberos authentication.
  • SEG uses the same service account user credentials that are configured under the Kerberos authentication settings for certificate mapping. The service account user must have the permissions to fetch the user details through the LDAP query.
  • Publish the client authentication certificate generated from the CA server to the respective user object in the Active Directory server.
  • Enable the Attribute Indexing and the Replication to Global Catalog settings in the Active Directory for the attributes listed in the following table.
    Attribute Name Attribute Indexing Default Setting Replication to Global Catalog Default Setting
    userCertificate Not Enabled Enabled
    userPrincipalName Enabled Enabled
    objectClass Enabled Enabled
    objectCategory Enabled Enabled
    Note: Attribute indexing for the userCertificate attribute is not enabled by default in the Active Directory. You must explicitly enable the same.

    Enabling Attribute indexing might consume additional storage space on the Active Directory servers.

    To enable or verify the Attribute Indexing and Replication to Global Catalog settings, see the Active Directory Settings to Enable Attribute Indexing and Replication section.

For improving the overall security of the system, enable LDAP over TLS (LDAPS) between the SEG and the Active Directory. When you enable LDAPS, the communication between the SEG and LDAP server is encrypted.

When the Attribute Indexing and Replication to Global Catalog settings are enabled, running the query against the Global Catalog port (generally port 3269 with TLS) instead of the LDAP port (generally port 636 with TLS) might perform better.

Certificate Mapping in SEG

To perform certificate mapping in SEG, update the following configuration properties in the application-override.properties file of the SEG.

Note: For SEG version 2.17.0 or later, with the Workspace ONE UEM console version 20.10 and later, perform the SEG configuration using the custom gateway settings. To understand the SEG custom gateway settings, see the SEG Custom Gateway Settings topic in the Secure Email Gateway (SEG V2) guide.

For SEG version before 2.17.0, SEG continues to use the default configuration (pre-defined configuration). If the custom settings feature is not available, manually update the respective files at the individual node and modify the SEG configuration.

Key Description Supported Values/Format Default Value Mandatory
cert.mapping.ldap.enabled

Indicates if the certificate mapping feature is enabled for SEG.

This setting is ignored and considered as false if the KCD authentication is disabled in the email configuration.

True/False False Yes
cert.mapping.ldap.host Specify the remote LDAP host information in a URL format. protocol://host:port/dc=whatever

For example, ldap://ldap-remote:3268, ldaps://ldap-remote:3269, and ldaps://ldap-remote:3269/dc=memldap,dc=org

None Yes
cert.mapping.ldap.user Used for authenticating the LDAP query.

SEG uses the same service account credential that is configured as part of the Kerberos authentication settings.

However for the LDAP query, the user name must be provided in the Distinguished Name (DN) format.

LDAP recognizable Distinguished Name (DN) of the Kerberos service user account.

For example, CN=servKCD,CN=Users,DC=memldap,DC=org.

None Yes
cert.mapping.ldap.lookup.base

Specify the distinguished name of the base domain configured for running the LDAP query. The query fetches the matching results from the domain.

By default, the LDAP query indicates the rootDSE of the LDAP setup. In cases, with userCertificate and userPrincipalName attributes indexed and replicated to the Global Catalog, these fields need not be modified.

Distinguished name of the base domain.

For example, DC=memldap, DC=org

None No

Active Directory Settings to Enable Attribute Indexing and Replication

You must first register the dynamic-link library (DLL) that is required for the Active Directory schema snap-in. You can then add the snap-in to Microsoft Management Console (MMC).

The membership in the Domain Admins, or equivalent, is the minimum required to complete the procedure. You can check the details about using the appropriate accounts and group memberships at Local and Domain Default Groups.

To configure the Active Directory settings, perform the following steps:

  1. Open a command prompt, type regsvr32 schmmgmt.dll and press Enter to install the Active Directory schema snap-in.
  2. Click Start > Run, type mmc, and then click OK.
  3. On the File menu, click Add/Remove Snap-in.
  4. In the Available snap-ins option, click the Active Directory Schema > Add and click OK.
  5. Expand the Active Directory Schema > Attributes.
  6. Select the userCertificate attribute to be updated and click the Properties of the attribute.
  7. Select the Index check box and verify that the Replicate this attribute to the Global Catalog check box is selected.
  8. Click Apply to save the changes.

Configure Certificate Revocation List over HTTP

Configure the certificate authority (CA) for the Certificate Revocation List (CRL) over HTTP.

The SEG requires that the client certificate CRLs are reachable over HTTP. By default, Microsoft CAs are configured for accessing the CRL over LDAP and not HTTP. You can configure the CA for accessing CRL over HTTP by installing the AD CS role service Certification Authority Web Enrollment. For more information about manually configuring a CA to access the CRL over HTTP, see the Creating a Certificate Revocation List Distribution Point for Your Internal Certification Authority topic available at Archived MSDN and TechNet Blogs.

The following table lists the configuration keys to enable the certificate revocation validation in SEG:

Configuration Key Description Default Value
enable.cert.revocation.validation Flag to enable the certificate revocation check using the CRL. This flag is used only when the Kerberos authentication or the RequireClientCertificate flag is enabled. False
remote.crl.fetch.interval.in.minutes Interval in minutes for a periodic timer that attempts to update the SEG with the latest CRL data. 1440 (1day)
remote.crl.distribution.http.uris Comma-separated list of HTTP URLs of the CRL Distribution Points (CDP).
fail.hard.on.crl.download.failure.during.server.startup Flag to determine how to handle the failure to fetch CRLs during the SEG startup.

If this flag is set to true and you are unable to fetch the CRL, then the SEG fails to start, else SEG ignores the error and starts.

True
Note: For SEG version 2.17.0 or later, the configuration keys must be configured using the custom gateway settings. For earlier versions of SEG, that is, for SEG versions before 2.17.0, the configuration keys must be configured using the application-override.properties file.

Configuration Updates when Migrating from Classic SEG to SEG V2

Upgrade from Classic SEG with KCD to SEGV2 with KCD.

If you are upgrading from a Classic SEG deployment, create a secondary MEM configuration for SEG V2. This is because the inputs for KCD with SEG V2 are different from that of Classic SEG. The configuration changes in SEG V2 with KCD are intended to help streamline the deployment and maintenance of SEG.

Following are the configuration changes required when upgrading from Classic SEG with KCD:

  • The Require Client Certificate is defined in the advaced settings.
  • The certificate chain of trust is provided in the configuration and is not stored in the Microsoft Management Console. The .pfx certificate type is supported.
  • A Service Account must be used, regardless of SEG being joined to the domain. Using the computer account for Kerberos and impersonation is not supported.
  • When entering domain and domain controller pairs, the domain controller needs to be explicitly provided as the Fully Qualified Domain Name (FQDN).

Disable LLMNR with Active Directory GPO

The Link-Local Multicast Name Resolution (LLMNR) protocol is enabled by default. The active directory has a Group Policy Object (GPO) you can configure to prevent its domain workstations from using LLMNR.

To disable LLMNR through the GPO, perform the following steps:

  1. Open gpedit.msc file.
  2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client.
  3. Click Turn Off Multicast Name Resolution and set the value to Disabled.