In this session, we'll be configuring Active Directory Integration so that ISE can

refer to Active Directory to look up and validate user objects and credentials, as
well as group names. To start off here, we'll take advantage of the Work Center, as
it provides some nice easy links and information helpful to the task at hand.
In this case, we're adding an external identity store. Note that ISE can be its own
identity store for many purposes, users, groups, and the like. One exception would
be the use of validating an endpoint ID certificate. ISE is currently not able to
authenticate using certificates from endpoints. But other than that, yeah, ISE can
be used for many things as an internal identity store.
In this case, though, Active Directory will be external. Let's go ahead and add
that. See the list of possible external identity sources that can be provided.
Active Directory is the first one on the list there. And we'll do an Add. In this
case, we're given two fields to fill out. The first one is called the Join Point
Name.
In this case, this is just a descriptive label that ultimately will be added into
the ISE dictionaries and available for policy building. So as we look at the
Condition Studio later on, that this is the value that we'll see listed here. If
needed, this name can be changed subsequent to adding it here. If we decide that we
have a better label or other domains that need to be added and distinguished
better, we can change that.
And then this is the actual domain name, not the domain controller itself, but the
domain name. And this was the official needs to be name resolvable domain name. ISE
needs to be pointing to a DNS server that can resolve this name to a set of DCIP
addresses and SRV records and the like.
We'll submit that. It gives us the opportunity to join all ISE nodes to the Active
Directory domain. So in the case of a multi-node deployment, that is a nice
convenient shortcut. And here, prompting us for credentials, what we need to supply
here are credentials sufficient to being able to add a computer object to the
domain. And one thing that we should point out here is that ISE becomes a full
domain member subsequent to this operation.
Additionally, to get somewhat more creative, we can place the ISE computer object
into a particular OU within the domain. It won't create this OU, but we can add it
and make it distinguishable from the rest of the computer objects that are probably
in the domain as well. Gives us a quick validation that the ISE node has been
joined to the domain.
Now, against this, and can be done at any particular point, if we suspect there are
issues with the communication from this node towards Active Directory, we can run
diagnostics. We'll go ahead and run all tests now. And we'll give a very thorough
interaction with that domain and related domain controllers. And verify
everything's operating properly.
Notice that with this dropdown that we could select particular nodes to run this
diagnostic tool from. Ultimately, in a distributed deployment, it's the PSN nodes
or policy service nodes that will need to be able to interact directly with a
domain for network reachability and what have you. In this case, yeah, be aware
that you have the full suite of ports are needed to be able to interact with the
domain. And then, likewise, we don't want to have any network translation policy in
the way of the ISE node that needs to interact with the domain controller. The node
network translation should be taking place there.
If we go back to our demo.local, in addition to the domain join point name itself,
we'll want to add other objects to the dictionary to support policy building, in
particular, user groups. And here we can do an Add. We can add our own information.
It's better to take advantage of browsing into the domain and retrieving those
group values.
In this case, the default filter has been left to All. So we're seeing a
substantial amount of groups in this list, many of which won't ever be utilized for
ISE policy building. So let's reduce the size of this list and look at globally
distributed objects in Retrieve once again. And here, we get a shorter list.
Let's go ahead and select All, and then deselect some that we know that we won't be
using. We won't need the DNS update proxy. We won't need domain controllers, but we
do want domain computers. We won't take advantage of domain guests. We won't take
advantage of group policy creators. And we won't take advantage of read-only domain
controllers.
So understand now what's happening here is we're importing these group objects into
the ISE dictionary where we can now use them for policy building. And it's also
important to note that this is more than just a name that's being matched and
validated against information being retrieved from the domain controller from the
domain itself. Notice that the set values are the more specific match.
If we need to modify this list later on, we can remove groups from the list, or of
course, add to them by redoing this operation. If new groups have been added
subsequent to this, we can add those groups. In addition to the groups, we'll also
want to add some specific object attributes. And we'll search on the directory, in
this case, for a particular user and user-related attributes.
Yeah, and there's a variety of attributes within any particular object that could
be useful for policy matching. In this case, we'll monitor bad password count. We
can derive policy around how many bad password attempts have been attempted so far.
And down at the bottom of the list, the user principal name we're wanting to match.
And so now, again, similar to the group objects, these objects, these attributes
for the user object are now also added to our dictionary for policy building on
ISE.
And we'll save that. This should save both the groups and the attributes. And we
get a success message back. And if we go back to the connection, notice one of the
other things that we can do here is test user access. ISE is a great platform for
this kind of activity that, as opposed to trying to get out into a network and
validate that the whole authentication loop is occurring, that we can check those
concepts and reachability and validation of authentication to that domain right
here.
We'll modify the tests that we're doing by performing a user look-up first. And
although we effectively already did this by looking at the attributes for employee
2, we see that we were able to retrieve those successfully. Have additional
information. Again, these values that are effectively retrieved along with the
authentication success, in this case just a look-up, we also can utilize any of
these values for policy building within ISE.
Try that again here with Kerberos. And this time, we're requiring a password. Let's
test the full credentials. And here, we see success. So credentials are matched and
valid. And we see a little bit of the interaction time between our node, that in
addition to PAN and MNT is also acting as a PSN and how long it took to retrieve
this information.
And then last we'll try interaction with a remote procedure call. And we see
successful interaction with that and basic authentication timers. These are
valuable when we consider overall latency between users and portals and whatnot,
that this would be a value in addition to that latency retrieval time from the
Active Directory domain.
Here we went through very briefly joining ISE to an Active Directory domain. Once
again, ISE becomes a domain computer object within the perspective of the Active
Directory domain itself. And this allows us to derive access to our users via
Active Directory and, of course, additional information being obtained by the mere
interaction. Group objects, as well as specific user attributes, can all be taken
advantage of within policy on ISE.