Years ago, 13 years ago specifically, I wrote a post about people who allow non-expiring service / application / generic IDs.
If you care to read what I wrote before please see http://blog.joeware.net/2005/05/08/10/
I did not have good things to say about non-expiring IDs then and I have even less good things to say about them now yet we STILL encounter these absolutely stupid constructs all over the Windows world. In fact I have seen accounts with passwords that are used daily that have passwords OLDER than the length of time since I wrote that previous post. And they are for important applications, sometimes absolutely critical applications! You wonder how much turnover has been in the application teams that have the passwords to those IDs… How much exposure does that application have???
I once saw an application ID that was exposed in a public manner and that digression absolutely required that the password get changed. They knew which app team requested the account originally (most companies don’t even have that much knowledge) so this shouldn’t be all that hard right? One bit of bad news… That account’s password hadn’t been changed in over a decade. They change the password and suddenly unrelated apps all over the company start crashing and burning. Completely different application teams completely unrelated to the original requesting team. The business was impacted in a major way so there was no choice but to set the password back to the original password and try to sort out what was going on. Several new application IDs were created and a few days later and the password was changed again. Boom! A bunch more apps all blew up. Several new application IDs were created and a few days later the password was changed again. Boom! Lather, Rinse, Repeat. This went on for many weeks. Literally. This never would have happened if the original service ID has been getting changed on a regular basis because apps would have broken soon after leveraging the well known ID and the owning app team would have said piss off we aren’t making our application less secure because you were a moron… So the app teams would have learned a valuable lesson; don’t “borrow” other teams’ IDs. My best guess as to what happened there was that there was turnover from the original team that “owned” the ID and whomever went to another team ran into a need for an ID so they knew about that one and used it. Year over year the ID’s use crept out from one team to two teams to four teams to eight teams to who knows how many teams in probably an even faster manner than the binary progression illustrated. Again all of that undeterminable risk to the company could have been prevented simply by not allowing non-expiring IDs.
Non-expiring IDs is something I have railed against for years (literally since the 90’s when I first saw it and thought wow that is really stupid) in many very very large companies since I have spent most of my career working in the Fortune 50 space with several companies in the Fortune 5 including several Fortune 1s. Despite all of that thought and railing I have never thought of non-expiring passwords on service IDs in a manner that I saw in an email the other day that I absolutely have to share because the second I saw it I thought it was a brilliant way to look at it. It takes what I have said and makes it so easy to comprehend to many people who generally have trouble understanding the concept of why you don’t allow for non-expiring passwords…
“We would never issue a Certificate with an infinite expiry date, but Active Directory service accounts are issued with passwords that never expire.”
This was written by my good friend and coworker Chris Farris. Even people who can’t seem to “get” why you wouldn’t set up a service ID with non-expiring password easily understand that you don’t give out certificates without an expiry date. In fact, the same people who think it is weird you wouldn’t give a non-expiring service ID would think it was very weird to have a certificate that didn’t expire.
The extra scary thing here though is that a service ID is far more flexible (hence dangerous) in its usage than a certificate yet people still want them to be non-expiring. When I say more flexible I mean anyone with the userid string and clear text password can pretty much use the ID anywhere they want in any way they want where if you have a certificate you have very limited ways and places that that can be used.
Microsoft has progressed a little past where we were in 2005 by giving us Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) which still do not, for some reason, enjoy significant saturation into the market[1] and unfortunately they don’t cover every use case and in particular don’t cover non-Windows based LDAP or CIFS/SMB type applications[2] but as I mentioned before, this isn’t rocket science, applications can and should be written to manage their own password. It can be more complicated if you have apps that run across multiple machines and have to share the same ID (why do they have to share the same ID??) but you coders are the smartest of the smart right?? Prove it. Write your applications intelligently and to use the security features that are available. This doesn’t require any expensive fancy PAM software, it just requires coders who have a clue about security and can write decent code.
joe
[1] Perhaps every Microsoft product that current asks for a service ID should be reviewed and changed to using MSA/gMSA by default and you have to jump through hoops to use a normal service ID?
[2] Theoretically (more than theoretically actually) a non-Windows platform app could actually use the gMSA functionality but it would take some work to get it all set up right[3].
[3] https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/ , https://www.dsinternals.com/en/retrieving-cleartext-gmsa-passwords-from-active-directory/
