We make our users change their passwords every ninety, forty five, sixty days; some places even do thirty days. Anyone do fifteen days? Probably not. It’s really unusual to see companies that change their service passwords that often and it’s easy to see why. Look, open up Server Manager, wait a few minutes, maybe you connect to a remote machine. You can certainly do that in here. Down to Configuration the down to Services, then you have to find whatever service it was. Then you have to change the password that it uses over here. Log on to this account, type in the password, whatever. Nobody wants to do it.
If you have a service account that is used on a dozen machines, that’s a dozen machines that you have to connect to and do this. You are changing them every ninety days and you have a bunch of different services accounts where you have to do that. It’s easy to see in some places you would have a full-time person that did nothing but log on and changed service passwords all day every day.
You can make it a little bit better. Let’s hop down here to Windows PowerShell for example. I could do something like this, get-wmiobject, class Win32_service, computer name. I’ll just specify one computer, but this could be a comma separated list of computers or you could query all users in a particular active directory or organization unit. I don’t want everything, I just want to grab the services that meet this filter criteria, name =’BITS’. Bits usually runs under local service. I like to play with in this example because if I break it I’m not going to be messing up anything to critical to the operating system. Then we are going to pipe those to a cmdlet called ForEach-Object, and we’re going to tell it for each one of those execute the change method. Surprisingly the first one, two, three, four, five, six seven perimeters I don’t care about. I just want to change the eight, which is password. Then hit Enter, wait, and perfect. Return value of zero is good news.
If I had provided several different computer names it would have gone out to each one and assuming I had the right permissions it would have changed that password for that service running on each of those computers. There is still a problem with this, you have to keep track of which computers are running which service and in any size environment that’s very easy to let get away from you. There is no automatic discovery here, no automatic inventory. If you are using something like System Center Configuration Management I could see you using its inventory base to determine which servers were running a particular service. Assuming that they are all using the same service account, then you could do this by pulling those names, but its starts to get really complicated. You are definitely building you own Toolset there.
I think, ultimately, is why we don’t change our service passwords all that often. It’s a hassle; it’s largely a manual effort. You largely have to keep track of who is running what running manually. How many of you just keep a little notebook with all the service passwords written down? Ok, maybe it’s locked up in a safe or something which is great, but this just a very manual process. That’s why we don’t do it. In this month’s blog article I want to talk about some of the capabilities that you might want to look for in a tool, whether free or commercial too, to help automate some of these things and make it a regularly scheduled task. Just provide a new list of passwords every ninety days and it takes over and does the work for you. Isn’t that what the computers are supposed to do, the manual work?