Quick answer: In SSMS, open Security > Logins > New Login, select the existing Windows user or group, configure database mapping and permissions, and create the login. Do not grant sysadmin unless the account genuinely requires unrestricted administrative control of the SQL Server instance.
Before You Start: Login, User, and Role Are Different
A SQL Server login is a server-level security principal. Access inside an individual database is normally represented by a database user mapped to that login. Server roles grant server-scoped privileges, while database roles and explicit permissions control access inside a database.
This distinction matters because creating the login alone does not automatically give the domain account application-level access to every database.
Step 1: Connect to the SQL Server Instance
Open SQL Server Management Studio (SSMS).
Connect to the target SQL Server instance using an account that has permission to create the login and grant the required access. Permission requirements vary by SQL Server version; use a deliberately privileged administrative account rather than broadening the target user's permissions.
Connect to the SQL Server instance in SSMS.
Step 2: Create a New Login
In Object Explorer, expand the server, right-click Security, and choose New > Login....
Open the Login - New dialog from Security > Logins.
Step 3: Select the Existing Domain User or Group
Choose Windows authentication. Enter the Windows principal as DOMAIN\Username, or use Search... to locate it. If necessary, use Locations... to select the correct Active Directory domain, then use Check Names to resolve the account.
Select and verify the existing Windows domain principal.
For teams: where practical, Microsoft recommends granting access through Windows groups rather than maintaining equivalent permissions separately for many individual users. This makes access easier to manage and revoke.
Step 4: Grant Only the Server-Level Permissions Required
The Server Roles page controls server-wide privileges. For an ordinary application or database user, you often do not need to select an elevated fixed server role at all.
Server roles apply at the SQL Server instance level.
Do not use sysadmin as a generic fix for access problems. Members of the sysadmin fixed server role can perform any activity on the instance, and their permissions cannot be denied. Grant it only when unrestricted SQL Server administration is actually required.
Step 5: Map the Login to the Required Database
If the account needs access to a particular database, use the User Mapping page in the Login dialog, select the database, and grant the appropriate database role or permissions. SQL Server permissions inside a database are granted to the database user, not directly to the server login.
Prefer the least privilege needed by the workload. A user that only reads application data should not receive server administration rights just to make a connection succeed.
Step 6: Set the Default Database if Needed
On the General page you can set a default database. This controls the database the login initially connects to when the client does not explicitly request another database. It is not a substitute for creating or mapping a database user with the required permissions.
Set a default database only when it is useful for the connection scenario.
Step 7: Create and Verify the Login
Select OK to create the login. Then expand Security > Logins to verify that the Windows principal is present. If the user needs access to a specific database, also verify its user mapping and permissions.
The equivalent server-level T-SQL is:
CREATE LOGIN [CONTOSO\Mary] FROM WINDOWS;Database access is a separate step. For example:
USE [YourDatabase];
CREATE USER [CONTOSO\Mary] FOR LOGIN [CONTOSO\Mary];
-- Example only: choose a role that matches the required access.
ALTER ROLE [db_datareader] ADD MEMBER [CONTOSO\Mary];Common Problems
The domain user cannot be found
Check that the correct domain is selected in Locations..., that the account exists, and that the machine can resolve the relevant domain.
The login exists but the user cannot access a database
Check the database user mapping and database-level permissions. A server login and a database user are separate principals.
Setting the default database does not fix access
A default database does not grant permission to that database. Map the login to a database user and grant the required permissions.
Should I grant sysadmin?
Only for accounts that genuinely require unrestricted administration of the SQL Server instance. For normal users and applications, use narrower server permissions, database roles, or explicit permissions.
