I have created 2 azure security groups (Read-SQL and the second is Write-SQL) in order for them to login into multiple Azure SQL servers via SSMS using their Azure AD identity based on their group membership in order to access multiple databases on those services.
First of all I have configured an admin group on the SQL Server in our Azure tenant.
I have connected to the SQL via SSMS using my credentials and so far so good.
After that I opened a query and typed in master database
CREATE USER [SQL-READ] FROM external provider
ALTER ROLE db_datareader ADD MEMBER [SQL-READ];
(Did the same thing for Write-SQL)
only the user is created and no permission given with an error saying the user does not exist or I don't have permission.
I have Azure global administrator permission in Azure and I don't know why I get this error.
In the bottom line I would like that Read-SQL and Write-SQL will be able to login in to the SQL Server and have access to all databases within it as well as giving Read-SQL reading permissions and to Write-SQL writing permission.
I read a few Microsoft articles but I got even more confused since I don't know if I need to create a login or create a user or a contained user.
Please help
Thank you
Here are few screenshots for better understanding
enter image description here
enter image description here
Read the following articles but only partial success.
https://www.mssqltips.com/sqlservertip/6751/azure-ad-authentication-azure-sql-databases/
https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure?view=azuresql&tabs=azure-powershell#create-contained-users-mapped-to-azure-ad-identities
https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-overview?view=azuresql
https://learn.microsoft.com/en-us/sql/relational-databases/security/contained-database-users-making-your-database-portable?view=sql-server-ver16
Whether you should create a login, user or contained user will depend on your access and security requirements. However, in Azure SQL Database, users are created per database. So, you can create the login in the master database and then you need to create the associated user in each database on that SQL Server.
This documentation gives more information on creating logins, users and contained users for Azure SQL Database.
I have a SQL Server 2017 database instance that was created before I was given administration of the database and I have a Login at DB server level named "atSupervisor" which is a user in database "StaffMonitoring". I wish to clone the login and user "atSupervisor" as login and user "bcSupervisor" in database "StaffMonitoring" to have all permissions, table access, grants etc.
I have tried a few suggestions on google such as this example - https://www.mssqltips.com/sqlservertip/3589/how-to-clone-a-sql-server-login-part-1-of-3/
This seems to creates the login and user and I can then assign the database "StaffMonitoring" in User Mapping in the login's properties and login with the user. However, none of the tables are present.
Is there a way to do this please that clones everything to include grant access to tables that mirrors the original login\user?
Greetings,
When I login into a particular MSSQL database as sa I see the following: somebody moved a database from server A to server B using restore option. I can see all the users in place (restored along with the database) - great. There are logins previously created on server A - great. All of those logins have sysadmin role. I think there's one problem - I don't see any mappings done between logins and users on server B (currently I have no access to Server A so I can't look at the configuration).
According to security properties - all of those 'local' database users are 'SQL user without login' - but I'm sure a proper application uses those users on a regular basis and there are configuration files where passwords are stored.
Question #1 - if there's a login with sysadmin role and there's a local database user of the same name (as login) - does the application use login or local db user in order to work properly? (there's no mapping between the two)
Question #2 - should mapping be done between all the logins and corresponding database users when moved from one server to another? At the moment there isn't any mapping done and my cooworkers are using logins with sysadmin role to access whole database.
Regards,
1) If a particular login has the sysadmin role the application or person using this login can do anything on the database server. It is generally not considered good practice to have a lot of sysadmin users because it opens up the database server (and more) to security breaches.
2) Mapping SQL logins to database users makes sense if the users have minimal server-wide permissions and if you want to assign several certain data access rights in different databases. For example, you have a login X but users Y and Z and want to have read-only permissions for user Y in database Y but read-write permissions for user Z in database Z; in this case mapping can be useful.
There is something else you should be mindful of. If you backup a database (including database SQL users) on server A and restore the database on server B and the database users that are residing on server A were not created on server B using the same SID for the corresponding login(s) you end up with orphaned users, meaning the name of the login is not important to SQL Server but the SID of the login is.
You can find the SIDs in system login tables:
SELECT * FROM sys.sql_logins
SELECT * FROM sys.syslogins
To make sure the login on both servers is exactly the same (same SID!) you have to create the logins using a script like this:
CREATE LOGIN MyTestUser WITH PASSWORD=N'!#MyTestPassword#$', SID=0x552C84CB83802C4A801C670265CCAFA4, DEFAULT_DATABASE=tempdb, DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
Hopefully this helps.
I have a Premium P2 SQL Azure Database for my Production App, and for security reasons I've created DB Specific Schemas/Views/Roles and a specific DB User account for reading the Data from SSRS Queries.
Lets just call the server PRIMARY and my database MyApp
The setup script for this is below.
-- On Primary Master
CREATE LOGIN ssrsuser WITH password='******'
-- On Primary MyApp
CREATE USER ssrsuser FOR LOGIN ssrsuser
CREATE ROLE [ssrsreader] AUTHORIZATION [db_owner]
GRANT SELECT ON SCHEMA :: [App] TO [ssrsreader]
GRANT SELECT ON SCHEMA :: [Reports] TO [ssrsreader]
EXEC sp_addrolemember 'ssrsreader', 'ssrsuser'
So our users were putting a LOT of load on the Prod DB and we decided it was time to move the reporting functions off to a secondary sync'd slave database.
Since we're using the SQL Azure Premium Tier, we can enable Active Geo-Replication with a read-only secondary copy. In fact MS even say that it's suitable for read-only workloads such as reporting.
So I've setup the SECONDARY server, enabled the seeding, it's now complete and I can access the readonly copy using the SECONDARY admin user and password.
But the SECONDARY server doesn't have a login for ssrsuser and I while I can create one in SECONDARY.master, I can't DROP RECREATE the user since the SECONDARY.MyApp database is in readonly mode.
Is there any otherway to get around this. I really don't want to have to put the SECONDARY server admin user & password into SSRS connection strings.
There is no need to regenerate SID for ssruser in the user database. It is already there as a result of replication. All you need to do is associate that SID with a LOGIN in the master in the secondary server. This article provides the details.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-geo-replication-security-config/
I hope this helps.
How can you hide databases you do not have access rights to when logging into SQL Server 2005 / 2008?
Currently if a user connects, they see all the databases on the server, meaning they have to scan though the list to find their database.
After hours of trying to figure out how to create a user account which only has access to 1 DB, and can only see that DB. I think i figured it out!!!!
Create a user account ( make sure its not mapped to any Database, otherwise you will get the final error Msg 15110, Level 16, State 1 and note proposed solution)
USE [master]
GO
CREATE LOGIN [us4]
WITH PASSWORD=N'123',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF,
CHECK_POLICY=OFF
Right Click on the upper section of the SQL (SQLSERVER Name)>Properties>Permissions>Click on the user account, and select Deny to view databases.
use [master]
GO
DENY VIEW ANY DATABASE TO [us4]
Right Click on the newly created DB, Properties,Files, and change the Owner to the newly created account.(important note: ALTER ROLE [db_owner] ADD MEMBER [us4] does not work)
USE [dbname]
GO
EXEC dbo.sp_changedbowner #loginame = N'us4', #map = false
At this point, once the user logs in he will see the Master,tempdb and will also see the new DB which he is a DB Owner of..You may want to go to Tools>Option and enabled the option to hide system objects so that you don't show the master,tempdb,etc. You may also need SP1 if this option does not work
Msg 15110, Level 16, State 1, Line 1
The proposed new database owner is already a user or aliased in the database.
proposed solution to Msg 15110: to resolve above error simply delete the user from database security node and try again
Hope that helps...
Nikhil
This actually won't work the way that makes sense or that you might expect that it would.
You REVOKE VIEW ANY DATABASE from the public role, but then the user has to be the database owner of the database or it can't be seen, but it still can be accessed.
The problem is a Database Engine Security shortcoming and not likely to be fixed in the current or future release of SQL Server.
Erland Sommarskog opened the following connect item for this a while ago, and it recently was discussed on twitter and with Microsoft by the SQL MVP's.
Vote for the connect and help make it more of a priority for Microsoft to fix:
Connect Feedback
Basically the permissions are stored at the database level, so it would require enumerating each database to determine if the user has connect rights to display the database in the object explorer, which is an expensive task to perform and how the older EM used to do things.
The proposes solution is for this information to be maintained at the server level as well, which is a major change.
You would need to revoke the permission 'VIEW ANY DATABASE' from the role PUBLIC (SQL SERVER 2005 onwards)
Add user to DB as Db owner after removing VIEW ANY DATABASE rights
This will show only the database owned by the login in SSMS.
USE master; GO
DENY VIEW ANY DATABASE TO [loginname]; GO
USE [your db]; GO
DROP USER [loginname]; GO
USE master; GO
ALTER AUTHORIZATION ON DATABASE::[your db]TO [loginname]; GO
Note: this requires the login to exists already
There appears to be a server-side setting on MS SQL 2005 and 2008 to restrict the databases a user may see. I found the following text at sql-server-performance.com
In SQL Server 2005 it is possible with a new server side role that has been created. VIEW ANY DATABASE permission is a new, server-level permission. A login that is granted with this permission can see metadata that describes all databases, regardless of whether the login owns or can actually use a particular database. Please note By default, the VIEW ANY DATABASE permission is granted to the public role. Therefore, by default, every user that connects to an instance of SQL Server 2005 can see all databases in the instance.