By default, Cisco ISE provides internal administrator authentication. To set up external authentication, you must create a password policy for the external administrator accounts that you define in the external identity stores. You can then apply this policy to the external administrator groups that eventually become a part of the external administrator RBAC policy.

To configure external authentication, you must:

• Configure password-based authentication using an external identity store.

• Create an external administrator group.

• Configure menu access and data access permissions for the external administrator group.

• Create an RBAC policy for external administrator authentication.

In addition to providing authentication via an external identity store, your network may also require you to use a Common Access Card (CAC) authentication device.

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 network access based on user attributes for both network access users and administrators. 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.

Custom User Attributes

You can configure more user-account attributes on the User Custom Attributes window (Administration > Identity Management > Settings > User Custom Attributes). You can also view the list of predefined user attributes in this window. You cannot edit the predefined user attributes.

Enter the required details in the User Custom Attributes pane to add a new custom attribute. The custom attributes and the default values that you add on the User Custom Attributes window are displayed while adding or editing a Network Access user (Administration > Identity Management > Identities > Users > Add/Edit) or Admin user (Administration > System > Admin Access > Administrators > Admin Users > Add/Edit). You can change the default values while adding or editing a Network Access or Admin user.

You can select the following data types for the custom attributes on the User Custom Attributes window:

• String: You can specify the maximum string length (maximum allowed length for a string attribute value).

• Integer: You can configure the minimum and maximum value (specifies the lowest and the highest acceptable integer value).

• Enum: You can specify the following values for each parameter:

  • Internal value

  • Display value

  You can also specify the default parameter. The values that you add in the Display field are displayed while adding or editing a Network Access or Admin user.

• Float

• Password: You can specify the maximum string length.

• Long: You can configure the minimum and maximum value.

• IP: You can specify a default IPv4 or IPv6 address.

• Boolean: You can set either True or False as the default value.

• Date: You can select a date from the calendar and set it as the default value. The date is displayed in yyyy-mm-dd format.

Check the Mandatory check box if you want to make an attribute mandatory while adding or editing a Network Access or Admin user. You can also set default values for the custom attributes.

The custom attributes can be used in the authentication policies. The data type and the allowable range that you set for the custom attributes are applied to the custom attribute values in the policy conditions.

Remember

Some characters are considered invalid for Attribute Names and Attribute Values. Using the following characters for Attribute Names and Attribute Values is restricted. Attribute Value: @, =, +, or - (do not use these characters at the beginning of an attribute name or value) Attribute Name: ^, =, , \, ", `, |, : (do not use these characters anywhere in the string)

Not all external identity stores allow network access users to change their passwords. See the section for each identity source for more information.

Network-use password rules should be configured in Administration > Identity Management > Settings > User Authentication Settings.

The following section has additional information about some of the fields in the Password Policy tab.

• Required Characters: If you configure a user-password policy that requires upper or lowercase characters, and the user’s language does not support these characters, the user cannot set a password. To support UTF-8 characters, uncheck the following check boxes:

  • Lowercase Alphabetic Characters

  • Uppercase Alphabetic Characters

• Password Change Delta: Specifies the minimum number of characters that must change when changing the current password to a new password. From Cisco ISE 3.2, the passowrd range has changed to 1-20. Cisco ISE does not consider changing the position of a character as a change. For Example, if the password delta is 3, and the current password is "?Aa1234?", then "?Aa1567?" ("5","6" and "7" are the three new characters) is a valid new password. "?Aa1562?" fails, because "?","2", and "?" characters are in the current password. "Aa1234??" fails, because even though the character positions changed, the same characters are in the current password.

  Password change delta also considers the previous X passwords, where X is the value of Password must be different from the previous versions. If your password delta is 3, and your password history is 2, then you must change the four characters that are not a part of the past two passwords.

• Dictionary words: Check this check box to restrict the use of any dictionary word, its characters in reverse order, or its letters replaced with other characters.

  Substitution of "$" for "s", "@" for "a", "0" for "o", "1" for "l", "!" for "i", "3" for "e", is not permitted. For example, "Pa$$w0rd".

  • Default Dictionary: Choose this option to use the default Linux dictionary in Cisco ISE. The default dictionary contains approximately 480,000 English words.

  • Custom Dictionary: Choose this option to use your customized dictionary. Click Choose File to select a custom dictionary file. The text file must be of newline-delimited words, .dic extension, and size less than 20 MB.

• You can use the Password Lifetime section to update the password reset interval and reminder. To set the lifetime of a password, check the Change password every __ days (valid range 1 to 3650) check box, and enter the number of days in the input field. A user account can be disabled if a user does not change the password in the specified time by selecting the Disable User Account option. Choose the Require password change on next login to prompt the user to change their password the next time they login to Cisco ISE.

  To send a reminder email for password reset, check the Display Reminder __ Days Prior to Password Expiration check box and enter the number of days before which a reminder email should be sent to the email address configured for the network access user. While creating a network access user, you can add the email address in the Administration > Identity Management > Identities > Users > Add Network Access User window to send an email notification for password reset.

  Note

  The reminder email is sent from the following email address: iseadminportal@<ISE-Primary-FQDN>. You must explicitly permit access for this sender. By default, the reminder email has the following content: Your network access password will expire on <password expiry date and time>. Please contact your system administrator for assistance. From Cisco ISE Release 3.2, you can customize the email content after the Please contact your system administrator for assistance portion of the email notification. From Cisco ISE Release 3.2, if the Change Password check box is not checked under the Password Lifetime field (Administration > Identity Management > Settings > User Authentication Settings > Password Policy > Password Lifetime), the Password Lifetime field is not displayed for this user in the Network Access Users window.

