(2006-12-28) Granting Admin Level Access For The OS On DCs But Not For AD

Yesterday and today I (and some other people) were involved in heavy discussion how you can accomplish:

• Granting Admin level access for the OS on DCs but not within AD

The posts can be found in:

• NG: "microsoft.public.windows.server.active_directory"
• Post subject: "Grant Administrative Access to a Domain Controller"

The original poster had the following requirements, which were summarized by me:

1. Allowing a group of one or more persons to install software on a DC
2. Allowing a group of one or more persons to restart services on a DC
3. NOT allowing a group of one or more persons to be domain admin
4. NOT allowing a group of one or more persons to change ANYTHING in AD in ANY way…

The short answer, talking ALL requirements into account: YOU CANNOT!!!

Delegating to see services configuration and to stop/start services is possible, but the other three without impacting the security of the other DCs in the AD forest and the directory itself is NOT possible.

Some other posters provided steps (after I asked) how they would accomplish such a thing. After the steps were posted I provided an explanation for the "how" and the "why or why not". Below you can see a copy of the posts. The steps were provided in brown and my answers in green.

——————————————————————————————————-

see inline….. for my answer see the "[JdAP:]" mark
> Ok here you go step by step on how to do this:
>
> (you are doing all of this while logged in as an Domain Admin)
>
> 1. Create an account (or elevate an existing one) and allow them full
> access to AD from the top of the domain in the mmc console users and
> computers. (this is the backup account you will need to reset perms
> back to the way they were and make sure they have admin rights on all
> abjects you want to manage within AD)
>

[JdAP:] In this I would prefer a group instead of a single user account

> 2. At the top level of the domain, change the ownership of the domain
> from Domain Admins to your Elevated account.  (this is done so not to
> lock yourself out)
>

[JdAP:] IMO, now here you are forgetting on thing… You are talking about
the domain only. Remember that each and every DC has multiple writable
naming contexts (partitions) like the configuration and schema partition.
Thinking about W2K3 DCs might also have application partitions. So all these
steps would need to be done for EVERY partition. As you can read below, and
I explain why/how, the procedure does not prevent changing stuff in AD.

> 3.  Deny permissions at the top for domain admins as well as Enterprise
> admin groups, then hit apply, and ok.  You will get a warning about
> deny perms.  click ok, and close the properties box.
>

