We have an OU structure similar to this as well, however in this particular
case we're talking about SUS server GPOs, which ideally should be set according
to a machine's *current* location rather than its 'usual' place of residence.
The issue we're addressing is that of mobile users being in the 'wrong' office
when large updates are approved; the way around this is to determine the local
SUS server by site.
-Z-
________________________________________
From: mcurole@shawinc.com [mailto:mcurole@shawinc.com]
Sent: Thursday, April 28, 2005 2:59 PM
To: focus-ms@securityfocus.com
Cc: Zack Schiel
Subject: RE: Group membership / Kerberos tickets
What is your OU structure like? We have on OU for servers e.g.
ou=server,dc=company,dc=com and an OU for our PC e.g.
ou=workstations,dc=company,dc=com. Then you just link your GPO to the
workstations ou.
Mark
"Laura A. Robinson" <larobins@bellatlantic.net> wrote on 04/28/2005 01:19:40 PM:
1. Yes, you are on the right track; this is [cringe- I hate this phrase]
expected behavior.
2. Have you tried using Kerbtray or another utility to purge the servers'
tickets?
3. If you don't purge the tickets and get new ones, then you're stuck with
either waiting for about a week if you have the default Kerberos settings in
your domain, or you have to reboot the servers.
4. This is the nature of Kerberos; it's not instantaneous in terms of
deny/grant/group population changes.
Laura
-----Original Message-----
From: Zack Schiel [mailto:ZSchiel@blueandco.com]
Sent: Thursday, April 28, 2005 10:52 AM
To: focus-ms@securityfocus.com
Subject: Group membership / Kerberos tickets
I'm hoping that someone here can confirm this for me and
possibly give a deeper explanation for the behavior that we're seeing.
Essentially, we are in the process of creating a series of
site GPOs; the default Authenticated Users permission
remains, and we've also denied Read and Apply Group Policy to
a new group containing certain computers, mainly servers.
The problem that we're running into is that these servers
don't appear in RSoP reports as members of the new security
group (even though they have been for nearly 24 hours now),
and thus they are receiving and applying these GPOs. When
the machines are rebooted, they correctly add the group to
their list of security groups to which they belong, and the
GPOs are denied.
The obvious solution is to reboot the servers before linking
the GPO. We would of course prefer to avoid rebooting dozens
of servers, however.
I believe the reason this happens is that a machine receives
its TGT at startup, and the TGT contains SIDs for groups to
which the machine belongs. This TGT is then simply renewed
every X number of hours for several days, and thus the list
of SIDs isn't updated until the ticket is actually reissued
at restart. Am I on the right track here? Is there a
relatively easy way to force a machine to reissue its TGT
without rebooting or causing other issues?
Aside from our current predicament, this seems to be a bit of
a security hole-machines can actively receive GPOs to which
they have been denied access, long after they are denied that
access.
Thanks,
-Zack-
______________________
Zack Schiel
Network Support
Blue & Co., LLC
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
**********************************************************
Privileged and/or confidential information may be contained in this message. If
you are not the addressee indicated in this message (or are not responsible for
delivery of this message to that person) , you may not copy or deliver this
message to anyone. In such case, you should destroy this message and notify the
sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this
kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other
information in this message that do not relate to the official business of the
company or its subsidiaries.
**********************************************************
---------------------------------------------------------------------------
---------------------------------------------------------------------------
