I have a new logical server on which I will be restoring an existing Azure SQL Data Warehouse database from a different logical server.
I've reviewed https://learn.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-restore-database-portal but need to understand how the LOGINs are handled on the new MASTER database. USERs exist on the database to be restored and they relate to LOGINs on the old MASTER database.
Do the LOGINs have to be manually CREATEd on the new MASTER before the restore occurs?
The logins have to be created on the MASTER of the new logical server. This can happen anytime before you re-create the users in the DW. After you have the Logins created, you then need to drop and re-create the users in the DW that you restored to the new logical server. That will associate your users in the DW with the logins in master.
If you have AAD integration with your on-premises AD in place and enabled for your DW, these steps are not needed.
Related
Since the cloud-sql-proxy already forces individual user authentication with the database through a users iam account, and allows specifying read / write permissions, it seems potentially pointless to also have an individual database accounts for each user as well.
For security, is it necessary to have a database user per dev when using cloud-sql-proxy, or is it fine to just have one database user, since they are already authenticated by the time they can enter a database user / password anyways. I'm not a server dev or a DBA, so I thought it best to ask.
In fact, you have 2 levels of permissions
Cloud IAM allows you to access to Cloud SQL product or not
Database user management allows to log into the db engine and to get the db engine permission (access to a specific schema, one schema per developer, on the same SQL instance for instance).
The hosted database engine are based on MySQL, PostgreSQL or SQL Server. All those databases have their legacy user authentication in place. You have to deal with.
I have a Django app that fetches DB secret from AWS Secret Manager. It contains all the DB parameters like username, password, host, port, etc. When I start the Django application on EC2, it successfully retrieves the secret from the Secret Manager and establishes a DB connection.
Now the problem is that I have a password rotation policy set for 30 days. To test the flow, at present, I have set it to 1 day. Every time the password rotates, my Django app loses DB connectivity. So, I have to manually restart the application to allow the app to fetch the new DB credentials from the Secret Manager.
Is there a way that secret fetching can happen automatically and without a manual restart of the server.? Once way possibly is to trigger an AWS CodeDeploy or similar service that will restart the server automatically. However, there will be some downtime if I take this approach.
Any other approach that can seamlessly work without any downtime.
If the old DB credentials are invalidated immediately during the rotation, then it will probably be pretty difficult to do this without some downtime. One option would be to have your app catch the credential error and (try to) fetch the new secret at that point from Secrets Manager, creating a new DB connection. Another other option is to have two valid user/password pairs, leaving the old valid while creating the new. I'm not sure if automatic rotation gives you this option. Then you can restart your app as you like. To do even that without a brief outage probably requires a load balancer and multiple instances of your application running, so that you can up one with new creds before you terminate the old one.
This was previously answered in how to use new secret created by key rotation.
If you are using multi user rotation (the "Use a secret that I have previously stored in AWS Secrets Manager" option in the console) you can use the Secrets Manager python caching library to cache and periodically refresh the secret.
If you use the single user rotation option you will need to write a connection wrapper (similar to the JDBC wrapper) that refresh the credentials when you get an error establishing a new connection.
I have a Power BI workbook that I have created in Desktop. It sources from a SQL Server database. I can access this database with account x. My Azure tenant admin has created a data source for this database in our gateway (within the Power BI service), and I have access to this gateway. The admin supplied account y in connecting to this data source. How does this work when I go to refresh the dataset that this workbook creates when I publish it to the service? That is, when I schedule a refresh on the dataset, will it dial into the SQL Server database using account y provided in the data source definition (virtually ignoring / dropping account x's credentials)?
Yep. That's exactly how it works. The automated refresh will use account 'Y.'
Data sources that have been deployed to some hosted location will almost always disregard the credentials used to create the dataset and instead use credentials that are specifically supplied for the refresh. These 'service' accounts will typically have different rules about password resets, have the lowest appropriate levels of access, and be under the prevue of system administrators rather than report authors. Its a very standard practice. It protects against misuse, error, loss of accounts, and segregates actual user activity from automated behaviors in the logs.
However, it is a little odd to me that your admin 'created the datasource' -- is that correct? Or did the admin just wire up the gateway to the datasource that was deployed when you published?
If you want to use a datasource that is already published, then you need to connect to that datasource from PowerBI desktop. Otherwise you'll be pushing out something new that has nothing to do with the resources that your admin created.
i'm used wso2 api manager v2.2.0 for api gateway, and i've problem for backup users and roles, at the moment i'm used api-import-export-2.1.0, but just backup APIs, any advice for my problem?
Users and roles are in the user database, therefore you need to backup your user database (or any other userstore you use).
By default WSO2AM comes with H2 embedded database which is not really recommended (or suited) for production deployment and you should setup your own databases on any supported DB system.
If you still use the the embedded H2 database, by default the user database file is located at repository/database/WSO2CARBON_DB.h2.db , however I don't recommend to backup/copy the file while it is open (while wso2am is running).
I have successfully created an AWS RDS SQL Server 2016 instance. I specified a master user name and password. I was able to log into that instance via SSMS using the master user name and password. I then created a database. However, it seems the master user doesn't have any permissions to do anything in that database, such as creating any schema objects. What do I have to do to have essentially db_owner permissions in the database I just created?
Going to sound funny, but try resetting the master user password. Don't know why it works, but it worked for me with a similar problem.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.ResetPassword.html