Applies To:

Show Versions Show Versions

Manual Chapter: NTLM Authentication for Outlook Anywhere Clients
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Overview: Providing NTLM authentication for Outlook Anywhere clients

Access Policy Manager supports Microsoft Exchange clients that are configured to use NTLM and HTTP Basic protocols independently. Typically, mobile devices use HTTP Basic authentication, while Outlook Anywhere clients can use both NTLM and HTTP Basic authentication. To determine whether a client uses NTLM or HTTP Basic authentication, APM supplies an iRule that makes the determination and enforces the use of one or the other. After a client authenticates with NTLM or HTTP Basic, APM supports single sign-on with the back-end application or server using Kerberos constrained delegation (KCD).

About using NTLM authentication

Microsoft software systems use NTLM as an integrated single sign-on (SSO) mechanism. However, in an Active Directory-based SSO scheme, Kerberos replaces NTLM as the default authentication protocol. NTLM is still used when a domain controller is not available or is unreachable, such as when the client is not Kerberos-capable, the server is not joined to a domain, or the user authenticates remotely over the web.

About configuration requirements for NTLM authentication

To support Kerberos SSO with Access Policy Manager, you need a special account in Active Directory for Kerberos constrained delegation (KDC).

In APM, you need to configure these elements:

  • Kerberos SSO configuration
  • Machine account
  • NTLM authentication configuration and a virtual server in the same partition and subfolder
  • Access profile (specifying the Kerberos SSO configuration)
  • Access policy
  • Pool of Outlook Anywhere servers

APM provides these elements:

  • An ECA profile, an Extensible Client Authentication profile, for the virtual server.
  • A system iRule _sys_APM_ExchangeSupport_OA_NtlmAuth.

About NTLM authentication configuration and virtual server pairs

You must configure an NTLM authentication configuration and a virtual server in the same partition (or, if you have configured subfolders, the same partition and subfolder).

The NTLM authentication configuration name must include exch_ntlm_ appended with the name of the virtual server. For example, if you create a virtual server, such as /Common/prod/virtualserv1, you must create the NTLM authentication configuration in the /Common/prod partition and you must name it exch_ntlm_virtualserv1.

You can configure multiple NTLM authentication configuration and virtual server pairs in one or more partitions and subfolders.

About reusing a machine account for different BIG-IP systems

You can use the same machine account for two BIG-IP systems when they are in an active-standby configuration. Otherwise, F5 recommends that you create a new NTLM machine account using the APM user interface on each BIG-IP system.

For example, creating a new NTLM machine account using the APM user interface on each BIG-IP system is helpful when two systems independently update their configurations without propagating them, or when you replicate the configuration into different BIG-IP systems using any configuration replication method. If you export a configuration and import it on another system, the machine account is included; however, after the import completes, you still need a new machine account and an NTLM authentication configuration that uses the new machine account on the target system.

Task summary for configuring NTLM authentication for Outlook Anywhere clients

Task list

Setting up a delegation account to support Kerberos SSO

Before you can configure Kerberos SSO in Access Policy Manager®, you must create a delegation account in Active Directory. Note that for every server realm, you must create a delegation account in that realm.
  1. Open the Active Directory Users and Computers administrative tool and create a new user account. The account name must be in this format, host/name.domain, where host is a literal string, name is any arbitrary name, and domain is the DNS FQDN for that realm. Here is an example, host/apm.example.com.
  2. Click Next.
  3. On the next screen, type in a password and click Finish.
  4. Edit the delegation account by running the adsiedit.msc administrative tool. To run this tool, type in the name of the tool at the Run command.
  5. Navigate to the domain user accounts, and locate the delegation account you created.
  6. Right-click the account and select Properties. The Active Directory properties for this account display.
  7. Locate servicePrincipalName and select it.
  8. Click Edit and type in the SPN value. This value should be identical to what you provided in the user account field. For example, host/apm.example.com. Click OK.
  9. Return to the Active Directory Users and Computers screen to open your account again. This time, there should be a Delegation tab present.
  10. Select Trust this user for delegation to specified services only.
  11. Select Use any authentication protocol, and add all your services to the list under Services to which this account can present delegated credentials. Every service should have Service Type HTTP (or http) and host name of the pool member or web application resource host that you will use in your configuration.
  12. Click OK. This creates the new delegation account.

