06-20-2017 09:04 AM - edited 03-11-2019 12:48 AM
Hello Team,
ISE working as SXP listener. Getting the mapping ip-sgt from the other
devices (SXP speakers).
1. Will ISE create a session on MNT for those mappings ? (ip-sgt only -
no mac, no username !). It would have to be "degradated" session, without CoA functionality, but why not ?
2. Will ISE share the contextual information about that "Session" via
pxGrid ?
(so for example FMC can get this data ip-sgt and have access policy
based on SGT ? -> since in new FMC version we do not need AD username when focusing on SGT conditions)
3. Just by correlation with passive identity: mappings received via AD/DC ip-username. That session is created and can be shared via pxGrid. Do we differentiate those sessions somehow ? (#1 and #3) ?
Thanks,
Michal
Solved! Go to Solution.
06-30-2017 01:15 PM
Michal,
We do have the capability already to receive IP-SGT mappings over SXP and publish them over pxGrid. You need to explicitly enable that behaviour in the SXP section of the TrustSec work Center in ISE. We have two TrustSec topics in pxGrid, one providing SGname to number and the other providing IP-SGT mappings.
06-22-2017 11:09 PM
Hi , I am checking with few experts for this query.
Regards,
Nidhi
06-23-2017 10:06 AM
Below is the response inline -
Will ISE create a session on MNT for those mappings ? (ip-sgt only -
no mac, no username !). It would have to be "degradated" session, without CoA functionality, but why not ?
<inline reply>: ISE can be a listener and can get to know IP-SGT mappings from peer speaker. There won’t be any session in this case. This is pure IP-SGT bindings that ISE learns from peer. When there is no session, no question of CoA.
pxGrid ?
<inline reply>: as I said earlier, there won’t be any session created in ISE when ISE is sxp listener. However, we could share IP-SGT mappings (learned and aggregated) via trustsec topic through pxgrid. Of course this is pretty common case.
(so for example FMC can get this data ip-sgt and have access policy
based on SGT ? -> since in new FMC version we do not need AD username when focusing on SGT conditions)
<inline reply>: we differentiate based on “source” attribute in session. If Source=radius, then it’s an authenticated session. If it is source=passive-id, then it’s a passive ID session. Based on this same “source” attribute, we are disabling CoA on Passive ID sessions
06-23-2017 04:58 PM
Hi Nidhi,
Thanks for the help.
That is why i am proposing a new source=sxp (if we have already source=passiveid). Both are sessions anyway. We would have to use source=sxp only for dynamically created records.
We can get ip-sgt mapping via pxGrid - but nobody is doing that, including FMC. To have it natively on FMC and WSA we need to make those mappings (ip-sgt) a session, then we can get those via pxGrid and have it out of the box on FMC/WSA.
Use case: N1k mappings created when VM is going up. Customers do not want to use switching infrastructure to enforce it (that is simple L3/L4), but rather differentiate policies on FMC/WSA (L7). And virtual switches will not support any type of authentication any soon (unless ovs + vmware combo is getting more attention).
Thanks,
Michal
06-30-2017 10:14 AM
Please discuss this with our product management teams. Also, since your inquiries are geared towards TrustSec, please direct similar to TrustSec space. I am moving this there now.
06-30-2017 01:15 PM
Michal,
We do have the capability already to receive IP-SGT mappings over SXP and publish them over pxGrid. You need to explicitly enable that behaviour in the SXP section of the TrustSec work Center in ISE. We have two TrustSec topics in pxGrid, one providing SGname to number and the other providing IP-SGT mappings.
07-02-2017 04:30 AM
Hi Kevin,
We do have it - and we do not use it at all. FMC/WSA is not supporting IP-SGT topic. As a result we do not have any solution for servers. We are very much focused only on endpoints, but not on servers. Customers are forced then to use ACI or Tetration for servers - and for most of the customers that in not applicable because of the scale.
We should really start thinking about server security - not just endpoints. Security which is L7, adaptive with different quarantine levels based on SGT.
If we could create ISE session out of IP-ADusername mapping, i do not see any problem with creating ISE session out of IP-SGT mapping. After that FMC/WSA would be able to provide L7 policies for servers (instead of L3 policies provided by switching Cisco specific infrastructure). After that our solutions (FMC/Stealthwatch) would be able to quarantine servers assigning them right SGT tag providing right L7 policies.
I'll raise it with trustsec team.
Thanks,
Michal
11-21-2017 11:46 AM
Hi Kevin,
We are trying to learn SXP bindings using PxGrid - SXP Binding subscription. We are only getting static bindings but not the dynamic ones that are learnt from RADIUS sessions.
We do see both static and dynamic SXP bindings into ISE>WorkCenters>TrustSec>AllSXPMappings. Is this expected or are we missing anything here? I would appreciate your help on this. Thanks.
Regards,
Iswarya Koushik,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide