|
Posted by Steven L Umbach on November 15, 2005, 2:38 pm
Please log in for more thread options
Glad to hear you got it working and thanks for explaining what happened. The
link below is the only one I know of how to interpret the info in the
userenv.log and is good to have for future Group Policy troubleshooting. It
is interesting that removing everyone caused that problem since domain
computers are supposed to be member of authenticated users also which you
should see when you run gpresult on a domain computer. --- Steve
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/ccd7b430-99a5-40fd-b68a-6c1979e565a2.mspx
> Okay, I found the problem and fixed it.
>
> The original domain controller settings are for ByPass Traverse Checking
> in
> group policy to allow all of the following entities:
>
> Authenticated Users
> Everyone
> Administrators
>
> I really hate Everyone in any permission, and I always try to think
> through
> what groups need access to something and restrict access to just those
> more
> specific entities.
>
> In this case I had removed Everyone and failed to realize that the domain
> controller would see GPO updates from each client as being in the security
> context of the computer, not a specific user. So I added the Domain
> Computers group, and instantly GPO updates work again.
>
> That's what I get for being just knowledgeable enough to hang myself. :)
> Unfortunately, permissions on Everyone is one of the many roads to getting
> hacked, and I just would rather punish myself in the short-term by being
> forced to think things through than end up with surprises at unexpected
> times later.
>
> --
> Will
>
>
>> Is there anything in the userenv.log that would indicate a problem
>> finding
>> or accessing a domain controller, sysvol share, folder path or otherwise
>> indicate GP processing is not working right? If you change a setting in
> GP
>> does the change show for the computer/user once the GP settings have
>> refreshed? Any problems shown in netdiag output from the domain client or
>> domain controller used as shown in the gpresult report? --- Steve
>>
>>
>> >I see errors in the Application Log with details:
>> >
>> > Event ID 1000: The Group Policy client-side extension Security was
>> > passed flags (17) and returned a failure status code of (3).
>> >
>> > gpresult reports no errors, but it's quite clear looking at the output
> for
>> > computers that it is not grabbing most of the group policy.
>> >
>> > --
>> > Will
>> >
>> >
>> >> I have never actually tried to audit that directory but are those
> client
>> >> computers failing to have Group Policy applied to them which among
> other
>> >> things would be evidenced by errors/warnings for userenv in the
>> > application
>> >> log and errors when running gpresult?? You also might want to enable
>> >> debug
>> >> logging of userenv to see what is going on with GP processing by
> looking
>> > at
>> >> the userenv.log file. --- Steve
>> >>
>> >>
>> >> > I'm getting an EventID 560 from machines on our network trying to
>> >> > access
>> >> > SYSVOL, and in examining the detail of the message I'm confused by
> what
>> > is
>> >> > happening. On our domain controller, the sysvol *share* is
>> >> > located
>> >> > at
>> >> > %SYSTEMROOT%\sysvol\sysvol. I've never understood why there is a
>> > sysvol
>> >> > share under the directory named sysvol. Maybe someone can explain
>> >> > that
>> >> > one
>> >> > to me as well.
>> >> >
>> >> > What I am seeing in the security section of eventviewer is that
>> >> > machines
>> >> > are
>> >> > trying to apply group policy by directory accessing the
>> >> > %SYSTEMROOT%\sysvol
>> >> > directory and NOT using the sysvol share. A typical event 560
>> >> > error
>> >> > is
>> >> > as
>> >> > follows:
>> >> >
>> >> > Object Open:
>> >> > Object Server: Security
>> >> > Object Type: File
>> >> > Object Name:
>> >> >
>> >
> \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume2\WINNT\SYSVOL\DOMAIN
>> >> > \POLICIES\\MACHINE\MICROSOFT\WINDOWS
>> >> > NT\SECEDIT\GPTTMPL.INF
>> >> > New Handle ID: -
>> >> > Operation ID:
>> >> > Process ID: 8
>> >> > Primary User Name: DOMAIN-CONTROLLERA$
>> >> > Primary Domain: CORPORATE
>> >> > Primary Logon ID: (0x0,0x3E7)
>> >> > Client User Name: CLIENT-WORKSTATIONC$
>> >> > Client Domain: CORPORATE
>> >> > Client Logon ID: (0x0,0x55B231A)
>> >> > Accesses READ_CONTROL
>> >> > ReadData (or ListDirectory)
>> >> > ReadEA
>> >> > ReadAttributes
>> >> >
>> >> > Privileges -
>> >> >
>> >> >
>> >> > I'm confused by a number of things here:
>> >> >
>> >> > 1) Why are machines attempting to apply group policy through a
> location
>> >> > that
>> >> > does not travel through the SYSVOL share?
>> >> >
>> >> > 2) Even once I explicitly give Read and Read & Execute permission to
>> >> > all
>> >> > Domain Users and Domain Computers to access the specific path they
> are
>> >> > traversing, I still get the event id 560.
>> >> >
>> >> > Any help understanding this is appreciated.
>> >> >
>> >> > --
>> >> > Will
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
| 
XML Sitemap