User identity is like a container that holds information about a user and forms their network access credentials. Each user’s identity is defined by data and includes: a username, e-mail address, password, account description, associated administrative group, user group, and role.

User groups are a collection of individual users who share a common set of privileges that allow them to access a specific set of Cisco ISE services and functions.

A user’s group identity is composed of elements that identify and describe a specific group of users that belong to the same group. A group name is a description of the functional role that the members of this group have. A group is a listing of the users that belong to this group.

A user role is a set of permissions that determine what tasks a user can perform and what services they can access on the Cisco ISE network. A user role is associated with a user group. For example, a network access user.

Cisco ISE allows you to restrict a user’s network access based on user attributes. Cisco ISE comes with a set of predefined user attributes and also allows you to create custom attributes. Both types of attributes can be used in conditions that define the authentication policy. You can also define a password policy for user accounts so that passwords meet specified criteria.

If the maximum number of sessions is configured at both the user and group level, the smaller value will have precedence. For example, if the maximum session value for a user is set as 10 and the maximum session value of the group to which the user belongs is set as 5, the user can have a maximum of 5 sessions only.

If you configure the maximum sessions to 1, and the WLC the user connects with is not running a supported version of WLC, then users gets an error telling them to disconnect and reconnect again. See Cisco Identity Services Engine Network Component Compatibility http:/​/​www.cisco.com/​c/​en/​us/​td/​docs/​security/​ise/​2-2/​compatibility/​ise_​sdt.html

Cisco ISE introduces the account disable policy for users and administrators to achieve parity with Cisco Secure ACS. While authenticating or querying a user or administrator, Cisco ISE checks the global account disable policy settings at Administration > Identity Management > Settings > User Authentication Settings page and authenticates or returns a result based on the configuration.

Cisco ISE verifies the following three policies:

• Disable user accounts that exceed a specified date (yyyy-mm-dd)—Disables the user account on the specified date. However, the account disable policy settings for an individual network access user configured at Administration > Identity Management > Identities > Users > Account Disable Policy takes precedence over the global settings.

• Disable user account after n days of account creation or last enable—Disables user accounts after specific number of days of account creation or the last date when the account was active. You can check the user status at Administration > Identity Management > Identities > Users > Status.

• Disable accounts after n days of inactivity—Disables administrator and user accounts that have not been authenticated for the configured consecutive number of days.

When you migrate from Cisco Secure ACS to Cisco ISE, the account disable policy settings specified for a network access user in Cisco Secure ACS is migrated to Cisco ISE.

Cisco ISE allows you to authenticate internal users against external identity store passwords. Cisco ISE provides an option to select the password identity store for internal users from the Administration > Identity Management > Identities > Users page. Administrators can select the identity store from the list of Cisco ISE External Identity Sources while adding or editing users in the Users page. The default password identity store for an internal user is the internal identity store. Cisco Secure ACS users will retain the same password identity store during and after migration from Cisco Secure ACS to Cisco ISE. When you upgrade from earlier versions of Cisco ISE to Cisco ISE 2.1, Cisco ISE 2.1 sets the internal identity store as the default identity store for all internal users.

Cisco ISE supports the following external identity stores for password types:

• Active Directory

• LDAP

• ODBC

• RADIUS Token server

• RSA SecurID server

Active Directory supports features such as user and machine authentications, changing Active Directory user passwords with some protocols. The following table lists the authentication protocols and the respective features that are supported by Active Directory.

Cisco ISE retrieves user or machine attributes and groups from Active Directory for use in authorization policy rules. These attributes can be used in Cisco ISE policies and determine the authorization level for a user or machine. Cisco ISE retrieves user and machine Active Directory attributes after successful authentication and can also retrieve attributes for an authorization that is independent of authentication.

Cisco ISE may use groups in external identity stores to assign permissions to users or computers; for example, to map users to sponsor groups. You should note the following restrictions on group memberships in Active Directory:

