A Real Access Control Poser (one of the strangest things I've ever seen).

A Real Poser (one of the strangest things I've ever seen).

Background. The enterprise network comprises a primary domain with serveral
children. The primary domain contains Administrators and several small
groups of executives, but that is all. It is prudent to note that
reorganization sometime ago placed these executives in their respective
child domains. whose credidentials have been and continue to be used. The
enterprise DFS environment encompasses almost every shared resource top to
bottom. Profile in Group Policy point to the DFS coordinates for the
respective children, with the exception of the primary, which points to
their parent. Sometime recently, a bit-fart occured and produced something
rather bizarre. We cannot reproduce this problem in our test environment
yet, and at this point are are having one hell of a problem resolving it. It
is notable that we can reproduce the situation, however (which creates the
problem), yet cannot solve it in Production. We have enjoyed practically
perfect operational performance for as long as anyone can remember, and as
far as security goes, is has been perfect, until what was discovered early
this morning, which is access being denied to parent profiles, even those in
the BUILTIN groups who enjoy their proper prominence everywhere else except
their profiles and desktops. So much for getting ready for the Server 2003
migration, which logging on to attempt revealed the Application Popup
informing the Administrator of the Access Denied situation reported by one
of the executives who aatempted to log-on at the same level, and whose
profile was kept there, like the Administrators is. It is also worth noting
that we can see the Administrator.pds object there.

A CACLS of the parent of the areas in question shows that only ©reate
privileges are granted all of the appropriate groups within only one of the
child subdomains. Access is denied to all of the children, amd as far as we
can tell, it is as if that all permissions have been removed, as we connect
enumerate anything beneath the parent branch to the parent profiles and
related folders on the same level. This includes those users and groups
granted the ActAsOperatingSystem right in group policy. What is even more
interesting is that despite having the CREATE privilege, users so endowed
cannot create anything in this folder. Equally puizzling is the fact that
even the OWNER cannot reset and propogate permissions beneath this rather
bolixed branch. A review of replication logs does not reveal the change, nor
from where it replicated to everywhere else. The only event of a relative
siginificance was a power surge many months ago, impacting a small group of
Domain Controllers being transferred to the newly installed UPS grid.

Logical conjugation indicates that the fix is taking ownership so that
repairs can be effected on this folders 'leaf' nodes, however we have been
unanable too accomplish this. The few restores that we have attempted
appears to be restoring (affirming) the defective permissions, or being
refused to.

Question: Will taking this PDC offline, accessing the recovery console, and
reseting the permissions work; e.g. Cause the proper permissions to be
written across the network (eg. all replicas)? We have considered finding
the GPO and deleting that, but fear making things worse and not having
enough time to fix them. We would normally consider leaving this sleeping
dog lie, however are unable to given other circumstances requiring access to
objects a key person is being refused at this time. Back when my hair had
color, and was still on my head, I would have ventured DISKPROBE (or a MASM
prog) but don't feel we are at that point yet.

Any ideas?

 

Post here instead:



Windminstrel-2000 wrote:<!--coloro:blue--><span style="color:blue <!--/coloro-->
> A Real Poser (one of the strangest things I've ever seen).
>
> Background. The enterprise network comprises a primary domain with
> serveral
> children. The primary domain contains Administrators and several small
> groups of executives, but that is all. It is prudent to note that
> reorganization sometime ago placed these executives in their respective
> child domains. whose credidentials have been and continue to be used. The
> enterprise DFS environment encompasses almost every shared resource top to
> bottom. Profile in Group Policy point to the DFS coordinates for the
> respective children, with the exception of the primary, which points to
> their parent. Sometime recently, a bit-fart occured and produced something
> rather bizarre. We cannot reproduce this problem in our test environment
> yet, and at this point are are having one hell of a problem resolving it.
> It
> is notable that we can reproduce the situation, however (which creates the
> problem), yet cannot solve it in Production. We have enjoyed practically
> perfect operational performance for as long as anyone can remember, and as
> far as security goes, is has been perfect, until what was discovered early
> this morning, which is access being denied to parent profiles, even those
> in
> the BUILTIN groups who enjoy their proper prominence everywhere else
> except
> their profiles and desktops. So much for getting ready for the Server 2003
> migration, which logging on to attempt revealed the Application Popup
> informing the Administrator of the Access Denied situation reported by one
> of the executives who aatempted to log-on at the same level, and whose
> profile was kept there, like the Administrators is. It is also worth
> noting
> that we can see the Administrator.pds object there.
>
> A CACLS of the parent of the areas in question shows that only ©reate
> privileges are granted all of the appropriate groups within only one of
> the
> child subdomains. Access is denied to all of the children, amd as far as
> we
> can tell, it is as if that all permissions have been removed, as we
> connect
> enumerate anything beneath the parent branch to the parent profiles and
> related folders on the same level. This includes those users and groups
> granted the ActAsOperatingSystem right in group policy. What is even more
> interesting is that despite having the CREATE privilege, users so endowed
> cannot create anything in this folder. Equally puizzling is the fact that
> even the OWNER cannot reset and propogate permissions beneath this rather
> bolixed branch. A review of replication logs does not reveal the change,
> nor
> from where it replicated to everywhere else. The only event of a relative
> siginificance was a power surge many months ago, impacting a small group
> of
> Domain Controllers being transferred to the newly installed UPS grid.
>
> Logical conjugation indicates that the fix is taking ownership so that
> repairs can be effected on this folders 'leaf' nodes, however we have been
> unanable too accomplish this. The few restores that we have attempted
> appears to be restoring (affirming) the defective permissions, or being
> refused to.
>
> Question: Will taking this PDC offline, accessing the recovery console,
> and
> reseting the permissions work; e.g. Cause the proper permissions to be
> written across the network (eg. all replicas)? We have considered finding
> the GPO and deleting that, but fear making things worse and not having
> enough time to fix them. We would normally consider leaving this sleeping
> dog lie, however are unable to given other circumstances requiring access
> to
> objects a key person is being refused at this time. Back when my hair had
> color, and was still on my head, I would have ventured DISKPROBE (or a
> MASM
> prog) but don't feel we are at that point yet.
>
> Any ideas? <!--colorc--><!--/colorc-->