Why should you care?

Wrong auth mode blocks apps; shared sa passwords cause breaches.

See it live — copy this example

Run in SQL Server Management Studio (SSMS) or Azure Data Studio.

USE master;
-- Create a SQL login (lab password — use strong secrets in real life)
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = N'dataverse_login')
    CREATE LOGIN dataverse_login WITH PASSWORD = N'ChangeMe!_LabOnly1';
USE DataVerse;
IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = N'dataverse_user')
    CREATE USER dataverse_user FOR LOGIN dataverse_login;
SELECT SUSER_SNAME() AS LoginName, USER_NAME() AS DbUser;

What happened?

• CREATE LOGIN makes an instance principal; CREATE USER maps it into your database.
• SUSER_SNAME/USER_NAME show your current identities.

Practice next

1. Create the login and user in lab.
2. Connect SSMS as dataverse_login and run SELECT USER_NAME();
3. Prefer Windows auth for people when possible.
4. ALTER LOGIN dataverse_login DISABLE; then ENABLE.
5. Check sys.server_principals for the login.

Remember

Login = instance; user = database. Windows or SQL authentication. Never run apps as sa.

App login per environment

DataVerse_App_Prod login is unique and vaulted.

Outcome: Leaked staging secrets cannot open production.