| Author | Messages | |
RPMiller
Posts:34
 | | 12/16/2009 1:56 PM |
| I am still working on that issue with my Outlook restriction policy not
getting applied to remote users. I've been working with Microsoft technical
support for a couple weeks now, and we do not appear to be any closer to an
answer, and they are starting to toss out the phrase "by design." I find
this extremely hard to swallow that user policies are not being applied "by
design," so I am hoping that I can pick your brains to see if you have run
into this issue.
- I have fifty to seventy-five remote users that travel, work from home,
or work at customer sites.
- I need to apply policy changes to these users.
- Currently I am trying to apply a policy that shuts off the autocomplete
feature of Outlook. (Don't ask why, long story.)
- I have created a group that will contain all users that this will be
applied to.
- I have created the policy and linked it to my custom "all users" OU.
- The policy works perfectly for all users that are connected to the
network when they long on, or that use the "Log on with dial-up networking"
option checked.
- It does not work for any users that simply log on with cached
credentials and then connect via a default Windows VPN connection to the
network no matter how long they stay connected, nor will it work if they try
a gpupdate /force.
- I've run rsop and network monitor and all the other usually recommended
procedures to track down what is happening, and the only problem we are
seeing is that the Outlook restriction policy is being filtered because the
user is not a member of the group.
- I've tested the Kerberos ticket after 10 hours and checked group
membership, and it still appears that the user is not being added to the
appropriate group.
- This, to me, sounds like it is the actual cause of the problem, but
so far Microsoft tech support has not been able to figure out
why the group
membership is not changing.
I have read several posts to the list, and also white papers that clearly
state that the policies get refreshed after 90 to 120 minutes, but I am not
seeing this to be true on my network.
So the big questions:
- Does anyone have new policies that they have created after a
computer/user has left the network, and had them get applied without user
intervention?
- Does anyone have Outlook specific policies that are getting applied to
users that are not logging directly into the network?
- Does anyone have any ideas regarding what the problem could possibly
be?
- Has anyone had problems with Kerberos not updating the user ticket for
remote users that connect via a VPN connection?
About my network:
- It is comprised of 2003 SR2 servers.
- It was migrated from a Windows NT 4.0 network a few years ago.
- It is running in 2003 native mode now.
- There do not appear to be any other problems beyond the policies not
being applied to remote users.
- All but three users on the network are running Windows XP SP3
Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
| | | |
| dmarelia
Posts:394
| | 12/16/2009 1:56 PM |
| I think Kevin is correct here. Let me ask you this. In GPMC GP Results, it will show what GP thinks the user's group membership are. When you run GP Results against one of these machines connected over the VPN, does it show the user as being in the group? If not, I wonder what happens if you do a klist /purge from one of these machines as the logged on user?
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Wornell, Kevin (Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes at Logon. The users are not actually logging on and therefore not picking up the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not getting applied to remote users. I've been working with Microsoft technical support for a couple weeks now, and we do not appear to be any closer to an answer, and they are starting to toss out the phrase "by design." I find this extremely hard to swallow that user policies are not being applied "by design," so I am hoping that I can pick your brains to see if you have run into this issue.
* I have fifty to seventy-five remote users that travel, work from home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this will be applied to.
* I have created the policy and linked it to my custom "all users" OU.
* The policy works perfectly for all users that are connected to the network when they long on, or that use the "Log on with dial-up networking" option checked.
* It does not work for any users that simply log on with cached credentials and then connect via a default Windows VPN connection to the network no matter how long they stay connected, nor will it work if they try a gpupdate /force.
* I've run rsop and network monitor and all the other usually recommended procedures to track down what is happening, and the only problem we are seeing is that the Outlook restriction policy is being filtered because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group membership, and it still appears that the user is not being added to the appropriate group.
* This, to me, sounds like it is the actual cause of the problem, but so far Microsoft tech support has not been able to figure out why the group membership is not changing.
I have read several posts to the list, and also white papers that clearly state that the policies get refreshed after 90 to 120 minutes, but I am not seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a computer/user has left the network, and had them get applied without user intervention?
* Does anyone have Outlook specific policies that are getting applied to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could possibly be?
* Has anyone had problems with Kerberos not updating the user ticket for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies not being applied to remote users.
* All but three users on the network are running Windows XP SP3 Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
| | | |
| JamieNelson
Posts:166
| | 12/16/2009 1:56 PM |
| I am pretty sure klist /purge works for the computer object's
membership, but I don't know if it does for a user. I think this subject
came up on here a while back.
Actually, on a computer object, I think the membership should update
automatically (without a reboot) after the Kerberos ticket renewal
lifetime expires, which by default is 7 days. Unfortunately I don't
think this is the case for users.
As Kevin mentioned, and Darren confirmed, the user's token normally
doesn't get updated until their next logon.
Jamie Nelson | Sr. Administrator | BI&T Infrastructure-Intel | Devon
Energy Corporation | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 |
http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, November 05, 2009 5:13 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think Kevin is correct here. Let me ask you this. In GPMC GP Results,
it will show what GP thinks the user's group membership are. When you
run GP Results against one of these machines connected over the VPN,
does it show the user as being in the group? If not, I wonder what
happens if you do a klist /purge from one of these machines as the
logged on user?
Darren
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Wornell, Kevin
(Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes
at Logon. The users are not actually logging on and therefore not
picking up the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not
getting applied to remote users. I've been working with Microsoft
technical support for a couple weeks now, and we do not appear to be any
closer to an answer, and they are starting to toss out the phrase "by
design." I find this extremely hard to swallow that user policies are
not being applied "by design," so I am hoping that I can pick your
brains to see if you have run into this issue.
* I have fifty to seventy-five remote users that travel, work from
home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the
autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this
will be applied to.
* I have created the policy and linked it to my custom "all users"
OU.
* The policy works perfectly for all users that are connected to
the network when they long on, or that use the "Log on with dial-up
networking" option checked.
* It does not work for any users that simply log on with cached
credentials and then connect via a default Windows VPN connection to the
network no matter how long they stay connected, nor will it work if they
try a gpupdate /force.
* I've run rsop and network monitor and all the other usually
recommended procedures to track down what is happening, and the only
problem we are seeing is that the Outlook restriction policy is being
filtered because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group
membership, and it still appears that the user is not being added to the
appropriate group.
* This, to me, sounds like it is the actual cause of the
problem, but so far Microsoft tech support has not been able to figure
out why the group membership is not changing.
I have read several posts to the list, and also white papers that
clearly state that the policies get refreshed after 90 to 120 minutes,
but I am not seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a
computer/user has left the network, and had them get applied without
user intervention?
* Does anyone have Outlook specific policies that are getting
applied to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could
possibly be?
* Has anyone had problems with Kerberos not updating the user
ticket for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies
not being applied to remote users.
* All but three users on the network are running Windows XP SP3
Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has
been prepared for the sole and exclusive use of the intended recipient
and on the basis agreed with that person. If you are not the intended
recipient of the message (or authorized to receive it for the intended
recipient), you should notify us immediately; you should delete it from
your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged.
If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
| | | |
| RobertMariani
Posts:35
| | 12/16/2009 1:58 PM |
| Robert - you mention that
* "The policy works perfectly for all users that are connected to
the network when they long on, or that use the "Log on with dial-up
networking" option checked."
The reason that this may work is because there is an open network (all
be it a VPN) connection to a DC prior to the laptop processing the logon
request. This means that the laptop will hand the authentication off to
be processed by the DC and hence pick up the new group membership
settings rather than using cached details.
If the users are going to bring up a VPN connection anyway once they
logon with cached credientials perhaps educate them to always use the
"Logon with Dial-Up Networking" checked so your user based membership
changes apply.
Be mindful though if the VPN is slow it may take ages for any user based
scripts to process if you decide to do this.
Alternatively maybe issue a memo when you have made changes to
memberships to ask users to logon with dial-up networking the next time
they logon so the laptop credential cache can be updated.
Regards,
Robert Mariani
Applications Manager
--
The Buchan Group, Melbourne
Architecture+Master Planning+Interiors+Graphics
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Robert Miller
Sent: Friday, 6 November 2009 12:26 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
So then how do you guys push out a policy for a remote user that rarely
logs on to the network? That seems like a serious flaw to me. Also, why
isn't the act of logging in via the VPN accepted as a user log in? This
makes no rational sense to me that it is designed with the idea that
users will always log in to a network.
On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Omar-I have a blog entry up at www.sdmsoftware.com/blog that describes
how you can use klist to refresh computer tickets without rebooting.
Jamie- you may be right. My assumption about klist is that it deals with
tickets within the context it runs. That is why you need to refresh
machine tickets in system context, but you should be able to purge
per-user tickets by running it in the user context. That being said, I
am not in a place where I can test this - I will try to do that tomorrow
if no one else can test this today.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Omar Droubi
Sent: Thursday, November 05, 2009 5:12 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
in my experience computer group membership is read and startup only but
I never tried to purge the kerb tickets. user group membership is read
only at logon from what I know.
omar
________________________________
From: xxxxxxxxxxxxxxxx [xxxxxxxxxxxxxxxx] On
Behalf Of Nelson, Jamie [xxxxxxxxxxxxxxxx]
Sent: Thursday, November 05, 2009 4:07 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I am pretty sure klist /purge works for the computer object's
membership, but I don't know if it does for a user. I think this subject
came up on here a while back.
Actually, on a computer object, I think the membership should update
automatically (without a reboot) after the Kerberos ticket renewal
lifetime expires, which by default is 7 days. Unfortunately I don't
think this is the case for users.
As Kevin mentioned, and Darren confirmed, the user's token normally
doesn't get updated until their next logon.
Jamie Nelson | Sr. Administrator | BI&T Infrastructure-Intel | Devon
Energy Corporation | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 |
http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, November 05, 2009 5:13 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think Kevin is correct here. Let me ask you this. In GPMC GP Results,
it will show what GP thinks the user's group membership are. When you
run GP Results against one of these machines connected over the VPN,
does it show the user as being in the group? If not, I wonder what
happens if you do a klist /purge from one of these machines as the
logged on user?
Darren
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Wornell, Kevin
(Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes
at Logon. The users are not actually logging on and therefore not
picking up the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx
[mailto:xxxxxxxxxxxxxxxx] On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not
getting applied to remote users. I've been working with Microsoft
technical support for a couple weeks now, and we do not appear to be any
closer to an answer, and they are starting to toss out the phrase "by
design." I find this extremely hard to swallow that user policies are
not being applied "by design," so I am hoping that I can pick your
brains to see if you have run into this issue.
* I have fifty to seventy-five remote users that travel, work from
home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the
autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this
will be applied to.
* I have created the policy and linked it to my custom "all users"
OU.
* The policy works perfectly for all users that are connected to
the network when they long on, or that use the "Log on with dial-up
networking" option checked.
* It does not work for any users that simply log on with cached
credentials and then connect via a default Windows VPN connection to the
network no matter how long they stay connected, nor will it work if they
try a gpupdate /force.
* I've run rsop and network monitor and all the other usually
recommended procedures to track down what is happening, and the only
problem we are seeing is that the Outlook restriction policy is being
filtered because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group
membership, and it still appears that the user is not being added to the
appropriate group.
* This, to me, sounds like it is the actual cause of the
problem, but so far Microsoft tech support has not been able to figure
out why the group membership is not changing.
I have read several posts to the list, and also white papers that
clearly state that the policies get refreshed after 90 to 120 minutes,
but I am not seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a
computer/user has left the network, and had them get applied without
user intervention?
* Does anyone have Outlook specific policies that are getting
applied to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could
possibly be?
* Has anyone had problems with Kerberos not updating the user
ticket for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies
not being applied to remote users.
* All but three users on the network are running Windows XP SP3
Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has
been prepared for the sole and exclusive use of the intended recipient
and on the basis agreed with that person. If you are not the intended
recipient of the message (or authorized to receive it for the intended
recipient), you should notify us immediately; you should delete it from
your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
________________________________
Confidentiality Warning: This message and any attachments are intended
only for the use of the intended recipient(s), are confidential, and may
be privileged. If you are not the intended recipient, you are hereby
notified that any review, retransmission, conversion to hard copy,
copying, circulation or other use of all or any portion of this message
and any attachments is strictly prohibited. If you are not the intended
recipient, please notify the sender immediately by return e-mail, and
delete this message and any attachments from your system.
| | | |
| jpochedl
Posts:6
| | 12/16/2009 2:00 PM |
| How about SMS or SCCM or any other type of software distribution mechanism that you use to manage the machines?
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 2:25 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
I'm running Windows RAS server.
On Fri, Nov 6, 2009 at 10:54 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Sorry, I missed the part about them not wanting it  . That's a different problem. Do you have any ability to run scripts or execute commands as a function of folks connecting to your VPN? Any kind of NAP in place?
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:47 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
Again, how would I go about getting them to run it if they do not want the policy applied to them?
On Fri, Nov 6, 2009 at 10:25 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Well, they would only need to run it once, when they're connected to the VPN. You could simply provide a batch file, via email, that did it for them, so they don't have to learn how to open a command prompt, etc. Once they get their membership, then the setting would apply during the next background refresh.
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:21 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
Not yet, but if it were to work, how would I go about getting my remote users to do it if they don't want to have the policy applied to them?
On Fri, Nov 6, 2009 at 10:00 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Robert-
Have you tried the klist /purge approach within the context of the user? Again, I haven't been able to test it but it *may* work and at least provide a workaround to your issue.
Darren
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:17 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
Yes, I definitely considered that, but the cost of administration goes too high for my tastes. The way to reduce the cost would be to only add the users that it is not applying to, but that would require users to be honest regarding whether the policy has applied or not. This is a problem because the policy is, understandably, not one that people want to have applied to them, so the likelihood of getting false positives is high; thus, the requirement that the policy be enforcible by IT.
On Fri, Nov 6, 2009 at 9:09 AM, Wornell, Kevin (Dallas) <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
One thing you could do is to add the user objects themselves directly to the policy. Not the cleanest or most elegant solution but it will work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:30 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
Yes, I have remote users that will not have the policy applied as well, so it looks like I'm still up the creek for a solution...
On Fri, Nov 6, 2009 at 7:54 AM, Wornell, Kevin (Dallas) <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I made the assumption that the users you need to NOT apply the setting to would be logging in normally. If all your remote users need the settings applied, then the scenario I described will work since they are already members of Domain Users. If there are any remote users that do not need the settings applied then you are correct and it will not work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:29 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
But if a the problem is users not being added to a group, won't the same problem still exist? I would have to add the users to the "Deny Outlook AutoComplete Disable" group, yes? How would those users get added to that group if they are not being added to the existing group?
On Fri, Nov 6, 2009 at 6:44 AM, Wornell, Kevin (Dallas) <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
One other thought I had on this is to get a bit more creative. The issue is the group membership change. If you can't get the remote users to see the group membership change then let's use a group they are already members of, Domain Users. By combining the Domain Users group on the ACL with a group based Deny permission on the Delegation we can isolate only those users that need to have the policy applied.
Here are the basic steps.
Create a new Domain Local security group appropriately named. For example 'Deny Outlook AutoComplete Disable'
Populate this group with those users objects that should NOT have the new setting applied.
Create a new group policy named 'Outlook Auto-Complete Disable', for example
Add the new 'Deny Outlook AutoComplete Disable' group via the Delegation-->Advanced tab on the Group Policy and check the Deny box for 'Apply Group Policy'
Remove all entries from the Security Filtering on the group policy
Configure the settings you want in the policy
Add the Domain Users group to the security filtering on the new policy
The end result is that all Domain Users, except those in the 'Deny Outlook AutoComplete Disable' group will get the setting at the next group policy refresh with no need for a group membership change.
If you have Remote Users who should not have the setting applied you will need to be sure and include them in the Deny group.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 7:26 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] "By Design"
So then how do you guys push out a policy for a remote user that rarely logs on to the network? That seems like a serious flaw to me. Also, why isn't the act of logging in via the VPN accepted as a user log in? This makes no rational sense to me that it is designed with the idea that users will always log in to a network.
On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Omar-I have a blog entry up at www.sdmsoftware.com/blog<http://www.sdmsoftware.com/blog> that describes how you can use klist to refresh computer tickets without rebooting.
Jamie- you may be right. My assumption about klist is that it deals with tickets within the context it runs. That is why you need to refresh machine tickets in system context, but you should be able to purge per-user tickets by running it in the user context. That being said, I am not in a place where I can test this - I will try to do that tomorrow if no one else can test this today.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Omar Droubi
Sent: Thursday, November 05, 2009 5:12 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: RE: [gptalk] "By Design"
in my experience computer group membership is read and startup only but I never tried to purge the kerb tickets. user group membership is read only at logon from what I know.
omar
________________________________
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Nelson, Jamie [xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>]
Sent: Thursday, November 05, 2009 4:07 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: RE: [gptalk] "By Design"
I am pretty sure klist /purge works for the computer object's membership, but I don't know if it does for a user. I think this subject came up on here a while back.
Actually, on a computer object, I think the membership should update automatically (without a reboot) after the Kerberos ticket renewal lifetime expires, which by default is 7 days. Unfortunately I don't think this is the case for users.
As Kevin mentioned, and Darren confirmed, the user's token normally doesn't get updated until their next logon.
Jamie Nelson | Sr. Administrator | BI&T Infrastructure-Intel | Devon Energy Corporation | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 | http://www.dvn.com<http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Darren Mar-Elia
Sent: Thursday, November 05, 2009 5:13 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: RE: [gptalk] "By Design"
I think Kevin is correct here. Let me ask you this. In GPMC GP Results, it will show what GP thinks the user's group membership are. When you run GP Results against one of these machines connected over the VPN, does it show the user as being in the group? If not, I wonder what happens if you do a klist /purge from one of these machines as the logged on user?
Darren
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Wornell, Kevin (Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes at Logon. The users are not actually logging on and therefore not picking up the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not getting applied to remote users. I've been working with Microsoft technical support for a couple weeks now, and we do not appear to be any closer to an answer, and they are starting to toss out the phrase "by design." I find this extremely hard to swallow that user policies are not being applied "by design," so I am hoping that I can pick your brains to see if you have run into this issue.
* I have fifty to seventy-five remote users that travel, work from home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this will be applied to.
* I have created the policy and linked it to my custom "all users" OU.
* The policy works perfectly for all users that are connected to the network when they long on, or that use the "Log on with dial-up networking" option checked.
* It does not work for any users that simply log on with cached credentials and then connect via a default Windows VPN connection to the network no matter how long they stay connected, nor will it work if they try a gpupdate /force.
* I've run rsop and network monitor and all the other usually recommended procedures to track down what is happening, and the only problem we are seeing is that the Outlook restriction policy is being filtered because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group membership, and it still appears that the user is not being added to the appropriate group.
* This, to me, sounds like it is the actual cause of the problem, but so far Microsoft tech support has not been able to figure out why the group membership is not changing.
I have read several posts to the list, and also white papers that clearly state that the policies get refreshed after 90 to 120 minutes, but I am not seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a computer/user has left the network, and had them get applied without user intervention?
* Does anyone have Outlook specific policies that are getting applied to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could possibly be?
* Has anyone had problems with Kerberos not updating the user ticket for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies not being applied to remote users.
* All but three users on the network are running Windows XP SP3 Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
________________________________
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
| | | |
| Syspro
Posts:0
| | 12/16/2009 2:03 PM |
|
How about having a batch file that everyone runs that reads AD to see if the
current user is a member of the group (as against checking the token of the
current user) and then do whatever you need to do?
Alternatively could use WMI filtering on the Policy to check the
membership?. I think this should allow you to code a WMI query that checks
AD rather than the Users Token, but I have never tried this sort of thing.
Alan Cuthbertson
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Saturday, 7 November 2009 8:07 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Don't have anything extra.
On Fri, Nov 6, 2009 at 12:51 PM, Joe Pochedley
<xxxxxxxxxxxxxxxx> wrote:
How about SMS or SCCM or any other type of software distribution mechanism
that you use to manage the machines?
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 2:25 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
I'm running Windows RAS server.
On Fri, Nov 6, 2009 at 10:54 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Sorry, I missed the part about them not wanting it J. Thats a different
problem. Do you have any ability to run scripts or execute commands as a
function of folks connecting to your VPN? Any kind of NAP in place?
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:47 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Again, how would I go about getting them to run it if they do not want the
policy applied to them?
On Fri, Nov 6, 2009 at 10:25 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Well, they would only need to run it once, when theyre connected to the
VPN. You could simply provide a batch file, via email, that did it for them,
so they dont have to learn how to open a command prompt, etc. Once they get
their membership, then the setting would apply during the next background
refresh.
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:21 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Not yet, but if it were to work, how would I go about getting my remote
users to do it if they don't want to have the policy applied to them?
On Fri, Nov 6, 2009 at 10:00 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Robert-
Have you tried the klist /purge approach within the context of the user?
Again, I havent been able to test it but it *may* work and at least provide
a workaround to your issue.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:17 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Yes, I definitely considered that, but the cost of administration goes too
high for my tastes. The way to reduce the cost would be to only add the
users that it is not applying to, but that would require users to be honest
regarding whether the policy has applied or not. This is a problem because
the policy is, understandably, not one that people want to have applied to
them, so the likelihood of getting false positives is high; thus, the
requirement that the policy be enforcible by IT.
On Fri, Nov 6, 2009 at 9:09 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
One thing you could do is to add the user objects themselves directly to the
policy. Not the cleanest or most elegant solution but it will work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:30 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Yes, I have remote users that will not have the policy applied as well, so
it looks like I'm still up the creek for a solution...
On Fri, Nov 6, 2009 at 7:54 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
I made the assumption that the users you need to NOT apply the setting to
would be logging in normally. If all your remote users need the settings
applied, then the scenario I described will work since they are already
members of Domain Users. If there are any remote users that do not need the
settings applied then you are correct and it will not work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:29 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
But if a the problem is users not being added to a group, won't the same
problem still exist? I would have to add the users to the "Deny Outlook
AutoComplete Disable" group, yes? How would those users get added to that
group if they are not being added to the existing group?
On Fri, Nov 6, 2009 at 6:44 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
One other thought I had on this is to get a bit more creative. The issue is
the group membership change. If you cant get the remote users to see the
group membership change then lets use a group they are already members of,
Domain Users. By combining the Domain Users group on the ACL with a group
based Deny permission on the Delegation we can isolate only those users that
need to have the policy applied.
Here are the basic steps.
Create a new Domain Local security group appropriately named. For example
Deny Outlook AutoComplete Disable
Populate this group with those users objects that should NOT have the new
setting applied.
Create a new group policy named Outlook Auto-Complete Disable, for example
Add the new Deny Outlook AutoComplete Disable group via the
DelegationàAdvanced tab on the Group Policy and check the Deny box for
Apply Group Policy
Remove all entries from the Security Filtering on the group policy
Configure the settings you want in the policy
Add the Domain Users group to the security filtering on the new policy
The end result is that all Domain Users, except those in the Deny Outlook
AutoComplete Disable group will get the setting at the next group policy
refresh with no need for a group membership change.
If you have Remote Users who should not have the setting applied you will
need to be sure and include them in the Deny group.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 7:26 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
So then how do you guys push out a policy for a remote user that rarely logs
on to the network? That seems like a serious flaw to me. Also, why isn't the
act of logging in via the VPN accepted as a user log in? This makes no
rational sense to me that it is designed with the idea that users will
always log in to a network.
On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
OmarI have a blog entry up at www.sdmsoftware.com/blog that describes how
you can use klist to refresh computer tickets without rebooting.
Jamie- you may be right. My assumption about klist is that it deals with
tickets within the context it runs. That is why you need to refresh machine
tickets in system context, but you should be able to purge per-user tickets
by running it in the user context. That being said, I am not in a place
where I can test this I will try to do that tomorrow if no one else can
test this today.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Omar Droubi
Sent: Thursday, November 05, 2009 5:12 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
in my experience computer group membership is read and startup only but I
never tried to purge the kerb tickets. user group membership is read only at
logon from what I know.
omar
_____
From: xxxxxxxxxxxxxxxx [xxxxxxxxxxxxxxxx] On
Behalf Of Nelson, Jamie [xxxxxxxxxxxxxxxx]
Sent: Thursday, November 05, 2009 4:07 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I am pretty sure klist /purge works for the computer objects membership,
but I dont know if it does for a user. I think this subject came up on here
a while back.
Actually, on a computer object, I think the membership should update
automatically (without a reboot) after the Kerberos ticket renewal lifetime
expires, which by default is 7 days. Unfortunately I dont think this is the
case for users.
As Kevin mentioned, and Darren confirmed, the users token normally doesnt
get updated until their next logon.
Jamie Nelson | Sr. Administrator | BI&T Infrastructure-Intel | Devon Energy
Corporation | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 |
http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Darren Mar-Elia
Sent: Thursday, November 05, 2009 5:13 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think Kevin is correct here. Let me ask you this. In GPMC GP Results, it
will show what GP thinks the users group membership are. When you run GP
Results against one of these machines connected over the VPN, does it show
the user as being in the group? If not, I wonder what happens if you do a
klist /purge from one of these machines as the logged on user?
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Wornell, Kevin (Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes at
Logon. The users are not actually logging on and therefore not picking up
the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not
getting applied to remote users. I've been working with Microsoft technical
support for a couple weeks now, and we do not appear to be any closer to an
answer, and they are starting to toss out the phrase "by design." I find
this extremely hard to swallow that user policies are not being applied "by
design," so I am hoping that I can pick your brains to see if you have run
into this issue.
* I have fifty to seventy-five remote users that travel, work from
home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the
autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this will be
applied to.
* I have created the policy and linked it to my custom "all users" OU.
* The policy works perfectly for all users that are connected to the
network when they long on, or that use the "Log on with dial-up networking"
option checked.
* It does not work for any users that simply log on with cached
credentials and then connect via a default Windows VPN connection to the
network no matter how long they stay connected, nor will it work if they try
a gpupdate /force.
* I've run rsop and network monitor and all the other usually
recommended procedures to track down what is happening, and the only problem
we are seeing is that the Outlook restriction policy is being filtered
because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group
membership, and it still appears that the user is not being added to the
appropriate group.
* This, to me, sounds like it is the actual cause of the problem, but
so far Microsoft tech support has not been able to figure out why the group
membership is not changing.
I have read several posts to the list, and also white papers that clearly
state that the policies get refreshed after 90 to 120 minutes, but I am not
seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a
computer/user has left the network, and had them get applied without user
intervention?
* Does anyone have Outlook specific policies that are getting applied
to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could possibly
be?
* Has anyone had problems with Kerberos not updating the user ticket
for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies not
being applied to remote users.
* All but three users on the network are running Windows XP SP3
Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
_____
Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, retransmission, conversion to hard copy, copying,
circulation or other use of all or any portion of this message and any
attachments is strictly prohibited. If you are not the intended recipient,
please notify the sender immediately by return e-mail, and delete this
message and any attachments from your system.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
| | | |
| RPMiller
Posts:34
| | 12/16/2009 2:03 PM |
| Sure, if it can do what you think it can, I am completely open to anything
that I can push out, and that will actually work. The primary issue here
with scripts and batch files, is that I can not count on the users to run
anything. It has to be something that I can force to run without user
interaction. That means that I can't email something out to users, or put it
up on a share for users to access, it has to be automated.
On Fri, Nov 6, 2009 at 11:01 PM, Alan and Margaret Cuthbertson <
xxxxxxxxxxxxxxxx> wrote:
>
>
> How about having a batch file that everyone runs that reads AD to see if
> the current user is a member of the group (as against checking the token of
> the current user) and then do whatever you need to do?
>
>
>
> Alternatively could use WMI filtering on the Policy to check the
> membership?. I think this should allow you to code a WMI query that checks
> AD rather than the User’s Token, but I have never tried this sort of thing.
>
>
>
> Alan Cuthbertson
>
>
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Saturday, 7 November 2009 8:07 AM
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Don't have anything extra.
>
> On Fri, Nov 6, 2009 at 12:51 PM, Joe Pochedley <
> xxxxxxxxxxxxxxxx> wrote:
>
> How about SMS or SCCM or any other type of software distribution mechanism
> that you use to manage the machines?
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 2:25 PM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> I'm running Windows RAS server.
>
> On Fri, Nov 6, 2009 at 10:54 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
> wrote:
>
> Sorry, I missed the part about them not wanting it J. That’s a different
> problem. Do you have any ability to run scripts or execute commands as a
> function of folks connecting to your VPN? Any kind of NAP in place?
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 10:47 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Again, how would I go about getting them to run it if *they do not want
> the policy applied to them*?
>
> On Fri, Nov 6, 2009 at 10:25 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
> wrote:
>
> Well, they would only need to run it once, when they’re connected to the
> VPN. You could simply provide a batch file, via email, that did it for them,
> so they don’t have to learn how to open a command prompt, etc. Once they get
> their membership, then the setting would apply during the next background
> refresh.
>
>
>
>
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 10:21 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Not yet, but if it were to work, how would I go about getting my remote
> users to do it if they don't want to have the policy applied to them?
>
> On Fri, Nov 6, 2009 at 10:00 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
> wrote:
>
> Robert-
>
> Have you tried the klist /purge approach within the context of the user?
> Again, I haven’t been able to test it but it **may** work and at least
> provide a workaround to your issue.
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 9:17 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Yes, I definitely considered that, but the cost of administration goes too
> high for my tastes. The way to reduce the cost would be to only add the
> users that it is not applying to, but that would require users to be honest
> regarding whether the policy has applied or not. This is a problem because
> the policy is, understandably, not one that people want to have applied to
> them, so the likelihood of getting false positives is high; thus, the
> requirement that the policy be enforcible by IT.
>
> On Fri, Nov 6, 2009 at 9:09 AM, Wornell, Kevin (Dallas) <
> xxxxxxxxxxxxxxxx> wrote:
>
> One thing you could do is to add the user objects themselves directly to
> the policy. Not the cleanest or most elegant solution but it will work.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 10:30 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Yes, I have remote users that will not have the policy applied as well, so
> it looks like I'm still up the creek for a solution...
>
> On Fri, Nov 6, 2009 at 7:54 AM, Wornell, Kevin (Dallas) <
> xxxxxxxxxxxxxxxx> wrote:
>
> I made the assumption that the users you need to NOT apply the setting to
> would be logging in normally. If all your remote users need the settings
> applied, then the scenario I described will work since they are already
> members of Domain Users. If there are any remote users that do not need the
> settings applied then you are correct and it will not work.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Friday, November 06, 2009 9:29 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> But if a the problem is users not being added to a group, won't the same
> problem still exist? I would have to add the users to the "Deny Outlook
> AutoComplete Disable" group, yes? How would those users get added to that
> group if they are not being added to the existing group?
>
> On Fri, Nov 6, 2009 at 6:44 AM, Wornell, Kevin (Dallas) <
> xxxxxxxxxxxxxxxx> wrote:
>
> One other thought I had on this is to get a bit more creative. The issue
> is the group membership change. If you can’t get the remote users to see
> the group membership change then let’s use a group they are already members
> of, Domain Users. By combining the Domain Users group on the ACL with a
> group based Deny permission on the Delegation we can isolate only those
> users that need to have the policy applied.
>
>
>
> Here are the basic steps.
>
>
>
> Create a new Domain Local security group appropriately named. For example
> ‘Deny Outlook AutoComplete Disable’
>
> Populate this group with those users objects that should NOT have the new
> setting applied.
>
> Create a new group policy named ‘Outlook Auto-Complete Disable’, for
> example
>
> Add the new ‘Deny Outlook AutoComplete Disable’ group via the DelegationàAdvanced
> tab on the Group Policy and check the Deny box for ‘Apply Group Policy’
>
> Remove all entries from the Security Filtering on the group policy
>
> Configure the settings you want in the policy
>
> Add the Domain Users group to the security filtering on the new policy
>
>
>
> The end result is that all Domain Users, except those in the ‘Deny Outlook
> AutoComplete Disable’ group will get the setting at the next group policy
> refresh with no need for a group membership change.
>
>
>
> If you have Remote Users who should not have the setting applied you will
> need to be sure and include them in the Deny group.
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Thursday, November 05, 2009 7:26 PM
>
>
> *To:* xxxxxxxxxxxxxxxx
>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> So then how do you guys push out a policy for a remote user that rarely
> logs on to the network? That seems like a serious flaw to me. Also, why
> isn't the act of logging in via the VPN accepted as a user log in? This
> makes no rational sense to me that it is designed with the idea that users
> will always log in to a network.
>
> On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
> wrote:
>
> Omar—I have a blog entry up at www.sdmsoftware.com/blog that describes how
> you can use klist to refresh computer tickets without rebooting.
>
>
>
> Jamie- you may be right. My assumption about klist is that it deals with
> tickets within the context it runs. That is why you need to refresh machine
> tickets in system context, but you should be able to purge per-user tickets
> by running it in the user context. That being said, I am not in a place
> where I can test this – I will try to do that tomorrow if no one else can
> test this today.
>
>
>
> Thanks!
>
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Omar Droubi
> *Sent:* Thursday, November 05, 2009 5:12 PM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> in my experience computer group membership is read and startup only but I
> never tried to purge the kerb tickets. user group membership is read only at
> logon from what I know.
>
>
>
> omar
> ------------------------------
>
> *From:* xxxxxxxxxxxxxxxx [xxxxxxxxxxxxxxxx] On
> Behalf Of Nelson, Jamie [xxxxxxxxxxxxxxxx]
> *Sent:* Thursday, November 05, 2009 4:07 PM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] "By Design"
>
> I am pretty sure klist /purge works for the computer object’s membership,
> but I don’t know if it does for a user. I think this subject came up on here
> a while back.
>
>
>
> Actually, on a computer object, I think the membership should update
> automatically (without a reboot) after the Kerberos ticket renewal lifetime
> expires, which by default is 7 days. Unfortunately I don’t think this is the
> case for users.
>
>
>
> As Kevin mentioned, and Darren confirmed, the user’s token normally doesn’t
> get updated until their next logon.
>
>
>
> *Jamie Nelson* | Sr. Administrator | BI&T Infrastructure-Intel | *Devon
> Energy Corporation* | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 |
> http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Darren Mar-Elia
> *Sent:* Thursday, November 05, 2009 5:13 PM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> I think Kevin is correct here. Let me ask you this. In GPMC GP Results, it
> will show what GP thinks the user’s group membership are. When you run GP
> Results against one of these machines connected over the VPN, does it show
> the user as being in the group? If not, I wonder what happens if you do a
> klist /purge from one of these machines as the logged on user?
>
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Wornell, Kevin (Dallas)
> *Sent:* Thursday, November 05, 2009 1:20 PM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> I think the underlying cause may be that Group membership only changes at
> Logon. The users are not actually logging on and therefore not picking up
> the group membership change.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Robert Miller
> *Sent:* Thursday, November 05, 2009 12:43 PM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* [gptalk] "By Design"
>
>
>
> I am still working on that issue with my Outlook restriction policy not
> getting applied to remote users. I've been working with Microsoft technical
> support for a couple weeks now, and we do not appear to be any closer to an
> answer, and they are starting to toss out the phrase "by design." I find
> this extremely hard to swallow that user policies are not being applied "by
> design," so I am hoping that I can pick your brains to see if you have run
> into this issue.
>
> - I have fifty to seventy-five remote users that travel, work from
> home, or work at customer sites.
> - I need to apply policy changes to these users.
> - Currently I am trying to apply a policy that shuts off the
> autocomplete feature of Outlook. (Don't ask why, long story.)
> - I have created a group that will contain all users that this will be
> applied to.
> - I have created the policy and linked it to my custom "all users" OU.
> - The policy works perfectly for all users that are connected to the
> network when they long on, or that use the "Log on with dial-up networking"
> option checked.
> - It does not work for any users that simply log on with cached
> credentials and then connect via a default Windows VPN connection to the
> network no matter how long they stay connected, nor will it work if they try
> a gpupdate /force.
> - I've run rsop and network monitor and all the other usually
> recommended procedures to track down what is happening, and the only problem
> we are seeing is that the Outlook restriction policy is being filtered
> because the user is not a member of the group.
> - I've tested the Kerberos ticket after 10 hours and checked group
> membership, and it still appears that the user is not being added to the
> appropriate group.
>
>
> - This, to me, sounds like it is the actual cause of the problem, but
> so far Microsoft tech support has not been able to figure out why the group
> membership is not changing.
>
> I have read several posts to the list, and also white papers that clearly
> state that the policies get refreshed after 90 to 120 minutes, but I am not
> seeing this to be true on my network.
>
> So the big questions:
>
> - Does anyone have new policies that they have created after a
> computer/user has left the network, and had them get applied without user
> intervention?
> - Does anyone have Outlook specific policies that are getting applied
> to users that are not logging directly into the network?
> - Does anyone have any ideas regarding what the problem could possibly
> be?
> - Has anyone had problems with Kerberos not updating the user ticket
> for remote users that connect via a VPN connection?
>
> About my network:
>
> - It is comprised of 2003 SR2 servers.
> - It was migrated from a Windows NT 4.0 network a few years ago.
> - It is running in 2003 native mode now.
> - There do not appear to be any other problems beyond the policies not
> being applied to remote users.
> - All but three users on the network are running Windows XP SP3
> Professional. The exceptions are running Vista Business.
>
> Hopefully I have everything you might ask for answered...
>
> *Notice of Confidentiality*
>
> This transmission contains information that may be confidential. It has
> been prepared for the sole and exclusive use of the intended recipient and
> on the basis agreed with that person. If you are not the intended recipient
> of the message (or authorized to receive it for the intended recipient), you
> should notify us immediately; you should delete it from your system and may
> not disclose its contents to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
> *
> ------------------------------
> *
>
> *Confidentiality Warning:* This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential, and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, retransmission, conversion to hard copy, copying,
> circulation or other use of all or any portion of this message and any
> attachments is strictly prohibited. If you are not the intended recipient,
> please notify the sender immediately by return e-mail, and delete this
> message and any attachments from your system.
>
>
>
> *Notice of Confidentiality*
>
> This transmission contains information that may be confidential. It has
> been prepared for the sole and exclusive use of the intended recipient and
> on the basis agreed with that person. If you are not the intended recipient
> of the message (or authorized to receive it for the intended recipient), you
> should notify us immediately; you should delete it from your system and may
> not disclose its contents to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
> *Notice of Confidentiality*
>
> This transmission contains information that may be confidential. It has
> been prepared for the sole and exclusive use of the intended recipient and
> on the basis agreed with that person. If you are not the intended recipient
> of the message (or authorized to receive it for the intended recipient), you
> should notify us immediately; you should delete it from your system and may
> not disclose its contents to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
> *Notice of Confidentiality*
>
> This transmission contains information that may be confidential. It has
> been prepared for the sole and exclusive use of the intended recipient and
> on the basis agreed with that person. If you are not the intended recipient
> of the message (or authorized to receive it for the intended recipient), you
> should notify us immediately; you should delete it from your system and may
> not disclose its contents to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
>
>
>
>
>
>
>
>
| | | |
| dn
Posts:6
| | 12/16/2009 2:03 PM |
| If these users are running XP or later and have the GPP client installed,
you could set a scheduled task to run the klist purge option using Group
Policy Preferences. This would just run it on a schedule hoping to hit
users when they are connected to the VPN. Ideally, you would wrap it in a
script that would first ping a device on the network to make sure it is
connected to the VPN. It could also create a seed file/registry key once it
ran successfully so it wouldnt run all the time. You might apply this to
all users as there is no real harm that would come from it then you wouldnt
have to worry about the group membership issue or the script could check AD
group membership (as Alan recommends below) and then run it only for users
that need it.
Doug
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Saturday, November 07, 2009 11:26 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Sure, if it can do what you think it can, I am completely open to anything
that I can push out, and that will actually work. The primary issue here
with scripts and batch files, is that I can not count on the users to run
anything. It has to be something that I can force to run without user
interaction. That means that I can't email something out to users, or put it
up on a share for users to access, it has to be automated.
On Fri, Nov 6, 2009 at 11:01 PM, Alan and Margaret Cuthbertson
<xxxxxxxxxxxxxxxx> wrote:
How about having a batch file that everyone runs that reads AD to see if the
current user is a member of the group (as against checking the token of the
current user) and then do whatever you need to do?
Alternatively could use WMI filtering on the Policy to check the
membership?. I think this should allow you to code a WMI query that checks
AD rather than the Users Token, but I have never tried this sort of thing.
Alan Cuthbertson
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Saturday, 7 November 2009 8:07 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Don't have anything extra.
On Fri, Nov 6, 2009 at 12:51 PM, Joe Pochedley
<xxxxxxxxxxxxxxxx> wrote:
How about SMS or SCCM or any other type of software distribution mechanism
that you use to manage the machines?
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 2:25 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
I'm running Windows RAS server.
On Fri, Nov 6, 2009 at 10:54 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Sorry, I missed the part about them not wanting it J. Thats a different
problem. Do you have any ability to run scripts or execute commands as a
function of folks connecting to your VPN? Any kind of NAP in place?
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:47 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Again, how would I go about getting them to run it if they do not want the
policy applied to them?
On Fri, Nov 6, 2009 at 10:25 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Well, they would only need to run it once, when theyre connected to the
VPN. You could simply provide a batch file, via email, that did it for them,
so they dont have to learn how to open a command prompt, etc. Once they get
their membership, then the setting would apply during the next background
refresh.
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:21 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Not yet, but if it were to work, how would I go about getting my remote
users to do it if they don't want to have the policy applied to them?
On Fri, Nov 6, 2009 at 10:00 AM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
Robert-
Have you tried the klist /purge approach within the context of the user?
Again, I havent been able to test it but it *may* work and at least provide
a workaround to your issue.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:17 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Yes, I definitely considered that, but the cost of administration goes too
high for my tastes. The way to reduce the cost would be to only add the
users that it is not applying to, but that would require users to be honest
regarding whether the policy has applied or not. This is a problem because
the policy is, understandably, not one that people want to have applied to
them, so the likelihood of getting false positives is high; thus, the
requirement that the policy be enforcible by IT.
On Fri, Nov 6, 2009 at 9:09 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
One thing you could do is to add the user objects themselves directly to the
policy. Not the cleanest or most elegant solution but it will work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 10:30 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
Yes, I have remote users that will not have the policy applied as well, so
it looks like I'm still up the creek for a solution...
On Fri, Nov 6, 2009 at 7:54 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
I made the assumption that the users you need to NOT apply the setting to
would be logging in normally. If all your remote users need the settings
applied, then the scenario I described will work since they are already
members of Domain Users. If there are any remote users that do not need the
settings applied then you are correct and it will not work.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Friday, November 06, 2009 9:29 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
But if a the problem is users not being added to a group, won't the same
problem still exist? I would have to add the users to the "Deny Outlook
AutoComplete Disable" group, yes? How would those users get added to that
group if they are not being added to the existing group?
On Fri, Nov 6, 2009 at 6:44 AM, Wornell, Kevin (Dallas)
<xxxxxxxxxxxxxxxx> wrote:
One other thought I had on this is to get a bit more creative. The issue is
the group membership change. If you cant get the remote users to see the
group membership change then lets use a group they are already members of,
Domain Users. By combining the Domain Users group on the ACL with a group
based Deny permission on the Delegation we can isolate only those users that
need to have the policy applied.
Here are the basic steps.
Create a new Domain Local security group appropriately named. For example
Deny Outlook AutoComplete Disable
Populate this group with those users objects that should NOT have the new
setting applied.
Create a new group policy named Outlook Auto-Complete Disable, for example
Add the new Deny Outlook AutoComplete Disable group via the
DelegationàAdvanced tab on the Group Policy and check the Deny box for
Apply Group Policy
Remove all entries from the Security Filtering on the group policy
Configure the settings you want in the policy
Add the Domain Users group to the security filtering on the new policy
The end result is that all Domain Users, except those in the Deny Outlook
AutoComplete Disable group will get the setting at the next group policy
refresh with no need for a group membership change.
If you have Remote Users who should not have the setting applied you will
need to be sure and include them in the Deny group.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 7:26 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] "By Design"
So then how do you guys push out a policy for a remote user that rarely logs
on to the network? That seems like a serious flaw to me. Also, why isn't the
act of logging in via the VPN accepted as a user log in? This makes no
rational sense to me that it is designed with the idea that users will
always log in to a network.
On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
wrote:
OmarI have a blog entry up at www.sdmsoftware.com/blog that describes how
you can use klist to refresh computer tickets without rebooting.
Jamie- you may be right. My assumption about klist is that it deals with
tickets within the context it runs. That is why you need to refresh machine
tickets in system context, but you should be able to purge per-user tickets
by running it in the user context. That being said, I am not in a place
where I can test this I will try to do that tomorrow if no one else can
test this today.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Omar Droubi
Sent: Thursday, November 05, 2009 5:12 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
in my experience computer group membership is read and startup only but I
never tried to purge the kerb tickets. user group membership is read only at
logon from what I know.
omar
_____
From: xxxxxxxxxxxxxxxx [xxxxxxxxxxxxxxxx] On
Behalf Of Nelson, Jamie [xxxxxxxxxxxxxxxx]
Sent: Thursday, November 05, 2009 4:07 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I am pretty sure klist /purge works for the computer objects membership,
but I dont know if it does for a user. I think this subject came up on here
a while back.
Actually, on a computer object, I think the membership should update
automatically (without a reboot) after the Kerberos ticket renewal lifetime
expires, which by default is 7 days. Unfortunately I dont think this is the
case for users.
As Kevin mentioned, and Darren confirmed, the users token normally doesnt
get updated until their next logon.
Jamie Nelson | Sr. Administrator | BI&T Infrastructure-Intel | Devon Energy
Corporation | Work: ' 405.552.8054 | Mobile: ' 405.248.7963 |
http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Darren Mar-Elia
Sent: Thursday, November 05, 2009 5:13 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think Kevin is correct here. Let me ask you this. In GPMC GP Results, it
will show what GP thinks the users group membership are. When you run GP
Results against one of these machines connected over the VPN, does it show
the user as being in the group? If not, I wonder what happens if you do a
klist /purge from one of these machines as the logged on user?
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Wornell, Kevin (Dallas)
Sent: Thursday, November 05, 2009 1:20 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] "By Design"
I think the underlying cause may be that Group membership only changes at
Logon. The users are not actually logging on and therefore not picking up
the group membership change.
Kevin
Kevin Wornell
Office Technology Group
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Robert Miller
Sent: Thursday, November 05, 2009 12:43 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] "By Design"
I am still working on that issue with my Outlook restriction policy not
getting applied to remote users. I've been working with Microsoft technical
support for a couple weeks now, and we do not appear to be any closer to an
answer, and they are starting to toss out the phrase "by design." I find
this extremely hard to swallow that user policies are not being applied "by
design," so I am hoping that I can pick your brains to see if you have run
into this issue.
* I have fifty to seventy-five remote users that travel, work from
home, or work at customer sites.
* I need to apply policy changes to these users.
* Currently I am trying to apply a policy that shuts off the
autocomplete feature of Outlook. (Don't ask why, long story.)
* I have created a group that will contain all users that this will be
applied to.
* I have created the policy and linked it to my custom "all users" OU.
* The policy works perfectly for all users that are connected to the
network when they long on, or that use the "Log on with dial-up networking"
option checked.
* It does not work for any users that simply log on with cached
credentials and then connect via a default Windows VPN connection to the
network no matter how long they stay connected, nor will it work if they try
a gpupdate /force.
* I've run rsop and network monitor and all the other usually
recommended procedures to track down what is happening, and the only problem
we are seeing is that the Outlook restriction policy is being filtered
because the user is not a member of the group.
* I've tested the Kerberos ticket after 10 hours and checked group
membership, and it still appears that the user is not being added to the
appropriate group.
* This, to me, sounds like it is the actual cause of the problem, but
so far Microsoft tech support has not been able to figure out why the group
membership is not changing.
I have read several posts to the list, and also white papers that clearly
state that the policies get refreshed after 90 to 120 minutes, but I am not
seeing this to be true on my network.
So the big questions:
* Does anyone have new policies that they have created after a
computer/user has left the network, and had them get applied without user
intervention?
* Does anyone have Outlook specific policies that are getting applied
to users that are not logging directly into the network?
* Does anyone have any ideas regarding what the problem could possibly
be?
* Has anyone had problems with Kerberos not updating the user ticket
for remote users that connect via a VPN connection?
About my network:
* It is comprised of 2003 SR2 servers.
* It was migrated from a Windows NT 4.0 network a few years ago.
* It is running in 2003 native mode now.
* There do not appear to be any other problems beyond the policies not
being applied to remote users.
* All but three users on the network are running Windows XP SP3
Professional. The exceptions are running Vista Business.
Hopefully I have everything you might ask for answered...
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
_____
Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, retransmission, conversion to hard copy, copying,
circulation or other use of all or any portion of this message and any
attachments is strictly prohibited. If you are not the intended recipient,
please notify the sender immediately by return e-mail, and delete this
message and any attachments from your system.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
Notice of Confidentiality
This transmission contains information that may be confidential. It has been
prepared for the sole and exclusive use of the intended recipient and on the
basis agreed with that person. If you are not the intended recipient of the
message (or authorized to receive it for the intended recipient), you should
notify us immediately; you should delete it from your system and may not
disclose its contents to anyone else.
This e-mail has come to you from Watson Wyatt & Company.
| | | |
| bgregorcy
Posts:1
| | 12/16/2009 2:11 PM |
| Robert Miller wrote:
> Finally got escalated to top level support where I was finally given
> the documentation that should have been given me at the very
> beginning. For those that are interested here is the article:
>
> http://technet.microsoft.com/en-us/library/cc736905%28WS.10%29.aspx
>
> Now to figure out how I'm going to get users to comply...
>
> On Sat, Nov 7, 2009 at 12:54 PM, Robert Miller <xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> Does a logon script run if the user is logging on using cached
> credentials remotely? I didn't think it would.
>
>
> On Sat, Nov 7, 2009 at 12:21 PM, Alan and Margaret Cuthbertson
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> I was suggesting that you run it as a logon script for all
> users so that they don’t get a choice. Basically you are
> writing your own Group Policy filtering process, but reading
> AD rather than the users token to resolve group membership.
>
>
>
>
>
> Alan Cuthbertson
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Sunday, 8 November 2009 5:26 AM
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Sure, if it can do what you think it can, I am completely open
> to anything that I can push out, and that will actually work.
> The primary issue here with scripts and batch files, is that I
> can not count on the users to run anything. It has to be
> something that I can force to run without user interaction.
> That means that I can't email something out to users, or put
> it up on a share for users to access, it has to be automated.
>
> On Fri, Nov 6, 2009 at 11:01 PM, Alan and Margaret Cuthbertson
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
>
>
> How about having a batch file that everyone runs that reads AD
> to see if the current user is a member of the group (as
> against checking the token of the current user) and then do
> whatever you need to do?
>
>
>
> Alternatively could use WMI filtering on the Policy to check
> the membership?. I think this should allow you to code a WMI
> query that checks AD rather than the User’s Token, but I have
> never tried this sort of thing.
>
>
>
> Alan Cuthbertson
>
>
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Saturday, 7 November 2009 8:07 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Don't have anything extra.
>
> On Fri, Nov 6, 2009 at 12:51 PM, Joe Pochedley
> <xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> How about SMS or SCCM or any other type of software
> distribution mechanism that you use to manage the machines?
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 2:25 PM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> I'm running Windows RAS server.
>
> On Fri, Nov 6, 2009 at 10:54 AM, Darren Mar-Elia
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> Sorry, I missed the part about them not wanting it J. That’s a
> different problem. Do you have any ability to run scripts or
> execute commands as a function of folks connecting to your
> VPN? Any kind of NAP in place?
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 10:47 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Again, how would I go about getting them to run it if /they do
> not want the policy applied to them/?
>
> On Fri, Nov 6, 2009 at 10:25 AM, Darren Mar-Elia
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> Well, they would only need to run it once, when they’re
> connected to the VPN. You could simply provide a batch file,
> via email, that did it for them, so they don’t have to learn
> how to open a command prompt, etc. Once they get their
> membership, then the setting would apply during the next
> background refresh.
>
>
>
>
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 10:21 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Not yet, but if it were to work, how would I go about getting
> my remote users to do it if they don't want to have the policy
> applied to them?
>
> On Fri, Nov 6, 2009 at 10:00 AM, Darren Mar-Elia
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> Robert-
>
> Have you tried the klist /purge approach within the context of
> the user? Again, I haven’t been able to test it but it **may**
> work and at least provide a workaround to your issue.
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 9:17 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Yes, I definitely considered that, but the cost of
> administration goes too high for my tastes. The way to reduce
> the cost would be to only add the users that it is not
> applying to, but that would require users to be honest
> regarding whether the policy has applied or not. This is a
> problem because the policy is, understandably, not one that
> people want to have applied to them, so the likelihood of
> getting false positives is high; thus, the requirement that
> the policy be enforcible by IT.
>
> On Fri, Nov 6, 2009 at 9:09 AM, Wornell, Kevin (Dallas)
> <xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> One thing you could do is to add the user objects themselves
> directly to the policy. Not the cleanest or most elegant
> solution but it will work.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 10:30 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> Yes, I have remote users that will not have the policy applied
> as well, so it looks like I'm still up the creek for a
> solution...
>
> On Fri, Nov 6, 2009 at 7:54 AM, Wornell, Kevin (Dallas)
> <xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> I made the assumption that the users you need to NOT apply the
> setting to would be logging in normally. If all your remote
> users need the settings applied, then the scenario I described
> will work since they are already members of Domain Users. If
> there are any remote users that do not need the settings
> applied then you are correct and it will not work.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Friday, November 06, 2009 9:29 AM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> But if a the problem is users not being added to a group,
> won't the same problem still exist? I would have to add the
> users to the "Deny Outlook AutoComplete Disable" group, yes?
> How would those users get added to that group if they are not
> being added to the existing group?
>
> On Fri, Nov 6, 2009 at 6:44 AM, Wornell, Kevin (Dallas)
> <xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> One other thought I had on this is to get a bit more creative.
> The issue is the group membership change. If you can’t get
> the remote users to see the group membership change then let’s
> use a group they are already members of, Domain Users. By
> combining the Domain Users group on the ACL with a group based
> Deny permission on the Delegation we can isolate only those
> users that need to have the policy applied.
>
>
>
> Here are the basic steps.
>
>
>
> Create a new Domain Local security group appropriately named.
> For example ‘Deny Outlook AutoComplete Disable’
>
> Populate this group with those users objects that should NOT
> have the new setting applied.
>
> Create a new group policy named ‘Outlook Auto-Complete
> Disable’, for example
>
> Add the new ‘Deny Outlook AutoComplete Disable’ group via the
> DelegationàAdvanced tab on the Group Policy and check the Deny
> box for ‘Apply Group Policy’
>
> Remove all entries from the Security Filtering on the group
> policy
>
> Configure the settings you want in the policy
>
> Add the Domain Users group to the security filtering on the
> new policy
>
>
>
> The end result is that all Domain Users, except those in the
> ‘Deny Outlook AutoComplete Disable’ group will get the setting
> at the next group policy refresh with no need for a group
> membership change.
>
>
>
> If you have Remote Users who should not have the setting
> applied you will need to be sure and include them in the Deny
> group.
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Thursday, November 05, 2009 7:26 PM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
>
> *Subject:* Re: [gptalk] "By Design"
>
>
>
> So then how do you guys push out a policy for a remote user
> that rarely logs on to the network? That seems like a serious
> flaw to me. Also, why isn't the act of logging in via the VPN
> accepted as a user log in? This makes no rational sense to me
> that it is designed with the idea that users will always log
> in to a network.
>
> On Thu, Nov 5, 2009 at 5:10 PM, Darren Mar-Elia
> <xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>> wrote:
>
> Omar—I have a blog entry up at www.sdmsoftware.com/blog
> <http://www.sdmsoftware.com/blog> that describes how you can
> use klist to refresh computer tickets without rebooting.
>
>
>
> Jamie- you may be right. My assumption about klist is that it
> deals with tickets within the context it runs. That is why you
> need to refresh machine tickets in system context, but you
> should be able to purge per-user tickets by running it in the
> user context. That being said, I am not in a place where I can
> test this – I will try to do that tomorrow if no one else can
> test this today.
>
>
>
> Thanks!
>
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Omar Droubi
> *Sent:* Thursday, November 05, 2009 5:12 PM
>
>
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> in my experience computer group membership is read and startup
> only but I never tried to purge the kerb tickets. user group
> membership is read only at logon from what I know.
>
>
>
> omar
>
> ------------------------------------------------------------------------
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] On Behalf Of Nelson,
> Jamie [xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>]
> *Sent:* Thursday, November 05, 2009 4:07 PM
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* RE: [gptalk] "By Design"
>
> I am pretty sure klist /purge works for the computer object’s
> membership, but I don’t know if it does for a user. I think
> this subject came up on here a while back.
>
>
>
> Actually, on a computer object, I think the membership should
> update automatically (without a reboot) after the Kerberos
> ticket renewal lifetime expires, which by default is 7 days.
> Unfortunately I don’t think this is the case for users.
>
>
>
> As Kevin mentioned, and Darren confirmed, the user’s token
> normally doesn’t get updated until their next logon.
>
>
>
> *Jamie Nelson* | Sr. Administrator | BI&T Infrastructure-Intel
> | *Devon Energy Corporation* | Work: ' 405.552.8054 | Mobile:
> ' 405.248.7963 | http://www.dvn.com <http://www.dvn.com/>
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Darren
> Mar-Elia
> *Sent:* Thursday, November 05, 2009 5:13 PM
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> I think Kevin is correct here. Let me ask you this. In GPMC GP
> Results, it will show what GP thinks the user’s group
> membership are. When you run GP Results against one of these
> machines connected over the VPN, does it show the user as
> being in the group? If not, I wonder what happens if you do a
> klist /purge from one of these machines as the logged on user?
>
>
>
> Darren
>
>
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of
> *Wornell, Kevin (Dallas)
> *Sent:* Thursday, November 05, 2009 1:20 PM
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* RE: [gptalk] "By Design"
>
>
>
> I think the underlying cause may be that Group membership only
> changes at Logon. The users are not actually logging on and
> therefore not picking up the group membership change.
>
>
>
> *Kevin*
>
> *Kevin Wornell*
> *Office Technology Group*
>
> *From:* xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>
> [mailto:xxxxxxxxxxxxxxxx
> <mailto:xxxxxxxxxxxxxxxx>] *On Behalf Of *Robert
> Miller
> *Sent:* Thursday, November 05, 2009 12:43 PM
> *To:* xxxxxxxxxxxxxxxx <mailto:xxxxxxxxxxxxxxxx>
> *Subject:* [gptalk] "By Design"
>
>
>
> I am still working on that issue with my Outlook restriction
> policy not getting applied to remote users. I've been working
> with Microsoft technical support for a couple weeks now, and
> we do not appear to be any closer to an answer, and they are
> starting to toss out the phrase "by design." I find this
> extremely hard to swallow that user policies are not being
> applied "by design," so I am hoping that I can pick your
> brains to see if you have run into this issue.
>
> * I have fifty to seventy-five remote users that travel,
> work from home, or work at customer sites.
> * I need to apply policy changes to these users.
> * Currently I am trying to apply a policy that shuts off
> the autocomplete feature of Outlook. (Don't ask why,
> long story.)
> * I have created a group that will contain all users that
> this will be applied to.
> * I have created the policy and linked it to my custom
> "all users" OU.
> * The policy works perfectly for all users that are
> connected to the network when they long on, or that use
> the "Log on with dial-up networking" option checked.
> * It does not work for any users that simply log on with
> cached credentials and then connect via a default
> Windows VPN connection to the network no matter how long
> they stay connected, nor will it work if they try a
> gpupdate /force.
> * I've run rsop and network monitor and all the other
> usually recommended procedures to track down what is
> happening, and the only problem we are seeing is that
> the Outlook restriction policy is being filtered because
> the user is not a member of the group.
> * I've tested the Kerberos ticket after 10 hours and
> checked group membership, and it still appears that the
> user is not being added to the appropriate group.
>
> o This, to me, sounds like it is the actual cause of
> the problem, but so far Microsoft tech support has
> not been able to figure out why the group
> membership is not changing.
>
> I have read several posts to the list, and also white papers
> that clearly state that the policies get refreshed after 90 to
> 120 minutes, but I am not seeing this to be true on my network.
>
> So the big questions:
>
> * Does anyone have new policies that they have created
> after a computer/user has left the network, and had them
> get applied without user intervention?
> * Does anyone have Outlook specific policies that are
> getting applied to users that are not logging directly
> into the network?
> * Does anyone have any ideas regarding what the problem
> could possibly be?
> * Has anyone had problems with Kerberos not updating the
> user ticket for remote users that connect via a VPN
> connection?
>
> About my network:
>
> * It is comprised of 2003 SR2 servers.
> * It was migrated from a Windows NT 4.0 network a few
> years ago.
> * It is running in 2003 native mode now.
> * There do not appear to be any other problems beyond the
> policies not being applied to remote users.
> * All but three users on the network are running Windows
> XP SP3 Professional. The exceptions are running Vista
> Business.
>
> Hopefully I have everything you might ask for answered...
>
> /Notice of Confidentiality/
>
> This transmission contains information that may be
> confidential. It has been prepared for the sole and exclusive
> use of the intended recipient and on the basis agreed with
> that person. If you are not the intended recipient of the
> message (or authorized to receive it for the intended
> recipient), you should notify us immediately; you should
> delete it from your system and may not disclose its contents
> to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
> *
> ------------------------------------------------------------------------
> *
>
> *Confidentiality Warning:* This message and any attachments
> are intended only for the use of the intended recipient(s),
> are confidential, and may be privileged. If you are not the
> intended recipient, you are hereby notified that any review,
> retransmission, conversion to hard copy, copying, circulation
> or other use of all or any portion of this message and any
> attachments is strictly prohibited. If you are not the
> intended recipient, please notify the sender immediately by
> return e-mail, and delete this message and any attachments
> from your system.
>
>
>
> /Notice of Confidentiality/
>
> This transmission contains information that may be
> confidential. It has been prepared for the sole and exclusive
> use of the intended recipient and on the basis agreed with
> that person. If you are not the intended recipient of the
> message (or authorized to receive it for the intended
> recipient), you should notify us immediately; you should
> delete it from your system and may not disclose its contents
> to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
> /Notice of Confidentiality/
>
> This transmission contains information that may be
> confidential. It has been prepared for the sole and exclusive
> use of the intended recipient and on the basis agreed with
> that person. If you are not the intended recipient of the
> message (or authorized to receive it for the intended
> recipient), you should notify us immediately; you should
> delete it from your system and may not disclose its contents
> to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
> /Notice of Confidentiality/
>
> This transmission contains information that may be
> confidential. It has been prepared for the sole and exclusive
> use of the intended recipient and on the basis agreed with
> that person. If you are not the intended recipient of the
> message (or authorized to receive it for the intended
> recipient), you should notify us immediately; you should
> delete it from your system and may not disclose its contents
> to anyone else.
>
> This e-mail has come to you from Watson Wyatt & Company.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
So I guess I am confused, are you saying that checking that box will not
work for you?
--Brian
| | | |
|
|