AD permissions problem - basic question

  • Thread starter Thread starter Michael A. Covington
  • Start date Start date
M

Michael A. Covington

Greetings,

Windows 2000 server with Windows 2000 and XP clients...

Clients frequently get an event in the log saying that
DC=ab,DC=cd,DC=uga,DC=edu (i.e., ab.cd.uga.edu -- the domain controller --
and that's not its real domain address) cannot be accessed because access
appears to have been denied, and Group Policy processing has therefore been
aborted.

(Sorry, I don't have the event numbers right now; will post them when I get
to the office later in the day.)

In spite of this, the clients can log in and use their roaming profiles.
But Group Policies from the domain controller are apparently not applied.

This sounds like a very simple permission needing to be changed. Is it, and
how do I do it?

Thanks!
 
Michael A. Covington said:
Greetings,

Windows 2000 server with Windows 2000 and XP clients...

Clients frequently get an event in the log saying that
DC=ab,DC=cd,DC=uga,DC=edu (i.e., ab.cd.uga.edu -- the domain controller --
and that's not its real domain address) cannot be accessed because access
appears to have been denied, and Group Policy processing has therefore been
aborted.

(Sorry, I don't have the event numbers right now; will post them when I get
to the office later in the day.)

In spite of this, the clients can log in and use their roaming profiles.
But Group Policies from the domain controller are apparently not applied.

This sounds like a very simple permission needing to be changed. Is it, and
how do I do it?

Thanks!

I should add that the clients are using the domain controller for DNS and
are getting good service.

And that "nslookup ab.cd.uga.edu" gets the IP address of the domain
controller. They're apparently not having any trouble identifying the
machine, just reading from it.
 
check, that your clients can access \\ab.cd.uga.edu\sysvol folder on your
DC. This is how GPO's are located and read. If you can not read them, then
you may have problem with your DFS client on with FDS on the server. Post
EventID from your event log when you can.

--
Regards

Matjaz Ladava, MCSE (NT4 & 2000), MVP
(e-mail address removed)
http://ladava.com
 
More details on what I'm getting:

Event 1101: "Windows cannot access the object DC=ab,DC=cd,DC=uga,DC=edu in
Active Directory. The access to the object may be denied."

Event 1030: "Windows cannot query for the list of Group Policy objects.
Access to the object may be denied."

I'm assuming this is a simple setting on the server that need to be
tweaked... ?
 
Check the permissions on %systemroot%\sysvol\sysvol folders on your DC.

--
Regards

Matjaz Ladava, MCSE (NT4 & 2000), MVP
(e-mail address removed)
http://ladava.com
 
Matjaz Ladava said:
Check the permissions on %systemroot%\sysvol\sysvol folders on your DC.

OK, what should they be?


Here are my results so far: From a roaming account,

dir \\ab.cd.uga.edu\sysvol is OK (lists ., .., and a "junction")

dir \\ab.cd.uga.edu\sysvol\ab.cd.uga.edu is OK

dir \\ab.cd.uga.edu\sysvol\ab.cd.uga.edu\Policies is denied

dir \\ab.cd.uga.edu\sysvol\ab.cd.uga.edu\scripts is denied

The latter two are denied to some accounts but not others.


I think you're hot on its trail. All I need to know now is the correct
permissions to set. Thanks!
 
It would be great if you could post your current security settings from
those two folders, but they should have identical rights so:
Administrators - Full
Authenticated Users - Read & Execute, List, Read
CREATOR OWNER - Full
Group Policy Creator Owner - Read & Execute, List, Read, Write
Server Operators - Read & Execute, List, Read
SYSTEM - Full

Try and let me know.

--
Regards

Matjaz Ladava, MCSE (NT4 & 2000), MVP
(e-mail address removed)
http://ladava.com
 
--
Michael A. Covington, Associate Director
Artificial Intelligence Center / The University of Georgia / Athens, GA
30602-7415 U.S.A.
http://www.ai.uga.edu/~mc http://www.CovingtonInnovations.com <><
Matjaz Ladava said:
It would be great if you could post your current security settings from
those two folders, but they should have identical rights so:
Administrators - Full
Authenticated Users - Read & Execute, List, Read
CREATOR OWNER - Full
Group Policy Creator Owner - Read & Execute, List, Read, Write
Server Operators - Read & Execute, List, Read
SYSTEM - Full

Try and let me know.

OK, for Policies:
Administrators - Full
- Right.
Authenticated Users - Read & Execute, List, Read
- Right.
CREATOR OWNER - Full
- Had no permissions. I've set them to Full. Should this make any
difference?
Group Policy Creator Owner - Read & Execute, List, Read, Write
- And Modify.
Server Operators - Read & Execute, List, Read
- Right.
SYSTEM - Full
- Right.


And for Scripts:
Administrators - Full
- Right. (Inherited.)
Authenticated Users - Read & Execute, List, Read
- Right. (Inherited.)
CREATOR OWNER - Full
- None. I set it to Full.
Group Policy Creator Owner - Read & Execute, List, Read, Write
- Was not on the list at all.
I've added it with the permissions you specified.
Server Operators - Read & Execute, List, Read
- Right. (Inherited.)
SYSTEM - Full
- Right. (Inherited.)


I'll report shortly as to whether this made any difference.
 
I am happy to report that our long-standing (9-month or longer) problem with
Group Policies not getting applied has been SOLVED.

(I do not yet know if this affects the other problems I have been discussing
with some of you.)

Since this is not in the Microsoft Knowledge Base, I'll explain it here.


In Default Domain Policy, the User policies weren't working but the Computer
policies were.

And in the log on the client machines, we were getting:

Event 1101 - Windows cannot access the object DC=foo,DC=bar,DC=uga,DC=edu in
Active Directory. [That's not the real domain address, of course.] The
access to the object may be denied.

Event 1030 - Windows cannot query for the list of Group Policy objects.



Cutting to the chase: the SYSVOL share (%SYSTEMROOT%/sysvol/sysvol) must be
readable by "Everyone." A while back I had abolished all the "Everyone"
permissions on drive C. This one shouldn't have gone, because client
machines have to read it *before* they authenticate themselves.


Thanks to all who helped (or can supply a deeper or more satisfying
explanation), especially Matjaz Ladava in
microsoft.public.windows.server.active_directory.


(Microsoft, how about putting this in the Knowledge Base?)
 
Back
Top