• Policy rule conditions may reference any of the following: a user’s or computer’s primary group, the groups of which a user or computer is a direct member, or indirect (nested) groups.

• Domain local groups outside a user’s or computer’s account domain are not supported.

Note

You can use the value of the Active Directory attribute, msRadiusFramedIPAddress, as an IP address. This IP address can be sent to a network access server (NAS) in an authorization profile. The msRADIUSFramedIPAddress attribute supports only IPv4 addresses. Upon user authentication, the msRadiusFramedIPAddress attribute value fetched for the user will be converted to IP address format.

Attributes and groups are retrieved and managed per join point. They are used in authorization policy (by selecting first the join point and then the attribute). You cannot define attributes or groups per scope for authorization, but you can use scopes for authentication policy. When you use a scope in authentication policy, it is possible that a user is authenticated via one join point, but attributes and/or groups are retrieved via another join point that has a trust path to the user's account domain. You can use authentication domains to ensure that no two join points in one scope have any overlap in authentication domains.

Note	See Microsoft-imposed limits on the maximum number of usable Active Directory groups: http:/​/​technet.microsoft.com/​en-us/​library/​active-directory-maximum-limits-scalability(v=WS.10).aspx

An authorization policy fails if the rule contains an Active Directory group name with special characters such as /, !, @, \, #, $, %, ^, &, *, (, ), _, +, or ~.

Cisco ISE supports certificate retrieval for user and machine authentication that uses the EAP-TLS protocol. The user or machine record on Active Directory includes a certificate attribute of the binary data type. This certificate attribute can contain one or more certificates. Cisco ISE identifies this attribute as userCertificate and does not allow you to configure any other name for this attribute. Cisco ISE retrieves this certificate and uses it to perform binary comparison.

The certificate authentication profile determines the field where the username is taken from in order to lookup the user in Active Directory to be used for retrieving certificates, for example, Subject Alternative Name (SAN) or Common Name. After Cisco ISE retrieves the certificate, it performs a binary comparison of this certificate with the client certificate. When multiple certificates are received, Cisco ISE compares the certificates to check for one that matches. When a match is found, the user or machine authentication is passed.

When authenticating or querying a user, Cisco ISE checks the following:

• MS-CHAP and PAP authentications check if the user is disabled, locked out, expired or out of logon hours and the authentication fails if some of these conditions are true.

• EAP-TLS authentications checks if the user is disabled or locked out and the authentication fails if some of these conditions is met.

Cisco ISE supports Active Directory with multidomain forests. Within each forest, Cisco ISE connects to a single domain, but can access resources from the other domains in the Active Directory forest if trust relationships are established between the domain to which Cisco ISE is connected and the other domains.

Refer to Release Notes for Cisco Identity Services Engine for a list of Windows Server Operating Systems that support Active Directory services.

Note	Cisco ISE does not support Microsoft Active Directory servers that reside behind a network address translator and have a Network Address Translation (NAT) address.

Cisco ISE supports multiple joins to Active Directory domains. Cisco ISE supports up to 50 Active Directory joins. Cisco ISE can connect with multiple Active Directory domains that do not have a two-way trust or have zero trust between them. Active Directory multi-domain join comprises a set of distinct Active Directory domains with their own groups, attributes, and authorization policies for each join.

You can join the same forest more than once, that is, you can join more than one domain in the same forest, if necessary.

Cisco ISE now allows to join domains with one-way trust. This option helps bypass the permission issues caused by a one-way trust. You can join either of the trusted domains and hence be able to see both domains.

• Join Point—In Cisco ISE, each independent join to an Active Directory domain is called a join point. The Active Directory join point is an Cisco ISE identity store and can be used in authentication policy. It has an associated dictionary for attributes and groups, which can be used in authorization conditions.

