Is ISE-PIC the right solution?

[amenichetti]

Hi,

an external webapp authenticates users and based on "required access privileges" may use a different backend, a 2fa, an so on.

When the auth process finishes with success, the webapp produces the following line of log:

[YYYY-MM-dd HH:MM:ss] user:$USERNAME ipaddress:$IPADDR seclevel:$SECLEVEL

We are planning to send the log to ISE-PIC (syslog adapter), so ISE-PIC can be the "identity provider" (through pxgrid) for some cisco firewalls (asa 9.x and firepower).

Our need is to detect in ISE-PIC the "seclevel" field and be able to "represent" it through pxgrid, because that field needs to be consumed by the firewalls; in fact the policies on the firewall should be based on that field (on a representation of that field). 

Can ISE-PIC do that?

Thanks,

AM

[hslai · Accepted solution]

With Syslog providers, ISE PassiveID service captures IP Address, User Name, Domain, and MAC address. Even if we are able to capture $SECLEVEL as if Domain, I do not know how FMC able to consume Domain as SECLEVEL.

ASA is not currently able to consume ISE PassiveID mappings via pxGrid.

[amenichetti]

Hi hslai,

what about using ISE (not the pic version but the standard one)?

I can't touch the access layer, so dot1x is not the way; maybe using the authentication portal function of ise (replacing the custom webapp with that)...but I always see that feature coupled with guest authentication, and that isn't my use case. The workflow I'm thinking about is:

1. ISE provides the web authentication portal for the user

2. the user authenticates by connecting to the portal and providing his AD credentias

3. ISE verifies the authentication using AD as backend

4. ISE associates an SGT to that user based on the AD groups he belongs to

5. firepower consumes the SGT information through pxgrid

[Damien Miller]

If you use ISE like that then you need the access layer switch or WLC to handle the central web auth (CWA) redirection in step 1. The workflow you describe is highly impactful since you would have to authenticate via the web portal before "releasing" the endpoint, and it doesn't account for headless devices.