Service Accounts Can Be Secure Yet Have Non-Expiring Passwords

BB is correct in the assertions made. But there still needs to be more. One only needs to scan the news headlines to know that admins snoop, abuse privileges on the job and when fired, and later, just to see if the account is still active. This in addition to anyone else who has ever overheard the password and the fact that these accounts do have some sort of system control and access to sensitive data (even if only via a network connection) makes them prime targets for malicious intent or mistakes. The worst part is even with a small group of admins knowing the passwords, there is still no control short of firing the entire group if something were to go wrong with the account. Regular password changes are necessary for these accounts. The problem is of course that not everyone is certain where these accounts are used and it can take many hours to update a password properly and verify and document it. There are products available that provide random password management and discover and propagate the password changes for these service accounts to all locations such as those in configuration files, services, tasks, applications etc. The best part is, no one knows what the passwords are unless they go to this system to recover it which generates an audit trail around who what when where and why which makes auditors happy, increases network and data security, fills a huge audit hole regarding attestation for who had access to the accounts, and provides for reporting at the touch of a button. Then, when someone leaves on good or bad terms, there is not a question about what knowledge are they taking with them and did we remember to change the password.

I agree with the GPO to add group to the Deny logon locally policy to prevent use of the account to directly access a system. This does not however provide enough restriction for these types of accounts. Designated "Service Accounts" are granted to be used to configure Windows services to run as this account locally or to be used for network service connections such as database credentials within web applications with back-end databses. Another key configuration we do with the service accounts is to add it to a "service account group", set it for primary group, and remove user object from default "domain users" group. Many domain and web ressources are granting access to "domain Users" group by default and never changed. The service account with the shared password and password never expiration allows access to resources that is not auditable to specifc users.
Service accounts should belong to a dsignated domain group only, password provided to a limited defined user base, and password reset each time a member of that user group changes.

BB