NTLM Authentication for Microsoft Exchange Clients
Overview: Configuring APM for Exchange clients that use NTLM authentication
Access Policy Manager® (APM®) supports Microsoft
Exchange clients that are configured to use NTLM, by checking NTLM outside of the APM session as
needed. APM requires a machine account and an NTLM Auth configuration to perform these checks.
APM requires an Exchange profile to support Microsoft Exchange clients, regardless of the
authentication they are configured to use.
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
In Access Policy Manager, you need
to configure these elements:
Machine account
NTLM authentication
configuration
Kerberos SSO
configuration
Exchange profile that
specifies the NTLM authentication configuration and specifies Kerberos SSO configurations for
the specific Microsoft Exchange services supported
Access profile that
specifies the Exchange profile
Access policy
Pool of servers for the
Exchange service to support Outlook Anywhere, supply a pool of Outlook Anywhere servers
Virtual server that
specifies the access profile and the pool
You also need to configure a special account in Active Directory for
Kerberos constrained delegation (KDC).
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 Access Policy Manager user
interface on each BIG-IP system.
Creating a new NTLM machine account on each BIG-IP system is helpful, for example, 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.
About Outlook Anywhere and NTLM authentication
Access Policy Manager (APM®)supports Outlook Anywhere 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. APM determines whether a client uses NTLM or HTTP Basic authentication 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).
Configure a
machine account
You configure a machine account so that Access
Policy Manager (APM) can establish a secure channel to a domain controller.
On the Main tab, click
Access
Authentication
NTLM
Machine Account
.
A new Machine Account screen opens.
In the Configuration area, in the
Machine Account Name
field,
type a name.
In the
Domain FQDN
field, type the
fully qualified domain name (FQDN) for the domain that you want the machine
account to join.
In the
Domain Controller FQDN
field,
type the FQDN for a domain controller.
In the
Admin User
field, type the
name of a user who has administrator privilege.
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.
Click
Join
.
This creates a machine account and joins it to the specified domain. This also creates
a non-editable
NetBIOS Domain
Name
field that is automatically populated.
If the
NetBIOS Domain Name
field on the machine account is empty, delete the configuration and recreate it. The
field populates.
Create an NTLM Auth configuration
Create an NTLM Auth configuration to specify the domain controllers that a machine
account can use to log in.
On the Main tab, click
Access
Authentication
NTLM
NTLM Auth Configuration
.
A new NTLM Auth Configuration screen opens.
In the
Name
field, type a name.
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.
For each domain controller, type a fully qualified domain name (FQDN) and click
Add
.
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.
Click
Finished
.
This specifies the domain controllers that a machine account can use to log
in.
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.
For every server realm, you must create a delegation account in that realm.
Open the Active Directory Users and Computers administrative tool and create a
new user account.
The user account should be dedicated for delegation, and the
Password never expires
setting enabled.
Set the service principal name (SPN) on the Windows server for the user
account.
For the support tools that you can use, and for the commands, such as
setspn
and
ktpass
, refer to
Microsoft documentation.
If you use the
ktpass
command, it sets the SPN on the Windows server and creates a keytab file.
APM Kerberos SSO does not need or use a keytab file.
Verify the result of setting the SPN.
This example is purely for illustration. Refer to Microsoft documentation for
up-to-date commands and correct usage.
C:\Users\Administrator>
setspn
-L
apm4
Registered
ServicePrincipalNames for
CN=apm4,OU=users,DC=yosemite,DC=lab,DC=dnet,DC=com:
HTTP/apm4.yosemite.lab.dnet.com
where
apm4
is the name of
the user account that you created.
Return to the Active Directory Users and Computers screen to open your account
again.
A Delegation tab should appear.
Click the Delegation tab.
Select
Trust this user for delegation to specified services
only
.
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.
Click
OK
.
This creates the new delegation account.
Creating a Kerberos SSO configuration in APM
Before you start, you must have
configured a delegation account in Active Directory.
To support Kerberos single sign-on authentication from Access Policy Manager (APM),
you must create a Kerberos SSO configuration.
To complete this task,
you need to know the service principal name (SPN) for the delegation
account.
On the Main tab, click
Access
Single Sign-On
Kerberos
.
The Kerberos screen
opens.
Click
Create
.
The New SSO Configuration
screen opens.
In the
Name
field, type a name for
the SSO configuration.
The maximum length of a single sign-on
configuration is 225 characters, including the partition name.
From the
Log Setting
list, select one
of the following options:
Select an existing APM log setting.
Click
Create
to create a new
log setting.
In the Credentials Source area, specify the
credentials that you want cached for Single Sign-On.
In the
Kerberos Realm
field, type
the name of the realm in uppercase.
For example,
MY.HOST.LAB.MYNET.COM
In the
Account Name
field, type the
name of the Active Directory account configured for delegation.
, apm4 is
the delegation account, apm4.my.host.lab.mynet.com is its fully qualified domain
name, and MY.HOST.LAB.MYNET.COM is the realm.
In the
Account Password
and
Confirm Account
Password
fields, type the delegation account password.
Click
Finished
.
Configuring an
Exchange profile
If any of the Microsoft Exchange clients you support authenticate using NTLM, you must
first create these objects:
A machine account
An NTLM Auth configuration
At least one Kerberos SSO configuration
For Access Policy Manager (APM) to support Kerberos SSO, a
delegation account is required on Active Directory.
You create an Exchange profile to specify how to
handle traffic from Microsoft Exchange clients.
On the Main tab, click
Access
Connectivity / VPN
Microsoft Exchange
.
A list of Exchange profiles displays.
Click
Create
.
A Create New Exchange Profile popup screen displays general
settings.
In the
Exchange Name
field, type a name for the Exchange
profile.
From the
Parent Profile
list, select a profile.
The Exchange profile inherits settings from the parent profile that you
select.
APM supplies a default Exchange profile named
exchange.
Repeat these steps for one or more Microsoft
Exchange services:
From Service Settings on the left, select
an Exchange service.
Settings for the
service are displayed in the right pane.
In the
URL
field, retain any
default settings that are displayed or type a path to use to match the
Exchange client.
Default settings for this field
are supplied in the default exchange profile.
From the
Front End
Authentication
list, select the type of authentication
to use:
Basic
,
Basic-NTLM
, or
NTLM
.
Only the applicable
authentication types for the particular the Exchange service are
included on the list.
If you select
NTLM
or
Basic-NTLM
, you
must also select a configuration from
NTLM
Configuration
list on the General Settings
screen.
From the
SSO Configuration
list, select an SSO configuration, if needed, for use after initial
login.
For
Basic-NTLM
and
NTLM
authentication types, only Kerberos SSO is supported.
You configured settings for
one or more Microsoft Exchange services.
Click
OK
.
The screen closes.
The Exchange profile is displayed on the list.
Apply this Exchange profile by adding it to an
access profile.
Creating an access profile for Exchange clients
You create an access profile to provide the access policy configuration for a
virtual server that establishes a secured session. You add an Exchange profile to the
access profile to specify how to handle traffic from Microsoft Exchange
clients.
On the Main tab, click
Access
Profiles /
Policies
.
The Access Profiles
(Per-Session Policies) screen opens.
Click
Create
.
The New Profile screen
opens.
In the
Name
field, type a name for
the access profile.
A access profile name must be unique among all access
profile and any per-request policy names.
In the Configurations area from the
Exchange
list, select an
Exchange profile.
Exchange profiles specify any SSO
configurations for Microsoft Exchange services, such as Autodiscover, Outlook
Anywhere, and so on. The configuration in the Exchange profile is used for
Microsoft Exchange clients regardless of any SSO configuration you select from
the
SSO Configuration
list in this access profile.
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.
Click
Finished
.
To change from using the default-log-settings that
APM automatically adds to the access profile, you can do this.:
Logging occurs for a session only when a
log setting is specified for the access profile.
Click the name of the access
profile.
The Properties screen
opens.
On the menu bar, click
Logs
.
The General
Properties screen opens.
In the Log Settings area, move log
settings from the
Available
list to the
Selected
list.
Click
Update
.
You can configure log settings in the
Access
Overview
Event Log
Settings
area of the product.
The access
profile displays in the Access Profiles List. Default-log-setting is assigned to the
access profile.
Verify log settings for the access profile
Confirm that the correct log settings are selected for the access profile to ensure that events are logged as you intend.
Log settings are configured in the
Access
Overview
Event Log
Settings
area of the product. They enable and disable logging for access system and URL request filtering events. Log settings also specify log publishers that send log messages to specified destinations.
On the Main tab, click
Access
Profiles /
Policies
.
The Access Profiles
(Per-Session Policies) screen opens.
Click the name of the access profile that you want
to edit.
The properties screen
opens.
On the menu bar, click
Logs
.
The access profile log
settings display.
Move log settings between the
Available
and
Selected
lists.
You can assign up to three log settings
that enable access system logging to an access profile. You can assign
additional log settings to an access profile provided that they enable logging
for URl request logging only.
Logging is disabled when the
Selected
list is
empty.
Click
Update
.
An access profile is in effect when it is assigned to a virtual server.
Configuring an
access policy for NTLM authentication
You configure an access 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.
NTLM authentication occurs before an access policy runs. If NTLM
authentication fails, an error displays and the access policy does
not run.
On the Main tab, click
Access
Profiles /
Policies
.
The Access Profiles
(Per-Session Policies) screen opens.
In the Per-Session Policy column, click the
Edit
link for the
access profile you want to configure.
The visual policy editor
opens the access policy in a separate screen.
Click the
(+)
icon anywhere in the
access policy to add a new item.
Only an applicable subset of access policy items is
available for selection in the visual policy editor for any access profile
type.
A popup screen opens, listing
predefined actions on tabs such as General Purpose, Authentication, and so
on.
On the Endpoint Security
(Server-Side) tab, 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 action
before an NTLM Auth Result action.
The Client
for MS Exchange action popup screen opens.
Click
Save
.
The properties screen closes and the policy displays.
Check whether the Outlook Anywhere
client authenticated using NTLM.
Click the
[+]
sign on the successful branch
after the Client for MS Exchange action.
An Add
Item window opens.
On the
Authentication
tab, select
NTLM Auth
Result
.
Click
Add Item
.
A popup screen opens.
Click
Save
.
The properties screen closes and the policy
displays.
Configure a branch in the access
policy for an Outlook Anywhere client that has authenticated
using NTLM.
Click the
[+]
sign on the successful branch
after the NTLM Auth Result action.
An Add
Item window opens.
On the Assignment tab, select
SSO Credential
Mapping
and click
Add Item
.
The SSO Credential Mapping screen opens.
Click
Save
.
The properties screen closes and the policy
displays.
On the fallback
branch after the SSO Credential Mapping action,
click the
Deny
ending.
A popup
screen opens.
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.
Configure a branch in the access
policy for an Outlook Anywhere client that uses HTTP Basic
authentication.
Click the
[+]
sign on the fallback branch after
the NTLM Auth Result action.
An Add
Item window opens.
On the Logon tab, select
Logon Page
and click
the
Add Item
button.
The Logon Page Agent properties screen opens.
Make any changes that you require to logon page properties and click
Save
.
The properties screen closes and the policy
displays.
On the Successful
branch after the Logon Page action, add an
authentication action.
On the Successful
branch after the authentication action, add an SSO
Credential Mapping action.
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.
On the fallback branch after the
MS Exchange Client action, configure a branch for a client
that is not an Outlook Anywhere client.
You could add Logon Page,
authentication, and SSO Credential Mapping actions or other
actions here.
Click the
Apply Access Policy
link to apply and activate
the changes to the 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.
Example access policy with actions
based on whether NTLM authentication occurred
To
apply this access policy to network traffic, add the access profile to a virtual
server.
To ensure
that logging is configured to meet your requirements, verify the log settings for
the access profile.
Adding the access
profile to the virtual server
You associate the access profile with the virtual
server so that the system can apply the profile to incoming traffic.
On the Main tab, click
Local Traffic
Virtual Servers
.
The Virtual Server List
screen opens.
Click the name of the virtual server you want to
modify.
In the Access Policy area, from the
Access Profile
list, select
the access profile that you configured earlier.
Click
Update
to save the
changes.
Maintain 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.
On the Main tab, click
Access
Authentication
NTLM
Machine Account
.
The Machine Account screen opens.
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.
Click the
Renew Machine Password
button.
The screen refreshes and displays the updated date and
time.
Updating the log level for NTLM for Exchange clients
Before you follow these steps, you must have an access profile that you configured to
use for NTLM authentication of Microsoft Exchange clients. You must know the name of the
log setting that is assigned to that access profile. (The default-log-setting is
assigned by default, but your access profile configuration might be different.)
You can change the level of logging for NTLM authentication for Microsoft Exchange
clients.
Logging at the default level,
Notice
,
is recommended.
On the Main tab, click
Access
Overview
Event Logs
Settings
.
A log settings table screen opens.
Select the check box for the log setting that you want to update and click
Edit
.
A popup screen opens.
To configure settings for access system logging, select
Access
System Logs
from the left pane.
Access System Logs settings display in the right panel.
