Recently I read an article regarding service accounts and how they should never be set to expire. Bold statement that in some respects I agree with. In the context of the author, I completely understand their frustration with the identity management system not properly alerting the end user that their account was about to be disabled and in turn bringing their development system to a screeching halt.
In the context of an enterprise environments, password and user account expiration are standard obligations that not only ever system administrator must adhere to, but every user on the domain. From an information assurance traceability perspective, without an account sponsor for each and every domain user object, there runs a risk of information loss and accessibility to information by individuals that should not have such access.
By and far I would see the majority of user account responsibilities and issues falling on the shoulders of the system administrator. From an availability perspective, they are the engineer that ensures the system continues to operate properly. While they may not be the face of a system, without their diligent caretaking, the other engineers and analysts are unable to perform their duties.
One core responsibility of a system administrator is to keep a running list of user accounts that are used in their Microsoft Windows Networking Infrastructure to include the service accounts used for MOSS, SQL and any other third party software that is operating which may have adverse effects on the availability of the system if disabled. As a part of the technical governance, one of the responsibilities of the system administrator should clearly state and define that they track user accounts used within the system (some might even call this a best practice).
An appropriate checklist to ensure user account availability would potentially include (but not be limited to):
- Listing of all service accounts (display name, UPN, sAMAccountName, POC, etc.)
- Where each of the accounts reside in the OU structure
- What security groups each of the accounts belong to at the local server level, the domain level, and the enterprise level
- If there are any DCOM modifications required for a service account to operate properly on a server
- What the operating period for the service account is (i.e. does it have a definitive expiration date)
- GPO policy on the particular set of service accounts
- Password change policy timeline
- …
In my experience, I’d say that the majority of system outages and incidents that have occurred when either a service account expires, the password aging that is required catches the administrator off guard when they forget to change it, the core network switches that provide for general connectivity go offline, or a new GPO is pushed down and inadvertently modifies security groups or other domain user object properties. Three of these four issues can be easily mitigated by the system administrator with proper notifications and alerts. Networks are networks and you never know when your core switch is going to have a board go bad or worse melt due to over processing (I’ve not seen the latter, but I have seen the former).
Based on the context of the environment, a system administrator should have a maintenance calendar in SharePoint linked to Outlook that users are subscribed to and receive alerts which provide pertinent information. Such information could potentially include when the next maintenance period is and what will be accomplished during the system outage. Additionally, and maybe it’s wishful thinking on my behalf, the System Administrator hopefully has a relationship of some sort with the Domain Admins or help desk and knows what the policy states in terms of how many days an account is valid for before expiration.
Should user accounts expire or passwords age? It depends on the context. How you approach the issue and handle it is a separate story. Working in the context of an enterprise system requires a higher specification of diligence to properly ensure system availability. In a small environment or dev system, rarely do I find password aging or expiration enabled, thereby reducing the risk of availability due to AD issues.
What works for your organization?
The Tech Blog of Dan Usher 
0 replies on “Expiring Service Accounts…”
Hmmm. Well do you ever want a password automatically expiring and disabling a service? Would it be better to monitor password age and enforce a process where the system administrators go in and change passwords at regular intervals?
Maybe get monthly reports on password age and make sure that any password over xx days old is changed immediately. But with full control of the change and the subsequent reconfiguration of the applications that rely on the accounts.
LikeLike
Joel,
Good questions – the trade off between system security and system availability is one that requires carefully balancing between the two and providing proper planning. My personal thought is that to be most effective, the user accounts used as service accounts should not be enabled for local interactive login, thereby removing the security risk of someone attempting to login to a server as that user.
With regard to the idea of changing the password and monitoring this, if passwords are set not to age, then great care must be taken to segregate the user accounts that are used for services within an enterprise so that the accounts do not necessarily lock out like a regular user account would after a certain predisposed number of times. Granted, by the same token, this may open up further security risks.
I suppose you could say it’s all about the context, the tradeoffs and what level of risk the owner of the system is comfortable with taking.
LikeLike