cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
 
ISE 2.3 Patch 7 has been posted. This will be the last patch for the ISE 2.3 release!
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

198
Views
5
Helpful
6
Replies
Highlighted
VIP Advocate

Using ODBC as an Identity Source for Guest Portal authentication

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

Everyone's tags (3)
3 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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
Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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.

Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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:

Screen Shot 2019-07-31 at 8.33.20 PM.png

Here are the LiveLogs events from my test:

Screen Shot 2019-07-31 at 8.32.10 PM.png

6 REPLIES 6
Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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
Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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.

VIP Advocate

Re: Using ODBC as an Identity Source for Guest Portal authentication

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?

 

Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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:

Screen Shot 2019-07-31 at 8.33.20 PM.png

Here are the LiveLogs events from my test:

Screen Shot 2019-07-31 at 8.32.10 PM.png

Beginner

Re: Using ODBC as an Identity Source for Guest Portal authentication

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?

Cisco Employee

Re: Using ODBC as an Identity Source for Guest Portal authentication

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.