NAC VDI inspection issues

[config t]

This is mostly just a rant to see if anyone has any ideas.

Our HBSS team has a trap set up to capture remote system login and it turns out our NAC solution is generating 1000+ logs on some hosts on a daily basis. I had them send me an example and it's what I would expect to see; vbs scripts and smb calls from NAC but a huge amount. It actually crashed their database server over a weekend.

Forescout inspects hosts on admission and whenever the policy recheck timers expire (usually 8-hours). There are exceptions to that which can be created thru policy but I am not currently running anything like that. Just discovery and interrogation and a few auto-remediation actions.

I suspect an issue with the vSphere integration or the VDI hosts themselves. When I look at the live host logs for the host entry I see a crazy amount of "host online" entries and noticed they are very slow to resolve LDAP info and populate host attributes in general.

In my mind NAC may be attempting to inspect but failing so just hammering it with retries.

[deanwebb]

Yes, Forescout will hammer with retries. Like a golden retriever going at Venetian blinds after you step out to get the mail because he is the bestest boy and KNOWS that if he keeps tearing down the blinds (and the furniture next), you eventually WILL come back through the door.

This is why I like the agent better. 

[config t]

I'm stealing that analogy.

We pushed the agent to a few test machines 

So far it looks promising and gives me ammo for moving it to production quickly.

[deanwebb]

I know customers that are 100% agent and 0% agentless because they don't want *any* extra accounts knocking on doors, an architecture I can respect.

[config t]

I'm moving current customer to that state. Although the latest best practice I read for Linux recommended SSH keys.

Btw used that analogy today and the previous lead got a kick out of it. I'm going to start doing that in meetings.

Is there a way to tune that behavior? There has to be a configuration file somewhere buried in the directory where the retries are set.

[deanwebb]

SSH keys are awesome, best way to manage Linux boxes.

As for tuning the behavior, no... best I've had is to either disable the feature or get it to where it works 100%, clean and smooth.

This is why I also insist on as few AD accounts in the HPS as possible. Having multiple accounts means all of them get tried when one doesn't work, and the AD servers can get swamped with requests in a short period of time if there are enough accounts and one of domain's controllers are offline. Needs to be a large deployment for that to hit a critical mass, but it can and will. Go with a single, top-level domain account so that when it fails, it fails just the once and there's no other accounts to try. Much preferable than trying 10 (!) accounts that *all* fail over nearly 100K Windows boxes.