Sometimes when I talk about Active Directory (AD) administration with PowerShell, people seem open to the idea of learning PowerShell, but I know they’re privately hoping they’ll never really need to. They might say, “I don’t really need to learn this stuff to use AD in Windows Server 2008 R2 or Server 2012, do I?” I have to answer truthfully that, yes, you can still do a lot of work in the GUI—I’m just not quite sure why you’d want to! Just as a quick example, setting my title to instructor is a lot quicker to accomplish with
set-aduser mark -title 'teacher'
than using the Active Directory Users and Computers snap-in or the Active Directory Administrative Center. And unlocking Larry’s account is a whole heck of a lot easier with
unlock-adaccount larry
than spelunking through Active Directory Users and Computers. Directing any query to a Global Catalog server is far simpler with PowerShell (just add -server servername:3268 to any get-aduser query) than with the GUI. Sometimes these kinds of examples will convince the skeptics, but not always. In those cases, I’ve got to pull out the big guns: managed service accounts (MSAs).
Have you ever had to create a domain account because you needed to run a service on a server, and it needed its own account to run under (or perhaps one to run an IIS application pool under)? If so, this story might sound familiar. You’re in the middle of some 25-step setup process for an important server-based application, and now it wants you to create a domain account. Or perhaps its Setup program informs you that it has created an account for the new service to run under. You either create the account or let the Setup program create the account, then you move along to the next step and eventually get the new service running. All is now well, and everyone loves the new service—for a while.
One day, you walk into the office, and everyone’s hair is on fire. The service you set up six weeks earlier is no longer working, no one can figure it out, and it dawns on you that your domain password policy requires a new password every six weeks. Eek! So you reset the password, look around to ensure than no security people are watching, and select the Password never expires check box.
Alternatively, if you have Server 2008 R2 or Server 2012, you could skip creating a domain user account to run the service under and instead set up an account called a Managed Service Account (MSA).
Related: Understanding the Differences Between MSAs and gMSAs
As long as you have at least one 2008 R2 domain controller (DC), and as long as you’re running that service on a 2008 R2 or Server 2012 member server, you simply create an MSA, configure the service to run under the MSA (leave the password field in the Services snap-in blank, and it’ll get filled in automatically) and AD. Then, the MSA account and the member server will create a new password once a month—with no need for human intervention.
I have no idea why most Server 2008 R2/Server 2012 admins have never heard of MSAs, but when I tell the preceding story to my skeptical AD learners, their eyes get big. “What does that have to do with PowerShell?” they ask. “Everything,” I answer, because for some reason the only way you can create an MSA is with PowerShell.
The PowerShell “noun” that describes MSAs is ADServiceAccount, and if you’ve spent a couple of hours with PowerShell, you’ll probably guess that you can create an MSA with new-adserviceaccount. For example, to create an account named svc1, you would type
new-adserviceaccount -name svc1
and if you’re doing this on Server 2012, you’d add -RestrictToSingleComputer, as in
new-adserviceaccount -name svc1 -RestrictToSingleComputer
Then, you would walk over to the member server where you’ll be running the service or do an Enter-PSSession to that system (the -computername parameter doesn’t work on this cmdlet) and essentially “introduce” the managed service account to the member server with the install-adserviceaccount cmdlet, followed by a space and the name of the managed service account, as in
install-adserviceaccount svc1
At that point, you’d need only tell the service to run under the account name. To do so, as I mentioned earlier, simply open the Services snap-in and—where you’d fill in the account that the service runs under—just fill in the MSA account name, and don’t put anything in the password area. An MSA behaves sort of like a machine account, so add a $ to the end of the name. For example, in the case of our svc1 account, if it were in a domain with a NetBIOS name of bigfirm, it would be
bigfirm\svc1$
The rest is automatic. Now, I can’t swear this is true, but I think MSAs might have been the “closer” for a few folks when it comes to learning PowerShell.
