Custom Identity Awareness settings not applying

[PatrikSkoglund]

Hello,

I'm currently setting up identity awareness with the agent on our clients. I've got everything working with Kerberos SSO, and the logs are filled with AD user names. So far so good! Now I wanted to package this in to a .msi file that we can distribute with SCCM.

The issue I'm having is that the properties under Gobal Properties > Advanved > Identity Awareness > Agent are not applying. Maybe I've got this part wrong. But should these settings not be applied to the customagent.msi under $NACPORTAL_HOME/htdocs/nac/nacclients/customAgent.msi? I've a few clients install in my pilot, should these settings be applied to these clients automatically or do I need to redistributed the updated client?

Thanks in advance

[PhoneBoy]

What specific settings are you interested in?

[PatrikSkoglund]

I'm trying to get the following settings to work:

nac_agent_hide_client

nac_agent_disable_quit

nac_agent_disable_settings

So I've ticked the checkbox next to them and pushed policy.

Is there a step I'm missing?

[PhoneBoy]

My understanding is that when the client connects to the gateway, the settings are pushed to the client.
If this isn't working, you probably need to engage with the TAC.

[Vladimir]

Please post your findings here when you'll get them resolved. I am battling with various IA issues in my lab as well.

[PatrikSkoglund]

I've yet to contact the TAC, as I've had some more pressing issues. I've thought done some more testing on my own. When installing the light client, settings are applied almost instantly. So the issue seems to be with the full client. Hopefully I'll be able to rise a TAC case this week.

[PatrikSkoglund · Accepted solution]

So after a few days of research, this is what I've gathered.

• There are no issues when deploying the light agent and the global settings being pushed to the client.
• When running the full client, one needs to have a dword(32bit) registry key on the client named "GlobalConfigEnabled" set to the value 1. But this only works, as far as I understand, when the full client is run as admin on the machine. Which is far from optimal.

With the following knowledge I decided to make use of the client registry to make it work like I wanted to. This is documented in the R75.20 admin guide, if I remember correctly. It's not mentioned in the newer versions.

So what I ended up doing was to download the latest full client .msi file from supportcenter, and use the IAConfigTool to set it up the way I wanted it. To make the necessary changes to the client I deployed the following registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CheckPoint\IA]
"DisableSettings"=dword:00000001
"DisableQuit"=dword:00000001
"HideGui"=dword:00000001
"GlobalConfigEnabled"=dword:00000000
"PdpDiscoveryEnabled"=dword:00000001
"DefaultGatewayEnabled"=dword:00000001

Registry path might be different depending on 32/64 bit and if you install for all users or only current user. 

The first three are pretty self explanatory, the other three disables the client from getting the global policy pushed from the gateway, enables the client to use Automatic discovery when trying to find the gateway(this must be configured in the distributed config tool installed with the local client, otherwise use the string value "DefaultGateway"="<gateway>") and the last one I'm not sure about, but without it, it asks how to connect on each log on of the client. So I guess that is needed.

With my pre-configured .msi file and a .reg file I was able to deploy this with SCCM. It will restart the NIC:s on install, and you need to log out, and back in if installed as SYSTEM, otherwise the logged on user won't be detected by the client.

[Steven_Lucas]

Applying these registry settings helped me in my environment, but I am also missing the TrustedGateways tree. I am okay with defining it myself but cannot find an example of what this would be though. Hopefully that is a legit strategy to begin with, but can you provide what you have there? You can cut out any environment specific info. 

[PatrikSkoglund]

Good to hear you had help from my post!

Regarding the trusted gateways. We're using an Microsoft Active Directory(AD) in our deployment. There is a tool that comes with the installation of the identity agent. At least on Windows. It's called Distributed Configuration. What it does is that it pushes all settings you configure there, to the AD. One of them being the trusted gateway. You need to have some form of domain admin rights to do this. I didn't test it out much, as I had access to the correct account needed. When this was done the agent found all the settings it needed when logged in to the Agent.

There are though a couple of ways to configure this. It's described in the R80.?? Identity Awareness Admin Guide(it's in r80.30, I just checked, and should behave the same on all R80) under Discovery and Trust Options.

I hope that sheds some light on it! If you have more questions, I'll answer them as soon as able!

 If you are on Windows, and want a truly seamless experience I would suggest to include SSO with kerberos.

[Steven_Lucas]

Thanks for the quick reply. We are using Kerberos SSO. I had a Domain Admin set up the SPN. That is working great. The part that isn't is that users still get prompted to have to review and trust the GW object. I was hoping that was something the export from configuration process might handle, but it may not.

[PatrikSkoglund · Accepted solution]

Everything you should need then is to run the Distributed Configuration tool. It should be located on a machine with the IA Agent installed, check under Start menu > All Programs > Check Point > Identity Agent.

Run it as domain admin or change the user inside the application to the domain admin account.

It's explained in the admin guide from page 160 and forward.