• Scope—A subset of Active Directory join points grouped together is called a scope. You can use scopes in authentication policy in place of a single join point and as authentication results. Scopes are used to authenticate users against multiple join points. Instead of having multiple rules for each join point, if you use a scope, you can create the same policy with a single rule and save the time that Cisco ISE takes to process a request and help improve performance. A join point can be present in multiple scopes. A scope can be included in an identity source sequence. You cannot use scopes in an authorization policy condition because scopes do not have any associated dictionaries.

  When you perform a fresh Cisco ISE install, by default no scopes exist. This is called the no scope mode. When you add a scope, Cisco ISE enters multi-scope mode. If you want, you can return to no scope mode. All the join points will be moved to the Active Directory folder.

  • Initial_Scope is an implicit scope that is used to store the Active Directory join points that were added in no scope mode. When multi-scope mode is enabled, all the Active Directory join points move into the automatically created Initial_Scope. You can rename the Initial_Scope.

  • All_AD_Instances is a built-in pseudo scope that is not shown in the Active Directory configuration. It is only visible as an authentication result in policy and identity sequences. You can select this scope if you want to select all Active Directory join points configured in Cisco ISE.

Identity rewrite is an advanced feature that directs Cisco ISE to manipulate the identity before it is passed to the external Active Directory system. You can create rules to change the identity to a desired format that includes or excludes a domain prefix and/or suffix or other additional markup of your choice.

Identity rewrite rules are applied on the username or hostname received from the client, before being passed to Active Directory, for operations such as subject searches, authentication, and authorization queries. Cisco ISE will match the condition tokens and when the first one matches, Cisco ISE stops processing the policy and rewrites the identity string according to the result.

During the rewrite, everything enclosed in square bracket [ ] (such as [IDENTITY]) is a variable that is not evaluated on the evaluation side but instead added with the string that matches that location in the string. Everything without the brackets is evaluated as a fixed string on both the evaluation side and the rewrite side of the rule.

The following are some examples of identity rewrite, considering that the identity entered by the user is ACME\jdoe:

• If identity matches ACME\[IDENTITY], rewrite as [IDENTITY].

  The result would be jdoe. This rule instructs Cisco ISE to strip all usernames with the ACME prefix.

• If the identity matches ACME\[IDENTITY], rewrite as [IDENTITY]@ACME.com.

  The result would be jdoe@ACME.com. This rule instructs Cisco ISE to change the format from prefix for suffix notation or from NetBIOS format to UPN formats.

• If the identity matches ACME\[IDENTITY], rewrite as ACME2\[IDENTITY].

  The result would be ACME2\jdoe. This rule instructs Cisco ISE to change all usernames with a certain prefix to an alternate prefix.

• If the identity matches [ACME]\jdoe.USA, rewrite as [IDENTITY]@[ACME].com.

  The result would be jdoe\ACME.com. This rule instructs Cisco ISE to strip the realm after the dot, in this case the country and replace it with the correct domain.

• If the identity matches E=[IDENTITY], rewrite as [IDENTITY].

  The result would be jdoe. This is an example rule that can be created when an identity is from a certificate, the field is an email address, and Active Directory is configured to search by Subject. This rule instructs Cisco ISE to remove ‘E=’.

• If the identity matches E=[EMAIL],[DN], rewrite as [DN].

  This rule will convert certificate subject from E=jdoe@acme.com, CN=jdoe, DC=acme, DC=com to pure DN, CN=jdoe, DC=acme, DC=com. This is an example rule that can be created when identity is taken from a certificate subject and Active Directory is configured to search user by DN . This rule instructs Cisco ISE to strip email prefix and generate DN.

The following are some common mistakes while writing the identity rewrite rules:

• If the identity matches [DOMAIN]\[IDENTITY], rewrite as [IDENTITY]@DOMAIN.com.

  The result would be jdoe@DOMAIN.com. This rule does not have [DOMAIN] in square brackets [ ] on the rewrite side of the rule.

• If the identity matches DOMAIN\[IDENTITY], rewrite as [IDENTITY]@[DOMAIN].com.

  Here again, the result would be jdoe@DOMAIN.com. This rule does not have [DOMAIN] in square brackets [ ] on the evaluation side of the rule.

