On this page
Why it happens
Error 15247 means the action you attempted is controlled at the server (instance) level, and your login does not hold the permission or role membership needed to perform it. Creating a login, altering a server configuration option, managing another user, and some backup or restore operations are all guarded this way, so SQL Server rejects the statement before it runs.
This error is broader than the database-scoped permission errors. Where error 229 and error 262 fire when you lack rights on an object or inside a single database, 15247 fires when the action reaches across the whole instance, so it needs a server-level permission such as ALTER ANY LOGIN or CONTROL SERVER, or membership in a fixed server role.
The message often names the procedure or action that was blocked, for example Procedure sp_addlogin. That tells you which privilege is missing: creating and managing logins needs ALTER ANY LOGIN (or the securityadmin role), while changing instance settings needs ALTER SETTINGS or sysadmin. It is severity 16, a normal permission denial you resolve by granting the right or running as an account that already has it.
Examples
Creating a login as a non-privileged user
-- Connected as a login without ALTER ANY LOGIN
CREATE LOGIN app_user WITH PASSWORD = 'S0meStr0ng!Pwd';Msg 15247, Level 16, State 1, Procedure sp_addlogin, Line 1 User does not have permission to perform this action.
Altering a server configuration option
-- Requires ALTER SETTINGS or sysadmin
EXEC sp_configure 'max degree of parallelism', 4;
RECONFIGURE;Msg 15247, Level 16, State 1, Line 1 User does not have permission to perform this action.
Managing another login you do not control
-- Requires ALTER ANY LOGIN or securityadmin
ALTER LOGIN other_user WITH PASSWORD = 'N3wStr0ng!Pwd';Msg 15247, Level 16, State 1, Line 1 User does not have permission to perform this action.
How to fix it
Grant the specific server-level permission
Ask a server administrator to grant the exact permission the action needs. This is the least-privilege fix: give only what is required rather than a broad role. For managing logins, grant ALTER ANY LOGIN; for full instance control, grant CONTROL SERVER. These are granted in the master database.
-- Run by an administrator (sysadmin), in master
GRANT ALTER ANY LOGIN TO [app_admin];
-- Or, for broad instance-wide control
GRANT CONTROL SERVER TO [app_admin];Add the login to the matching server role
Fixed server roles bundle related privileges. Add the login to securityadmin to let it manage logins, or to sysadmin for full control of the instance. Grant these only to trusted administrators, since they are powerful.
-- Manage logins only
ALTER SERVER ROLE securityadmin ADD MEMBER [app_admin];
-- Full control of the instance (administrators only)
ALTER SERVER ROLE sysadmin ADD MEMBER [dba_account];Run the action under an account that already has the right
If your own login should stay low-privileged, run the administrative statement while connected as an account that already holds the permission, such as a DBA login or a member of sysadmin. This keeps everyday logins limited while still letting the setup task complete.
-- Connect as a DBA / sysadmin login, then run
CREATE LOGIN app_user WITH PASSWORD = 'S0meStr0ng!Pwd';How to prevent it
Reserve sysadmin and securityadmin for database administrators only, and hand out fine-grained server permissions such as ALTER ANY LOGIN or ALTER SETTINGS where possible instead of full roles. This keeps everyday application logins from carrying rights they do not need.
Decide up front which accounts perform setup tasks (creating logins, changing instance settings) and grant them the exact server permission for that task. Application logins that only read and write data should never need server-level rights. For a wider walkthrough of principals, roles, and grants, see the SQL security guide.
Common questions
Which server role lets me create logins?
Membership in the securityadmin fixed server role lets a login create and manage other logins, and the sysadmin role can do it as part of full instance control. If you prefer least privilege, grant the ALTER ANY LOGIN permission instead of adding the login to a role, which allows creating and altering logins without the rest of the securityadmin rights.
How is error 15247 different from errors 229 and 262?
Error 15247 is a server-level (instance-wide) permission denial for actions like creating logins or changing server settings, so it needs a server permission such as ALTER ANY LOGIN or CONTROL SERVER. Errors 229 and 262 are database-scoped: 229 fires when you lack a permission on a specific object such as a table or procedure, and 262 fires when you lack a permission inside a single database. In short, 15247 is about the whole server while 229 and 262 are about one object or one database.
Do I need sysadmin to fix error 15247?
Not always. You only need sysadmin if the blocked action truly requires full control. For most cases you can grant a narrower permission such as ALTER ANY LOGIN or ALTER SETTINGS, or add the login to securityadmin for login management. Whoever grants these must themselves be an administrator.