1
votes

I have written a suite of Powershell scripts that can build out my IAAS infrastructure using Azure Resource Manager. All of these scripts are intended to run non-interactive from a continuous integration framework we use. In the Powershell scripts, prior to calling a command like New-AzureResourceGroup, I first check to make sure machine running the script is authenticated to Azure by running Get-AzureSubscription and Get-AzureAccount. If it finds that it is not authenticated, then it will run a series of cmdlets such as Import-AzurePublishSettingsFile, Select-AzureSubscription, Add-AzureAccount and so on.

This works fine most of the time, and I am able to change subscriptions and credentials each time through and the script will notice the change, and point to the correct subscription and re-authenticate as needed. However, once the Azure account session times out (I think it takes 12 hours), none of the above will work to re-authenticate. If I run something like New-AzureResourceGroup while it is in this state, I will receive the message "Unauthorized".

Once that happens, the only thing will fix it is if I manually run Add-AzureAccount, and manually type in my credentials. Once that is done, my scripts will run fine until the next timeout.

I have read that importing the publish settings file alone should work for this scenario, but re-importing the file doesn't seem to work either. Has anyone else been able to authenticate to Azure from a Powershell script after a timeout?

1
In looking around a bit, I found this article: link In it, it says: The cmdlets in the AzureResourceManager module require the Azure AD method (Add-AzureAccount). These cmdlets do not support publish settings files. So it appears the AzureResourceManager mode has a slightly different authentication mechanism than the AzureServiceManagement mode. This makes sense as a lot of other Azure cmdlets continue to work while New-AzureResourceGroup does not. I might need to ping Microsoft about this.Focker

1 Answers

0
votes

I figured this out, and it was my own dumb mistake. Our company has several Azure subscriptions, and in an effort to not log in and out of subscriptions all the time, I setup my own Azure account to be co-admin on all of them. Unfortunately for me, I created two AzureAutomation accounts...one under my Azure account, and one under the Subscription owner account. This resulted in two accounts that were very similar but slightly different:

[email protected] [email protected]

One was setup as an Admin on the subscription and the other was not. The non-admin was the one I was using in my Powershell script, so the Unauthorized message was completely valid.