Example of Active Directory Service Account Naming Scheme For Schools

In the last two blog posts in this series we looked at bad uses of the domain administrator username and how some schools I’ve come across have implemented a whole networking with the domain administrator.  This is a big issue and by changing the password of that user it can bring down the school network.

• Who should know your Domain Administrator password at your School?
• Don’t use the domain administrator to install software or you’ll have trouble…

 

I thought I would share with you what my naming scheme is for the different applications I have installed into schools.  Some of these have special permission and are easy for me to remember so when administrating and troubleshooting I know what I’m looking for.

Naming Scheme

Most people have their own naming scheme and to me I have my own set that I use.  Each product I implement I first create a two letter acronym that will identify product for me.

• SharePoint = SP
• Exchange = EX
• Moodle = MD

You could use what ever naming scheme you want but keep it relevant to the product so if someone else is looking after your network they understand what the product might be.  Here are some other examples.

• SharePoint
• SPS
• SHAR
• Exchange
• EXC
• EXCH

If you are looking at how your network evolves over the next 5 to 10 years you may want to use a naming scheme that reflects the version of the product so you know which user is for which application.

• SharePoint 2007 = SP07
• SharePoint 2010 = SP10 or SP2010

I personally then like to break the name up by adding a underline after product so it becomes

• SP_
• EX_
• MD_

This is just a personal thing as it helps me to read the name of the user easily.

Each product will require some king of administrative permission to implement the software on the local machine.  To me this is the administrative account for that piece of software.  When implementing SharePoint or Exchange I create an admin user so these are used to implement the software on the required server.

• SP_admin
• EX_admin

I now know that these users were the users who implemented the software, no issues with resetting the domain administrators password now as it does not affect these products.  These admin accounts are only given permission when and where required allowing these user accounts and my network to be secure.

Service Accounts

Products such as SharePoint and SQL Server allows you to use different domain user accounts for the different services.  It is best practice to create the different users that it requires.  SQL should have an admin account which manages the product which there is another that run the services.

SharePoint requires a lot more accounts, running it on a single account such as the domain administrator or any user is bad practice.  It should be implemented with several accounts and I’m sure depending on who you talk to they will recommend more or less.  When implementing SharePoint I usual start of with 4 accounts.  These are the admin account it will be installed with, one for application pool, one for Search and another for the User Profile Sync.  Each of these users has different permissions either in your Windows/Active Directory environment or SharePoint.

This means for these 2 products I start off with 6 accounts.

• SQL Server
• SQL_admin
• SQL_services
• SharePoint 2010
• SP_Admin
• SP_Services
• SP_Search
• SP_UPS

When implementing SQL Server you are asked which user accounts will run the SQL services allowing you to enter your SQL Server service (SQL_services) account and password.  Depending on your requirements you don’t need a single user for each service as you’re most likely implementing it in a school with only one or two databases.

As discussed in the Moodle 2.0 with Microsoft technologies eBook you may require a user to read Active Directory or even write back.  In the book we created this user as md_ldap (Moodle and LDAP) and the user has delegated permission to use the Active Directory OUs required for that user.  The user is not a domain administrator nor is a enterprise administrator allowing it to have write permission to Active Directory, it only has permission to where it requires.  This user does not require local administrator rights and does not have permission, it only has delegated rights to the organisational units it requires.

Passwords

Its all great having these naming schemes but there is not point if you are using the same password for each.  Ensure each password has a complex password, the admin accounts need to be complex while the service accounts can be even more complex. Example

• SP_Admin
• Password: Ty8jF!4
• SP_Search
• Password: Y8I9kjsd(!@fj39

The point here is that you don’t need to log in as any of the service accounts so you can make them even more complex so they are more secure.

SharePoint 2010 has got this so right.  With selected service accounts you don’t need to know the password to run or manage SharePoint so why know the password at all.  Built into SharePoint is managed accounts which is where you can managed each of the accounts and you can set a password policy to certain accounts.  You have to set these up manually but when configured, the password for the accounts can be reset by SharePoint and you aren’t give a prompt or any information what the password is.  If you do need to change the password for this account for troubleshooting you do this in SharePoint as it will then change the password in all the place it requires such as the application pool for the windows service.

Conclusion

As mentioned in the previous two posts the most important part before deploying any software is to read the implementation guide and find out how the software runs, what its requirements are and what you need to provide the software for it to work.

If you do this properly you will find that you all of a sudden have lots of admin accounts and service accounts for different software and to remember the right username and password can be difficult unless you have a good naming scheme.

During this post we looked a just one naming scheme but consider what your is, are they all consistent and do you remember them all.  The next time you are implement any software ensure you have created yourself a user and they have the minimum amount of rights to install the product.