Re: Group membership / Kerberos tickets
From: Miroslaw Slawek Chorazy (mchorazy_at_depaul.edu)
Date: 04/28/05
- Previous message: Laura A. Robinson: "RE: Group membership / Kerberos tickets"
- Maybe in reply to: Zack Schiel: "Group membership / Kerberos tickets"
- Next in thread: Zack Schiel: "RE: Group membership / Kerberos tickets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 28 Apr 2005 10:49:00 -0500 To: <ZSchiel@blueandco.com>, <focus-ms@securityfocus.com>
YOu could also be experiencing additional reasons for the denials;
For instance, you have too prohibitive IPSec policies in place and the
Servers are denied access to DCs because they can't establish IPSec with
DCs.
To troubleshoot this further, I would simply establish a mapping to DCs
using the \\dc_name\ipc$ and would run ping in the background to the
same DC. When its time for the policies to re-apply, the server should
not try to renew the Kerberos ticket.
On the Servers, I would also try to execute and learn from the
following commands as to why they don't apply policies:
gpupdate.exe /target:computer /enforce
gpresult.exe /SCOPE computer /V
enable debugging flags for winlogon.log on DCs and Servers
slawek
>>> "Zack Schiel" <ZSchiel@blueandco.com> 4/28/2005 09:51 >>>
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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
- Previous message: Laura A. Robinson: "RE: Group membership / Kerberos tickets"
- Maybe in reply to: Zack Schiel: "Group membership / Kerberos tickets"
- Next in thread: Zack Schiel: "RE: Group membership / Kerberos tickets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
