Creating Domain User Accounts
Full-Access Members Only
Sorry, this lesson is only available to Server Academy Full-Access members. Become a Full-Access member now and get instant access to this and many more premium courses. Click the button below and get instant access now.
Instructions
Q&A (0)
Notes (0)
Resources (0)
Saving Progress...
Resources
There are no resources for this lesson.
Notes can be saved and accessed anywhere in the course. They also double as bookmarks so you can quickly review important lesson material.
Log in to your domain controller (in my case SADC01) and within Server Manager, click Tools > Active Directory Users and Computers:
Next, navigate to where you would like to store the domain user accounts for our SCCM installation. For my scenario, I am going to place everything under ServerAcademy.com > ServerAcademy:
Inside of the Service Accounts OU, create the following user:
- SQLService
I am going to configure the users password to never expire. This is generally a bad security practice and in a real production network, you should be constantly cycling secure passwords. If you don’t check this checkbox and the account password expires then the service that uses the service account will be broken until you fix the password.
I am going to use “Pa$$w0rd” as the password and I will create the user account.
Inside of the Groups OU, create the following groups:
- SQL Admins
- SCCM Admins
Next, open the “SQL Admins” group and add the appropriate members that you wish to be able to administrate your SQL server. I am going to include the following user accounts I have in my domain:
- paul.hill-admin
- robert.hill-admin
- test.user-admin
- Administrator
Next do the same for the “SCCM Admins” security group. In my case I am going to use the same two accounts since I am in my lab environment:
In theory, we could use a single group for SCCM and SQL, but in a real production network, you might have database admins that ONLY need access to the SQL Server databases and SCCM admins that do not need to access the SQL server database.
Configure Service Account GPO settings
Next we need to grant the “Log on as a service” right to our SQLService account. There are a couple of methods we could use to accomplish this task:
- Group Policy from our AD Server
- Local Group Policy on our SCCM Server (gpedit.msc)
We are going to use method #2...here’s why. If we configure the settings from our domain group policy using method #1, those settings will take precedence over our local group policy which will overwrite the automatically configured user accounts.
Explanation:
When we install the IIS roles on our SCCM, it will automatically configure the “Log on as a service” local group policy setting with a few IIS users accounts as shown in the photo below:
If we configure our domain Group Policy to include “ServerAcademy.com\SQLService”, that GPO setting will take precedence over (overwrite) these locally configured settings which will break things on your server. One example issue you might experience is the inability to install server roles and features.
Now let’s open the local group policy on the server by clicking the Windows button and typing “gpedit.msc”.
Navigate to the path below and right-click Log on as a service, then choose Properties:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service
Next click Add User or Group
Search for and add the SQLService user account we created earlier then click OK
As an FYI - Once we install all the server roles for SCCM, this setting will be updated the show those listed below:
And that’s it! We are done creating and configuring the domain accounts that we need to install SCCM and SQL server.
Server Academy Members Only
Sorry, this lesson is only available to Server Academy Full Access members. Become a Full-Access Member now and you’ll get instant access to all of our courses.
Is there a difference between adding users to the local group policy of “Log on as service” instead of just adding the SQLService user to the Remote Desktop User local group?
Hi
Matthew Stricker
The best practice is to disable interactive and remote interactive sessions for service accounts.
Ricardo