Realm Fields

The following fields are used to configure a realm.

Realm Configuration Fields

These settings apply to all Active Directory servers or domain controllers (also referred to as directories) in a realm.

Name

A unique name for the realm.

To use the realm in identity policies, the system supports alphanumeric and special characters.
To use the realm in RA VPN configurations, the system supports alphanumeric, hyphen (-), underscore (_), and plus (+) characters.

Description

(Optional.) Enter a description of the realm.

Type

The type of realm, AD for Microsoft Active Directory, LDAP for other supported LDAP repositories, or Local. For a list of supported LDAP repositories, see Supported Servers for Realms. You can authenticate captive portal users with an LDAP repository; all others require Active Directory.

Note	Only captive portal supports an LDAP realm.

The realm type LOCAL is used for configuring local user settings. The LOCAL realm is used in remote access user authentication.

Add the following Local User Information for the LOCAL realm:

Username—Name of the local user.
Password—Local user password.
Confirm Password—Confirm the local user password.

Note	Click Add another local user to add more users to the LOCAL realm. You can add more users after creating the realm and update password for the local users. You can also create multiple LOCAL realms but cannot disable them.

AD Primary Domain

For Microsoft Active Directory realms only. Domain for the Active Directory server where users should be authenticated.

Note

You must specify a unique AD Primary Domain for every Microsoft Active Directory (AD) realm. Although the system allows you to specify the same AD Primary Domain for different AD realms, the system won't function properly. This happens because system assigns a unique ID to every user and group in each realm; therefore, the system cannot definitively identify any particular user or group. The system prevents you from specifying more than one realm with the same AD Primary Domain because users and groups won't be identified properly. This happens because system assigns a unique ID to every user and group in each realm; therefore, the system cannot definitively identify any particular user or group.

AD Join Username and AD Join Password

(Available on the Realm Configuration tab page when you edit a realm.)

For Microsoft Active Directory realms intended for Kerberos captive portal active authentication, the distinguished username and password of any Active Directory user with appropriate rights to create a Domain Computer account in the Active Directory domain.

Keep the following in mind:

DNS must be able to resolve the domain name to an Active Directory domain controller's IP address.
The user you specify must be able to join computers to the Active Directory domain.
The user name must be fully qualified (for example, administrator@mydomain.com, not administrator).

If you choose Kerberos (or HTTP Negotiate, if you want Kerberos as an option) as the Authentication Protocol in an identity rule, the Realm you select must be configured with an AD Join Username and AD Join Password to perform Kerberos captive portal active authentication.

Note

The SHA-1 hash algorithm is not secure for storing passwords on your Active Directory server and should not be used. For more information, consult a reference such as Migrating your Certification Authority Hashing Algorithm from SHA1 to SHA2 on Microsoft TechNet or Password Storage Cheat Sheet on the Open Web Application Security Project website.

We recommend SHA-256 for communicating with Active Directory.

Directory Username and Directory Password

The distinguished username and password for a user with appropriate access to the user information you want to retrieve.

Note the following:

For Microsoft Active Directory, the user does not need elevated privileges. You can specify any user in the domain.
For OpenLDAP, the user's access privileges are determined by the <level> parameter discussed in section 8 of the OpenLDAP specification. The user's <level> should be auth or better.
The user name must be fully qualified (for example, administrator@mydomain.com, not administrator).

Note

We recommend SHA-256 for communicating with Active Directory.

Base DN

(Optional.) The directory tree on the server where the Cisco Defense Orchestrator should begin searching for user data. If you don't specify a Base DN, the system retrieves the top-level DN provided you can connect to the server.

Typically, the base distinguished name (DN) has a basic structure indicating the company domain name and operational unit. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com.

Group DN

(Optional.) The directory tree on the server where the Cisco Defense Orchestrator should search for users with the group attribute. A list of supported group attributes is shown in Supported Server Object Class and Attribute Names. If you don't specify a Group DN, the system retrieves the top-level DN provided you can connect to the server.

Note

Following is the list of characters the system supports in users, groups, DNs in your directory server. Using any characters other than the following could result in the system failing to download users and groups.

Entity	Supported characters
User name	a-z A-Z 0-9 ! # $ % ^ & ( ) _ - { } ' . ~ `
Group name	a-z A-Z 0-9 ! # $ % ^ & ( ) _ - { } ' . ~ `
Base DN and Group DN	a-z A-Z 0-9 ! @ $ % ^ & * ( ) _ - . ~ `

Proxy

From the list, click one or more managed devices or a proxy sequence. These devices must be able to communicate with Active Directory or ISE/ISE-PIC to retrieve user data for identity policies.

The following fields are available when you edit an existing realm.

User Session Timeout

(Available on the Realm Configuration tab page when you edit a realm.)

Enter the number of minutes before user sessions time out. The default is 1440 (24 hours) after the user's login event. After the timeout is exceeded, the user's session ends; if the user continues to access the network without logging in again, the user is seen by the CDO as Unknown (except for Failed Captive Portal Users).

You can set timeout values for the following:

User Agent and ISE/ISE-PIC Users: Timeout for users tracked by the user agent or by ISE/ISE-PIC, which are types of passive authentication.

The timeout value you specify does not apply to pxGrid SXP session topic subscriptions (for example, destination SGT mappings). Instead, session topic mappings are preserved as long as there is no delete or update message for a given mapping from ISE.

For more information about ISE/ISE-PIC, see The ISE/ISE-PIC Identity Source.
Terminal Services Agent Users: Timeout for users tracked by the TS Agent, which is a type of passive authentication. For more information, see The Terminal Services (TS) Agent Identity Source.
Captive Portal Users: Timeout for users who successfully log in using the captive portal, which is a type of active authentication. For more information, see The Captive Portal Identity Source.
Failed Captive Portal Users: Timeout for users who do not successfully log in using the captive portal. You can configure the Maximum login attempts before the user is seen by the CDO as Failed Auth User. A Failed Auth User can optionally be granted access to the network using access control policy and, if so, this timeout value applies to those users.

For more information about failed captive portal logins, see Captive Portal Fields.
Guest Captive Portal Users: Timeout for users who log in to the captive portal as a guest user. For more information, see The Captive Portal Identity Source.