Creating a Kerberos SSO configuration in APM

Before you create a Kerberos SSO configuration in Access Policy Manager®, create a delegation account in Active Directory.
To support Kerberos single sign-on authentication from APM™, you must create a Kerberos SSO configuration.
  1. On the Main tab, click Access Policy > SSO Configurations > Kerberos. The SSO Configurations screen opens for Kerberos type.
  2. Click Create. The New SSO Configuration screen opens.
  3. In the Name field, type a name for the SSO configuration.
  4. In the Credentials Source area, specify the credentials that you want cached for Single Sign-On.
  5. In the Kerberos Realm field, type the name of the realm in uppercase. For example, MY.HOST.LAB.MYNET.COM
  6. In the Account Name field, type the name of the Active Directory account configured for delegation.
  7. In the Account Password and Confirm Account Password fields, type the delegation account password.

Adding Kerberos SSO to a new access profile

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. Click Create. The New Profile screen opens.
  3. Type a name for the access profile.
  4. In the SSO Across Authentication Domains (Single Domain mode) area from the SSO Configuration list, select a Kerberos SSO configuration.
  5. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  6. Click Finished.
The access profile appears in the Access Profiles List.

Configuring a machine account

You need to configure a machine account so that Access Policy Manager can establish a secure channel to a domain controller.
  1. On the Main tab, clickAccess Policy > Access Profiles > NTLM > Machine Account. A new Machine Account screen opens.
  2. In the Configuration area, in the Machine Account Name field, type a name.
  3. In the Domain FQDN field, type the fully qualified domain name (FQDN) for the domain that you want the machine account to join.
  4. Optional: In the Domain Controller FQDN field, type the FQDN for a domain controller.
  5. In the Admin User field, type the name of a user who has administrator privilege.
  6. In the Admin Password field, type the password for the admin user. APM uses these credentials to create the machine account on the domain controller. However, APM does not store the credentials and you do not need them to update an existing machine account configuration later.
  7. Click Join.
This creates a machine account and joins it to the specified domain.

Creating an NTLM Auth configuration

Before you start, decide on the name of a virtual server to use with this configuration and plan to configure that virtual server in the same partition (and subfolder) as this NTLM authentication configuration.
Note: To view the partition and any subfolder, see the Partition list at the top of the screen.
Create an NTLM Auth configuration to specify the domain controllers that a machine account can use to log in.
  1. On the Main tab, click Access Policy > Access Profiles > NTLM > NTLM Auth Configuration. A new NTLM Auth Configuration screen opens.
  2. In the Name field, type exch_ntlm_<vsname> where vsname is the virtual server name.
  3. From the Machine Account Name list, select the machine account configuration to which this NTLM Auth configuration applies. You can assign the same machine account to multiple NTLM authentication configurations.
  4. For each domain controller, type a fully qualified domain name (FQDN) and click Add.
    Note: You should add only domain controllers that belong to one domain.
    By specifying more than one domain controller, you enable high availability. If the first domain controller on the list is not available, Access Policy Manager tries the next domain controller on the list, successively.
  5. Click Finished.
This specifies the domain controllers that a machine account can use to log in.

Configuring an access policy for NTLM authentication

