Using ODBC as an Identity Source for Guest Portal authentication

[Arne Bier]

Hello

I did some searches but I cannot find the answer whether ISE 2.4 allows an ISE Guest Portal to perform username/password authentication against an SQL database, instead of the ISE Internal Guest repository.  The idea is that the customer has a Microsoft SQL Database containing a list of users that they want to give guest internet access.  The users would only need to enter their unique ID and then click "Login".  ISE would make a stored procedure call to the SQL database and return some arguments (pass/fail, client_type, etc.).

is this feasible?  A Portal Configuration has the "Authentication method" option and I have only ever used the Internal Users, Guest Users or AD Join Points.  Not sure whether ODBC also works here?  The reason I am unsure is that I see MAC address mentioned a lot in the ODBC config in ISE - I don't see how this plays into a web authentication to a SQL database, since the DB doesn't contain any MAC address data.

thanks in advance

regards

[Jason Kunst · Accepted solution]

ISE supports external identity sources using ODBC. It doesn’t have the ability to do direct SQL calls. If that’s needed you could authenticate against another RADIUS server as a proxy.

The guest flow only has the ability to authenticate a username and password. There is no ability to pass along other attributes from the guest portal for verification.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210521-Configure-ISE-2-2-for-integration-with-M.html

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/compatibility/b_ise_sdt_24.html#externalidstores

[hslai · Accepted solution]

Jason Kunst is mostly correct.

However, we should be able use an ODBC identity source to authenticate the login at an ISE guest portal, similarly to AD or LDAP, and depending on how the store procedure or function configured on the DBMS and mapped to ISE for the plain-text password authentication. Upon successful login, then attributes (using the stored procedure/function) mapped to Fetch Attributes) may be evaluated for authorize-only CoA.

[Arne Bier]

Hello @hslai and @Jason Kunst 

Hsing, are you able to perform a quick proof of concept test in your Cisco labs against a basic SQL database, to see whether one can map back the responses from the ODBC query to an ISE Guest Type?

e.g

ODBC response = "patient" -> ISE GuestType: GUEST_TYPE_PATIENT

ODBC response = "contractor" -> ISE GuestType: GUEST_TYPE_CONTRACTOR

This initial response would inform ISE about the Guest Type, so that we can store the MAC address of the client in the appropriate Endpoint Identity Store.  This would be crucial for a RememberMe call flow.

How else could this pan out?

[hslai · Accepted solution]

ISE is only mapping the info from an external ID source to an internal user group for the following:

1. ISE Guest Sponsor Groups
2. ISE Admin Groups

Thus, ISE is not providing a direct mapping between the info from ODBC to a Guest Type.

We may achieve it indirectly somewhat.

1. Create two endpoint groups -- PatientEndpoints (PE) and ContractorEndpoints (CE)
2. Create two hotspot portals. The PatientDevReg (PDR) portal assigns endpoints to PE and the ContractorDevReg (CDR) portal assigns them to CE.
3. Create or update an ID source sequence to use the ODBC source.
4. Create or update a Sponsor Guest (SG) portal to use (3) for authentication.
5. Create authorization profiles:
   • ODBC Web Auth -- CWA redirects to SG and allows auth using ODBC
   • PatientDevReg Web Auth -- CWA redirects to PE
   • ContractorDevReg Web Auth -- CWA redirects to CE
   • PatientAccess
   • ContractorAccess
6. Create a new policy set or update an existing policy set to allow MAB w/ internal endpoints
7. Construct the authorization policy rules. Below shows an example:

Here are the LiveLogs events from my test:

[Armen V.]

That's very complete information.

Would it be possible to swap the duplication of captive portals and just add in additional ODBC sources which can point to a single DB, but run different stored procedures? then depending on which one actually returns the user, the policy is then mapped effectively by ODBC source?

what is the ODBC Group lookup used for in this scenario?

[hslai]

Would it be possible to swap the duplication of captive portals and just add in additional ODBC sources which can point to a single DB, but run different stored procedures? then depending on which one actually returns the user, the policy is then mapped effectively by ODBC source?

The reason we registering the endpoints is to skip the gust portal login again after some network disconnects -- remember me.

---

what is the ODBC Group lookup used for in this scenario?

---

The group lookup is here just an example. We may use any attribute in the database that associated to the users.