temporary domain admin. opinions?

  • Last Post 29 September 2017
MatCollins posted this 25 September 2017


My boss insist on having a separate user in domain admin group for later use. He says when we want to troubleshoot clientside problems we need a domain admin to logon (because it is much easier than local admin among 3K computers) and since I have configured built-in domain admin to only logon to DCs, he wants to have a user in DA group.

I am trying to convince him that, this is not best practice to have more domain admins. I am saying no matter if you change password every day and make it disabled, it is still in DA group! But he says that this is the option we have. we can have a user in DA group but keep it secure. 

Am I too much worried as an AD specialist? I can not convince myself to accept that.

Order By: Standard | Newest | Votes
a-ko posted this 25 September 2017

Domain Admin not needed. Just use GPP to add a group to the Administrators group on all of the machines.


It accomplishes the same goal without creating a privileged domain admin.


Bonus points: Also place users in this group into the “Protected Users” group, which significantly limits the ability for things like PTH/PTT to work.


For Domain Admin machines, create a separate account for this from your general population.



g4ugm posted this 25 September 2017

Matt (or is it Mat) So are you saying he wants to have a DA account that he uses to log into broken, so probably compromised with spyware, possibly virused, may be contain Chinese malware, workstations to debug problems. I don’t suppose you have proper change control so you can’t put that in a change request! In places where I have worked in the past we have used group policy to add a normal domain account to the local computer admins. Dave     


ken posted this 25 September 2017

What does your boss mean by “keep it secure”? There’s no such thing as “secure” – there’s only degrees of risk management.


My personal opinion is that what your boss is proposing isn’t a good idea. If the purpose is simply to have the ability to troubleshoot client-side issues from a single, problematic end-point. Perhaps

