In this mode of deployment, the SEG server will be on a separate domain (in the DMZ) from the domain to which the users will be authenticating against (on the internal network). In this cross-domain environment, SEG uses a service account with the delegation rights and impersonates the authenticating user. To retrieve the user’s mail, the Exchange server uses a separate Alternate Service Account (ASA).

Leveraging an ASA Credential Type

If there are multiple EAS servers in an array, you must create an ASA in the Active Directory and then continue with assigning delegation rights to the Service Account.

If you have only one EAS or CAS server in your environment, then perform the following steps. If there are multiple EAS or CAS servers, skip the following steps and see the Create and Apply an Alternate Service Account section.

  1. If SEG is not referring to the Exchange server using its fully qualified domain name (FQDN) or its machine name, create a service principal name (SPN) for your domain controller to allow delegation by the service account.

    If SEG is referring to the Exchange server using its FQDN or its machine name, skip this step.

  2. To configure the SPN, open a command line window from a server on the domain being authenticated and run the following command. For example,
    setspn -s HTTP/{EX_DNS_NAME} {EX_MACHINE_NAME}

    Here, {EX_DNS_NAME} is the name that SEG uses to refer to the Exchange server and {EX_MACHINE_NAME} is the actual machine name of the Exchange server. You must select this SPN when assigning delegation rights to the Service Account.

Create and Apply an Alternative Service Account

Configure an ASA to represent the Exchange server. You can create a computer account or a user account for the ASA. In the following steps, if you use a computer account, append a $ to the end of the account name shown as {ASA Account}. For user type accounts the $ is not required.

As a computer account does not allow interactive logon and might have simpler security policies than a user account, it is a preferred solution for the ASA credential. If you create a computer account, you must update your password periodically even though the password does not expire. A local group policy can specify a maximum account period for computer accounts and there might be scripts scheduled to periodically delete computer accounts that do not meet the current policies. You must periodically update the password for computer accounts to ensures that your computer accounts are not deleted for not meeting the local policies. Your local security policy determines when the password needs to be updated.

Credential Name

There are no specific requirements for the name of the ASA credential. You can use any name that conforms to your naming scheme.

Groups and Roles

The ASA credential does not need special security privileges. If you are deploying a computer account for the ASA credential, the account only needs to be a member of the Domain Computers security group. If you are deploying a user account for the ASA credential, the account only needs to be a member of the Domain Users security group.

Password

The password you provide when you create the account is never used. Instead, the script resets the password. So, when you create the account, you can use any password that conforms to your organization’s password requirements. All computers within the Exchange server must share the same Service Account. In addition, any CAS that are referred in a data centre activation scenario must also share the same Service Account.

  1. Open the Active Directory User, Computers, and create a new computer account. Create an ASA for the Exchange server in the domain. Enter a name for the ASA.
  2. To configure the ASA to the Exchange servers, run the ASA credential script in the Exchange Management Shell RollAlternateserviceAccountPassword.ps1 based on the Exchange version.

    Example:

    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers {FIRST-MAIL-SERVER-FQDN} -GenerateNewPasswordFor “{DOMAIN}{ASA_ACCOUNT}” -Verbose

    After you run the script, a Success message is displayed.

  3. Verify if the ASA credentials are deployed.

    Example:

    Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*
  4. Repeat this step for all other EAS servers in the cluster using the following command to copy the configuration from the first server in the cluster.

    Example:

    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers {NEXT-MAIL-SERVER-FQDN} -CopyFrom {FIRST-MAIL-SERVER-FQDN} -Verbose
  5. Create an SPN on the domain using the following command. See the Microsoft documentation on how to use the setspn command. The syntax for this command varies depending on your environment.

    Example:

    setspn -s http/{MAIL-SERVER-FQDN} {ASA_ACCOUNT}

    The MAIL-SERVER-FQDN must be the same mail server configured in the MEM configuration.

  6. Run the following command in PowerShell and verify that all relevant SPNs are assigned.

    Example:

    setspn –L {ASA_ACCOUNT}
  7. Enable the SEG to delegate HTTP EAS traffic to the newly created ASA instead of the Exchange server FQDN. For more information, see step 6 in the Assign Delegation Rights to the Service Account section in the Configure KCD for Cross Domain Authentication topic.

Assign Delegation Rights to the Service Account

Configure delegation rights for the service account.

  1. Open Active Directory Users and Computers on the domain that you are authenticating to and navigate to View and enable the Advanced Features.
  2. If you do not have a Service Account created for the SEG to use for the Kerberos request, create a Service Account and name the Service Account SVC awseg.
    Note: SVC awseg is the name of the SEG service account used here.
  3. Right-click the Service Account and select Properties. In the Properties menu, select the Attribute Editor tab.
  4. To assign delegation rights to a user account, Microsoft requires that the account be assigned a Service Principal Name (SPN). Find the servicePrincipalName attribute in the list and edit the servicePrincipalName in the format HTTP/SVC_awseg.

    Example:

    Assign delegation rights to the user account

  5. After setting up the SPN for the user account, close the Properties window and reopen it to access the Delegation tab. Delegation cannot be set for a user account until an SPN is set.
  6. On the Delegation tab, select the option Trust this user for delegation to specified services only and Use any authentication protocol.
  7. Select Add and then search and select the Exchange server (or the ASA account if you followed the Create an Alternative Service Account section in the Configure KCD for Cross Domain Authentication topic) for which you want to provide the delegation rights. You should provide the actual machine name of the Exchange server {EX_MACHINE_NAME}. For example, EXCH. Scroll through the list to find the HTTP service type. If you set the SPN for the Exchange server in Step 2, select the SPN you created. If you have not set the SPN, select the HTTP service type for your server.

    Example:

    Add Exchange server name to the service account

Add Service Account to Local IIS_IUSRS Group of the CAS/EAS Server

Add a service account to the IIS user groups of the ActiveSync server.

  1. On the CAS/EAS server, open a Command Prompt or a PowerShell window with administrative permissions and run the lusrmgr command to open the Local Users and Groups window.
  2. Expand Groups, right click on IIS_IUSRS and select Add to Group. Select Add… to search for the SVC_awseg Service Account, add the user to the local group, and then select OK.

    Example:

    Add service account to local IIS_IUSRS group of the CAS/EAS server

Enable Windows Authentication on the CAS/EAS

Configure Windows Authentication on CAS/EAS. If you configure SEG with KCD, and the EWS proxy is enabled, then you must perform the following procedure on the EWS Virtual Directory also.

  1. On the Exchange Server, open IIS Manager and navigate to the Microsoft-Server-ActiveSync Virtual Directory.
  2. Select Authentication, disable Basic authentication, enable Windows authentication, and add Negotiate as a provider.

    Example:

    Enable Windows authentication and add negotiate as authentication providers.

  3. In the Microsoft-Server-ActiveSync Virtual Directory, access the Configuration Editor and navigate to system.webServer > Security > Authentication > WindowsAuthentication. Select Enabled, set useAppPoolCredentials and useKernelMode values to True.

    Example:

    Configuration editor for IIS manager