Identity Agent - Auto Detecting gateway

[David_Spencer]

For some reason within the Identity Agent, when I auto detect the gateway to connect to, the correct IP address shows, but does not connect. If I edit this to the hostname, it does connect.

I'm not sure why this is occurring, but what have others done for setting this up. I'm working towards deploying the agent, but want to make sure it's as seamless as possible for my users. I'd rather get to the root of this than bundle a custom MSI that includes our host name in the field already.

Anyone see this situation before?

[Daniel_Taney]

When you say it connects if you edit the hostname, do you mean that it works when you manually specify the Gateway? or that you manipulated the host file on the machine to make it connect?

[David_Spencer]

I mean that I manually specify the gateway in the agents settings.

I think I need to have the correct _tcp DNS record setup to get this working, however i'm having trouble creating the record, as CHECKPOINT_NAC_SERVER isn't accepted as a service.

[Daniel_Taney]

Yes, you will need that service record to exist for the auto-discovery to complete. I asked our AD admin to set up this record for me, so I don't know if there was some trick to getting it to work. But, he didn't come back to me saying he had issues creating it. 

I'm assuming you are doing this in Windows DNS? Do you already have an A record for the GW defined? Were you using the FQDN for the Gateway in the "Host offering this service" field? 

[David_Spencer]

yup we are on windows DNS. the "Host offering this service" I put in the FQDN of the gateway.

whenever I choose the _https protocol, it creates a new subdomain in _tcp, which I don't think should be happening, it should just be the protocol for the srv record, not another subdomain

[Daniel_Taney · Accepted solution]

You are setting the protocol to "_https"? I think the protocol is supposed to be "_tcp" and just the port number specified as 443. At least, that's how the IA Admin Guide shows it:

Maybe that's your issue?

[David_Spencer]

Ah yea, thats what I had wrong. I was doing _https instead of _tcp.

I can create the entry now, however I'm realizing i have a problem with auto connecting still. My gateway is in the main domain, and the computers are in a subdomain, however the subdomain is defined as a separate domain. Our DNS is a little messy. Any idea on getting around this?

[Daniel_Taney]

Which domain did you put this SRV record in? I think it should work if you create an A record in the "computers subdomain" that points to the IP of the Gateway running IA. It shouldn't matter that the Gateway's DNS registers in a different domain as long as the desktops can route to the IP of the Gateway.

With that A record in place, put the SRV record in the computers subdomain and point it at the FQDN computers domain hostname you just created for the GW. This way, the computers should be able to find this SRV record and resolve DNS to the Gateway. 

Sorry if that got a little word-y! It made sense in my head, hopefully I translated the idea clear enough  

[David_Spencer]

You got the idea through, no worries!

I deleted the srv record from the base domain, and created it in the subdomain instead, using the original FQDN for the "host offering this service", which resolved to the correct domain. No need to create pointers or additional records.

My test client then connected immediately 

[Daniel_Taney]

Cool! Glad that all worked out! 

In your OP, you said you wanted it to be as seamless as possible for the users. From my experience, your users may have to manually accept the Check Point CA fingerprint when the client connects for the first time. Since we try to discourage users from just clicking YES to everything, we tried to communicate this to our users through email ahead of time.

[David_Spencer]

I've noticed some of my test clients see the fingerprint popup, and some trust right away. Both have received the same certificates from Group policy. I'm going to try and figure out why, but I'll likely still inform them prior to deployment, as we have lots of different devices and OS's deployed that may act differently.

[Mark_Mitchell]

Hi David, 

I don't know if it is of any use to you, but you could configure the configuration to be stored in Active Directory? This will store both the "Trusted Gateways" with their fingerprint and also the rule configuration that ties in a AD site or IP range to a particular gateway. 

The Distributed configuration tool installs as part of the Identity Agent on the client machine. 

To set it up is really easy, just open the distributed configuration tool with an account that has administrative permissions within the domain and it automatically creates the CheckPoint container in the default naming context in AD. 

The client will then check AD each time to locate the best IA server to use. 

This should resolve your fingerprint issue and removes the decision from the user to accept the fingerprint of the gateway. 

Hope this helps. 

Cheers

Mark

[David_Spencer]

Hi Mark,

Sorry for the late reply, I was away on break.

I've tried the distributed configuration tool without success, but I'll give it another attempt.

I'm unable to find the container it is supposed to create, Where in AD can I verify if the distributed configuration tool created the container properly?

Thanks,

David

[Mark_Mitchell]

Hi David, 

Not a problem at all. To view the container in Active Directory you will need to open ADSIEdit.msc and connect to your domains "Default naming Context". You should be able to browse the structure to dc=<domain>,<dc=local>,CN=Program Data,CN=Check Poiint.

