Re: Grant Administrative Access to a Domain Controller

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

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"MPerrault" <mperrault@xxxxxxxxxxxxxxx> wrote in message
news:1167291342.778011.274070@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Jorge de Almeida Pinto [MVP - DS] wrote:
OK, let me try to ask the question as pointed out by the original
poster...

He wants some group of persons to:
(1) install software on a DC
(2) restart services on a DC

He does not want that same group of persons
(3) to be domain admin
(4) change ANYTHING in AD in ANY way...

if you guys (Mike and Matt) feel the problem/issue has been described
correctly, please explain to me in detailed steps how you are going to
configure things so that the original poster is able to accomplish
requirements (1), (2), (3) and (4)...

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"mfarr" <mfarr@xxxxxxxxxxxxxxx> wrote in message
news:1167249029.682242.42270@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Archi one other thing . .

To clarify, this user cannot be a member of the domain admins group,
but shouldn't be if they are not managing AD. Use the capability of AD
to delegate the appropiate rights.

Matt


mfarr wrote:
Archi,

My colleague Mike is correct in saying you can deny access to Active
Driectory but still allow logon to the DC's. To do this, delegate read
only rights to your restricted administrator to everything within AD
then add that user to the list of accounts that can log on locally to
the dc within the Domain Controller Security Policy. Within the Domain
Controller Security Policy are also options to log on as a service,
etc for management functionality.

I recommend checking out Active Administrator from Scriptlogic to
handle the delegations of control within AD. With Active Administrator
you can easily configure these restricted permission within AD for
your
admins via permissions templates that even self heal. Good luck.

Matt


Archi wrote:
We have a group Domain Server Operators and we need to give them
admin
rights
to domain controllers to restart services, install software and etc.
But they
should not have rights to Active directory

"Jorge Silva" wrote:

Hi
Can you explain exactly what do you need to do?
also have a look at :
Step-by-Step Guide to Using the Delegation of Control Wizard
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/ctrlwiz.mspx

--

I hope that the information above helps you.
Have a Nice day.
Jorge Silva
MCSE

"Archi" <Archi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:24F63807-E425-4294-AFFD-6A36ACD3DB97@xxxxxxxxxxxxxxxx
I need to give admin access to domain controllers for a certain
domain
group
but without accessing Active directory.
Any options?



I had a few people email me on how to do this outside this forum, so i
thought i would post it here for all.

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)

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)

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.

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

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. 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.

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.

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

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.


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

Michael P. Perrault
MCSE, CCNA, A+, MBA
Senior Systems Engineer,
ScriptLogic Corporation

Michael.Perrault@xxxxxxxxxxxxxxx
www.scriptlogic.com



.

Relevant Pages

  • Re: Incoming E-Mail - cant create contact in OU
    ... account out of local administrator to attempt to find any denied access. ... I then added full permissions to my user account on both of these keys, ... local admin rights to the server hosting incoming email. ... what permission I need to give the app pool locally to avoid this issue. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Incoming E-Mail - cant create contact in OU
    ... account out of local administrator to attempt to find any denied ... I then added full permissions to my user account on both of these keys, ... that's for every app pool you create for every new web app on the ... local admin rights to the server hosting incoming email. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: NTFS owner problem
    ... power options, ... permissions that control access. ... to which any admin account should have full access. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: 2003 Server Client/Delegation and Data Issues
    ... The test account has the same issue as the junior admin. ... The AD information is up to date - I could view the account I ... I am starting to suspect a permissions conflict as I have poked around ... The jr admin is a member of the Remote Desktop Users group at the domain ...
    (microsoft.public.windows.server.active_directory)
  • Re: Incoming E-Mail - cant create contact in OU
    ... account out of local administrator to attempt to find any denied access. ... I then added full permissions to my user account on both of these keys, ... local admin rights to the server hosting incoming email. ... what permission I need to give the app pool locally to avoid this issue. ...
    (microsoft.public.sharepoint.windowsservices)