I want to setup a Windows Azure development storage on my dev machine but I don't want to install SQL server on it because I want to use an existing one on another machine. Is it possible to set up the development storage service so that it uses the SQL server from another machine?
I tried calling dsinit with the /sqlinstance argument set to the remote machine, but it doesn't have any argument to allow me to specify the login credentials.
You can use undocumented command line argument /server:.
Example: dsinit /server:remote-sql-name
Added reservation for http://127.0.0.1:10000/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10001/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10002/ in user account DOMAIN\username.
Creating database DevelopmentStorageDb20110816...
Granting database access to user DOMAIN\username...
The login already has an account under a different user name.
Changed database context to 'DevelopmentStorageDb20110816'.
Adding database role for user DOMAIN\username...
User or role 'user' does not exist in this database.
Changed database context to 'DevelopmentStorageDb20110816'.
Initialization successful. The storage emulator is now ready for use.
I think the short answer is no. Certainly dsinit is designed to only work on your local machine.
Can you setup the remote database server to use windows authentication and add the currently logged in user as an admin on that server? That may be enough to fool it (but I wouldn't hold my breath)
If this doesn't work and you still don't want to SQL on your development machine, then using the actual Azure storage is not a bad idea. It does cost some money, but not much and it does avoid some of the kinks that occur only in development storage.
Related
I set up a Storage Container (Blob) and a Role Assignement (Storage Account Contributor) to a App Registration with a client Secret-> so I can query the blob files in a runbook as a service principal. So far so fine. App Registartion has API Permission to Azure Storage and it run fine.
I then wanted to check my error-handling and output of the runbook when permissions are missing and removed the API Permission to Azure Storage on the App Registration. And nothing changed at all...The runbook succesfully created storage context and down-/uploaded the file without problem.
After some digging, I noticed that the object-id of the App Registration is different when I look at it in Access Control (IAM) of the storage container than when I load the object in Azure Active Directory (see pic below). So I thought well there must be some "noise" and removed and re-added the Role Assignement to the container. I then run into the error as expected.
After successfully worked on my error-handling i re-applied the permissions and...the error wont disapear. So I again looked at the objects and again...die object-ids where different. I had to remove the RBAC and re-add it to reflect the permission change. After re-adding still the same issue. I have different ID's.
Does anyone know why thats different? And why wont it reflect the permission change withour remove-re-add?
Thank you!
Storage Container vs AAD:
Azure AD app registration is backed by 2 directory objects: an application and a service principal. As its name implies, the latter is the principal for authentication/authorization. Thus, you will see 2 object ids.
Regarding the access issue, all the principal (user or service) needs is an RBAC role assigned, thus adding or removing application permissions won't make a difference.
The Laravel Vapor database documentation states:
To quickly create a publicly accessible database of the smallest performance class, you may use the --dev flag when creating your database. These small, affordable databases are perfect for testing or staging environments
I have created a dev database with the suggested vapor database dev-db --dev command, and a public db.t3.micro has been created in AWS, but when I go to add an additional user to the database with the vapor database:user dev-db user1 command I receive an error that a jumpbox is required:
Whoops! There were some problems with your request.
A jumpbox is required to create database users.
The documentation about private/public databases states:
In addition, these databases may be publicly accessible (with a long, random password automatically assigned by Vapor) or private. Private databases may not typically be accessed from the public Internet. To access them from your local machine, you will need to create a Vapor jumpbox.
Since the --dev database creation command creates a publicly accessible database, why is an error returned stating that a jumpbox is required?
That sounds like a bug unless you tried to create the user before the database finished provisioning
I'm trying to apply the 'Application Administrator'role to a service principal to allow it to create other service principals in AD. I would have assumed that having the ability to manage all aspects of app registrations etc as explained in the docs here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/users-groups-roles/directory-assign-admin-roles.md would have allowed me to do this but i still cannot create new service principals in this way?
It looks as if it has created when looking in AD App Registrations but errors out with insufficient privileges
I have tried several approaches through bash & powershell, trying to create the AD application first then creating a service principal from that application id, also tried with the 'Global Admin' role and that works as expected however we're trying to limit as much as possible.
The command i'm trying to run in bash is
az ad sp create-for-rbac -n $spn_name --skip-assignment
And the equivalent in powershell
New-AzAdServicePrincipal -ApplicationId $appid
From an SPN with only the 'Application Administrator' role assigned.
Creating service principal failed for appid 'http://test-spn1'. Trace followed:
{Trace JSON}
Insufficient privileges to complete the operation.
To grant an application the ability to create, edit and delete all aspects of apps (both Application objects and ServicePrincipal objects, represented in the portal under App Registrations and Enterprise Apps, respectively), you should consider the following two app-only permissions (instead of the directory role):
Application.ReadWrite.All - Create Application and ServicePrincipal objects and manage any Application and ServicePrincipal objects.
Application.ReadWrite.OwnedBy - Create Application and ServicePrincipal objects (and automatically get set as owner), and manage Application and ServicePrincipal objects it is owner of (either because it created them, or because it was assigned as an owner).
These permissions are pretty close to what the Application Administrator directory role allows for users. They're available for both Azure AD Graph API (which is the API used by the Azure CLI, the Azure AD PowerShell module (AzureAD), and the Azure PowerShell module (Az)), and Microsoft Graph API (which you should not use for production scenarios, as the application and servicePrincipal entitles are still in beta). The permissions are documented here:
* https://learn.microsoft.com/graph/permissions-reference#application-resource-permissions
Warning: Both of these permissions are very high privilege. By being able to manage Application and ServicePrincipal objects, they can add credentials for those objects (keyCredentials and passwordCredentials) and in doing so, exercise any access which has been granted to those other apps. If an app granted Application.ReadWrite.All is compromised, pretty much all apps are compromised.
I have been tasked with developing a service that takes requests for admin access to a windows server, receives approval from management, grants access, and then automatically revokes access after an hour.
I am required to do all deployments through Octopus Deploy.
I cannot store the super user password within the service, since all developers have read access to our SVN.
I was planning on storing the password within a secure variable in Octopus Deploy, but then realized that anyone with modification permissions on the project could add a powershell script to send themselves the variable values.
Is there any way to secure a variable within Octopus Deploy that can be used to install a windows service with super user access, but cannot be retrieved by any means?
How I have this setup uses a combination of roles and environments to limit access to sensitive variables such as prod passwords.
You need two roles:
1) is a project editor role that allows developers to do everything but only for Dev/UAT environments. This allows them to get everything ready and tested without access to the prod environment.
2) a production editor role which only a few people have access to. Production password variables are scoped to the Prod environment so developers can't access them.
I have a computer that is used for getting database information from the server in the same domain, and this computer is used by employees who don't have the server admin information.
When the computer restarts, I'd like it to automatically log in to Windows Server so that it can access the database files. Is it possible to write a script for this that runs on boot?
Thanks in advance
I solved this by adding the credentials to the Credentials Manager in Windows, along with disabling the Windows Server dashboard program. This makes Windows automatically log in to the server with the stored credentials on boot.
Since your question really isn't specific, I'd like to suggest two ways of accomplishing your goal.
Since you'd like to access database information, why not use some kind of database management software (like SSMS if you're using MSSQL) and set up proper permissions for the user/computer that will need to obtain information from that particular server/database.
If you need access to raw files (which doesn't make much sense in case of MSSQL for accessing purposes), why not set up proper permissions on the file or parent folder, giving the user that is logged to the client PC proper permissions to access the files that are of interest.