January 4, 2022 at 6:56 pm
The approach we take at our workplace is that service accounts do not have password expiration in place unless we believe the account has been compromised. The service accounts also lack permission to log into any internal systems. So if a linked server password was compromised for example, you would still need to gain access to our internal system somehow (access to an account with VPN access or access to a computer on-site).
We trust our employees, so changing service account passwords for internal systems has little benefit without other knowledge. On top of that, you would need internal knowledge to know what applications use the account and what it is used for.
Now if you want to change passwords on service accounts or on SQL accounts, I would recommend documenting where it is used and when the password was last used. SOME things may still get missed, but you can do an inventory prior to setting up password expiry then change the password to one account and update the account to follow the password policy and validate you didn't miss anything in your inventory. If anything breaks, change the password back, update the inventory, and repeat the test. Repeat with all of the accounts and then you are good to go.
One big risk you have with changing it to follow password policies is if you have the account lock after so many failed attempts. Why this is a risk is because if the account is used for a linked server that you were aware of AND for a few SQL Jobs, the failed jobs could end up locking the account. Once the account is locked, the linked server will be unusable. This can be more challenging with Windows accounts too as you MAY use the account across multiple instances. It gets locked on one instance, it is locked on ALL instances. This is why we do not change service account passwords unless we believe they are compromised. The risk of the change and missing some application or service could take down a system (or more than 1) and we want maximum uptime.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing post 1 (of 2 total)
You must be logged in to reply to this topic. Login to reply