Enabling public access to SQL Server in Azure devops release pipelines - azure-devops

In order to run migrations on my Test Azure SQL which is configured with PrivateLink I temporarly enable public access and then disable it again.
Set-AzSqlServer
-ServerName $sqlServerName
-ResourceGroupName $(IntegrationResourceGroupName)
-PublicNetworkAccess "Enabled"
And it worked for months, but recently I started receiving this error message.
Cannot find the Azure Active Directory object 'My_DB_Admins_Group_Name'.
Please make sure that the user or group or application you are authorizing is registered
in the current subscription's Azure Active directory. To get a list of Azure Active Directory
groups use Get-AzADGroup, or to get a list of Azure Active Directory
users use Get-AzADUser or to get a list of Azure Active Directory applications use Get-AzADApplication.
Release pipeline was not modified. What might be the reason?
I can execute this PS command from my local machine, as me, and it works fine.

As per the error message : Only azaduser and azadgroup are filtered by azsqlserveractivedirectoryadministrator. It is unlikely that it will look for service principles. You might make an azure ad group called dbas or something similar. To that group, then add the service principal to it.
Then add the group to the sql server using that set-azsqlcommand
$sp = Get-AzADServicePrincipal -DisplayName "theserviceprincipalname"
Add-AzADGroupMember -MemberObjectId $($sp.id) -TargetGroupDisplayName "AAD Group Name"
Set-AzSqlServerActiveDirectoryAdministrator -ResourceGroupName 'data-eastus2' -ServerName 'data-eastus2-sqlsvr' -DisplayName "AAD Group Name"

Related

Azure DevOps agent cannot write to UNC path when Service Account is in a Group

The Problem
When executing my Release Pipeline, I cannot copy a file to a UNC path unless the service account the agent is running under has DIRECT R/W permissions on the destination share. Since we manage permissions using AD groups, adding the service account to several folders in many locations is not scalable nor maintainable. If the service account is a part of a group that has R/W permission to the share, the pipeline fails.
Pipeline Code
I have release pipeline that deployed via Self-Hosted agent. The agent is running under the account MYDOMAIN\SRVACCOUNT. The pipeline has the following Powershell Task step:
Write-Host "User running the script is: $([System.Security.Principal.WindowsIdentity]::GetCurrent().Name)"
$path = "\\server\share\myfolder"
New-Item -Path $path -Name "testfile1.txt" -ItemType "file" -Value "This is a text string." -Force
The pipeline fails on the PowerShell task and says:
New-Item : Access to the path '\\server\share\myfolder\testfile1.txt' is denied
From the logs, it says User running the script is 'MYDOMAIN\SRVACCOUNT', so I assume that it must be running under the correct credentials.
Picture of Windows Service running on the self-hosted agent:
Group Permissions
User MYDOMAIN\SRVACCOUNT is a part of the group MYDOMAIN\APP_ADMINS which has Full Control to the UNC folder path.
When the user is a part of the group the pipeline fails.
When the user is assigned DIRECT Full-Control access, the pipeline success.
When I log as this service account, I can navigate to the folder just fine and create files whether the user has group or direct permissions to the shares.
Would someone be able to educate me why Azure DevOps pipelines fails in R/W permissions to a UNC path when the user is assigned to a group rather than being directly assigned to the folder?
After assigning permissions to the service account, you must restart the Azure DevOps agent on the server (or just restart the server). For some reason, it seems that the permissions/access to the resources is cached at the time the Azure DevOps Windows Service is started up, so restarting it after allocating the new permissions will allow it to work.

Get-AzureNetworkSecurityGroup not working

I try too add some Security roules in my Azure NSG via Powershell, but
Get-AzureNetworkSecurityGroup
doesn't seem to work, it alway returns nothing. I can't select a NSG by Name too
Get-AzureNetworkSecurityGroup -Name myname
Although
Find-AzureRmResource -ResourceNameContains nsg
finds my NSGs.
What do I do wrong?
Thanks
Get-AzureNetworkSecurityGroup is meant for NSG's created using the classic deployment model (Old Portal). This will yeild output only if you have classic NSG's in your subscription.
You have indicated that you get output when you use the Find-AzureRmResource commandlet. Now this is a commandlet for the resources created using the ARM deployment model in Azure. One easy way to identify the Resource Manager commandlets is to look for the letters RM in the commandlet.
Looks like you have NSG's created using Resource Manager, so try the following:
Get-AzureRmNetworkSecurityGroup -Name nsg1 -ResourceGroupName "KaushalRG"
Looks for network security group "nsg1" in resource group "KaushalRG"
More information on the deployment models in Azure can be found here: Azure Resource Manager vs. classic deployment

