[gptalk] Re: Group Policy sticks after domain migration
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Tue, 18 Nov 2008 17:55:03 -0800
Actually, I was thinking of both ADM and non-ADM policies. What is not clear
in this original question was whether the machines being moved into domain2
are the same TSs that are mentioned earlier. Also, what is not clear is what
policies are sticking around--and whether they are truly per-user or
per-computer, since Charlie mentions Computer Config, below. Probably need
some more info here.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Alan & Margaret
Sent: Tuesday, November 18, 2008 4:36 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Group Policy sticks after domain migration
Hi Darren,
Fair enough... I haven't looked in to how non-Admin Template policies get
removed. You may well be right that it doesn't have access to the NTuser.pol
file for the non tattooed parts.
Although in this case, I think the problem relates to User based policy, so
removing machine base policies shouldn't make any difference.
Alan Cuthbertson
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Mar-Elia
Sent: Wednesday, 19 November 2008 10:49 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Group Policy sticks after domain migration
Alan-
First off, you need to differentiate between registry policy and other
policy, but let's say you remove a system from the domain or move it into a
different domain. What I have seen is that policy gets left behind from the
old domain, regardless of whether you're talking about registry or other
policy (e.g. security). My guess is that the ntuser.pol file for the
computer is either ignored or invalidated if domain membership changes,
though I haven't tested this to confirm. I do know that, for example,
removing a machine from a domain completely results in these policies being
left behind, even though, presumably, the local GPO is still processing. One
of these days I will look at the code and see what the process does in this
circumstance, but AFAIK, you need to explicitly remove those policies prior
to moving or removing a domain.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Alan & Margaret
Sent: Tuesday, November 18, 2008 3:34 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Group Policy sticks after domain migration
Hi,
If I understand you correctly, what is happening is that the Local Admins
are being locked out, even though neither policy is being applied...
I am not sure what Darren means by "because the new domain knows nothing
about them (and thus doesn't know to remove them)". I thought the only
information about old policies was held in the NTUSER.POL file, so provided
that moved across, old policies (or at least the non tattooed parts of it)
would be removed.
The problem could be that the Default User directory was built by copying
over the NTUser.dat from a user that had the policy applied, but the
NTUSER.pol was not copied. This means that the registry has the non tattooed
entries, but Group Policy doesn't know how to remove them.
Also, wouldn't it be easier to just have one policy, and put ADMINS in the
DENY list?
Alan Cuthbertson
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Mar-Elia
Sent: Wednesday, 19 November 2008 9:45 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Group Policy sticks after domain migration
In addition, in general when you move machines between domains, policies get
stuck from the old domain because the new domain knows nothing about them
(and thus doesn't know to remove them). So, I do recommend that before you
move machines between domains, you move them to a "staging" OU that has no
GPOs applied to it. Let the machines process the lack of policy and then
move into a new domain. Also, you can use my freeware Clean Registry Policy
(www.sdmsoftware.com/freeware) which is designed to clean up registry policy
from computers moved from domains.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Jake (sanfranjake)
Sent: Tuesday, November 18, 2008 2:23 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Group Policy sticks after domain migration
Your big mistake is using Authenticated Users.
At thee verty least with this strategy I'd use a separate security group
so you have at least a way to filter admins out. As admins are
authenticated users, you will keep running into this type of issues,
therefore I'd recommend a separate TSAPP-security group which filters
this policy.
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
On Behalf Of Kaiser, Charlie
Sent: Tuesday, November 18, 2008 10:41 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Group Policy sticks after domain migration
Hi all...
Scenario:
W2K3 native mode AD domain (domain1)
W2K Terminal server locked down with GPO (computer configuration,
administrative templates, Start Menu and taskbar (among many others))
that applies to auth users.
Second GPO that disables all those lockdowns that applies only to domain
admins and enterprise admins.
Works fine. Users get nothing except the app, domain admins get
everything.
Problem:
Domain migration project. Move all member servers to W2K3 native mode AD
domain (domain2).
Now GPOs from domain 1 are still applied. Server admins cannot get into
the box. Login and get locked down desktop. Domain admins in domain2 can
get in fine, but now local admins group needs access.
Gpresult doesn't show the settings being applied. No apparent way to
remove.
Any ideas?
I'm thinking move the box back to domain1, remove GPO and force, verify
access, and then move back to domain2... Any other ideas?
Thanks!
**********************
Charlie Kaiser
W2K3 MCSA/MCSE/Security
Systems Engineer
925 274 3183 desk
925 890 3517 cell
**********************
**********************
Charlie Kaiser
W2K3 MCSA/MCSE/Security
Systems Engineer
925 274 3183 desk
925 890 3517 cell
**********************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR
by logging into the freelists.org Web interface. Archives for the list
are available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
Other related posts:
