Just yesterday I ran into a really weird issue with, what turned out to be, the Azure AD PowerShell Module when credentials save in a variable and Azure AD cmdlets were combined with the SharePoint Dev PnP cmdlets. This same issue occurs both in an Azure Runbook (working on a future blog post and where I first discovered the issue) as well as on a normal Windows desktop (where I was able to replicate the issue). It also only seems to occur if you’re using the latest version of the Azure AD Module. Not the preview, but the GA V2. Module Version number 2.0.0.115 is where this first seems to surface.
The Original Issues
The PowerShell code I was using looked just like this:
|
1 2 3 |
$cred = Get-AutomationPSCredential -Name "PowerShell" Connect-AzureAD -Credential $cred Connect-PnPOnline https://tennant-admin.sharepoint.com -Credential $cred |
In the past this has worked flawlessly. Store the credentials in a $cred variable so I can use it over and over again, and then connect to various systems. I use this a lot on the desktop as well only use Get-Credential to save my credentials so I don’t have to type them over and over again. However, what started happening yesterday is when running the code above I would get the following error:
|
1 2 3 4 5 6 |
Connect-PnPOnline : The remote server returned an error: (403) Forbidden. At line:4 char:1 + Connect-PnPOnline https://tennant-admin.sharepoint.com -Credentia ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Connect-PnPOnline], WebException + FullyQualifiedErrorId : System.Net.WebException,SharePointPnP.PowerShell.Commands.Base.ConnectOnline |
Ok, I know my credentials are good because I can connect to Azure AD, I know it’s not ADFS or anything like that because I was actually using a cloud only account, but I couldn’t figure out for the life of me why Connect-PnPOnline was getting a 403 error. Did Microsoft change something with permissions for connecting to SPO with PowerShell as a Global Admin and licensing? Come to find out, this issue wasn’t with SPO, or the PnP cmdlets, it was with the AzureAD Module.
So, the latest version of the AzureAD Module somehow corrupts, erases, re-writes something in the $cred variable. You can still do $cred.username and $cred.password and they contain values. However, they don’t work with Connect-PnPOnline if they’ve been used for Connect-AzureAD first. I didn’t confirm it’s the Azure AD Module as well as I had an older run book as well as a computer, that didn’t have the latest AzureAD Module installed and they worked fine. As soon as I updated to the latest version, those environments had the exact same issue.
The fix?
Simple, get your credentials a second time 🙂
I updated my runbook code to this:
|
1 2 3 4 |
$cred = Get-AutomationPSCredential -Name "PowerShell" Connect-AzureAD -Credential $cred $cred = Get-AutomationPSCredential -Name "PowerShell" Connect-PnPOnline https://tennant-admin.sharepoint.com -Credential $cred |
Notice the Get-AutomationPSCredential before each Connect- cmdlet? As long as I go grab the credential a second time before issuing the Connect-PnPOnline command, everything works just fine. This isn’t a big deal in a runbook since the credentials are already stored, but doing anything locally, it means I have to type in my credentials multiple times. Even storing a backup set of credentials in a different variable didn’t work. The only way around this was to go get the credentials a second time.
Hope this saves someone else hours of banging there head on the desk and feel free to leave a comment if you have any further insights into what is going on here. If I find any more details I’ll be sure to update as well!
Also, for more on PowerShell and Office 365, go listen to our latest podcast where Scott and I spend 30 minutes just talking about using PowerShell with Office 365.