Best Practice: What domain admin credentials to use when adding/joining computer to network domain?

Question

Environment: 1 Win2008R2 Network Server (also domain controller) 13 or so Workstations.

Traditionally we've always used the server administrator credentials to join a workstation to a business domain network or 13 workstations. However we're now enforcing password policies and it's required that admin password will change regularly.

The network server admin account password was changed today as a result of this policy enforcement.

My network user account password that's used on my workstation also had to be updated.

I logged off my workstation and back in after being prompted to change the password. I was then required to enter Domain Admin credentials to access the domain. I suspect this was because the server admin account password was changed.

I had thought that as the workstation was already added to AD that it would be remembered, but the credentials still needed to be entered on the workstation.

So this had me thinking that there has to be a better/correct way to do this.

I thought I could create a Domain Admin user just for this purpose and set the password to never expire but I think that surely defeats the purpose in the first place of maximising security.

So what is the best way to do this.

I.E. When first adding/joining a workstation to a network domain, what Domain Admin credentials should be entered?

All of the articles and YouTube videos I've seen so far say to enter Administrator and it's password.

Please let me know if this requires further expansion.

Answer 1

Ideally, each technician/administrator should have at least two (if not more) accounts.

• Standard Account (for daily non-administrative tasks)
• Workstation Admin account (administrative access only to Workstations; delegated access to Workstation OUs in Active Directory, no access to servers)
• Server Admin account (administrative access to servers and delegated access to Server OUs - no access to workstations)
• Domain Admin account (administrative access to Active Directory; NO access to servers, NO access to workstations [except Secured Management workstations])
• Other accounts as necessary.

Accordingly, the technician's Workstation Admin account should be used to join the computer to the domain. Shared accounts - should be used only in situations where no other option is available. Alternatively, I could see an option where an automated deploiyment tool (like SCCM or something) could leverage a dedicated account with no access other than that of joining computers to the domain in a dedicated OU.

In order for it to work properly (aside from the first 10 workstations joined), you can refer back to this article: https://support.microsoft.com/en-us/help/932455/error-message-when-non-administrator-users-who-have-been-delegated-con (an oldie but a goodie). In short the steps are

1. Open Active Directory Users and Computers
2. Right-click the Workstations OU, select Delegate Control
3. Work through the wizard and delegate a custom task of Creating and Deleting selected objects in the folder; limited to only computer objects in the folder.
4. Grant the Reset Password, R/W Account Restrictions, Validated write to DNS hostname, and Validated write to service principal name.

The trick is that the workstation admin account should be a member of a group of "workstation admins" from there all access and permissions should be granted to the workstation admin group.

Answer 2

Updated answer based on corrected/edited question

Once a computer has been joined to a domain it does not have to re-join the domain. Once an administrator account has confirmed the system is to be added to the domain, you could delete that admin account and it would have no impact on the computer added using that account.

I'm not sure where the wires are getting crossed in your understanding, but they are crossed.

The trust relationship between the domain and its member computers is NOT predicated or dependent on the administrator accounts used to authenticate the various systems together.

Previous answer, based on original question:

There are many ways to solve this, some of them good and properly security-minded, and some of them not. For that reason, this question really deserves more of an open-ended discussion format to fully flesh out. However, here's two methods I'm familiar with:

1. Each technician of appropriate responsibility has two domain user accounts, one regular user that they use to login to their own computer and do most of their day-to-day tasks with, and another account that has domain admin permissions which they use to open the tools and perform the tasks that require this. The administrator account has higher security requirements, longer password, and more frequent changes. But it belongs to the specific technician.

2. When domain admin permissions are required, a form is submitted specifying the need and time required. Temporary credentials are issued with permissions limited to the particular requirements. These are then deleted once the task is completed.

There are situations where each of these may be appropriate. The easiest method though is to have two sets of credentials for technical staff and they are then each responsible for using them appropriately.

Also, creating shared credentials is a terrible, horrible, no-good, very bad idea. Making their password to never expire makes it even worse. I don't know what your background or experience is, but from the context of your question I'm guessing you're not in a position of authority in your organization, and you should really talk to those who are about the best way to go about balancing security and convenience.

Answer 3

Commonly, the users who can add a machine to an Active Directory Domain are members of the Domain Admins Active Directory user group.

However, non-Domain Admins can add machines as well, if given the proper permission. Some companies might not want Help Desk technicians to have Domain Admin privileges, but do want them to able to join machines to the domain. With the proper permissions, this can be accomplished. See this Microsoft article for more information.