[massimo_m]

Hello everyone

I have a question. I've just discovered a pretty strange behaviour in my Active Directory Forest. Domain Administrator for child domain can create and delete connection object for their domain controllers. Looking in DACLS for connection object you can see that "CHILD-DOMAIN\Domain Admins" has full control. So, he/she can easily remove Enterprise Admins from ACL. I think this is a very bad issue. First of all because I have deployed the whole infrastructure, I have disabled KCC from generating Site Connection Objects and I have manually created every single connection object for all domain controllers (well, i wanted to have the maximum control possible over replication topology). Also I wanted to control replication bandwitdth over WAN. I find this issue unacceptable because every single domain admin in its own domain can easily delete my connection objects; for example he can create as many connection objects as he wants without any kind of control.

Does anyone know if I can avoid this issue?

Bye
Max

PS: another good point is that CHILD\Domain Admins can remove Enterprise Admins from DACLs for the connection object and we found NO WAY for Enterprise Admins to restore DACLS !!!!!

PPS: same issue for NTDS Settings Object !!!!!!!!!!!!!

[wkasdo]

That is an interesting observation. I'm not sure you should worry about it though. A Domain Admin can do anything he likes to his box anyway. Also, you need to trust Domain Admins in any domain. Don't fool yourself; any DA can take over the forest with a little bit of know-how.

PS: another good point is that CHILD\Domain Admins can remove Enterprise Admins from DACLs for the connection object and we found NO WAY for Enterprise Admins to restore DACLS !!!!!

You can take ownership as Enterprise Admin, and do your thing! Or am I missing something here?

I wonder why you go to these extremes to control replication, though. What's wrong with sitelinks? If your network is not fully routable, you can always disable transitivity, right? Seems to me that you loose a lot of flexibility and create extra work by doing it all yourself.

[massimo_m]

Originally Posted by wkasdo

That is an interesting observation. I'm not sure you should worry about it though. A Domain Admin can do anything he likes to his box anyway. Also, you need to trust Domain Admins in any domain. Don't fool yourself; any DA can take over the forest with a little bit of know-how.

Sure... only if he can access phisically a root dc

Originally Posted by wkasdo

You can take ownership as Enterprise Admin, and do your thing! Or am I missing something here?

Yes... you are missing something. Have you ever tried it? There's no way for EA to restore permissions nor taking ownership!! That's why I'm really suprised and upset!

Originally Posted by wkasdo

I wonder why you go to these extremes to control replication, though. What's wrong with sitelinks?

Well, working with a forest with 1 root domain and 19 child domains, spread across hundreds of sites, often requires you to make a little more work by manually configuring connectors.
Many huge enterprises disable KCC from working to avoid creation of undesired connections between DCs. I have a particular network topology so I prefere manual working.
The point is another. How comes a DA has power to decide the use of MY bandwith (of course he can create as many connector as he wants and setting them to replicate every 15 minutes). Also how comes he can remove permissions in very important objects like "NTDS Settings" in a way that EA cannot restore them! He will fill the Configuration Partition structure with garbage and the only way to clean it up is removing that domain from AD Forest with ntdsutil, purging the orphaned domain and reacreating it!

[wkasdo]

Hi Massimo,

> Sure... only if he can access phisically a root dc

Sorry, no. There are simple and complicated hacks out there that will accomplish EA access from any DC in the forest. Plan for that if that is important to you.

> Yes... you are missing something. Have you ever tried it

yes, I tried it before posting, and it worked. I admit that I did not try every permutation of permissions, so maybe there's something there. In my understanding, it is a fundamental right of an admin to take ownership. There is something funny going on if it fails. Perhaps it is something in the GUI?

> spread across hundreds of sites

Ok, that makes sense then. Few people run networks that large, so I thought I'd ask.

He will fill the Configuration Partition structure with garbage and the only way to clean it up is removing that domain from AD Forest with ntdsutil, purging the orphaned domain and reacreating it!

I'm not fully convinced. I'll see if I can reproduce it to the point where I cannot take ownership and take it from there. Any hints on how to set the permissions?

And by the way, I'm talking W2003 here. You?

[massimo_m]

Hi wkasdo

>Sorry, no. There are simple and complicated hacks out there that will
> accomplish EA access from any DC in the forest. Plan for that if that is >important to you.

Well, I do know a procedure for this kind of hack. It only works if I have phisical access to any domain controller of the root domain. If I have access from child domain, and I'm just a Domain Admin for this child domain, and I have physical access to a DC from child domain, I've never heard about a way to gain EA access.

>yes, I tried it before posting, and it worked.