Identity rewrite rules are always applied within the context of an Active Directory join point. Even if a scope is selected as the result of an authentication policy, the rewrite rules are applied for each Active Directory join point. These rewrite rules also applies for identities taken from certificates if EAP-TLS is being used.

Some type of identities include a domain markup, such as a prefix or a suffix. For example, in a NetBIOS identity such as ACME\jdoe, “ACME” is the domain markup prefix, similarly in a UPN identity such as jdoe@acme.com, “acme.com” is the domain markup suffix. Domain prefix should match to the NetBIOS (NTLM) name of the Active Directory domain in your organization and domain suffix should match to the DNS name of Active Directory domain or to the alternative UPN suffix in your organization. For example jdoe@gmail.com is treated as without domain markup because gmail.com is not a DNS name of Active Directory domain.

The identity resolution settings allows you to configure important settings to tune the security and performance balance to match your Active Directory deployment. You can use these settings to tune authentications for usernames and hostnames without domain markup. In cases when Cisco ISE is not aware of the user's domain, it can be configured to search the user in all the authentication domains. Even if the user is found in one domain, Cisco ISE will wait for all responses in order to ensure that there is no identity ambiguity. This might be a lengthy process, subject to the number of domains, latency in the network, load, and so on.

For Windows 2012 R2, give the Active Directory user Full Control permissions on the following registry keys:

• HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}

• HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}

The following permissions also are required when an Active Directory user is not in the Domain Admin group, but is in the Domain Users group:

• Add Registry Keys to Allow ISE to Connect to the Domain Controller (see below)

• Permissions to Use DCOM on the Domain Controller
• Set Permissions for Access to WMI Root/​CIMv2 Name Space

These permissions are only required for the following Active Directory versions:

• Windows 2003

• Windows 2003R2

• Windows 2008

• Windows 2008 R2

• Windows 2012

• Windows 2012 R2

• Windows 2016

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"AppID"="{76A64158-CB41-11D1-8B02-00600806D9B6}"