[JdAP:] Again, you are forgetting one thing… You are setting permissions
at top level which means for lower level permissions are inherited. Remember
that objects ALSO have explicit defined permissions. And explicit ALLOW
permissions have precedence over implicit DENY permissions. You would need
to change each and every permission. You are talking about ADUC, but there
are multiple ways to "view" AD. Think about LDP or even ADSIEDIT.MSC or even
just using scripts to target some object within the directory. Although you
cannot see things in ADUC, it DOES NOT mean you cannot do it in another way.
Entering the DN of some lower level OU shows you lower level objects and
with the explicit permissions you can still "have fun"…
Also, you did not mention the domain administrators group (not Domain
Admins). Those also have a crap load of permissions all over the place in
AD. And even if you would, it would be no good as well (think "explicit
permissions")
Although those "Domain Admins" would not be able to do anything in AD as you
mention (which I do not agree), they would still be able to do ANYTHING on
ANY member server (Domain Admins is a member of local administrators)

> 4. Now you are denied access to AD, however you are still allowed to
> perform administrative tasks to the DC.
>

[JdAP:] As mentioned earlier…. think about other NCs and explicit defined
permissions

>>From here if you try to open the mmc console while logged in as the
> admin you will get denied access.
>
> I know the next comment will be that the refresh of the AdminSDHolder
> will take place and the permissions will be reset.  this is true for
> the objects inside of AD, not AD itself.

[JdAP:] I do not understand "this is true for the objects inside of AD, not
AD itself"
Objects protected by the AdminSDHolder only have explicit defined
permissions which are the same as the AdminSDHolder object itself. So, the
change mentioned (DENY and ownership change) will not have any effect on the
by the AdminSDHolder protected objects

> The part that has been denied
> access is the outside outer or beginning part of AD.  If you can’t get
> past this you can not get in.  This part is not reset because it is not
> affected by the AdminSDHolder refresh.  You can also disable the
> AdminSDHolder for the "sacred" accounts if you like as well.

[JdAP:] Now that (changing the AdminSDHolder) is something I do not
recommend as you do not gain anything from it. Leave the default as is. Do
not use default builtin groups, other than Domain Admins and Administrators.
Delegate stuff as stuff should be delegated!

>
> Here is the error you will get for trying to access AD through the MMC
> :
>
> " Naming information cannot be located because:
> the specified directory service attribute or value does not exist.
> Contact you current admin to verify that AD is correctly configured and
> online."
>
> then:
>
> "The directory schema is not accessible because:
> An invalid directory pathname was passed,
> for this reason, the new menu may be inaccurate, and extension snap-ins
> may not work properly."
>
> and then:
>
> Data from AD users and computers is not available from domain
> controller (null) because:
> unspecified error
> try again later, or choose another domain controller by selecting
> connect to domain controller on the domain context menu."
>
> the beauty of this is you can logon to the DC as an admin and still
> perform admin tasks because you are still allowed in the dc policy, but
> you cannot manipulate AD.

[JdAP:] Sorry, I again do not agree. There is nothing beautiful about this,
because with the steps mentioned, you changed things that should not be
changed because you will not gain anything from it. Try it yourself. Start
LDP, target some lower level OU’s distinguished name instead of the domain
and you would still be able to delete/create accounts, OUs, or whatever
object in AD. The fun part is the guy you want to keep out, can make YOUR
life a living hell by changing other things and lock you out. Even he wants
to and knows how, he would even be able to revert everythi
ng back to the
original situation.
Wanna know how? Login, start LDP, start the DN of the Domain Admins group,
remove his membership, logoff, logon, do whatever you want! (he is now only
member of domain administrators, not domain admins, and again has full
access to do whatever he wants)
I imagine you would say: "OK, I’ll remove him from enterprise admins, domain
admins and administrators, and adjust the security policies and permissions
on the system so he can do (1) and (2)". Again, no go. READ CAREFULLY:
Although he would not be able to do it DIRECTLY, it would still be possible
to do it INDIRECTLY. I imagine it sounds strange, but trust me (if you want)
"INDIRECTLY" has a special maning which I’m not going to explain here.

>
> If you logoff and login as the admin you still authenticate even though
> you can’t access AD (this is by design).
>

[JdAP:] Sorry, not correct. Read what I mentioned above

> Jorge to answer the questions:
>
> 1. Your admins group can install software
> 2. They can restart services
> 3. They are  a domain admin
> 4. they do not have acess in AD
>
> Now, to reset this you can just perform a run as or login with account
> created earlier and reset permissions back to the way they were,
> remember you delegated full AD perms to this account, even though it
> was not in the domain admins group.
>

[JdAP:]
(1) true
(2) true
(3) true
(4) sorry no go! (read above and below why and how)

>
> And honestly, if anyone does find a way to get access to AD through MS
> tools let me know, There is always something new.

[JdAP:] Please READ what I have written above, READ what I and joe have
written earlier AND please… go back to some test environment and try for
yourself what I mention in this mail and what joe mentions in his mails.
This is enough information to circumvent the steps you described. Even if
you removed those abilities there are still OTHER ways because I’m able to
screw with software, services, etc. on the local DC. Those ways I’m not
going to mention here….
"There is always something new" –> That "new" thing you are talking about
is as old as joe and I have mentioned, It is as old as AD exists! I guess it
is a personal definition, but in this case I would define "new" as old as
the way to Rome

For now: the message WAS, IS and REMAINS (until really solved): IT CANNOT BE
DONE! (IT = fulfill the requirements as mentioned earlier) Everyone
accessing a DC and changing things on a DC MUST MUST MUST be fully trusted
(no matter what domain in the foresdt). It is that simple!
You can believe this or not, that is up to you. However, I hope you are not
selling this to your customers as some solution to something in some way.
Why? Because IT IS NOT A solution.

——————————————————————————————————-

Windows Server Longhorn will provide a new type of DC, called the "Read-Only DC" which will allow administrative separation on that particular DC. This applies to all "Read-Only DCs", but it will still not apply to all "Writable DCs".

Wanna hear more about the "Read-Only DC", make sure you attend the "Directory Experts Conference" as I will be speaking about this new feature in Windows Server Longhorn.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————