In order to do more automation and empower other teams in our organization I am interested in deploying software to users via Active Directory group memberships. I have been able to do this by using the following relevance however I have run into an issue with users that only login via VPN.
(((exists value whose(it as lowercase = "BFSWD-TEST" as lowercase) of components whose(type of it="CN") of distinguished names ((distinguished names of groups of it; distinguished names of it) of logged on users of it))) of active directory)
Since they never actually log out and back in again their token never gets updated UNLESS I force a restart of the BigFix agent while they are on VPN which seems to do the trick. I would rather not do this as there could be another BigFix process running at the time that could be interrupted. Is there another way to do this without prompting the user in any way?
It looks like it’s the default of every 12 hours as that value isn’t being set in the registry currently. I’m assuming you are referring to this value right?
Because of the “expense” of querying AD data (the time it takes AD to respond vs the amount of time the client remains active, hence the long refresh window), I try not to rely on AD properties for Actions.
I prefer to use Tattoos. Either Registry Keys or files under a designated folder for the kind of function you are working on.
You could always try reducing the Refresh period to something like 4 hours, but you’ll jam up your BES clients and the AD servers if you set it too low.
I found this page and it looks like the user information does not get updated on the 12 hour interval only the computer info:
I suppose adding a gpupdate /force for the logged on user account when they connect to VPN might do the trick but I don’t know if that process will in fact force the client to evaluate new group memberships for the logged on user as well.
Using gpupdate /force will cause the computer to refresh it’s Group Policy objects, but will have no impact on the User Group information which is part of the current logon session.
If the user logs into the endpoint using Cached Credentials (used when the Domain Controller is not accessible at login time), I don’t know that the user session will ever update it’s User Group memberships. The user would need to login at a time when the AD controllers were reachable by the endpoint computer. The same way that if you add a user to an AD Group after they login, then their session will not reflect this fact until they log off and back on again.
I know that at one point, we had some of our laptop computers configured so that the VPN client was started as part of the login process, that way the Domain Controllers were accessible while the login session was negotiated, and the Group Memberships could be retrieved at that time.