In my previous blog post we discussed the use of the domain administrator user at schools and how this username and password is known by so many people within the team and can cause security risks. I feel like schools need to have this cultural changes from using the user as any other user and being the most securest user possible that no one uses.
I spent a bit of time thinking about why the user is used so much. Is it lack of understanding of the power of the domain admin account, lack of training provided to the user or laziness? The more I think about it the more I actually things it’s all of these but the main issue I believe that doesn’t help, is the implementation of the network and products using the domain administrators username to implement all of these.
I was recently at a school looking at a few of their issues and noticed that the only technician at the school had implemented every piece of software using either the domain admin account or his username which was also part of the domain administrators group. This is a big no no even more so when you find that he has implemented Exchange using his own username and SharePoint has been implemented and the System Account is running as the domain administrator.
This is a serious sign of bad practise and I’m sure some of your are thinking how bad this really is. The main problem here is password of the domain administrator being used in different applications.
In the setup of this school the reason why he was having so many problems was because they changed the domain administrator password. As services in Exchange started to connect to other services, servers were restarted and it all failed. You tried to start the service manually and you got an error due to the wrong password.
When implementing a new product, first read the implementation and guidance documents. It will give you information on how to setup the product properly and the type of users required and how the product has dependent services. Microsoft have loads of whitepapers and information on TechNet which will give you a lot of information and if you’re not sure ask the online community, use forums or twitter.
Ask yourself this question. Does the user/username who will implemented the software require domain administrator rights? Can you give them just local administrator rights?
I personally create a new user and give them local administrator rights to install the product. Depending on the product you may be required to create different users for services, usually I would create a group of all these users and add the group to the local administrators group for the servers they are required.
Some products don’t require local administrator access so don’t give that user permission, only give them permission when required.
For products such as Microsoft Exchange, SharePoint and SQL Server they all require many users with different permissions. They have local service accounts that require a domain users, an implementation that might require to write to Active Directory or even their own authentication type so you don’t have to use Active Directory.
Conclusion
Create yourself a new user when implementing software such as Microsoft Exchange, SQL, SharePoint or Moodle. It’s important that your network stays in good shape and does not rely on a single user to run. Each user should only have the permission that is requires to install and then run.
Read the information that is provided by the software company as they will guide you in the type of requirements for a user and do not install anything using your own username!
One thought on “Don’t use the domain administrator to install software or you’ll have trouble…”