Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

RE: Group membership / Kerberos tickets

Subject: RE: Group membership / Kerberos tickets
Date: Thu, 28 Apr 2005 13:19:40 -0400
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 



--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------



---------------------------------------------------------------------------
---------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>