ADFS to PingFed and broken PowerShell

When I migrated an Office 365 connection from ADFS 2012 R2 to PingFederate, I ran into two interesting issues. The resolutions may be helpful for others who are going through the same work so I have posted them here.

First, and this one is easy, your certificate signing algorithm has to be SHA1, as Microsoft doesn’t support SHA256 at the time of this writing. PingFed 7.3 does not let you generate SHA1 certs any longer so you’ll have to use a different mechanism such an OpenSSL or the like.

Second (the more interesting problem):  When I migrated from ADFS to PingFederate, I could not longer use PowerShell with the Connect-MSOLService cmdlet if the account I was binding with was itself Federated.  For example, if account “Sam” was an Active Directory user, synchronized with DirSync, then I could not make a successful connection with Connect-MSOLService.  However, if the account was Cloud-only (, then I could make the connection successfully.

The error I would receive when attempting to connect is as follows:

Connect-MsolService : Exception of type
'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was
At line:1 char:1
+ Connect-MsolService
+ ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], MicrosoftOnlineException
+ FullyQualifiedErrorId : 0x800488FC,Microsoft.Online.Administration.Automation.ConnectMsolService

After spending a reasonable amount of time Googling that “0x800488FC” error code (along with related error text) and came up empty, I reached out to Microsoft for help.  I’ll spare you the painful details but suffice it to say – Microsoft was unable to help me.

Let me cut to the chase: When I configured Ping – I configured the WS-Trust STS and the WS-Fed components separately (like so):

Bad Configuration

As you can see, I have two different connections… one for each protocol. Each have a unique EntityId (“urn:federation:MicrosoftOnline” and “o365STSentityId”) and a different VirtualID (“XXX:SAML1:PROD” and “urn:federation:XXX”).

Now, caveat lector: I am not certain of root cause… I am going to tell you the changes I made that immediately fixed the issue along with a brief analysis. I did not have the opportunity to collect as much evidence as I would have liked. Still, the narrative is compelling.

The solution started with a friend of mine suggested that since one can configure WS-Trust inside a WS-Fed connection in PingFederate, that I merge these configuration together (Spoiler: That fixed my problem).

So, I exported both connections – just in case – and then disabled and then deleted the “Office 365 (STS)” connection from the screen shot above. I then configured the WS-Fed configuration to include the WS-Trust settings that I had just removed (but now all included in a single connection instead of two). At the end of the day, I had a connection that looked like this:


And again, note that connection contains the WS-Trust configuration settings that I had removed:


So what happened here that fixed my problem?

Well the first thing is – and it can be seen in the first screen shot – the EntityIDs were different. This is because Ping enforces all connections to have unique EntityIDs.

Second thing was that the default VirtualIDs were different (from the second column of the first screen shot).

I believe that either one or both of these have to match for both WS-Trust and WS-Fed to work properly – which means that they’d have to be configured in a ‘merged’ fashion (although I cannot stress enough, I am not certain of this).

For the first issue – the EntityIDs. The WS-Fed has an EntityID of “xxx:SAML1:PROD”. Once the configuration was merged, this is what went ‘live’ (and these were the values we put in the Office 365 configuration with PowerShell).


Additionally – the configuration files originally looked like this:


<md:EntityDescriptor entityID="urn:federation:MicrosoftOnline" urn:name="Office 365" urn:LogLevel="NONE" urn:isActive="true" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:urn="">


<md:EntityDescriptor entityID="o365STSentityid" urn:name="Office 365 (STS)" urn:LogLevel="STANDARD" urn:isActive="true" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:urn="">

Merged (working config):

<md:EntityDescriptor entityID="urn:federation:MicrosoftOnline" urn:name="Office 365" urn:LogLevel="NONE" urn:isActive="true" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:urn="">

The XML export of the configs on all three exported configs (WS-Fed, WS-Trust, and then the merged one at the end) had a series of attributes that looked something like this:

<urn:VirtualIdentity EntityID="AAA:SAML1:PROD"/>
<urn:VirtualIdentity EntityID="urn:federation:BBB"/>
<urn:VirtualIdentity EntityID="urn:federation:CCC"/>
<urn:VirtualIdentity EntityID="urn:federation:DDD"/>
<urn:VirtualIdentity EntityID="urn:federation:EEE"/>
<urn:VirtualIdentity EntityID="urn:federation:FFF"/>
<urn:DefaultVirtualIdentity EntityID="AAA:SAML1:PROD"/>

That last one “DefaultVirtualIdentity” was different on the WS-Trust and WS-Fed connections.

On the merged config, the WS-Fed is the config that “won” and the DefaultVirtualIdentity from the WS-Trust connection (“o365STSentityid”) just fell away as it was not really used for anything other than to keep me from having two connections with the same EntityID.

So at the end of the day – these two changes appears to be the solution. I hope to follow up this post with interesting logs to see what is happening with a little better clarity than this post, but lets call this an ‘early release’ just in case others are having the same issue.



2 thoughts on “ADFS to PingFed and broken PowerShell

  1. Very nice write up… An interesting item I found with 8.2 is that it now fails to save as it seems to need to validate pre save. Had to export the connection as an xml and then add the entry there and then re import it to get around the validator


  2. Hey Michael, that’s interesting. If you get an opportunity, would you mind replying with a little more detail on the issue (was it exactly the same?) and your steps to repair so future readers may benefit from your experience?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s