[HKEY_CLASSES_ROOT\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"="  "

[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"="  "

To get started using Cisco PassiveID work center quickly, follow this flow:

1. Ensure you have properly configured the DNS server, including configuring reverse lookup for the client machine from ISE. For more information, see DNS Server.

2. Enable the Passive Identity and pxGrid services on the dedicated Policy server (PSN) you intend to use for any of the Passive Identity services — Choose Administration > System > Deployment, open the relevant node, and under General Settings, enable Enable Passive Identity Service and pxGrid.

3. Synchronize clock settings for the NTP servers. For more information, see Specify System Time and NTP Server Settings.

4. Configure an initial provider with the ISE Passive Identity Setup. For more information, see Getting Started with the PassiveID Setup

5. Configure a single or multiple subscribers. For more information, see Subscribers

After setting up an initial provider and subscriber, you can easily create additional providers (see Additional Passive Identity Service Providers) and manage your passive identification from the different providers in the PassiveID work center:

• RADIUS Live Sessions

• Cisco ISE Alarms

• Reports

• TCP Dump Utility to Validate the Incoming Traffic

The Cisco PassiveID Work Center dashboard displays consolidated and correlated summary and statistical data that is essential for effective monitoring and troubleshooting, and is updated in real time. Dashlets show activity over the last 24 hours, unless otherwise noted. To access the dashboard, choose Work Centers > PassiveID and then from the left panel choose Dashboard. You can only view the Cisco PassiveID Work Center Dashboard in the Primary Administration Node (PAN).

The Home page has two default dashboards that show a view of your PassiveID Work Center data:

• Main—This view has a linear Metrics dashboard, chart dashlets, and list dashlets. In the PassiveID Work Center, the dashlets are not configurable. Available dashlets include:

  • Passive Identity Metrics—Passive Identity Metrics provides an overview of: the total number of unique live sessions currently being tracked, the total number of identity providers configured in the system, the total number of agents actively delivering identity data, and the total number of subscribers currently configured.

  • Providers—Providers provide user identity information to PassiveID Work Center. You configure the ISE probe (mechanisms that collect data from a given source) through which to receive information from the provider sources. For example, an Active Directory (AD) probe and an Agents probe both help ISE-PIC collect data from AD (each with different technology) while a Syslog probe collects data from a parser that reads syslog messages.

  • Subscribers—Subscribers connect to ISE to retrieve user identity information.

  • OS Types—The only OS type that can be displayed is Windows. Windows types display by Windows versions. Providers do not report the OS type, but ISE can query Active Directory to get that information. Up to 1000 entries are displayed in the dashlet. If you have more endpoints than that, or if you wish to display more OS types than Windows, you can upgrade to ISE.

  • Alarms—User identity-related alarms.

Active Directory (AD) is a highly secure and precise source from which to receive user identity information, including user name, IP address and domain name.

The AD probe, a Passive Identity service, collects user identity information from AD through WMI technology, while other probes use AD as a user identity provider through other technologies and methods. For more information about other probes and provider types offered by ISE, see Additional Passive Identity Service Providers.

By configuring the Active Directory probe you can also then quickly configure and enable these other probes (which also use Active Directory as their source):

• Agent—Active Directory Agents

• SPAN—SPAN

• Endpoint probe—Endpoint Probe

In addition, configure the Active Directory probe in order to use AD user groups when collecting user information. You can use AD user groups for the AD, Agents, SPAN and Syslog probes. For more information about AD groups, see Configure Active Directory User Groups.

In order to enable ISE to provide identity information (Passive Identity Service ) to consumers that subscribe to the service (subscribers), you must first configure an ISE probe, which connects to the identity provider.

Providers that have been mapped and are actively delivering information to ISE can be viewed in the session directory, from the Live Sessions menu. For more information about Live Sessions, see RADIUS Live Sessions.

The table below provides details about all of the provider and probe types available from ISE, while the remainder of the chapter provides information regarding all types available except for Active Directory which is described in detail, in a dedicated chapter. For more information, see Active Directory as a Probe and a Provider.

You can define these provider types:

From the Passive Identity service work center install the native 32-bit application, Domain Controller (DC) agents, anywhere on the Active Directory (AD) domain controller (DC) or on a member server (based on your configurations) to retrieve user identity information from AD and then send those identities to the subscribers you have configured. The Agent probe is a quick and efficient solution when using Active Directory for user identity information. Agents can be installed on a separate domain, or on the AD domain, and once installed, they provide status updates to ISE once every minute.

The agents can be either automatically installed and configured by ISE, or you can manually install them. Upon installation, the following occurs:

• The agent and its associated files are installed at the following path: Program Files/Cisco/Cisco ISE PassiveID Agent

• A config file called PICAgent.exe.config is installed indicating the logging level for the agent. You can manually change the logging level from within the config file.

• The CiscoISEPICAgent.log file is stored with all logging messages.

• The nodes.txt file contains the list of all nodes in the deployment with which the agent can communicate. The agent contacts the first node in the list. If that node cannot be contacted, the agent continues to attempt communication according to the order of the nodes in the list. For manual installations, you must open the file and enter the node IP addresses. Once installed (manually or automatically), you can only change this file by manually updating it. Open the file and add, change or delete node IP addresses as necessary.

• The Cisco ISE PassiveID Agent service runs on the machine, which you can manage from the Windows Services dialog box.

• Each agent can monitor up to 100 domain controllers.

If you cannot install agents, then use the Active Directory probe for passive identity services. For more information, see Active Directory as a Probe and a Provider.

The API Providers feature in Cisco ISE enables you to push user identity information from your customized program or from the terminal server (TS)-Agent to the built-in ISE passive identity services REST API service. In this way, you can customize a programmable client from your network to send user identities that were collected from any network access control (NAC) system to the service. Furthermore, the Cisco ISE API provider enables you to interface with network applications such as the TS-Agent on a Citrix server, where all users have the same IP address but are assigned unique ports.

For example, an agent running on a Citrix server that provides identity mappings for users authenticated against an Active Directory (AD) server can send REST requests to ISE to add or delete a user session whenever a new user logs in or off. ISE then takes the user identity information, including the IP address and assigned ports, delivered from the client and sends it to pre-configured subscribers, such as the Cisco Firepower Management Center (FMC).

The ISE REST API framework implements the REST service over the HTTPS protocol (no client certificate validation necessary) and the user identity information is delivered in JSON (JavaScript Object Notation) format. For more information about JSON, see http:/​/​www.json.org/​ .

The ISE REST API service parses user identities and in addition, maps that information to port ranges, in order to distinguish between the different users logged in simultaneously to one system. Everytime a port is allocated to a user, the API sends a message to ISE.

SPAN is a Passive Identity service that allows you to quickly and easily enable ISE to listen to the network and retrieve user information without having to configure Active Directory to work directly with ISE. SPAN sniffs network traffic, specifically examining Kerberos messages, extracts user identity information also stored by Active Directory and sends that information to ISE. ISE then parses the information, ultimately delivering user name, IP address and domain name to the subscribers that you have also already configured from ISE.

In order for SPAN to listen to the network and extract Active Directory user information, ISE and Active Directory must both be connected to the same switch on the network. In this way, SPAN can copy and mirror all user identity data from Active Directory.

With SPAN, user information is retrieved in the following way:

1. The user endpoint, on the network, logs in.

2. Log in and user data are stored in Kerberos messages.

3. Once the user logs in and the user data passes through the switch, SPAN mirrors the network data.

4. ISE listens to the network for user information and retrieves the mirrored data from the switch.

5. ISE parses the user information and updates passive ID mappings.

6. ISE delivers the parsed user information to the subscribers.

With the Syslog feature, the Passive Identity service parses syslog messages from any client (identity data provider) that delivers syslog messages, including regular syslog messages (from providers such as InfoBlox, Blue Coat, BlueCat, and Lucent) as well as DHCP syslog messages, and sends back user identity information, including MAC addresses. This mapped user identity data is then delivered to subscribers.

The Passive Identity service utilizes syslog messages received from a variety of providers once the administrator activates Passive ID and pxGrid services and configures the syslog client from the GUI. When configuring the provider, the administrator indicates the connection method (TCP or UDP) and the syslog template to be used for parsing.

Note

When TCP is the configured connection type, if there is a problem with the message header and the host name cannot be parsed, then ISE attempts to match the IP address received in the packet to the IP address of any of the providers in the list of providers that have already been configured for Syslog messages in ISE. To view this list, choose Work Centers > PassiveID > Providers > Syslog Providers. It is recommended that you check the message headers and customize if necessary in order to guarantee parsing succeeds. For more information about customizing headers, see Customize Syslog Headers.

Once configured, the syslog probe sends syslog messages that are received to the ISE parser, which maps the user identity information, and publishes that information to ISE. ISE then delivers the parsed and mapped user identity information to the Passive Identity service subscribers.

Note

DHCP syslog messages do not contain user names. Therefore, these messages are delivered from the parser with a delay so that ISE can first check users registered in the local session directory (displayed from Live Sessionss) and attempt to match those users by their IP addresses to the IP addresses listed in the DHCP syslog messages received, in order to correctly parse and deliver user identity information. If the data received from a DHCP syslog message cannot be matched to any of the currently logged in users, then the message is not parsed and user identity is not delivered.

In order to parse syslog messages for user identity from ISE:

• Configure syslog clients from which to receive user identity data—Configure Syslog Clients

• Customize a single message header—Customize Syslog Headers

• Customize message bodies by creating templates—Customize the Syslog Message Body.

• Use the message templates pre-defined in ISE when configuring your syslog client as the message template used for parsing, or base your customized header or body templates on these pre-defined templates—Work with Syslog Pre-Defined Message Templates.