Azure PowerShell - Selecting Subscription

I need to select my Azure Subscription in Azure PowerShell.
I copy/paste the Subscription ID (to ensure no typos) from the Azure Management Portal, it's a hex-string:
When I run:
Select-AzureSubscription -SubscriptionId '0300...'
I get an error message:
Select-AzureSubscription : The subscription id 0300... doesn't exist.
I know my subscription ID is correctly copied from the settings in Azure Management Portal, I even did a BeyondCompare to make sure.
I'm wondering about security... am I missing something? Do I need to somehow provide my Azure credentials? It wouldn't make sense to just allow anyone to select any Azure subscription, unless the Subscription ID is supposed to be super-secret, like an SSN.
You need to log on to your Azure account first:
To start working with the Azure Service Management cmdlets, first log
on to your Azure account. To log on to your account, run the following
command:
Add-AzureAccount
After logging into Azure, Azure PowerShell creates a context for the
given session. That context contains the Azure PowerShell environment,
account, tenant, and subscription that will be used for all cmdlets
within that session. Now you are ready to use the modules below.
Source: https://learn.microsoft.com/en-us/powershell/azure/install-azure-ps?view=azuresmps-3.7.0

Azure Powershell - Can't find classic VMs

I'm trying to retrieve a complete list of VMs through PowerShell, but I'm having trouble pulling Classic VMs, and I'm having trouble understanding the distinction between RM and regular cmdlets, particularly when it comes to subscriptions.
Get-AzureRMSubscription correctly returns a complete list of the subscriptions my Azure account has access to. Get-AzureSubscription returns nothing. This means that I can correctly pull all of the new style VMs from any one subscription using Get-AzureRMVM, but since I can't find a 'classic' style subscription, I can't pull any of my existing classic VMs as I can't define which subscription to look in.
I can successfully view all VMs in all Subscriptions through the portal, but not through Powershell for whatever reason. I'm all out of ideas, is there something I'm missing?
Get-AzureRMSubscription Get-AzureSubscription Get-AzureRMVM are resource mode cmdlet, your VMs are classic mode VM, you should use classic cmdlets. Just use the following cmdlets.
#login your classic account
Add-AzureAccount
# Enumerates all configured subscriptions on your local machine.
Get-AzureSubscription
# Select the subscription to use
Select-AzureSubscription -SubscriptionName "mysubscription"
#get classic VM
Get-AzureVM
Classic VM's were the norm when Azure was used using manage.windowsazure.com where, each virtual machine had a cloud service attached to it by default and resources such as Virtual Networks and Firewalls (ACL) were static to each resource.
Azure Resource Manager (ARM) based deployments gives you the power of having flexible deployment models (e.g. one firewall/NSG for x number of VM's). A detailed study can be found on the below link:
Azure Resource Manager based deployments explained
For your question you can use the below Cmdlets to get all classic virtual machines.
#login your classic (work AD / Personal) account using the pop-up
Add-AzureAccount
# Get All subscriptions under the non-rm account. DO NOT USE Get-AzureRMSubscription for any classic resources
Get-AzureSubscription
# Select the subscription to use using the Subscription name or ID (if all your subscription names say pay-as-you-go for e.g. you may want to use your subscription ID)
Select-AzureSubscription -SubscriptionName "enter-your-subscription-name" OR -SubscriptionId "alternatively-use-subscription-id"
#List all the VM's in a variable for further use (if needed, else direct display)
$vmList = Get-AzureVM
#Output the Virtual Machines on the subscription
Write-Output ($vmList)
Done !

Azure PowerShell start Virtual Machine with RBAC

In the new Azure portal you have the option to use Role Based Access (RBAC). I want to give a user rights to startup and shutdown a virtual machine in Azure. I also don't want that is it possible for this user to create new VM's in Azure so I don't want to make this user Administrator. I gave the user the required rights in the new Azure portal (owner for: the VM, Cloud Service and storage).
When I open PowerShell with the user that has rights on Azure. I first execute the command Add-AzureAccount. After this I execute the following command: Start-AzureVM -ServiceName "MyVM" -Name "MyVM". Then I receive the following error: ForbiddenError: The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.
When I perform this scenario for a Subscription Administrator everything works fine.
Is the described scenario supported by the Azure PowerShell cmdlets? What are possible alternatives?
Thanks in advance
Unfortunately, RBAC through Powershell is currently only available for ARM-resources, i.e. non-"classic" resources in the preview portal, and users needs to have accounts in the Azure AD tenant associated with the subscription. Federated Microsoft accounts will won't work.