Re: Grant Administrative Access to a Domain Controller

Jorge you have the patience of a saint.

At this point I just am going to tell everyone to avoid ScriptLogic products because obviously the support staff doesn't understand Active Directory. Additionally, they have also proven they don't understand the core security model of Windows which includes everything from the ACLs on services to ACLs on threads to this to that and to the file system with this bulleted list of "how to do it" and "why this will stop an admin".

As you mention, this will only stop armchair AD pilots who know how to use one or two GUI tools and NEVER use anything else and have no understanding of Windows and no access to tools written by people who do understand Windows. Everyone else will be walking all over them.

Folks are more than welcome to follow this listing but they will have gone through a bunch of silly steps that are more likely to hurt them and make their life difficult than actually secure AD from someone who shouldn't have Admin rights in the first place. They will have the same luck locking down by crushing the bones of last year's Christmas turkey and throwing it in the air while doing a chacha around 3 lit firecrackers.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Jorge de Almeida Pinto [MVP - DS] wrote:
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 everything 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.

Thank you anyway for explaning the steps

.

Relevant Pages

  • Re: Domain groups show up as a SID
    ... I believe that is the way security ... If you logon as a member of a Domain Admins group, but the Local Admins group is ... So if the Domain Admin group has an account named Administrator and the Local ... SID's for all Permissions viewed and granted to any Domain Account. ...
    (microsoft.public.win2000.security)
  • Security permissions on specific account wont take
    ... I have a particular account that I need to set permissions on, ... asisstant full mailbox access so she can monitor his mailbox in her Outlook, ... One thing I noticed is the opton on his account to inherit permissions from ... Should I remove Domain Admins from the permissions list, ...
    (microsoft.public.exchange2000.active.directory.integration)
  • Re: Domain Admins missing in GAL - AdminSDHolder?
    ... This was down to the AdminSDHolder object stripping out permissions and unticking the "Allow inheritable permissions" button. ... my problem now is that members of Domain Admins appear missing in the GAL to eveyone except other Domain Admins. ... Those users should have "normal" account with mailbox etc for daily tasks and account with domain admin privileges to perform administrative tasks. ...
    (microsoft.public.windows.server.active_directory)
  • Re: cant do a differential get "server not found or access denied"
    ... what permissions should I ... Operation: Backup ... >remove the domain admins from the account. ...
    (microsoft.public.exchange.admin)
  • Re: Exchange admin viewing users emails
    ... My account is already part of the domain admins and the permissions have ... been added on the Exchange System Manager, but when I try to open the Inbox ...
    (microsoft.public.exchange.admin)
Loading