SQL Server 2016 - Availability Groups - How To Copy Permissions To Secondary Node [duplicate]

Question

This question already has an answer here:

Proper way to create logins on Always on (1 answer)

Closed 8 months ago.

• SQL Server 2016
• SSMS v18.4

I want to create the same logins and give the same privileges on both node.

In primary node I have no problem about this operation.

But when I create the same login on secondary node and want to user mapping, it gives below error:

Create failed for login 'loginname'.

Additional information:

An exception occured while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

Failed to update database "dbname" because the database is read-only. (Microsoft SQL Server, Error:3906)

But my database is not read-only.

I'm trying the give permission like this:

Node 2 (Secondary) -> Security -> Logins -> Right click on MyLogin-> Properties -> User Mapping -> Select database and choose dbo for default schema -> Select public and db_owner -> OK.

It gives this error all of the databases for secondary node.

How can I solve this problem without doing failover (failover can solve this because it does primary node to Node-2 but I don't want to failover)?

If it possible with using PowerShell, how can I do it on this operation on PowerShell for Node-2?

Thank you.

Best regards,

Answer 1

1. Use sp_help_revlogin procedure to safely script SQL logins and their passwords (and Windows-authenticated Logins as well), so you can re-create all those logins on secondary replica with exactly same SIDs, as they have on primary replica

https://support.microsoft.com/en-us/help/918992/how-to-transfer-logins-and-passwords-between-instances-of-sql-server

2. After you create all necessary logins on secondary replica with same SIDs as on primary, you need to use ScriptLoginPermissions procedure, find out if your logins on primary replica have any server-level permissions.

Those are permissions that are stored in the master database. If any of your logins have any server-level permissions on primary, you need to grant those permissions on secondary replica to these logins. ScriptLoginPermissions procedure helps you to generate T-SQL for that, it can be found here:

https://github.com/aleksey-vitsko/Database-Administrator-Tools

3. Database level permissions, that are granted at user-database level, you do not need to grant those at secondary replica. And you do not need to do login to user mapping at secondary replica. Because any permission or user changes at primary, are copied to secondaries automatically, in Availability Groups.

You do not need to do any failover, all database-level permissions on primary, are also synchronized to secondary replica. You can't do any changes to permissions on secondary replica's, because user databases there are in read-only state

p.s. Important to have logins on primary and secondary replicas with matching SID (security identifiers, which can be seen at sys.server_principals)