cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
707
Views
0
Helpful
6
Replies

ISE LDAP authentication problem

echo
Level 1
Level 1

Hello!
I am very new to ISE and I have one which is empty. I upgraded it to 3.3p4. My goal is to set it up for Cisco switch administration over TACACS+ so that the admin accounts are located in MS AD -- we want to use the already existing AD accounts (and possibly for a failover, use local accounts defined in ISE, lastly switch-local accounts). Maybe it is not important but there is already a working NAC solution for end users' computers who connect to the switches (against MS AD-integrated RADIUS servers) which I set up and also, by expanding aaa, I got the admin login (for switch administration) working against the same RADIUS servers. But we need to log the commands that admins enter so that's why we need TACACS+ and we have ISE for that. I found two possible other solutions to get this without using TACACS+ but they're not good enough. Also, I prefer not to go through "adding ISE to domain" and want to use LDAPS instead.

It has been challenging to configure ISE: so many details and possible policy elements and new terms for naming those elements, the ISE seems to be like a different kind of MS AD type of permission system. So many possibilities but to get one needed out of the possible tens or hundreds of scenarios and options is very difficult, especially for a beginner.

Anyway, I have finally defined a policy and the initial conditions are met when I try to log in: "Network access . Protocol equals" TACACS+ and "Network Condition . Allowed networks" equals True. Next is the default authentication policy Default where I have changed Use column to the LDAP connection which includes the specific group in AD against which I want to authenticate and attribute sAMAccountName because I want admins and myself use the username of this form. The three lower options are default. I never get past this point because authorization policy gets no hits.

The result when logging into switch is:

Message TextFailed-Attempt: Authentication failed
Failure Reason22056 Subject not found in the applicable identity store(s)

In steps part: "User not found in LDAP Server - EIS_LDAP_GRP".

So is there anybody who has a working device authentication over TACACS+ that uses LDAPS connection? Any hints or examples about where exactly should each detail be configured?

As a last resort, I could try to set it up for local ISE authentication first and then expand to LDAPS after that.

 

Another thing that is unclear is about the authentication orders. There are at least two principally different ways I can think of:

1a. if an auth server (LDAPS) responds, check the user and if it is not found or password is wrong etc., auth fails,

1b. if the first auth server does not respond, try the backup and if this also fails then auth fails;

2. if an auth server (LDAPS) responds, check the user and if it is not found, go to the next type of auth server, eg ISE local user and if this doesn't have the user, check the local users defined in the switch.

I am more interested in the second type of sequence but I don't understand what is the proper way to define such a sequence and in which place of the policy I have to use it (should I use the special sequence object or not because I don't know the logic there).

 

I have read the admin guides for a while already and have tried different ways to create the policy but they don't give me clear answers what to define where for my setup (or I haven't found it yet) that's why I ask here.

1 Accepted Solution

Accepted Solutions

echo
Level 1
Level 1

I tried finding examples of this authentication using Google and Bing searches but I didn't really find any and I am surprised that my goal/need seems to be so rare.

I found this though: ISE and LDAP Attributes Based Authentication - Cisco. This gave me an idea to test the Custom schema. Unbelievable but this helped!

So ISE Active Directory schema does not work properly, or? Of course I assumed that this is so standard and old stuff that it's just a formality there and can be chosen only to offer integration with other types of LDAP servers than just MS AD. But it's not like that.

I configured the custom schema like this:

echo_0-1748269672966.png

I'm not sure if this is the ideal configuration but it works. For example, the subject and group objectclasses may be something else, maybe "top" as I see from the AD-objects' attributes, but nevermind.

Now Attributes tab. It turned out this place is meant to describe the building blocks to build the Authorisation policy. I pasted my admin test user's distinguishedName (CN=testuser,CN=...,OU=...,...,DC=contoso,DC=com) into "Example Subject" and pressed Retrieve Attributes. From the retrieved list I chose two rows: sAMAccountName and memberOf -- just because the first is the user name I want to use to log in to switches and the second one is to check the group membership. Back in the General tab, I chose the first of the two options "Subject Objects Contain..." because memberOf was shown in this retrieved list of attributes. And lastly, because the value of memberOf attribute was in the form of distinguishedName of the group I am authenticating against (CN=testgroup,OU=...,...,DC=contoso,DC=com), I chose that in the drop down list of "Subjects In Groups Are..." (if it wasn't like that by default already). I cleared what I had done in Groups tab earlier.

