Hot answers tagged security
This may not be popular among your users, but I believe the only way you can know for sure is to force a password change for every SQL login with CHECK_POLICY = ON. This will generate a set of ALTER LOGIN commands with blank passwords, you can update the query giving them all a common password or manually update each one with individual passwords - just make ...
There is no way that you are going to get this 100% accurate. Though you can use PWDCOMPARE to check against a list of weak passwords (you can add to the list of weak passwords and do a comparison). I have written a similar script that does the comparison and gives you the results. I have posted it on github.
I found a solution involving a few extra steps. The "tenant_admin" role is still created the same way, but it is now used as follow: postgres=> SET ROLE tenant_admin; SET postgres=> CREATE ROLE "owner3"; CREATE ROLE postgres=> GRANT ...
I faced the same problem and at first, I solved the problem by turning on the TRUSTWORTHY property on the database. But, I find it not a safe way in terms of security. The best practice to tackle this problem is by going to the job steps "-->Advanced-->" make it blank under "Run as user". When you provide a login account under "Run as user", you are telling ...
SQL Server never automatically disables any account. Only a human intervention can do that.... Probably you could put a request for your DBA to provide error logs for the timings you wanted....and you could find the info from the logs....
Grant the necessary permissions on the database RidaDatabase to the user PLESK01\IWAM_plesk
Only top voted, non community-wiki answers of a minimum length are eligible