use the local built-in Administrator account, in combination with LAPS (https://www.microsoft.com/en-us/download/details.aspx?id=46899&751be11f-ede8-5a0c-058c-2ee190a24fa6=True)

so that you have unique Administrator passwords on each end point? Alternatively, with 3K endpoints, do you really need to troubleshoot? Can’t you simply rebuild? Or swap out the machine if you need to do forensics?


If you really need a DA account, then if you have the right level of other risk mitigations in place, then the risk might be bearable, even if it’s not best practise.



SmitaCarneiro posted this 25 September 2017

If the computer you are troubleshooting is compromised, logging in as a Domain Admin could mean handing over the keys to the kingdom to the malware residing on that computer.


Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy



ITaP logo clipping path2



gduke posted this 25 September 2017

Using Domain Admin credentials to manage workstations is the opposite of a best practice. It’s the fast way to getting your organization compromised. In fact, Microsoft’s best practice is that you don’t even use Domain Admin creds on your

own (IT worker responsible for AD administration) workstation that you also use for web browsing and email.


As others have said, we use Group Policy Preferences to add a different AD group to the local administrators group on the user workstations in our organization. Our front-line support staff each have an account in this group. We use the

analogy of a HazMat suit for these accounts. They are used to log into broken, probably compromised systems. You don’t want to use those same accounts for anything else, especially anything sensitive. This solution has worked for our organization, with distributed

IT support staff and thousands of workstations, for almost 15 years.


We also use GP to assign the Deny access to this computer from the network User Rights Assignment to this group so that these accounts that have admin rights on all workstations can’t be used to move laterally via the network.


I still haven’t convinced my boss that I need two laptops.


Hope that helps,



Geoffrey Duke

802.656.1172 | Sr Systems Administrator | Enterprise Technology Services | University of Vermont






amulnick posted this 25 September 2017

LOL!  That's a good way to point out several of the risks.  One to add is that once you give DA, you have to work really hard to make sure they don't create additional unauthorized domain accounts, which can cause all kinds of havoc.  
I've done same as Dave mentions, using GPO to put specific accounts (one per person) into the local admins group for desktops.  
The goal is to figure out break points and compartments you can limit damage to.  
"There are two types of enterprises out there: those that have been hacked and those that don't know they have been hacked"


MikeLeone posted this 25 September 2017

On Mon, Sep 25, 2017 at 4:20 AM, Michael Cramer wrote:


MatCollins posted this 25 September 2017

What does your boss mean by “keep it secure”? There’s no such thing as “secure” – there’s only degrees of risk management.

 Thanks everybody. First of all I would like to let you know that I am completely against this approach and I already suggested using Local Admins (Controlled by LAPS or other ways). But he is indicating like this:

"We can have a user account in out domain admin group, but keep it disabled and have heavy passwords in place. Once there is a need to login to that workstation, we enable that computer and do our stuff, and once the task is finished we disable it again"

I just cannot accept this guys. Even if I say that this is not best practice, he simply will say:

"OK we can have a user account, once there is a need to login to workstation, add that to domain admin, once ithe job is done, remove it from DA."

this is funny in my point of view.. but he is in charge..

From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of matcollins66@xxxxxxxxxxxxxxxx

Sent: Monday, 25 September 2017 5:25 PM

To: activedir@xxxxxxxxxxxxxxxx

Subject: [ActiveDir] temporary domain admin. opinions?



My boss insist on having a separate user in domain admin group for later use. He says when we want to troubleshoot clientside problems we need a domain admin to logon (because it is much easier than local admin

among 3K computers) and since I have configured built-in domain admin to only logon to DCs, he wants to have a user in DA group.

I am trying to convince him that, this is not best practice to have more domain admins. I am saying no matter if you change password every day and make it disabled, it is still in DA group! But he says that this

is the option we have. we can have a user in DA group but keep it secure. 

Am I too much worried as an AD specialist? I can not convince myself to accept that.

kennedyjim posted this 25 September 2017

Sounds like you are going to lose on this one, he has made up his mind.  But I will play along, some more ideas:



What is the job I need to do and what is the least privileged account that can do that job. Least privileged is an accepted cornerstone of security.

Follow on question/point to him.  “Why does this account need DA to work on a workstation?”


Mimikatz. That DA will be leaving it’s footprint all over.


Disabling and enabling a DA account is extra steps that are prone to error.








g4ugm posted this 25 September 2017

Matt, First all you can do is make him aware of the issues and make sure records are kept, perhaps e-mailing him… Secondly disabling accounts only prevents new logons. The account will continue to work for some time after its disabled. So if you use the account while a machine is infected, and the infection starts processes on other computers, say to encrypt their files as we have seen with recent ransomware attacks, the tasks will continue to run and encrypt the files even after the account is disabled. I quote from the Sophos web site… https://nakedsecurity.sophos.com/2016/02/17/locky-ransomware-what-you-need-to-know/Remember, also, that like most ransomware, Locky doesn’t just scramble your C: drive.It scrambles any files in any directory on any mounted drive that it can access, including removable drives that are plugged in at the time, or network shares that are accessible, including servers and other people’s computers, whether they are running Windows, OS X or Linux.If you are logged in as a domain administrator and you get hit by ransomware, you could do very widespread damage indeed. Of course if UAC is enabled this will offer some protection…… I also note it scrambles your bitcoin wallet so even if you already own enough bit coins to pay you have to buy more. Nice… Dave 


Biju_Babu posted this 25 September 2017

Assuming you already knows the different technical solutions to the problem and looking for a way to convince the management/boss.


May be a cliché.. I would suggest a pro/cons or risk vs benefit presentation for his understanding with the available option including his/her suggestions,

Microsoft recommendations
etc. Sometime a written document along with what a vendor recommends or what industry best practices can change their opinion.


If they are still adamant about their choices at least you will have a good documentation about the proposals and associated approvals. It may help you down the road









barkills posted this 25 September 2017

Ultimately, this thread is not about technical matters—it’s about influencing stakeholders. So I’d suggest we stop piling on with the technical solutions, because

I think we’re preaching to the choir. J


Working in a university, I’ve been in a lot of similar situations. By which I mean that

there are often a diversity of opinions about service design by stakeholders who in some way control the design that I must operate.


Often those opinions are misguided from my point of view, and the challenge is to understand the other’s point of view and reach consensus that you can both agree



There are a lot of approaches I’ve learned over the years for doing this:


One which I find effective is writing an analysis paper on the topic. The paper usually has the following sections in it: background, problem, discussion,

recommendation, status. If there are a lot of possible solutions with details, I’ll add a section just to document what each are and so I have a simple label to refer to each solution. And sometimes I’ll add other sections like risks/costs or whatever else

is needed. My usual flow for this is to write a draft, then review with the service team members. Then edit to address anything at that level. Then move to the stakeholder level. An example of one such paper is at :


The key is to publish the paper to the stakeholders so everyone has a starting place for further discussion. Because transparency is an important value to me, I go one step beyond that and publish it to everyone. This approach has a couple nice benefits:


You can reference other materials


It can be referenced in any change process you have


It records historical reasons behind changes, should you need them


It forces you to be even-handed in your evaluation of the possible solutions


It enables folks who may not be able to do the analysis to participate in decision making. This enables governance bodies to function.


If the decision goes against the analysis, you’ve got documentation about why you thought it wasn’t a good idea


Another approach is identifying key third parties (ideally who you both trust on the topic). For example, perhaps your CISO is willing to make a statement.

Or perhaps there is a strategically important customer. The key here is that this is not about power, it’s about consensus building. You are finding partners who will help the two of you to come to consensus. When this is more formalized, it can be a governance

body. We use this kind of approach to govern all changes to our Azure AD tenant.


Often the stakeholders are not the real stakeholders, but a rather a proxy stakeholder representing the business/customers. When that is the case and

those stakeholders are resistant to a direct approach, I find building consensus among the customers and getting them to influence those proxy stakeholders will work. I often think of this as an option of the last resort, and frankly it is a kind of guerilla

warfare. I typically only use this approach to influence investment decisions—e.g. this is the approach I used to get a central AD here at UW. This takes a lot of time, but when you know your solution is the right thing to do, it will work.


There are many other approaches, I’m sure, but these are the constructive ones that come immediately to mind.





ken posted this 26 September 2017

At the risk of sounding like a broken record, can I state my previous post in a different way…


Why does the boss feel that there is a need for a DA account? This, once properly analysed (or to whatever sub-optimal level you can manage

to get out of him c.f. stakeholder management posted by Brian) would provide your requirements.


From our very superficial overview, it seems that there’s some troubleshooting or analysis tasks that need to be undertaken on the workstation. So again, the question is “why?” Can you just rebuild

the workstation (assuming you have an automated solution)? Can you just give the user a new workstation and take the old one away for analysis (assuming you actually need to troubleshoot or diagnose/document the issue)? Or is it necessary for your helpdesk/servicedesk

to be able to provide a near instant troubleshooting capability? We don’t know what the SLAs etc. are, so we don’t know the requirements. As such, it’s hard to provide firm solutions.


From basic security principles, this stinks. But then, maybe the

risk of domain compromise is low, and the consequences (financial loss, reputation damage) of domain compromise are also low. If so, then, as I said before, everything is about risk management. If a rogue operator being a DA is not going to cripple

your business, but being unable to quickly troubleshoot issues is, then the risk/business enablement tradeoff might favour what your boss is suggesting (though I strongly doubt it)


Lastly (and please don’t take this as criticism), this also indicates to me a lack of organizational maturity. With 3K seats, I’d recommend a formal risk/governance function of some kind – there

should be a Chief Risk Officer (at least some office bearer that has that responsibility). And they should have a risk policy, and what they consider to be their top 10/20/30 business risks. Some kind of committee where changes (whether it be business, technological,

whatever) that could materially impact business risk are considered and formally endorsed. The last para is a vast oversimplification of the enormous bureaucracy that exists in a major bank to manage risk

😊 But it might be a starting point for you (maybe not now, but at a later point in your career).  Try to develop a little

“Risk matrix” – likelihood on one axis, consequence on another. Anything in the, say, “High” bucket needs to go for formal endorsement at some forum (risk, architectural, senior leadership – whatever exists in your org). It’s their job to be accountable for,

and accept risk. And if the proverbial sh*t does hit the fan, then it’s their jobs on the line, not yours.









rwf4 posted this 28 September 2017

We have  GPO that blocks all (potential)  EA/DA level folks from logging into any workstations/member servers except Tier 0. Tell your boss to bingle zero domain admins ;-)


It is very easy to put whoever you want who does desktop (or server) support in the local admin groups on workstations/servers via GPO, use LAPS or a password vault for 500

account etc.


We are in the process of emptying those groups out on all servers in favor of JIT/JEA and privilege management solutions. Workstations are harder but they have priv mgmt on

them too….



danj posted this 29 September 2017

Yeah keep you Tier 0 guys away from workstations or assume breach. (In fact just assume breach.)

Interested to hear of experiences with powershell JEA. Someone told me it was a bit of a PITA to manage, but if I could get it working in just a few limited cases it would be great. Having full admin access to a server just because you need to run a couple

of IIS commands or whatever is nonsense, but inescapable with the usual windows permissions model sometimes. My current client's PCI-DSS compliance exceptions register is full of this sort of thing.