I have yet to get a confirmation from Microsoft that this was the result of an update. But considering it worked a week ago (the week of April 3, 2017), and doesn’t work this week (April 10, 2017) I can only assume that’s what it was. They also had several users with issues logging into Office 365 via ADFS starting the same time we experience our issue, so I’m also assuming the two were somehow related. My specific issue was with Office 365, ADFS and CSOM.
So what actually happened…
It used to be the case, that when using ADFS, you could store credentials in a PowerShell variable for both cloud managed account or ADFS accounts. You could then use those stored credentials to connect to Office 365. Something like:
|
1 2 3 |
$cred = Get-credentials Connect-SPOService -url https://tenant-admin.sharepoint.com -Credentials $cred Connect-MsolService -credentials $cred |
If you want to use CSOM with PowerShell, or the <a href=”https://github.com/SharePoint/PnP-PowerShell” target=”_blank”>Office 365 Dev PnP PowerShell CmdLets</a>, they have to stored the credentials so you can do something like:
|
1 2 |
$Creds = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($User,$Password) $Context.Credentials = $Creds |
Well, as of Friday afternoon on April 7, 2017 we started getting strange errors with some of our scripts.
Connecting to SharePoint Online we get:
Connect-SPOService : The remote server returned an error: (503) Server Unavailable.
Connecting to Azure AD we see:
Connect-MsolService : Authentication Error: Bad username or password.
Connecting to Exchange Online results in:
New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message : [ClientAccessServer=DM5PR12CA0065,BackEndServer=sn1pr04mb2061.namprd04.prod.outlook.com,RequestId=4efc5dde-c6a6-4d7d-9b28-d313796b9bbd,TimeStamp=4/11/2017 8:32:52 PM] Access Denied For more information, see the about_Remote_Troubleshooting Help topic.
The work around (there is no fix)
We eventually figured out, and Microsoft has since confirmed, that this is a result of using ADFS accounts stored in a variable and the way Office 365 now authenticates ADFS users. If you want to use PowerShell you must do one of the following:
1. Use a Cloud Managed account
2. Run Connect-SPOServivce and Connect-MsolService without -credential and put your ADFS credentials in the resulting popup
3. Use CSOM with a Cloud Manged Accounts…no ADFS for you
Conclusion
Again, Microsoft hasn’t directly confirmed a change or patch that was applied last week that changed how PowerShell, ADFS and CSOM (or just storing credentials in a variable) all interact with each other, but I can’t think of any other reason for the scenario described above. I do have confirmation from Microsoft though that they’re lab environment behaves the same way…yes, they had to go test it, this obviously wasn’t a documented or known issues before today, at least to Office 365 Support. They also informed me that this isn’t a bug, going forward, don’t use ADFS credentials unless you plan to authenticate with the popup dialog box.
Want to stay up to date on even more Office 365, SharePoint and Azure News? Sign up for the Intelligink Newsletter https://www.intelligink.com/newsletter/
Prefer audio instead of reading, I co-host a Podcast focused on IT Pros talking all about Office 365 and Azure. You can listen to the latest podcast (as well as subscribe to future episodes and listener participation emails) here: https://www.msclouditpropodcast.com