When you ran the Distributed Configuration Tool, was it run with an account that has administrative permissions in the domain? 

Regards

Mark

[David_Spencer]

Hey Mark,

I've found the program data entry for it now, however the two containers are empty. What would they normally contain?

I did the creation with an account that has admin permissions.

[Mark_Mitchell]

Hi David, 

That is great. That looks good. I wouldn't expect to see anything as such in these. Can you screenshot your Distributed Tool configuration output please? When you open the tool you should see any entries that you had entered before. 

Regards

Mark

[David_Spencer]

Pretty simply, we just have the one server, it's fingerprint correctly shows in the trusted gateways

[Mark_Mitchell]

Thanks David. That looks good to me.  Is your identity agent on your client set to automatically detect the gateway?

Also, I am assuming that your Gateway also has the Identity Awareness blade enabled and the identity source set as Identity Agent on your gateway configuration? If you can share your gateways Identity Agent configuration as well please?

Regards

Mark

[David_Spencer]

After testing a few more clients, this seems to be working well for the identity agent.

I am noticing some problems with the terminal server agent running on windows 10 clients. We have some computers that multiple users sign on to, and use the fast user switching function, so we were going to use the MUH for them. They are connecting successfully, but no users are detected. This seems similar to sk113732, however this is windows 10 which is compatible with sha2.

[Mark_Mitchell]

So just to review where we are at. The normal identity agent is working as expected on Windows 10 machines now, and the issue currently lies with the MUH Agent?

Is there any error displayed within the gateway logs? Filter search. "blade:Identity Awareness" that may relate to the issue?

Regards

Mark

[David_Spencer]

You've got the current state of things correct

no errors are displaying. I see the successful machine authentication logs, but no user logins show up.

In the MUH log files on the endpoint, I see the same error as referenced in sk113732 "[UIPLib (NAC::IS::TD::Surprise)] UIP::UserIdentificationByPort::startDriver: StartService failed error code = 0x241"

Windows 10 has built in sha2 support, so the articles solution doesn't seem valid for this scenario. 

[Mark_Mitchell]

Fantastic thank you. 

I have an identity awareness lab I've used recently so I will have a go at re-creating the error you are getting on a vanilla platform. It sounds like it is an Windows issue rather than a Check Point one at the minute. 

Do you have any restrictive group policies that would do anything that would stop services running or any other security related configurations? Also is the Windows 10 client fully patched and up to date?

[David_Spencer]

Thank you for helping dig into this!

No restrictive policies are in place, nothign that would stop the services from running, no real security related configurations in place, I've put it into an open group for testing.

The client is fully up to date on patches.

[David_Spencer]

So I think I found the problem.

sk138252 - MUH does not correctly work with Windows 10 computers with Secure Boot enabled.

So for me to deploy this, I would have to update the BIOS settings on all my windows 10 machines to disable secure boot.

Is the only option at this point to move with an RFE?

[Mark_Mitchell]

Hi David, 

I am more than happy to help.

I believe you are 100% spot on with the find. I have just tested this in a vanilla setup in a virtual machine running Windows 10. Secure boot enabled the agent is not able to collect identities. With Secure Boot disabled the agent works flawlessly.

Long term I think it would be beneficial to raise the RFE so that this is a supported feature in future releases of the agent. In the meantime, as a workaround for this specific scenario could you do the following?

1. Configure the captive portal on the gateway
   1. Kerberos SSO as well
2. Create an AD group for the users/machines that use quick switching.
3. Create a group policy that will start IE and browse the captive portal where SSO will be performed and target the group you just created. Group policy will also need to contain the certificate of the captive portal so that the machines trust it and don't display a certificate error page. 

Once the SSO within the captive portal has completed your identity based rules should apply as normal. I believe that this may be a viable workaround?

Regards

Mark

[David_Spencer]

Hi Mark,

Sorry for the late reply again.

I think we are instead going to opt for a different path with our agents.Our approach will be to install the full Identity Agent, and perform the following:

1. Known shared computers will only be auto logged in to a shared account, no other accounts will be allowed to log in to those computer. They are meant for checking webmail, health & safety, internal websites, and other needs for the workers, that do not require individual user logins

2. Individual computers will be reviewed, and we may possibly remove fast user switching across the domain, as there isn't too big of a need for it, just QoL for some cases.

I like your SSO captive portal idea, I'll see if i'm able to demo it out on a test group, although I tend to be met with resistance when I bring up captive portals.

[Keith_Mcdonald]

With Vmware .6.7 u3, and Server 2019, the issue was also secure boot. Had to disable secure boot only at the VM level not at the host level, in order for the Identity agent to work properly. Hopefully this is resolved in futures versions. I am using 80.20 latest version, and downloaded the latest TS identity Agent. 80.190.0000