I would like to start off by saying that a large part of this documentation was obtained from MobileIron documentation that can be obtained from the MobileIron support site. I am simply adding to to it and updating things that I found to be more difficult.
About Kerberos Constrained Delegation and MobileIron
Starting at VSP version 4.5.3 and later and Sentry version 3.3 and later, you can use Kerberos constrained delegation for authentication. To use Kerberos constrained delegation, you need to already have a Kerberos environment set up that includes the following components:
- Kerberos Key Distribution Center (KDC) A Kerberos Key Distribution Center (KDC) is a service on the Active Directory server that serves as an authentication service and supplies session tickets and keys to users and computers within the Active Directory domain.
- Active Directory (AD) and Exchange Server Active Directory is a directory service that authenticates and authorizes all users and computers in the associated Windows network. The server that runs Active Directory is also called a domain controller.
- Exchange Server The following configurations are supported (however it has been successful with Exchange 2013 as well):
- Exchange 2007 SP3 with AD 2003
- Exchange 2010 SP1/SP2 with AD 2008 R2
- Client Access Server (CAS) One the server roles for Exchange Server. CAS supports Exchange ActiveSync applications. It accepts connections to the Exchange server from different clients.
- Exchange ActiveSync (EAS) A data protocol for syncing data (email, contacts, calendar, tasks) between mobile devices and Exchange. These components can exist on separate servers or on one server.
The following diagram shows the flow of information among the servers and MobileIron components. The majority of these steps happen just one time. Once the service token is cached on Sentry, the device accesses Exchange without requiring authentication for subsequent communication with Exchange until the token expires.
The steps that correlate with the numbers in the diagram above are listed below with a description of what is happening with each step:
|1||Configure the VSP for Kerberos and VSP sends Sentry the certificate with the Kerberos
configuration when the configuration is saved. Sentry reboots after receiving the configuration information from the VSP.
|2||VSP pushes the SCEP profile that you configured for Kerberos and the trusted root certificate to the device on check-in.|
|3||After Sentry reboots (step 1), it connects to the KDC and requests a proxyable, renewable, and forwardable service token, configured for the Sentry SPN.|
|4||The KDC returns the service token for the configured Sentry’s SPN to the Sentry. The Sentry caches this token.|
|5||A device sends a request for Exchange access along with the cert, received in step 2, to Sentry. Sentry receives the request from the device and extracts the device UPN from the certificate.|
|6||Sentry sends the service token (received in step 4) and the device UPN to the KDC.|
|7||The KDC generates a device service token and returns it to Sentry.|
|8||Sentry inserts the device service token (received in step 7) into the ActiveSync request and forwards the request to the CAS server.|
|9||Exchange responds by sending the requested information (for example, email) to Sentry and Sentry forwards the requested information to the device.|
Notes: Ports 88 (UDP and TCP) and 389 (TCP) between Active Directory and Sentry (or port 636 (TCP) if you are using SSL-enabled Active Directory) need to be opened to allow communication. Port 88 is used for Kerberos protocol communication. Port 389 (or 636) is used for the LDAP ping between Sentry and the KDC to verify that the KDC IP is the same as the Active Directory IP.
If Windows Server 2003 is being used, the KDC may listen for requests on port 88 using UDP
instead of TCP. You can force Kerberos to use TCP instead of UDP by changing the MaxPacketSize
from 0 to 1 in the registry editor. For information about how to do this, refer to the following
Microsoft KB article: http://support.microsoft.com/kb/244474.
Configuration OverviewThe following steps are required to set up Sentry for Kerberos authentication:
|1||Verify IP Connectivity Between Sentry, AD, KDC, and Exchange.|
|2||Verify that Sentry, KDC, and Exchange are Syncing Network Time.|
|3||Create a Kerberos Service Account on the KDC For Each Sentry.|
|4||Map the Sentry Service Account to the servicePrincipalName.|
|5||Configure Constrained Delegation For Sentry Service Accounts.|
|6||Verify the Group Policy Values.|
|7||Enable the Kerberos Protocol on the Exchange Server.|
|8||Set Up SCEP for Kerberos Authentication.|
|9||Set Up the Exchange Profile for Kerberos Authentication.|
|10||Configure Device Authentication.|
|11||Set up Kerberos Notifications.|
|12||Validate the Kerberos Configuration.|
Verify IP Connectivity Between Sentry, AD, KDC, and Exchange
The Active Directory server and the KDC server are typically the same server. Before you configure Kerberos, ensure that there is IP connectivity between Sentry, the KDC server, and Exchange. For example, verify firewall ports and DNS resolution of the server names.
Verify that Sentry, KDC, and Exchange are Syncing Network Time
Sentry, the KDC, and Exchange servers must not have a time skew of more than five minutes
(the default on the KDC server). If the time skew is more than five minutes, the Exchange server
assumes that the service token has been spoofed or manipulated and will not accept it. The best way to avoid a time skew is to set up the servers to sync network time.
To configure Sentry to sync network time:
- Log in to the Sentry using the configuration URL (https://<servername>.<companyname>.com:8443).
- Select the Settings tab
- Select Date and Time (NTP) in the left panel
- Set the Primary NTP Server to the same NTP server that KDC and Exchange are using
- Click Apply
Create a Kerberos Service Account on the KDC For Each Sentry
To facilitate communication among KDC server, Exchange server, and Sentry, a Kerberos service account is set up for Sentry on the KDC server (usually on the Active Directory server). If multiple Sentries are being used, it is recommended best practice to set up a service account for each Sentry on the Active Directory server.
MobileIron recommends that you create a separate service account on the KDC for each Sentry. Having separate accounts for each Sentry assists in auditing and is especially useful in a multidomain configuration, but is not a requirement.
To create a Kerberos service account:
- Log in to your KDC server as an administrator
- From Start > All Programs, select Administrative Tools > Active Directory Users and Computers. A browser appears that displays the Active Directory domains
- Expand the realm (Kerberos refers to a domain as a realm)
- Right-click Users and select New > User
- Enter the First Name and Last Name for the Kerberos service account. The Full Name field is auto-populated.
- Enter the User Logon Name, preceded by HTTP/
- Choose the realm name from the drop-down list next to the User Logon Name field
- Delete the HTTP/ from the User Logon Name (pre-Windows 2000) field. When you entered the User Logon Name in step 6, the User Logon Name (pre-Windows 2000) field auto-populated with the same string, but the slash (/) is not a valid character for this field. Remove the slash and HTTP from the string in this input field.
- Click Next
- Enter and confirm the password
- Check (or uncheck) the password and account options depending on the organization’s policies. If your company password policy allows, select Password Never Expires. If this isn’t possible, plan a maintenance cycle where you update the password and/or create a new keytab for the
Sentry configuration on the VSP. If the passwords take a long time to propagate across the domain, you can use two service accounts per Sentry, rotating the service accounts as their passwords are about to expire. Because this is a Sentry configuration change, Sentry will reboot causing a disruption of email traffic for a short time.
- Click Next
- Click Finish
The new user account now appears in the Users list. If you have multiple Sentries, MobileIron recommends that you create a service account for each. Note that if you change the password for the Kerberos service account after you generate the keytab, Kerberos will not be able to renew the service token. When the service token expires the user will no longer have access to email. If the password is changed for the service account, a new keytab must be generated as described in the section titled Map the Sentry Service Account and Create a Keytab and it must be uploaded to the VSP as described in the section titled Configure Device Authentication.
Verify Realm in User Account Properties
Ensure that the realm is specified for each of the newly created service account(s).
The steps to verify the realm for the new service account(s):
- Right-click the new account in the Users list
- Select Properties
- Select the Account tab
- Select the realm from the drop-down list, if it is not already there You can also make changes to the Account Options in this tab.
- Click OK
Map the Sentry Service Account to the servicePrincipalName
After you map the Sentry service account to the servicePrincipalName, the Delegation tab appears in the User Account Properties. The delegation tab is required for the next step, Configure Constrained
Delegation For Sentry Service Accounts.
In this step you use the ktpass command on the KDC to perform one of the following two procedures:
- Map the Sentry Service Account and Create a Keytab (optional)
Generating a keytab is optional. A keytab is a file that stores domain credentials so that Sentry can log into Kerberos without being prompted for a password. When you configure Sentry for Kerberos authentication you can upload the keytab file.
- Map the Sentry Service Account to the ServicePrincipalName (SPN)
You can map the Sentry service account to the servicePrincipalName without creating a keytab.
Note: If a keytab is not generated, the Realm, Sentry Service Principal, Password, and Key Distribution Center information is entered into the Kerberos Configuration form, as explained in the About Kerberos Constrained Delegation section.
Map the Sentry Service Account and Create a Keytab
When you create a keytab, the Sentry service account is concurrently mapped to the servicePrincipalName.
To generate a keytab:
- On the KDC server, open a command prompt window
- At the prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>
Note: the realm must be in all uppercase. This is characteristic of Kerberos.
Below is an example:
ktpass /out sentry1_eas_kcd.keytab /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1
where sentry1_eas_kcd.keytab is the filename that you will upload to Sentry. The returned information for the above example looks like this:
Targeting domain controller: dc_01.texas.ironmobile.com Using legacy password setting method Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd. WARNING: pType and account type do not match. This might cause problems. Key created. Output keytab to sentry1_eas_kcd.keytab: Keytab version: 0x502 keysize 74 HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM ptype 0 (KRB5_NT_UNKNOWN) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x0d9d8f20b3d46f65b2cdb5cc9ec3167b)
Note: the warning can be ignored.
The keytab (in this example, sentry1_eas_kcd.keytab) is saved in the current working directory or where the command was entered. To specify another location to save, simply include the full path in front of the filename. For example, if the file is to be saved in the Desktop folder of the Administror account, sentry1_eas_kcd.keytab would be replaced with c:\Users\Administrator\Desktop\sentry1_eas_kcd.teytab. This file should be copied to a location that is accessible when configuring Sentry in the VSP. The file will be uploaded to the VSP. Repeat this procedure to create a keytab for each Sentry / Sentry Service Account in the system.
Note: If the password for the service account changes, a new keytab file must be created and uploaded to the VSP before the current service token expires. Failure to upload the new keytab file before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.
Map the Sentry Service Account to the ServicePrincipalName (SPN)
To map the Sentry Service account to the servicePrincipalName:
- On the KDC server, open a command window
- At the command prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>
Note: The realm must be in all uppercase.
The following is an example:
ktpass /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1
The returned information for the above example looks like this:
Targeting domain controller: dc_01.texas.ironmobile.com Using legacy password setting method Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd. WARNING: pType and account type do not match. This might cause problems. Key created.
Note: the warning can be ignored.
Repeat this procedure to map each Sentry / Sentry Service Account name to the servicePrincipalName if multiple Sentry service accounts where created.
Note: If the password for the service account changes, you must remap the service account to
the ServicePrincipalName using the new password before the current service token expires. Failure to re-map using the new password before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.
Configure Constrained Delegation For Sentry Service Accounts
Now the Sentry service account is mapped to the servicePrincipalName, constrained delegation needs to be configured on properties dialog windows for each of the configured service accounts. The following steps can be used to accomplish this configuration:
- Enable Delegation
- Configure Allowed Authentication Protocols for the CAS
- Select Services
To enable delegation:
- From Start > All Programs, select Administrative Tools > Active Directory Users and Computers. A browser appears that displays the Active Directory domains.
- Expand the realm
- Click Users
- Select the Kerberos user account that you created in “Create a Kerberos Service Account on the KDC For Each Sentry ” on page 4
- Right-click the account and select Properties
- Select the Delegation tab
- Select Trust This User For Delegation To Specified Services Only
- Select Use Any Authentication Protocol
Configure Allowed Authentication Protocols for the CAS
To configure the allowed authentication protocols for the Client Access Server (CAS):
- In the Delegation tab the Properties dialog for the service account, click Add
- Click Users or Computers
- In the Select Users or Computers dialog that appears, type the name (or the first few characters) of the CAS
- Click Check Names, the names of the CAS servers that match the string entered appear in the box
- Select the CAS to configure the authentication protocols
- Click OK
The Add Services dialog appears and displays a list of all services available on the selected CAS
Multiple service types can be selected, but http must be selected at minimum for this functionality.
To select services to use for authentication:
- Scroll down to the http service type and select it
- Use Ctrl-click to select additional services types
- Click OK, the service types selected are added to the Delegation tab
- Click OK in the Properties dialog
If multiple CAS servers are in use, add the http service for each of the servers using the steps above.
Verify the Group Policy Values
Verify the group policy settings for Kerberos are set to the default values. MobileIron recommends that the default values are used.
To verify the group policy values for Kerberos:
- Log in to the KDC server as an administrator
- From Start > All Programs, select Administrative Tools > Group Policy Management
- Expand the domain and select Group Policy Objects
- Right-click Default Domain Policy and select Edit, the Group Policy Management Editor appears.
- Expand Computer Configuration and select Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy.
The highlighted values are the default Kerberos values.
Edit a policy setting:
- Double-click the policy
- Edit the value in the pop-up that appears
- Click OK
Enable the Kerberos Protocol on the Exchange Server
Enable the Kerberos protocol on the Exchange server so that Sentry can use Kerberos to
authenticate with Exchange
Steps to enable Kerberos authentication in IIS:
- Log in to your Exchange server as an administrator
- From the Start menu, select Administrative Tools > Internet Information Services (IIS) Manager
- Expand the Exchange CAS that is configured for the Sentry
- Navigate to Sites > Default Web Site > Microsoft-Server-ActiveSync
- Double-click Authentication in the middle pane, the Authentication page opens in the middle pane
- Select Windows Authentication in the middle pane
- Select Providers in the right pane, the Providers dialog displays
- If Negotiate:Kerberos is not already in the Enabled Providers list, select it from the Available Providers drop-down list and click Add, Negotiate:Kerberos moves from Available Providers to Enabled Providers
- Click OK
- Ensure that Windows Authentication and Basic Authorization are enabled in the middle pane
If one or both of them are not enabled, select the disabled authentication type and click Enable
in the Actions pane on the right. Check that all other authentication types are disabled. The Exchange server and the Active Directory server are now both set up for Kerberos authentication.
Note: Basic Authentication can be disabled to prevent non-certificate-based authentication.
Set Up SCEP for Kerberos Authentication
Configure SCEP to work with Kerberos constrained delegation. It is important to configure the SCEP profile with the following:
- enable the proxy
- set the Subject Alternative Name Type to NT Principal Name
- set the Subject Alternative Name Type Value to $USER_UPN$
To set up SCEP for Kerberos authentication:
- Log in to the VSP Smartphone Manager
- If you are setting up a new SCEP profile, select Apps & Files | App Settings | Add New | SCEP
If you are updating an existing SCEP profile, select the profile name and click Edit in the right panel.
- Configure the SCEP settings by filling out the form. For details on the configuration options, please look here.
4. Click Save.
Note: If the SCEP entry is not valid, you will be prompted to correct it. Partial and invalid entries cannot be saved.
Set Up the Exchange Profile for Kerberos Authentication
Configure the Exchange profile for each of your Exchange servers that are using Kerberos authen- tication. Configure the Password field to pass the $NULL$ variable. Sentry is using identity certifi- cates for authentication so a password is not required.
To set up the Exchange profile for Kerberos authentication:
- Log in to the Smartphone Manager.
- If you are setting up a new Exchange profile, select Apps & Files | App Settings | Add New | Exchange.
- Configure the Exchange profile by filling out the form with the required values. Explanations of each setting can be found here. The 2 important settings for Kerberos authentication are going to be ActiveSync Password which should have a value of $NULL$ and Identity Certificate which should have the certificate of the user.
- Click Save once everything has been set correctly
Configure Device Authentication
Configuration of device authentication for Standalone Sentry takes place on the associated VSP.
To configure authentication:
- Obtain the certificates required for your implementation, this will be the certificate authority certificate
- In Smartphone Manager, select Settings | Sentry
- Click the edit icon for the existing Standalone Sentry
- In the Device Authentication list, select Identity Certificate (Kerberos).
The following figure shows the form for Kerberos authentication.
- Click Upload Certificate
- Select the trusted root certificate chain received from the Kerberos administrator
- Click Upload
- If the certificates presented by the device against the Certificate
Revocation List (CRL) published by the CA are going to be validated, then the Check Certificate Revocation List (CRL) checkbox should be selected.
Notes: Only HTTP- and HTTPS-based CRLs are supported. Some CAs create LDAP-based CRLs by default that will not work with Sentry.
For CRL validation to work, Sentry requires network connectivity to the CRL Distribution Point
(CDP), usually the CA that issued the certificate, through an HTTP or HTTPS port.
- Use the Subject Alternate Name Type list to select the field in the client certificate that will be
used to identify the user for Kerberos Constrained Delegation.
Note: The Type is the same type that you specified when generating the client certificate. This type is often the NT Principal Name.
- Use the Value list to select the value used in the Subject Alternate Name field.
Usually, the User UPN (user principal name) is used to identify the user.
- If a Kerberos-generated keytab file is used:
a. Select the Use Keytab File checkbox
b. Click the Upload File button that displays
c. Select the keytab file
d. Click Upload
The keytab file provides the required Kerberos authentication information. For information
about generating a keytab, see Map the Sentry Service Account and Create a Keytab.
e. Optionally configure one or more Key Distribution Centers (see step 12).
Note: If no KDC is specified, the system auto-detects the KDC.
- If no keytab file was uploaded, the Kerberos configuration fields will need to be completed manually. Use the following guidelines:
- Realm Enter the Kerberos administrative domain. The realm is usually the company domain name, in all uppercase characters.
- Sentry Service Principal The service principal for the Sentry service account, preceded by HTTP/. For example, if the user name of the service account is sentry1_eas_kcd, the service principal would be HTTP/sentry1_eas_kcd.
- Password Password for the Sentry service account
- Key Distribution Center (optional) The network service that supplies session tickets and temporary session keys. This is generally the Active Directory domain controller hostname.
- Configure the ActiveSync Server SPNs:
- If you used the fully-qualified domain name of the ActiveSync server as the basis for the Service Principal Name of the server in the ActiveSync Server(s) field above, then select Derive SPN From FQDN Of ActiveSync Server.
- If you configured the IP address or alternate DNS name of the ActiveSync server in the ActiveSync Server(s) field above, then deselect Derive SPN From FQDN Of ActiveSync Server. Enter the SPNs for each of your ActiveSync servers, separated by semicolons, in the field that appears when this option is deselected. Typically, SPNs are in the form: http/<FQDN>. For example, http/CAS.ironmobile.com.
Note that the SPN is case-sensitive. The name of the CAS node that uses Kerberos Constrained Delegation (KCD) must exactly match the name of the node.
- To view the CAS node:
- Log on to the Active Directory server as an Administrator.
- From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.
- Navigate to the Computers folder for the Kerberos realm (Kerberos refers to a domain as a realm).
- Note the exact hostname of the CAS.
- Click Save
Set up Kerberos Notifications
The VSP can send notifications to one or more email addresses in the following
- The Kerberos service account is locked
- The Kerberos service account password is about to expire
- The Kerberos service account password has expired
Email notifications are sent to the specified email addresses seven, five, two, and one days before the Kerberos service account password expires. For a locked or unavailable Kerberos service account, one notification is sent after you configure Sentry and save the configuration and the VSP detects the unavailable status of the account.
To set up notifications for Kerberos:
- In Smartphone Manager, select Settings | Sentry
- Click Preferences
- Enter the email address(es), separated by commas, to send the notifications.
Validate the Kerberos Configuration
Verify that the Kerberos configuration is valid by viewing information in the Sentry log in VSP.
To validate the Kerberos configuration:
- Log in to System Manager on the VSP
- Select the Troubleshooting tab
At the bottom of the Logs page, the associated Sentries appear in the Remote Logs section.
- Click the View Logs link for the Sentry to be checked
A dialog appears that shows the Sentry log
- Look for the following string in the Sentry log:
Informational only: Successfully Received Sentry Service Ticket from KDC
Although this message appears as a warning in the log, it just provides verification that Sentry
has received the Kerberos service ticket.
- Repeat steps 3 and 4 for additional Sentries.
Debugging Kerberos Certificate Issues
Kerberos certificates aren’t authenticating.
Authentication is failing when:
- errors like the ones below are present in the sentry.log file
- Users aren’t receiving email
The logs will show error messages that can indicate possible causes.
ERR_BAD_OPTION (error code 13)
This error code is very generic and requires you to look at the e-data in the packet trace (sentry.log?).
Use the following resource to map the error code with the issue:
Once you have mapped the error code to the issue, look up the issue using the following resource
for an explanation of the issue:
The edata (NT_STATUS_UNMATCH) error means that the Exchange server name is incorrect.
Check the Sentry configuration on the VSP to see if the Exchange host name is the same as the
hostname configured in Active Directory.
Error while getting client service ticket com.dstc.security.kerberos.KerberosException: No keytab entry for decrypting data encrypted with key type 23 and kvno 3.
A warning also appears on the KDC:
“The currently selected KDC certificate was once valid, but now is invalid and no suitable replacementwas found. Smartcard logon may not function correctly if this problem is not remedied. Havethe system administrator check on the state of the domain’s public key infrastructure. The chainstatus is in the error data.”
What this means is that after the keytab was generated, the key on the KDC was changed (could
be that the password for the Sentry’s service account was changed on the AD after generating the
keytab). So, the Sentry is no longer able to decrypt the KDC packets and the Kerberos tokens that
Sentry caches can no longer be renewed. The traffic will continue to flow to the client until the client
Kerberos token expires.
To fix this issue, regenerate the keytab on the KDC and upload the new keytab to the VSP.