• Lock/Suspend Account with Incorrect Login Attempts: Use this option to suspend or lock an account if the login attempt failed for the specified number of times. The valid range is from 3 to 20.

• Account Disable Policy: Configure the rules about when to disable an existing user account. See Disable User Accounts Globally for more information.

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 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. The disable accounts after n days of inactivity option is only applicable for Cisco ISE Internal Users using internal passwords.

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.

Note

A collection filter configured for any Filter Type filters out the authentication syslog messages that are sent to the monitoring node. For more information, see the topic "Collection Filters" in the chapter "Maintain and Monitor" in the Cisco ISE Administrator Guide. If you configure a collection filter (Administration > System > Logging > Collection Filter) for any Attribute and Filter Type; and you have also selected the Disable account after n days of inactivity check box (Administration > Identity Management > User Authentication Settings > Disable Account Policy), your account might be disabled as a result of the syslog messages of successful authentication not being relayed to the monitoring node.

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 window. Administrators can select the identity store from the list of Cisco ISE External Identity Sources while adding or editing users in the Users window. 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.

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

• Active Directory

• LDAP

• ODBC

• RADIUS Token server

• RSA SecurID server

Note

As per the current design, if authentication is done against an external ID store, then the internal user identity group name cannot be configured in authorization policy. In order to use internal user identity group for authorization, authentication policy must be configured to authenticate against Internal Users ID store and password type, which can be either internal or external, must be selected in user configuration.

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.

During the authorization process in a multi join point configuration, Cisco ISE will search for join points in the order in which they listed in the authorization policy, only until a particular user has been found. Once a user has been found the attributes and groups assigned to the user in the join point, will be used to evaluate the authorization policy.

In a multi join point configuration, if authentication is successful for the same identity from each of the join points individually, then this authentication fails if it is done against the identity source sequence "All_AD_Join_Points".

In a multi join point configuration, if Active Directory group retrieval is successful for the same identity from each of the join points individually, then Active Directory group retrieval fails if:

• different join points are used for authentication and authorization.

• authentication uses EAP-TLS without Binary Comparison (Match Client Certificate Against Certificate In Identity Store is set to Never in the Certificate Authentication Profile) and there is an unmatched authorization rule with a different join point ahead of the matched authorization rule.

• authentication uses EAP-TLS without Binary Comparison (Match Client Certificate Against Certificate In Identity Store is set to Never in Certificate Authentication Profile) and Machine Access Restriction (MAR) is enabled with the endpoint using a different join point within the MAR period, from the join point in the current matched authorization rule.

Note

In a multi join point configuration, Active Directory group retrieval is successful for each of the join points individually, but it fails if the authentication rule is configured with an identity source sequence that includes "All_AD_Join_Points". Active Directory group retrieval also fails if different join points are used for authorization and authentication. 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 ~.

Admin user login through Active Directory might fail if the admin username contains $ character.

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 any of these conditions are true.

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

From Cisco ISE Release 3.1, Cisco ISE supports endpoint authentication and authorization with Microsoft Entra ID. Cisco ISE Release 3.1 supports only the Resource Owner Password Credentials (ROPC) method. Cisco ISE Release 3.2 supports EAP-TLS and TEAP methods in addition to the ROPC flow.

Caution

The Resource Owner Password Credentials (ROPC) flow in Cisco ISE is a controlled introduction feature. We recommend that you thoroughly test this feature in a test environment before using it in a production environment.

Resource Owner Password Credentials (ROPC) is an OAuth 2.0 grant type that allows Cisco ISE to carry out authorization and authentication in a network with cloud-based identity providers.

Using the ROPC flow, Cisco ISE validates a user’s credentials with a cloud-based identity source. The ROPC flow supports plaintext authentication protocols.

Cisco ISE currently supports Microsoft Entra ID through the ROPC flow.

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.

Cisco ISE identifies users using the attributes SAM, CN, or both. Cisco ISE uses sAMAccountName attribute as the default attribute.

You can configure Cisco ISE to use SAM, CN, or both, if your environment requires it. When SAM and CN are used, and the value of the SAMAccountName attribute is not unique, Cisco ISE also compares the CN attribute value.

Note	To modify this default behavior, change the value of the "IdentityLookupField" flag as mentioned in the "Configure Attributes for Active Directory Identity Search" section.

For Windows Server 2012 R2, give the Microsoft AD 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}

Use the following commands in Windows PowerShell to check if full permission is given to the registry keys:

• get-acl -path "Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}" | format-list

• get-acl -path "hklm:\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}" | format-list

The following permissions are required when a Microsoft AD user is not in the Domain Admin group, but is in the Domain Users group:

• Add registry keys to allow Cisco ISE to connect to the domain controller.

• Permissions to Use DCOM on the Domain Controller

• Set Permissions for Access to WMI Root and CIMv2 Namespace

These permissions are only required for the following Microsoft AD 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 Cisco 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.

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.

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.

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 Main 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: Displays 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.

  • 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.

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):

• Active Directory Agents

  Note	The Active Directory agents are only supported on Windows Server 2008 and higher.

• SPAN

• 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.