Windows Server - Remove builtin\administrator domain account from "domain admins gr

Asked By Chris on 14-Jun-10 06:45 AM
Hi,

I want to control where "domain admins" can log on. I will deny this group
to logon locally on the domain except from a set of well controlled
workstations. Since builtin\administrator is a member of "domain admins", it
will deny this account too. So can I safely remove it from the "domain
admins" group.

Thank you

Chris


Meinolf Weber [MVP-DS] replied to Chris on 14-Jun-10 06:59 AM
Hello chris,

Any domain admin can reset the configuration you create, if you do not like
domain admins to logon in the domain, do not make them member of domain admins
group. For this group working with deny i would not recommend. This can result
in the loss of option for logging on yourself.

The administrator account just disable it and give it a strong password that
will be stored in a safe place.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
Joe Dunn replied to Chris on 14-Jun-10 07:28 AM
You cannot restrict what domain admins can do in a domain.  Any restriction
you try to setup they can undo due to the very fact they are domain admins.

If you do not trust someone to logon to a PC\Server you certainly should not
trust them to be a domain admin.

Best regards
Joe Dunn
MCITP:EA, MCSE, CCNA
Chris replied to Joe Dunn on 14-Jun-10 08:13 AM
Joe,

I just try to implement Microsoft recommendations regarding active directory
security that can be found here :
http://www.microsoft.com/DownLoads/details.aspx?familyid=2EAA45C7-D936-413E-9586-A8BB6FF739D9&displaylang=en

Chapter 5 :

Securing Service Administrator Workstations
In addition to limiting access to resources that are stored on the domain
controllers and access to information that is stored in the directory, you
can also enhance security by strictly controlling the workstations that are
used by service administrators for administrative functions.

Denying Logon Access to the Domain
To deny logon access to a domain, limit the locations where the service
administrator accounts can log on by denying log on locally to members of the
Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and
Account Operators groups at the domain level. Doing so prohibits
administrators from logging on to any computers in the domain. Also, be sure
to follow the procedure in the next section, ???Allowing Logon Access to
Administrative Workstations,??? for restoring logon capability to
administrators so that they can log on to administrative workstations.


May be I missed something...
Paul Bergson [MVP-DS] replied to Chris on 14-Jun-10 08:14 AM
Don't do this!!!  I am guessing even if you try and cripple them AD will not let
you.  This account controls and manages the domain, yank out any user you
do not trust and move on.

--
Paul Bergson
MVP - Directory Services
MCITP - Enterprise Administrator
MCTS, MCT, MCSE, MCSA, MCP, Security +, BS CSci
2008, Vista, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com   Twitter - @pbbergs

Please no e-mails, any questions should be posted in the NewGroups.  This
posting is provided "AS IS" with no warranties and confers no rights.
Chris replied to Paul Bergson [MVP-DS] on 14-Jun-10 09:20 AM
I plan to do it because I have read it in "Best Practice Guide for Securing
Active Directory Installations" white paper published by Microsoft :

To limit the locations where the service administrator accounts can log on,
perform the following tasks:
1.	Modify the User Rights Assignment policy in the Default Domain Policy GPO
(Default Domain Security Settings) to Deny log on locally to the following
groups: Schema Admins, Enterprise Admins, Domain Admins, Server Operators,
Backup Operators, and Account Operators.

I think it  reduces the attack surface.

May be I should not follow Microsoft recommendations.
Ben Humpert replied to Chris on 14-Jun-10 12:11 PM
The most Microsoft recommendations are useless, just ignore them like spam!
Best example is "Upgrade to Windows Vista now" ;)

Lets assume you followed the advice and your AD allows you to do that. So
you have two Domain-Admins, you and Jane Doe. Jane Doe is not allowed to
login with Domain-Admin account anywhere except on her workstation. If she
notice that she can login on her workstation as Domain-Admin and disable the
restriction.
To prohibit this, you can forbid setting changes directly for her account -
but then - without the ability to change domain settings she does not need to
be an Domain-Admin!

If you just follow MS recommendations, just ignore them. If you want to
restrict the logins because of whatever, tell us exactly why and we probably
can give you better recommendations.

Regards
Joe Dunn replied to Chris on 14-Jun-10 12:32 PM
This is the first time I have seen this recommendation but I would not follow
it for the reasons already stated in this post.  I can see where Microsoft
are coming from but it is no real defence from someone who has admin
credentials and malicious intent.

Instead I would, and do, concentrate on strict management of who has admin
credentials.  Disable the administrator account, create individual named
accounts separate from the standard accounts for you admins and delegate
permissions for them to do nothing more than there job role requires, ensure
the passwords are strong and regularly changed.

There are many recommendations out there and you could have a full time job
trying to follow them all and probably contradict yourself as well.  Instead
take them as guidance to ascertain the requirements of your environment and
come up with your own policies and best practices to secure it.

Best regards
Joe Dunn
MCITP:EA, MCSE, CCNA
Chris replied to Ben Humpert on 15-Jun-10 03:14 AM
Ben,

I think in some situations anybody can be tempted to log in as a"domain
admin" on a workstation. Read this story :

at a local college. To preempt any trouble, he has always worked diligently
to make sure that the administrator account is well protected on his Windows
networks.

The students in the class use Windows 2000 Professional on the client side.
One of the students booted a workstation using a utility that allows direct
access to the machine???s file system. Once he had access to the file system,
he replaced the print spooler service with a utility that records keystrokes
to a log file. Then, he called my friend over and told him that he was having
trouble printing.

My friend tried all the basic quick fixes and then decided that he needed to
reinstall the print spooler. He logged into the machine as the administrator
and fixed the ???corrupt??? print spooler, and the problem was cured. The student
then opened the log file that his keystroke recorder had created and
instantly had the administrator password. No guessing, no deciphering, no
brute-force cracking. He had stolen the password in a matter of minutes.>>

it is not only a problem of trusting or not trusting individuals. If a domain
admin account has been stolen, I feel more secure knowing domain admin
account can only be use on well controlled and audited workstations,
physically protected too.

I do not understand why you compare Microsoft commercial speech with security
best practices.
I have found another IT pro recommending this kind of security settings :
http://www.networkcomputing.com/-architecting-a-secure-windows.php

Chris
Joe Dunn replied to Ben Humpert on 15-Jun-10 04:42 AM
The recommendation is neither right or wrong.  it is a recommendation.  If
you feel there that your environment is at risk from domain admins logging in
to workstations proceed with locking them down.  But test it first then test
it again and before you deploy it test it once more to be fully aware of the
consequences and that it is not a perfect defence.

Regarding to story you posted.  It comes back to managing your admin
accounts.  You should never have anyone log in as a domain admin to fix a
print spooler.  If the account had only to sufficient level of access, i.e.
local admin then the recommendation would have secured nothing.  You will
always have to allow local admin access to the PCs.

Best regards
Joe Dunn
MCITP:EA, MCSE, CCNA