FMC with Identity Policy using Azure AD

[dm2020]

Hi All,

We are currently running FMC and FTD with user identity access control polices. FMC is integrated with ISE, which in turn is integrated with our on-premises Microsoft Active Directing domain using WMI so that user to IP mappings can be passed to FMC from windows security events. This is all working ok.

We are now in the process of migrating devices and users to Azure AD. We have tested 802.1X EAP-TLS wired and wireless authentication for Azure users with ISE and this is working without any issues. We now need to test identity polices, however I dont think that will work as even if ISE publishes the Azure AD user to pxGrid (captured from the certificate CN user@xxx.onmicrosoft.com), FMC will not be able to lookup the user to confirm group membership etc as the Realm configuration only support AD or LDAP sources.

Is support for FMC integration with Azure AD on the roadmap? Are there any workarounds to support this?

[Marvin Rhoads]

My customers needing this have a local AD DC synced to Azure. FMC is then integrated with the AD realm via that DC.

[dm2020]

Thanks @Marvin Rhoads 

This may work as a temporary solution, however long term we want to move away from on-prem Microsoft AD and use Azure only. To support this I assume that FMC will need to support direct integration with Azure (like how ISE does today) to be able to query user to group membership? 

[Marvin Rhoads · Accepted solution]

@dm2020 for the longer term, we hope to see Azure AD realm type added in release 7.4 later this year.

[dm2020]

Thanks @Marvin Rhoads - Good to know that this feature is on the roadmap. Appreciated

[nic-m]

Hi Marvin, sorry if I ask you directly and please, let me know if it's better to open another thread but I'm currently stuck on this. May you please explain me a little more this configuration? I'm currently trying (at least I presume) to do exactly the same. Local AD is configured as Realm under FMC and used in identity policy (locally we use passive auth with passive identities provided by ISE-PIC, no full ISE installation in place), local AD is synchronized to Azure AD. I configured a Remote Access VPN connection profile in order to authenticate the users with Azure AD and the authentication works fine, but the Realm for the logged-in user is set as "Discovered Identities" and not matched to the local AD realm, so it does not match any rule that use identity policy. What am I missing? Thank you in advance for your attention

[nic-m]

Sorry, forgot to tag @Marvin Rhoads 

[Marvin Rhoads]

Are you gathering the same samAccountName for the user and using that as the unambiguous identity throughout?

[nic-m]

Hello @Marvin Rhoads and thank you very much for your reply. I think it's exactly here where I'm stuck. Azure AD sends as Unique User Identifier (Name ID) the azure his userprincipalname but I tried to customize it with the user.onpremisessamaaccountname or user.onpremisesuserprincipalname and all I get are weird characters in the username and the realm is still discovered identities.

If you can share any pointer to what customize in the SAML claims in order to get it working it would be great.

Thank you very much again

[Marvin Rhoads]

@nic-m  I'm not sure about this one.

I suggest you open a TAC case. Please let us know what you find out.

[nic-m]

Hi @Marvin Rhoads I was able to solve this. I used a transformation to change the Unique User Identifier value set as user.userprincipalname from the Azure format (that is, for example user@domain.com to the local realm one (for example user@domain.local) as shown below

In this way the user realm is correctly set in the FMC and identity policies work.

I really would like to thank you for your time and for point me in the right direction with your first answer.

[Marvin Rhoads]

That's really good to know @nic-m . I was thinking about transformations since we do something similar in ISE sometimes but I couldn't see how we could do so in FMC.

Doing it at the Azure end seems to be the trick - good work!

[nic-m]

@Marvin Rhoads I have to thank you. Your first reply to me, asking about gathering the same samAccountName, pointed me out to the right direction on what it was needed and I had to try to achieve in some way. And I found the way I posted above. Also the TAC confirmed that.