How do I prevent a desktop policy from being downloaded/enforced?

[RobertGraham]

In my case, I had a test client that I didn't want to downloading the policy and start blocking stuff. It should run the SecureClient software, connect to the gateway, but not download or install the desktop policy.

There are a couple ways to do this, but the simplest route I found:

1. Delete all the files in the policy folder
2. Set the permissions to read/exec only on the policy folder.
3. Restart the client

Caveat: This doesn't scale particularly well. You might be able to write this into group policy if you wanted to, but that's probably not necessary very often anyway.

PS: I tried manipulating the policy files and setting them to read-only, but the client whined or ignored it and I gave up on that. If you have done this before, I'd be really happy to read your post.

[chillyjim]

On the policy server object, go to authentication->policy server and chose a group for users to receive a policy and put your test user/client in a different RA group

[RobertGraham]

Jim:

Sorry I didn't specify, but this test user is used in several different testing scenarios. So, I can't change anything on the "server" side lest the other things break.

Under these circumstances, any changes would have to take place on the client side.

Robert

[melipla]

Originally Posted by chillyjim

On the policy server object, go to authentication->policy server and chose a group for users to receive a policy and put your test user/client in a different RA group

Is that an R60 option?

[chillyjim]

Originally Posted by melipla

Is that an R60 option?

Yeah I think it started with NGX when the policy server was included with the VPN-1 license.

[chillyjim]

Originally Posted by RobertGraham

Jim:

Sorry I didn't specify, but this test user is used in several different testing scenarios. So, I can't change anything on the "server" side lest the other things break.

Under these circumstances, any changes would have to take place on the client side.

Robert

In that case, you lose. The whole point of SVC is it isn't end user modifiable.

[RobertGraham]

You mean, you lose unless you do it the way I described in my original post. ;-)

Another option would be to write a script that runs after the policy download and overwrites the policy downloaded with one that contains nothing. But, that hardly seems like it's worth the effort.

[RobertGraham]

In the end I ended up simply unbinding SecuRemote from the NIC. That worked great!


...until they upgraded the gateway from NG to NGX and the whole thing blew up.

Now I'm back to figuring out how to disable the policy or preventing the policy from ever being loaded. :-(

[melipla]

Good to see that SCV actually works..in NGX at least :) Let me know if figure out a way around it!

[RobertGraham]

OK, this is completely nuts! With all the difficulties of making sure that we block the policy download with SecureClient, we finally decided to move to SecuRemote. We're only trying to test the authentication anyway...

So, I uninstalled SecureClient, downloaded the latest and greatest installer (R60HFA02) and proceeded to install SecuRemote. Policy problem - gone. However, this tunnel_test nonsense began to rear its ugly head once again.

Two sites were configured, and for the one it always did a tunnel test. I found it strange that it was the first site created after the fresh installation. Sooooo....I deleted the site and recreated it and VOILA! It works.

There's no real solid info on the tunnel test application in the SecureKnowledge and several of my questions remain unanswered. I don't have the luxury of doing the research now. But eventually I will...

[jrdld]

In R56 you can do this by excluding the user from the group of users allowed to use the policy server. In the firewall object, goto Authentication, and look in the Policy Server section. There will be a group of users selected there. If you can isolate the user from that group, they won't get policy updates. I found this to my cost when a couple of new users weren't getting policy updates, because they were in a newly configured group, which had not been added to the group given access to the policy server.

JR