January 4, 2022 at 4:03 pm
Hi,
I would like to ask you for 'best practices' regarding password expiration policy for accounts used by linked servers and SSRS, or other applications.
I can see that due to security reasons it makes sense to enforce password policy expiration for all accounts which use SQL server authentication. At the same time, I can see that such a policy may produce additional work. Plus, (what is worse) it seems to be very easy to forget about an account used by a linked server or SSRS report, let it expire, and cause production issues that way...
Could you please advise what is your approach? Should password expiration be forced? If yes, do you have any advice, articles, how to proceed with that wisely, and minimize the risk that any password/lined server will be omitted?
Thanks,
Radek
January 4, 2022 at 5:29 pm
This was removed by the editor as SPAM
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 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply