We have been working on setting up thebuild definition on the on Premise TFS 2015 server, however are stuck with the proxy issue that’s coming while running a build task (Azure powershell). The build task actually makes a call out to Azure to add an authenticated account to be used for Azure cmdlets, but however getting blocked by the proxy server as seen below. We need a way to pass current user credentials to the Azure Powershell cmdlets, any help would be appreciated.
Error Message
Network Access Message: The page cannot be displayed
Technical Information (for Support personnel)
Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. (12209)
IP Address: some IP address
Date: 17/03/2017 09:03:58 [GMT]
Server: ..com
Source: proxy
Tried putting [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials in the custom PowerShell script to be run as the task, however it gets blocked before entering the custom script. Basically, before running the custom script, Azure PowerShell build task tries to run Add-AzureRmAccount which makes a call out to Azure to add an authenticated account to be used for Azure cmdlets where it gets blocked by the proxy.
Finally, had to go to the basics, we switched to simple PowerShell task instead of Azure PowerShell for doing the initial handshake and passing the default credentials to the proxy.
Here's the link to the detailed workaround.
Related
We just upgraded from TFS 2017 to ADS 2020. The ADS runs in one domain and the build server runs in another. All appropriate cross-domain permissions are set up - these domains talk all of the time every day.
I had a service account created for the build server from the ADS domain for the ADS pipeline to run under (even thought the machine is on the other domain) and when we first tried this I got errors that the build didn't have access to write to the registry. This despite the service account (which again is on a different domain than the build server) is in the Administrators group on the build server. At some point that error went away, but now I get an error trying to run a PowerShell script from the build.
Just to summarize, Build Server on Domain1, ADS Server on Domain2, Service account running pipeline is on Domain2, but is part of the Administrators group on Build Server (Domain 1). Pipeline runs fine up until it tries to execute a PowerShell script and then gets an error saying the permissions aren't there to run a script.
Hope this all makes sense.
We have a release pipeline that is failing with following message:
resource ID for resource type 'Microsoft.Web/Sites' and resource name
'appservicename'. Error: Could not fetch access token for Managed
Service Principal. Please configure Managed Service Identity (MSI) for
virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400,
status message: Bad Request
We have 2 different service connections:
Azure Resource Manager using service principal authentication
Azure Resource Manager using managed identity authentication
The first one works like a charm. However, because the developer wanted to limit admin access on the Azure AD, he tried creating a managed identity authentication service connection which at first glance, since it allowed us to select the App Service, appeared to indicate it's working, until an actual deployment was triggered and it failed per the error message above.
After numerous searches online, I think this answer may be the clue to why this is failing with the managed identity authentication service connection yet succeeding with the service principal connection just fine.
I just want to confirm, is this truly the case? that a hosted agent doesn't support MSI based authentication, which is what we are using… or has that changed?
We are indeed using Microsoft agent pool.
It doesn't make sense for our app service to use a VM at this time. The use case just isn't applicable for the dashboards we have.
As it is written in the docs:
You are required to use a self-hosted agent on an Azure VM in order to use managed service identity
I assume that it was alway like that. Here we are talking abut MSI assigned to VM which serves as build agent. Not MSI which is identity of App Service. Why? Service Connection is an abstraction which makes easy authentication to your Azure Subscription. So it gives identity to VM and then when your perform some action against your Azure thanks to MSI Azure know that can perform that action. Another aption is authentication via Service Principal, but thi can be done from any VM (inlcuding MS Hosted) because it relies on Client Id and Client secret which is kept in service connections. And MSI have to be assigned to particular VM which cannot be done with MS Hosted agents.
We were originally using Start-AzureWebsite and Stop-AzureWebsite in a powershell script to start and stop web apps in Azure before publishing. In the VSO build it was using Azure Powershell, the connection type was Azure Classic. Microsoft recommended switching to Start-AzureRmWebApp and Stop-AzureRmWebApp which uses the Azure Resource Manager. We modified the Azure Powershell step in the build to have a connection type of Azure Resource Manager, and selected the correct subscription. When it calls our external script using the script path, it appears as though the authentication is not being passed on to the script, we get the error "Run Login-AzureRmAccount to login." when it tries to execute the command to start/stop the websites. How do we get the authentication to persist down to the script being called?
Not sure why the connection get lost, it should work if you dotsource the script to invoke it. However:
I would suggest to create a service principal within the AAD that is linked to your subscription and grant it access to your web app. Then you should use the existing Azure App Service Manage Task to start / stop your app:
By the way, starting / stopping / deploying a web app should be part of a Release Definition / Step - not build.
-
Turns out instead of using Connect-AzureRMAccount i needed to be using Add-AzureRmAccount, once i changed that i can now connect and start/stop App Services! Thank you for the help. – Link
I am trying to publish to a service fabric cluster secured using Azure Active Directory from PowerShell calling Deploy-FabricApplication.ps1 as part of a TeamCity build configuration.
I have been unable to find how you provide credentials in this situation.
I did notice in Deploy-FabricApplication.ps1 that there is a SecurityToken parameter for Active Directory.
Is this what you need to pass to authenticate, and if so how can you generate the security token within PowerShell?
I have set up a user within my Azure Active Directory for TeamCity that I am hopping to authenticate as.
The token can be acquired by making use of the Active Directory Authentication Library (ADAL), specifically by calling the method AcquireToken in Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.
A good example of this being used can be seen in the code for the VSTS Service Fabric Deploy task at: https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/ServiceFabricDeploy/utilities.ps1.
There's a function in that file called Get-AadSecurityToken which shows the call to the AuthenticationContext.AcquireToken method.
You need to ensure that you have both the cluster app ID and the client app ID. Both of these are retrievable from the cluster by calling Connect-ServiceFabricCluster with the -GetMetadata switch (this is also done in the Get-AadSecurityToken function).
I have some powershell scripts in my CI server to check the state of some WebJobs.
But I have few problems.
I'm using publish settings file, but it expires and my build starts to fail.
I don't want to use a Management Certificate that will expose all management features.
And I don't want to put my user credentials on the CI server that will also expose all management features.
There is any way to create a CI user or credential with restricted permissions?
Thanks!
Azure Functions provides a good solution to this problem. You can create a Service Principle account, with certificate login and then restrict that account to whatever actions you need it to allow (via RBAC)
You can then have an Azure PowerShell script running in Functions, that is called from a webhook from your CI engine. That way the only credentials that are stored on your CI are the webhook secret, and if your CI engine has a static IP you can verify that commands only come from that address, and drop anything else.