RE: Group membership / Kerberos tickets
From: Laura A. Robinson (larobins_at_bellatlantic.net)
Date: 04/29/05
- Previous message: Marc Fossi: "SecurityFocus Microsoft Newsletter #238"
- In reply to: Zack Schiel: "RE: 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 19:51:23 -0400 To: "'Zack Schiel'" <ZSchiel@blueandco.com>, <focus-ms@securityfocus.com>
The problem here isn't one of OU structures- it's one of construction of
access tokens, when that is occurring, and which group SIDs are made part of
the access tokens/Kerberos PAC information. The quickest/dirtiest solution
is, as Zack found, to reboot the servers as this purges all of their tickets
and they obtain new ones at startup. Remember the old "you have to log off
and log back on to get new group memberships" axiom with Windows? That
really hasn't changed, with some specific exceptions that aren't relevant to
this situation (cross-domain resource access for the first time, etc.). The
problem Zack is experiencing is that because the existing Kerberos tickets
are simply being renewed rather than regenerated, the new group SIDs are not
being passed in the PAC information passed via Kerberos. The only way for
the servers' group memberships to be updated is to force reissuance of PAC
information (SIDs).
If Zack can purge the servers' tickets without rebooting, then the servers
would have to get new tickets and would generate new access tokens/obtain
new TGTs, etc. I imagine this could be scripted through WMI, but to be
honest, I've not dug around to determine this with certainty.
Laura
> -----Original Message-----
> From: Zack Schiel [mailto:ZSchiel@blueandco.com]
> Sent: Thursday, April 28, 2005 4:23 PM
> To: focus-ms@securityfocus.com
> Subject: RE: Group membership / Kerberos tickets
>
>
> 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.
> **********************************************************
>
>
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------
>
---------------------------------------------------------------------------
---------------------------------------------------------------------------
- Previous message: Marc Fossi: "SecurityFocus Microsoft Newsletter #238"
- In reply to: Zack Schiel: "RE: Group membership / Kerberos tickets"
- Next in thread: Zack Schiel: "RE: Group membership / Kerberos tickets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
