April 11, 2018 at 8:30 am
Eric M Russell - Wednesday, April 11, 2018 7:57 AMThere is an alarming issue when using SQL Server authentication that many DBAs don't consider. Keep in mind that once an application or user logs in, there is nothing preventing them from changing the account password using ALTER LOGIN statement and thus blocking any other users from logging in. An account doesn't need sysadmin membership to change it's own password.ALTER LOGIN TestApp WITH
OLD_PASSWORD = 'TheOriginalPassword'
PASSWORD = 'HaHaHa@ImSoEvil';
That's more an alarming issue with letting people share login information regardless of whether it's SQL Server, AD, or any other system that stores login information.
April 11, 2018 at 8:59 am
ZZartin - Wednesday, April 11, 2018 8:30 AMEric M Russell - Wednesday, April 11, 2018 7:57 AMThere is an alarming issue when using SQL Server authentication that many DBAs don't consider. Keep in mind that once an application or user logs in, there is nothing preventing them from changing the account password using ALTER LOGIN statement and thus blocking any other users from logging in. An account doesn't need sysadmin membership to change it's own password.ALTER LOGIN TestApp WITH
OLD_PASSWORD = 'TheOriginalPassword'
PASSWORD = 'HaHaHa@ImSoEvil';That's more an alarming issue with letting people share login information regardless of whether it's SQL Server, AD, or any other system that stores login information.
For domain authenticated service accounts, the AD admin can disable account's permission to change the password, so there is some level of centralized control. However, as far as I know, the DBA can't similarly disable user password reset permission for SQL accounts.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 11, 2018 at 9:07 am
Just wanted to throw this out. I've setup and used gMSA in the past. Although I'm no expert at it.
There are many other links on this topic on the internets.
April 11, 2018 at 9:08 am
Eric M Russell - Wednesday, April 11, 2018 8:59 AMFor domain authenticated service accounts, the AD admin can disable account's permission to change the password, so there is some level of centralized control. However, as far as I know, the DBA can't similarly disable user password reset permission for SQL accounts.
If you really want to disallow SQL users changing their passwords, you can set a trigger on ALTER_LOGIN that throws an error and rolls back any attempts to change the password.
That practice seems ill advised to me, but it's not hard to do and since it's a trigger, you've got a lot of flexibility. For example, you could create a database with a table such that only logins that correspond to records in that table are unable to change their password.
April 11, 2018 at 10:30 am
Eric M Russell - Wednesday, April 11, 2018 8:59 AMZZartin - Wednesday, April 11, 2018 8:30 AMEric M Russell - Wednesday, April 11, 2018 7:57 AMThere is an alarming issue when using SQL Server authentication that many DBAs don't consider. Keep in mind that once an application or user logs in, there is nothing preventing them from changing the account password using ALTER LOGIN statement and thus blocking any other users from logging in. An account doesn't need sysadmin membership to change it's own password.ALTER LOGIN TestApp WITH
OLD_PASSWORD = 'TheOriginalPassword'
PASSWORD = 'HaHaHa@ImSoEvil';That's more an alarming issue with letting people share login information regardless of whether it's SQL Server, AD, or any other system that stores login information.
For domain authenticated service accounts, the AD admin can disable account's permission to change the password, so there is some level of centralized control. However, as far as I know, the DBA can't similarly disable user password reset permission for SQL accounts.
This would only happen if you let users run SQL statements. Run everything through Stored Procedures and don't allow direct reads and writes!
Student of SQL and Golf, Master of Neither
Viewing 5 posts - 46 through 49 (of 49 total)
You must be logged in to reply to this topic. Login to reply