You mean that using EA access you where able to restore DACLS for NTDS Settings Object?

Well, I'll explain in details the procedure I followed:
Two domains for this test: PARENT-DOMAIN (called PARENT) with PARENTDC1 & CHILD-DOMAIN (called CHILD) with CHILDDC1.
Logged on to CHILDDC1 as CHILD\Administrator. Open ADSS / Sites / DFSN / Servers / CHILDDC1 / , right click on NTDS Settings / Properties, selected SECURITY, removed any ACE except CHILD\Domain Admins (which had Full Control rights). Wait for replication to occours.

Then, logged on to PARENTDC1 as PARENT\Administrator. Tried to access to ADDS / Sites / DFSN / Servers / CHILDDC1 / NTDS Settings. Received error "Unable to open Object".
Tried to right click on NTDS Settings / Properties. Immediately received error "Unable to get object name" or something like that, and I was unable to open ACL to change owner of object. Unfortunately I cannot write down the exact error because I removed domain with ntdsutil. I'll try again asap

I got the same error using ADSI Editor (actually I have not tried using ntdsutls)

>And by the way, I'm talking W2003 here. You?

Of course

[guyt]

You might want to take a look at the following thread:
http://www.petri.co.il/forums/viewtopic.php?t=3111

[massimo_m]

Hi Guyt

Already seen that thread, but I think that
1) usingo Run value in registry, also require that EA logs to a machine controlled by DA (in the same way, DA can installa a KeyLogger in his machine and wait for EA to login, in order to capture EA credentials), so I don't consider that a valuable hack.

2) at the moment there are no exposed API that allow filling the sIDHistory attribute with a SID from the same forest; for example: I am administrator for a CHILD domain, I can copy objectSID attribute from ROOT\Administrator to my CHILD\useraccount sIDHistory attribute. This way my token has SID with EA credentials. At the moment this kind of hack seems to be unavailable (btw... I found no way to bring this out... if you have an idea, I'm happy to listen to )

[wkasdo]

Hi Massimo,

I'll experiment a bit more with the NTDS settings tonight.

W.r.t. the hack: there is a hack out there that allows anyone with physical access on any DC in the forest to inject the EA Sid. I'm not going to post the link in public, as I'm sure you'll understand.

Also, on W2000 there is a very simple hack to allow anyone with admin access to any DC in the forest to elevate themselves to SYSTEM, which is even worse then EA in most cases. On w2003 it is more complicated, but I've heard of people doing it. I'll see if I can dig that out again.

Bottom line: any DA, and anyone with physical access to the DC should be considered masters of the forest. Check with MS if you like. The security boundary is the forest, not the domain.

[massimo_m]

Hi wkasdo

I've tried again with NTDS Settings, using test environment, but this time I was able to restore EA permissions via ADDS.... don't know why i wasn't able to do it 2 days ago...

>W.r.t. the hack: there is a hack out there that allows anyone with physical
>access on any DC in the forest to inject the EA Sid. I'm not going to post
>the link in public, as I'm sure you'll understand.

Of course I do. BTW if you want to write in private, I'm here!
In other case, I'll try to find it out by myself....at least I'll enjoy searching ehehe

>Also, on W2000 there is a very simple hack to allow anyone with admin
>access to any DC in the forest to elevate themselves to SYSTEM, which is
>even worse then EA in most cases. On w2003 it is more complicated, but
>I've heard of people doing it. I'll see if I can dig that out again.

I know 2000 hack about this. On w2003 I haven't seen anything yet.

>Bottom line: any DA, and anyone with physical access to the DC should
>be considered masters of the forest. Check with MS if you like. The
>security boundary is the forest, not the domain.

This is becoming a phylosophical discussion (and I like it ). There shouldn't be any difference between EA and DA if physical access is so unsecure.
MS in every book, every white paper and every article posted before w2003 release, always stated that DOMAINS are security boundary. Only with w2003 they realize that DOMAINS in forest are not as secure as they stated before, so the warning is now that FORESTS are security boundary. This way any DA in a forest should be TRUSTED at the maximum level and when you work in a large enterprise with many business units, where this kind of trust is not always possible, there can be problems with security.

In large enterprises, DA for every single country is not always a EXTREMELY-TRUSTED person, so security boundary becomes importants.

[wkasdo]

> In large enterprises, DA for every single country is not always a EXTREMELY-TRUSTED person, so security boundary becomes importants.

Oh yes. MS made a big design mistake with this one. It would be extremely nice if the domain was a true security boundary, such that you could nail it shut as much as needed. And all that because they wanted to make migration a little bit easier (sidhistory). I guess that hindsight is always 20/20.