You configure a policy for NTLM authentication to support Outlook Anywhere clients that log in using NTLM to also gain SSO access to a backend server that is protected by Kerberos KCD.
Note: NTLM authentication occurs before an access policy runs. If NTLM authentication fails, an error displays and the access policy does not run.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. In the Server Side Checks area, select Client for MS Exchange and click Add Item to add the action to the access policy. A Client for MS Exchange action determines whether the client is using Microsoft Exchange or ActiveSync protocols. You must add this check before an NTLM Auth Result Check action. The Client for MS Exchange action popup screen opens.
  5. Click Save The properties screen closes and the visual policy editor is displayed.
  6. Check whether the Outlook Anywhere client authenticated using NTLM.
    1. Click the [+] sign on the successful branch after the Client for MS Exchange action. An Add Item window opens.
    2. From the Authentication list, select NTLM Auth Result Check.
    3. Click Add Item. A popup screen opens.
    4. Click Save. The properties window closes and the visual policy editor is displayed.
  7. Configure a branch in the access policy for an Outlook Anywhere client that has authenticated using NTLM.
    1. Click the [+] sign on the successful branch after the NTLM Auth Result Check action. An Add Item window opens.
    2. From the General Purpose list, select SSO Credential Mapping agent, and click Add Item. The Variable Assign: SSO Credential Mapping screen opens.
    3. Click Save. The properties window closes and the visual policy editor is displayed.
    4. On the fallback branch after the SSO Credential Mapping action, click the Deny ending. A pop-up window opens.
    5. Select Allow and click Save. You have completed a branch in the access policy for an Outlook Anywhere client that, having previously authenticated with NTLM, has SSO (Kerberos KCD) access on the back end.
  8. Configure a branch in the access policy for an Outlook Anywhere client that uses HTTP Basic authentication.
    1. Click the [+] sign on the fallback branch after the NTLM Auth Result Check action. An Add Item window opens.
    2. From the General Purpose list, select Logon Page, and click Add Item. A properties screen pops us.
    3. Make any changes that you require to logon page properties and click Save. The Access Policy window displays.
    4. On the Successful branch after the Logon Page action, add an authentication action.
    5. On the Successful branch after the authentication action, add an SSO Credential Mapping action.
    6. On the fallback branch after SSO Credential Mapping, change the ending from Deny to Allow.
    You have completed a branch in the access policy to authenticate an Outlook Anywhere client that uses HTTP Basic authentication and provides SSO (Kerberos KCD) access for the client on the back end.
  9. Optional: On the fallback branch after the MS Exchange Client action, configure a branch for a client that is not an Outlook Anywhere client. In the figure, access is denied on this branch. You could add Logon Page, authentication, and SSO Credential Mapping actions or other actions here.
  10. Click the Apply Access Policy link to apply and activate your changes to the access policy.
You have created an access policy that checks whether the client is an Outlook Anywhere client and whether such a client has authenticated using NTLM. If so, the policy provides SSO (Kerberos KCD) access on the backend server.
When NTLM authentication has passed, perform SSO Credential Mapping;                     otherwise, present a Logon Page and perform authentication. Example access policy with actions based on whether NTLM authentication occurred

Adding the default ECA profile to a virtual server

Before you can add an ECA profile, you must create a host virtual server.
You need to add the default ECA profile to a virtual server to support Outlook Anywhere clients that authenticate using NTLM.
Note: The only supported way to add an ECA profile to a virtual server is from the command line using the Traffic Management Shell (tmsh).
  1. Log on to the command line of the BIG-IPsystem. At the command line prompt, type: tmsh. This starts tmsh in interactive shell mode and displays the prompt: (tmos)#.
  2. Type this command: modify ltm virtual virtual-server-name profiles add { eca } Replace virtual-server with the virtual server name. This adds the default ECA profile to the virtual server.

Completing virtual server configuration for NTLM authentication

Before you configure this virtual server, create a pool of Outlook Anywhere servers.
You add an iRule, access profile, and Outlook Anywhere server pool to the virtual server to complete the configuration required to support Microsoft Exchange clients logging on from the edge of the network using NTLM or HTTP Basic authentication.
  1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
  2. Click the name of a virtual server that is associated with a default ECA profile. The properties screen opens.
  3. In the Access Policy area, from the Access Profile list, select the access profile.
  4. Click Update. The access policy is now associated with the virtual server.
  5. On the menu bar, click Resources. The Resources screen opens.
  6. In the Load Balancing area, from the Default Pool list, select a pool. Select a pool of Outlook Anywhere servers.
  7. Click Update.
  8. Above the iRules® area, click Manage. The Resource Management screen opens.
  9. From the Available list, select the iRule: _sys_APM_ExchangeSupport_NtlmAuth system.
  10. Click Finished.
The virtual server is associated with an iRule that determines whether to enforce NTLM or HTTP Basic authentication, an access policy that checks whether NTLM authentication occurred, and a pool of Outlook Anywhere servers.

Maintaining a machine account

In some networks, administrators run scripts to find and delete outdated machine accounts on the domain controllers. To keep the machine account up-to-date, you can renew the password periodically.
  1. On the Main tab, click Access Policy > Access Profiles > NTLM > Machine Account. The Machine Account screen opens.
  2. Click the name of a machine account. The properties screen opens and displays the date and time of the last update to the machine account password.
  3. Click the Renew Machine Password button. The screen refreshes and displays the updated date and time.
This changes the machine account last modified time.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)