(Just a note to those who haven't done too much with AD. When using "Active Directory Users and Computers" in MMC and having this opened, choose View>Advanced Features to see more tabs when opening a user or group object. This gives the Attribute Editor tab from where it is very simple to copy and paste both attributes and values to ISE. Also, having the Attribute Editor opened, choose Filter (button)>Show only attributes that have values.)

And now the policy.

1. The main condition. I checked the Device type what I want (as I defined my test switch), then the Network Access>Protocol equals TACACS+ and lastly Network Condition>Allowed management networks (defined earlier) equals true.

2. Authentication policy. I left the Default only and used a custom order of authentication in Use column: first LDAP, then ISE (that is, Internal users from the ISE point of view). Options left as default.

3. Authorization policy. I want my order be 1. LDAP, 2. ISE. So I added two new lines with their conditions and I leftthe third Default as denying all commands.

3.1 The first line was puzzling: how to put there the simple "user is member of this AD-group"? That's where this memberOf attribute was helping, that is, it is in the list now to choose in the editor. It works like this: EIS_LDAPS·memberOf CONTAINS CN=testgroup,OU=...,...,DC=contoso,DC=com (this value can be pasted there as text). And the actions in the Results>Command Sets and Shell Profiles: my own defined allow all commands and attributes for the login (eg having the privilege level and session timeout set).

3.2 The second line is for ISE internal users. This was easier: IdentityGroup·Name EQUALS User Identity Group:<an ISE group with a test user inside, configured earlier>.

This way I got my authentication working against AD with LDAPS with ISE as the second option but I will most certainly tweak or improve the details in the upcoming days.

Maybe the best practice of these details in ISE is a bit different but I'm doing it first time so I can make it better later.

A warning too: negative testing (that other AD-users can't log in) is important in these AD-related authentications and not only in this case with ISE. For example, when using Continue in the options in the Authentication policy, any AD-user could log in (of course, provided they happen to have network level access to the switch management IP-address). I only tested this Continue to try to get the order of authenticating servers working this way: if the user is not present in the AD, then use ISE internal users. But as I suspected and as it was already described in this post, I had to use my own Identity Source Sequence for that: Solved: Re: ISE device authentication local and AD in one policy - Cisco Community. I have already seen this in the past with another device that when setting up AD authentication for device administration, I got it working (good!) and only after a couple of weeks or months I had a hunch and when testing a user that was not in the AD group meant for administration, that one also authenticated successfully (bad!).

I wrote all this down here so perhaps this could be useful to somebody else too.

Thank you who responded! I will ask other questions that are not related to the initial question in other posts.

View solution in original post

6 Replies 6

Why don't you want to join ISE to AD? Every customer I have ever worked with has their NAC solution joined to AD.

Is it any better or would it make any difference? I don't do NAC here with ISE but only admin authentication (device administration) with TACACS+. I considered LDAPS connection simpler and preferred because in any other device with a need to authenticate admins against AD for device administration the LDAPS is the usual thing to do (or RADIUS), there is no such thing as joining domain in those devices and no need for that. If I would like to authenticate end users (with computer certificates) in the switch ports, that is, do the NAC, the AD-connection would be necessary just like the MS NPS servers need to be AD-integrated for NAC; but my need is simpler.

PSM
Level 1
Level 1

@echo  If you go to Administration>Identity Management > External > Identity Sources and then to LDAP connection.

1. In "connection" tab what happens when you click on "Test Bind to Server"

2. In Directory Organization" tab have you defined Subject Search Base and Group Search Base correctly ?

1. This works nice.

2. There I have set up the whole domain level (DC=contoso,DC=com), I didn't need to narrow it down to anything more specific.

PSM
Level 1
Level 1

Ok, can you share snapshot of general tab from LDAP connection.

echo
Level 1
Level 1

I tried finding examples of this authentication using Google and Bing searches but I didn't really find any and I am surprised that my goal/need seems to be so rare.

I found this though: ISE and LDAP Attributes Based Authentication - Cisco. This gave me an idea to test the Custom schema. Unbelievable but this helped!

So ISE Active Directory schema does not work properly, or? Of course I assumed that this is so standard and old stuff that it's just a formality there and can be chosen only to offer integration with other types of LDAP servers than just MS AD. But it's not like that.

I configured the custom schema like this:

echo_0-1748269672966.png

I'm not sure if this is the ideal configuration but it works. For example, the subject and group objectclasses may be something else, maybe "top" as I see from the AD-objects' attributes, but nevermind.

Now Attributes tab. It turned out this place is meant to describe the building blocks to build the Authorisation policy. I pasted my admin test user's distinguishedName (CN=testuser,CN=...,OU=...,...,DC=contoso,DC=com) into "Example Subject" and pressed Retrieve Attributes. From the retrieved list I chose two rows: sAMAccountName and memberOf -- just because the first is the user name I want to use to log in to switches and the second one is to check the group membership. Back in the General tab, I chose the first of the two options "Subject Objects Contain..." because memberOf was shown in this retrieved list of attributes. And lastly, because the value of memberOf attribute was in the form of distinguishedName of the group I am authenticating against (CN=testgroup,OU=...,...,DC=contoso,DC=com), I chose that in the drop down list of "Subjects In Groups Are..." (if it wasn't like that by default already). I cleared what I had done in Groups tab earlier.

(Just a note to those who haven't done too much with AD. When using "Active Directory Users and Computers" in MMC and having this opened, choose View>Advanced Features to see more tabs when opening a user or group object. This gives the Attribute Editor tab from where it is very simple to copy and paste both attributes and values to ISE. Also, having the Attribute Editor opened, choose Filter (button)>Show only attributes that have values.)

And now the policy.

1. The main condition. I checked the Device type what I want (as I defined my test switch), then the Network Access>Protocol equals TACACS+ and lastly Network Condition>Allowed management networks (defined earlier) equals true.

2. Authentication policy. I left the Default only and used a custom order of authentication in Use column: first LDAP, then ISE (that is, Internal users from the ISE point of view). Options left as default.

3. Authorization policy. I want my order be 1. LDAP, 2. ISE. So I added two new lines with their conditions and I leftthe third Default as denying all commands.

3.1 The first line was puzzling: how to put there the simple "user is member of this AD-group"? That's where this memberOf attribute was helping, that is, it is in the list now to choose in the editor. It works like this: EIS_LDAPS·memberOf CONTAINS CN=testgroup,OU=...,...,DC=contoso,DC=com (this value can be pasted there as text). And the actions in the Results>Command Sets and Shell Profiles: my own defined allow all commands and attributes for the login (eg having the privilege level and session timeout set).

3.2 The second line is for ISE internal users. This was easier: IdentityGroup·Name EQUALS User Identity Group:<an ISE group with a test user inside, configured earlier>.

This way I got my authentication working against AD with LDAPS with ISE as the second option but I will most certainly tweak or improve the details in the upcoming days.

Maybe the best practice of these details in ISE is a bit different but I'm doing it first time so I can make it better later.

A warning too: negative testing (that other AD-users can't log in) is important in these AD-related authentications and not only in this case with ISE. For example, when using Continue in the options in the Authentication policy, any AD-user could log in (of course, provided they happen to have network level access to the switch management IP-address). I only tested this Continue to try to get the order of authenticating servers working this way: if the user is not present in the AD, then use ISE internal users. But as I suspected and as it was already described in this post, I had to use my own Identity Source Sequence for that: Solved: Re: ISE device authentication local and AD in one policy - Cisco Community. I have already seen this in the past with another device that when setting up AD authentication for device administration, I got it working (good!) and only after a couple of weeks or months I had a hunch and when testing a user that was not in the AD group meant for administration, that one also authenticated successfully (bad!).

I wrote all this down here so perhaps this could be useful to somebody else too.

Thank you who responded! I will ask other questions that are not related to the initial question in other posts.