Enabling Identity Awareness Globally

[Bob_Stevens]

I am in a position where I want to enable Identity Awareness globally.  We are in a multi-domain environment with a global policy that installs into each of our local policies.  I was told to be able to use Identity Awareness I would have to create a global gateway object to enable the software blade on.  I tried creating the object when in the global domain, but get an error that I cannot create a gateway globally.

How can I enable IA globally?

[Houssameddine_1]

Identity awareness blade is per gw object not per policy.

[Kaspars_Zibarts]

Good question! I've had it on my mind for a while but never got round to dig deeper into it! I haven't found or heard that it would possible so for now we just connect each gateway to the Identity Controller but it does seem overkill to collect the same info multiple times. And ID sharing between CMAs is way to complex.

Looking forward hearing from some experts 

[Bob_Stevens]

This is what I'll have to do if I can't get it enabled globally.  The issue is that we have our global policy that we want to setup IA on so we can start to do away with needing to assign static IPs to each user that needs custom firewall rules.  If we can't get it setup globally it may not be worth setting up at all for us.

[Kaspars_Zibarts]

I haven't played with global rules and IA but I'm guessing you could define IA roles and therefore IA based rules globally. But not gateway connection to ID source. Will check tomorrow.

[Marco_Valenti]

It depends on the method of identity acquisition , based on my experiences with microsoft ad if you have a an ad forest things can go nasty really quickly.

If you have 1 dc per site you can enable IA on the local gateway and start sharing the identity within the other gateways if they are on the same cma

if you have just 1 dc on your central site you can do the opposite and sharing from central to satellite (had to be on the same cma)

Based on your environment you need to choose wisely how do you want to acquire identities and if use or not the identity collector  in very large ad environments you need to be carefully with load on gateway and dc (at least without collector)

IA can't be enabled globally as far as I know

[Bob_Stevens]

We have identity collectors configured and data is being shared to one of our local gateways for our POC.  We have a number of DCs, so that was the best way we could get all of the identity information without killing the DCs or gateways.  Our global policy is applied to every local policy we have.  I created a global LDAP account unit that can interpret AD groups, but it doesn't talk to the Identity Collectors to see the additional identity information.  To get this ability I need to enable IA on a global gateway object but am still looking for a bit of guidance as to how to implement this.  I haven't found any documentation yet that can help me out.

[Houssameddine_1]

I think you are little bit confused by on how identity awareness works.

• When you create an account unit in smartconsole that allows you to create the mapping between the LDAP groups and the access roles that you will use in your policies. This communication requires access from your management server to the DCS if it is R80.10 mgmt server and from mgmt server and smartconsole machine if R77.30 mgmt server and lower.
• Now the gw side which is the fun part. In the configuration you have to tell the gateway which account unit it is going to use for identity awareness and which includes the dcs and the domain name.
• The acquisition method you configure this on the gateway object, this tells the gw what are the sources for identities (Identity collector, WMI, captive portal, Radius accounting, Identity agents,etc)

In your case you have identity collector as acquisition source. What happens the  identity collector reads the security event on the DCs after that it extracts the username and the ip information form that security event and forwards it to the gateway using https connection. As soon the pdp process on the gateway receives the information from the collector it checks the domain information and the account unites after that it opens an LDAP connection to the dcs to get the user’s groups after it receives the groups it starts the calculation of the access roles based on ldap groups and create the binding between the access roles and the LDAP group to enforce policies.

As conclusion, if you can tell the gateways that configured in CMA to use the Account unit in global domain and you should be ok. The identity collector doesn’t connect to the management server or CMAs it connects to the gateways. 

Thanks

[Bob_Stevens]

OK so I'm just trying to verify that I have this all configured right...in one of our local policies I have 2 account units showing up:

The '-g' group is created in the global policy so I can create access roles that can be used globally.  I have created 2 access groups: 

One with the '-g' is created in the global policy and is added to the local policy when global is reassigned.  The one without the '-g' was just created locally.  I created 2 rules, granting ICMP access to different servers.  If I try to ping either of the servers it doesn't hit on either of the rules...global nor local.

If I check pdp monitor user for my account it only shows that I'm in the 'All Users' group.  Do I need to create an Access Group first and then an access role? I had this working locally and then the pdp service stopped responding and I had to reconfigure it on the gateway.

When you mentioned the User Directory on the Gateway object I can only use the 'Any' option or use the local Account Unit.  If I try to use the global one it just errors out and says that the global object can't be modified.  Should I leave it at any or should I select the local Account Unit?

[Kaspars_Zibarts]

It might take quite long time often enough to have user roles updated from AD security logs retrieved by IDC. It's nowhere near instantaneous. So either wait or use captive portal. We have given that as a backup option if automatic role update is taking too long to propagate.

Captive portal is a good option to verify that rules work as expected as you can force update your role.

In your case it would be interesting to see if globally defined role is associated with the user if you do captive portal. 

Hope you're learning to use CLI commands both PDP and PEP.  They will be you friend you're planning to use IA

[Royi_Priov]

Hi Bob,

There is no way to enable Identity Awareness globally. 

This should be enabled on the gateway object on CMA level.

As for the questions raised in this thread regarding sharing identities between MDS domains, although Identity Collector is not assigned to specific domain and therefore it can overcome this issue, we do not recommend configuring it as the sharing method.

There is a customer release of "Identity Broker" which is PDP to PDP sharing over MDS domains.

In case this is relevant for your environment, I suggest contacting your local SE and open RFE.

Thanks,

Royi Priov, Identity Awareness R&D.

[Bob_Stevens]

So I wouldn't be able to create a global account unit (AD_AU-g) for the purpose of creating global access roles that will be installed on all firewalls assigned to that policy?

I have the AU setup globally and can talk to AD, but when I put the access group in an IA enabled gateway, it doesn't see my user as being in the particular AD group (and hence access group) so the rule doesn't hit.

[Houssameddine_1]

You will be redirected to captive portal only for http/https(need https inspection enabled) , if you want to use captive portal for other services you have to browse manually to it.

I believe Royi provided the final answer that you have create your account units on the CMA level and create your access roles there. if you are using LDAP for user groups, your gateway and your CMA should be able to communicate with the domain controllers.

Thanks

[Kaspars_Zibarts]

I was referring to the "local" role not working  @Houssameddine Zeghlache And not as redirect action but direct login into portal itself, as in https://gw_ip_or_name/connect

Hope it clarifies.

[Peter_Elmer]

Have you seen the PDP Broker documentation I just published? 

Getting_Started_Guide_PDP_Broker_HF_v7 .pdf 

[Marco_Valenti]

outstanding work as usual thanks Peter