Office 365 IdP

  • 64 Views
  • Last Post 2 weeks ago
AlLilianstrom posted this 3 weeks ago

Has anyone ever changed the IdP for a Office 365 environment?

Currently using ADFS. Looking to move to Ping Federate. Docs available for configuring a new O365 installation with Ping. Can't seem to find anything for moving from ADFS to Ping. Ping support hasn't been able to help as of yet.

Any ideas?

al

--
Al Lilianstrom
Group Leader - Authentication Services

Fermi National Accelerator Laboratory
www.fnal.gov
lilstrom@xxxxxxxxxxxxxxxx

Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
AlLilianstrom posted this 2 weeks ago

Ravi,

 

We’ve found exactly the opposite. Our cloud vendors were a breeze to setup with Ping Fed rather than ADFS.



 

On prem – other than SharePoint our SPs are Apache based. Works with either Ping or ADFS. It was easier on Ping. Not being tied to a OS, the management console and API, flexible authentication adapters, the ability to work with a Shibboleth

IdP in a very unique way, and excellent support made the Ping license cost worth the money.

 

                al

 

--

Al Lilianstrom

Group Leader – Authentication Services

 

Fermi National Accelerator Laboratory

www.fnal.gov

lilstrom@xxxxxxxxxxxxxxxx

 

show

AlLilianstrom posted this 2 weeks ago

Thanks Bob. I appreciate the help.

--
Al Lilianstrom
Group Leader - Authentication Services

Fermi National Accelerator Laboratory
www.fnal.gov
lilstrom@xxxxxxxxxxxxxxxx

show

rwf4 posted this 3 weeks ago

Ping was ultimately selected as the federation platform of choice. We also already had it deployed for a number of workloads.  

 

ADFS had been stood up in the interim for O365 while final decisions were made because it was so easy and could integrate with the existing solutions we had on the edge.. (our

entire edge infrastructure was revamped concurrent to the O365 POC)

 

Final decision was largely due to integration with the MDM solution we are heavily entrenched in.



 

Allegedly it played nicer with Ping than ADFS, I assume because 3rd parties like to integrate with each other more simply to add to the value proposition of paying

for the licensing J

 

 

show

Ravi.Sabharanjak posted this 3 weeks ago

I am curious what the drivers for moving off ADFS are. We have ping I'd and if there was not a big ping installation, we would have moved off to ADFS. A lot of the cloud stuff is easier to deploy using ADFS versus ping, leaving aside the yearly licensing cost of ping.
On Sep 28, 2017 6:11 PM, "Free Jr., Bob" <RWF4@xxxxxxxxxxxxxxxx> wrote:
Al-



This is roughly what I did. YMMV because I don't know your Ping environment but this is what Pro Services had us do for our environment (ADFS ---> PING)



#break existing federation



Set-MsolDomainAuthentication -DomainName contoso.com -Authentication Managed



#wait 15 mins and check it took ... Get-Msoldomain should show managed



#CUTOVER to PING after


#make sure cert file is all on one line with no CR/LF



$domainName = "contoso.com"


$pingfederate = "https://pingwhatever.contoso.com"


$issuer = "urn:pingwhatever"


$brandName = "Contoso"


$spId = "urn:federation:MicrosoftOnline"


$activeLogOn = "$pingfederate/idp/sts.wst"


$logoff = "$pingfederate/idp/prp.wsf"


$metadata = "$pingfederate/pf/stsmex.ping?PartnerSpId=$spId"


$passiveLogOn = "$pingfederate/idp/prp.wsf"


$certFile = "C:\temp\pingdev\MyCert.crt"


$cert = [IO.File]::ReadAllText($certFile)



#one line, probably wrapped



Set-MsolDomainAuthentication -DomainName $domainName -Authentication Federated -IssuerUri $issuer -LogOffUri $logoff -PassiveLogOnUri $passiveLogOn -ActiveLogOnUri $activeLogOn -FederationBrandName $brandName -SigningCertificate $cert -MetadataExchangeUri $metadata -PreferredAuthenticationProtocol WSFED



HTH



--bob


show

rwf4 posted this 3 weeks ago

Al-

This is roughly what I did. YMMV because I don't know your Ping environment but this is what Pro Services had us do for our environment (ADFS ---> PING)

#break existing federation

Set-MsolDomainAuthentication -DomainName contoso.com -Authentication Managed

#wait 15 mins and check it took ... Get-Msoldomain should show managed

#CUTOVER to PING after
#make sure cert file is all on one line with no CR/LF

$domainName = "contoso.com"
$pingfederate = "https://pingwhatever.contoso.com"
$issuer = "urn:pingwhatever"
$brandName = "Contoso"
$spId = "urn:federation:MicrosoftOnline"
$activeLogOn = "$pingfederate/idp/sts.wst"
$logoff = "$pingfederate/idp/prp.wsf"
$metadata = "$pingfederate/pf/stsmex.ping?PartnerSpId=$spId"
$passiveLogOn = "$pingfederate/idp/prp.wsf"
$certFile = "C:\temp\pingdev\MyCert.crt"
$cert = [IO.File]::ReadAllText($certFile)

#one line, probably wrapped

Set-MsolDomainAuthentication -DomainName $domainName -Authentication Federated -IssuerUri $issuer -LogOffUri $logoff -PassiveLogOnUri $passiveLogOn -ActiveLogOnUri $activeLogOn -FederationBrandName $brandName -SigningCertificate $cert -MetadataExchangeUri $metadata -PreferredAuthenticationProtocol WSFED

HTH

--bob

show

rwf4 posted this 3 weeks ago

BTDT. Looked all over for advice, in the end ee got a script from Ping Prof Services. I'll find it and share with you. It was pretty straightforward. Worst part was not getting all the hidden CR/LFs out of the cert and it silently failing :-(

show

Anthony.Vandenbossche posted this 3 weeks ago

Hi,

You can remove the Relying party on ADFS and perform this cmdlet against
Azure AD (Connect-MSOLService):

Set-MsolDomainFederationSettings -DomainName $domain -IssuerUri $issuer
-PassiveLogOnUri $passiveLogon -ActiveLogOnUri $activeLogon
-MetadataExchangeUri $mexUri -SigningCertificate $signingCert

Potentially (not entirely sure - haven't done this too many times), you will
need to convert the MSOL domain to managed before running above cmdlet:

Set-MSOLDomainAuthentication -DomainName $domain -Authentication Managed

This will redirect authentication requests from the specific domain towards
your Ping Federate deployment.

ANTHONY VAN DEN BOSSCHE
Technical Consultant
Hybrid Cloud

You can mail me anthony.vandenbossche@xxxxxxxxxxxxxxxx
Call me at my UC number +32 2 801 54 59



www.realdolmen.com

This e-mail message and any attachment are intended for the sole use of the
recipient(s) named above and may contain information which is confidential
and/or protected by intellectual property rights. Any use of the information
contained herein (including, but not limited to, total or partial
reproduction, communication or distribution in any form) by other persons
than the designated recipient(s) is prohibited. If you have received this
e-mail in error, please notify the sender either by telephone (+32 2 801 55
55) or by e-mail and delete the material from any computer. Please note that
neither Realdolmen nor the sender accept any responsibility for viruses and
it is your responsibility to scan or otherwise check this e-mail and any
attachments.  Realdolmen is responsible neither for the correct and complete
transfer of the contents of the sent e-mail, nor for the receipt on due
time.

Think green, keep it on your screen

show