R80 Identity awareness Client side logic/server side logic

[Nigel_Dennison1]

Good morning all

Running through the R80 CCSE course today and we were discussing the change from R7X to R80 in the way that the smart console interacts with the database. In pre R80 the smart dashboard effectively downloads a copy of the database for editing and only writes back during save function. In R80+ it is more of a client interacting with a database located on the manger in more or less real time. Makes sense as this allows for multiple managers etc. My question though comes from the use of user groups in rules when Identity awareness is enabled. In R7X the local PC that had the smart dashboard installed needed to be able to talk to the AD server to populate the AD objects such as users or groups. Has this interaction with the AD been pushed to the management server in R80. So only the management server needs to be able to talk to the AD?

If it has this this would end up being a massive plus for remote management of clients Checkpoints using Identity awareness in there rule base, a great boon for us MSP's. 

[Tomer_Sole · Accepted solution]

In R80.10, when the administrator searches for LDAP entities, such as users and groups, the flow is as follows:

1. Administrator searches for LDAP entities, such as users and groups.
2. The search properties are sent from the SmartConsole GUI client to the Management Server.
3. The Management Server opens the LDAP connection to the AD domain controller based on the operating system routing and interfaces.
4. The Management Server performs an LDAP query against the AD domain controller and sends the result back to the SmartConsole GUI client.
5. The SmartConsole GUI client presents the candidates to the administrator.
6. If the administrator configured the Account Unit object to work with SSL, then the Management Server opens the LDAPS connection. In addition, the port that is configured, is the port that is used.

The available LDAP connection options are:

• Kerberos LDAP bind with encryption
• Kerberos LDAP bind with encryption, but if it fails, use a Simple LDAP bind.
• Simple LDAP bind
• LDAPS bind

(5) Notes:

• The recommendation is to use LDAPS bind. However, the domain controller should allow it.
• The default option is Kerberos LDAP bind with encryption.

[Nigel_Dennison1]

Excellent, So that is a change in behavior from R7X where the client would do the LDAP look up when editing the policy for the sake of adding LDAP objects that is going to make life a little more easy for remote management. 

[Maarten_Sjouw]

So in a Multi Domain setup, where we have many different customers and locations scattered around the world, where we have no access to their AD servers from the MD servers, we have to tell our customers who control this part themselves today, will no longer be able to use IA?

As the SmarDashboard client in these cases was in their network with access to their AD and the domain management server, which is in ours, the old situation worked just fine, but will no longer work. This will mean we will need to get the NAT trick to work in this situation.

We need to create another AD server with the NAT IP that we need to connect to from the Management server (will it use the MDS IP or the DMS IP as the source? That NAT IP AD server will be the one in the top filed shown in the previous post and it should use an encrypted LDAP method. Then use the Priorities again to make it totally uninteresting to connect to.

[Nigel_Dennison1]

In R80 you can create a site to site VPN between the firewall in front of the MDS and the customers gateway then use hide NAT so that you do not get overlapping encryption domains and a dummy AD server like you mention above . That way the MD servers will be able to talk to the AD servers directly. 

One slightly creative if over complicated way we have managed to get round the issue in R7X is to create a port forward through an SSL tunnel between you and one of the customer gateways to get to the AD server. Then as you mention above create a dummy object in the dashboard with the port forward IP address as AD server and set that dummy object with no priority. It works so long as you bring up the SSL tunnel with the port forward before connecting to the dashboard. 

[Maarten_Sjouw]

Nigel,

All very nice but there are some snags in this scenario for us, we have around 30 customers using IA already out of the 150 total customers, with number growing.

Next to that we do not manage the FW in front of our MDS, that is another team within our company and this is always a challenge of its own.

We really don't want to build tunnels for this for each and every customer, certainly not when you want the customer themselves to manage the rulebase with the IA part.

[Tomer_Sole]

Hi Maarten, 

Good to see you here   I'm looking forward to seeing more posts from you

You raised an important point. What I can offer you with R80.10 is to use the LDAP Group objects. 

1. Create an LDAP Group object.

2. Create an Access Role Object. 

Inside the "Users" page, make sure you change the selection to "LDAP Groups". Then use the LDAP Group that you created in the previous steps.

Drawback is that you will miss the LDAP picker unfortunately. 

Hope this helps.

We plan to simplify this further in our next releases.

[Maarten_Sjouw]

Tomer, sorry to come back late on this issue.

I now have a working situation where the management server can access the AD through a NAT construction, but what I noticed is that when you use the fetch branches from the LDAP server object, it uses the IP of the Domain server, but when you try to add a user role and want to browse the AD it switches to the main IP of the MDS server.

I was told that there would be an option to set the Gateway as a proxy for this part of the communication, will this be part of the R80.20 GA?

[MartijnElzenaar]

Hi Maarten,

It's still part of the R80.20 public EA release notes:

"Ability to use an Identity Awareness Security Gateway as a proxy to connect to the Active Directory environment, if SmartConsole has no connectivity to the Active Directory environment and the gateway does"

You mean this one? 

I don't see it being cancelled at this stage of the EA, but let's wait for RnD to confirm. 

Cheers

Martijn

[Maarten_Sjouw]

Hi Martijn,

I think that is what was said before, however it is not the SmartConsole itself that connects to the AD, as it was in R77.30 It now is the Management server and as you know how our environment  is built, this will improve the scurity of this specific communication, without a need for VPN's to every customer.

Greetings Maarten.

[Maarten_Sjouw]

Hi Tomer,

Been posting here for a while alerady...

Will the simplification include the gateway to make a proxy connection to the AD server?

The might be used as a workaround but is certainly not the way we want the customers to go forward, so we hope you can really make it work in a different way.

[Tomer_Sole]

Been posting here for a while alerady...

And it seems that I also replied to some of those posts  apparently sometimes I reply from my sleep and don't notice the names of the people asking the question..

[Maarten_Sjouw]

Tomer,

Would you care to comment on this part:

what I noticed is that when you use the fetch branches from the LDAP server object, it uses the IP of the Domain Management Server,

but when you try to add a user role and want to browse the AD it switches to the main IP of the MDS server.

Were there two teams working these parts, where the one team did think about using the Domain IP and the other team did not think about that and ended up using the MDS IP?

Thanks Maarten.

[Tomer_Sole]

Hi,

We will look into this. Thank you for noticing. 

And no, these weren't two different teams...  it's one team, that apparently does way too many features than you would imagine...

[Maarten_Sjouw]

Ok, thanks for having a peek.