Azure B2C : Tracking errors

I've posted before on how crucial Application Insights is to troubleshooting B2C custom policies.

Once you had got it setup, you need to wait about 5 minutes and then run something like:

traces

This displays all the data. You can sort by clicking on the "timestamp column".

 Expand the "message" section.

Expand the "FatalException" section.

and you'll see the error.

If you want to filter the errors, try something like:

traces
| where severityLevel > 0 and message contains "Exception"

Enjoy!

Azure B2C : Custom policies with ADFS

Azure AD B2C has custom policies in preview that enable you to add extra IDP / social to B2C via an "Identity Framework" that is a collection of XML files that document standards, orchestrations, user journeys etc.

Using this you can add providers that use either SAML or OpenID Connect.

So ADFS 4.0 was a good candidate for OIDC.

As per my SO question:

"I have ADFS 4.0 on an Azure VM and am trying to add ADFS as a provider to my Azure AD B2C tenant.

I have set up all the custom policies.

I am using OpenID Connect as the protocol.

My ADFS SSL certificate is self-signed and I have certificate rollover for the encryption and signing certificates.

The error I get in Application Insights is: 

Exception {"Kind":"Handled","HResult":"80131501",

"Message":"The remote certificate is invalid according to the validation procedure.","Data":{}} Kind Handled HResult 80131501 

Message The remote certificate is invalid according to the validation procedure.

I battled for hours trying to get this to work before asking the question.

Turns out:

"Your ADFS needs to have a valid SSL cert signed by the standard Certificate Authorities in order for Azure AD B2C to communicate with it".

So no self-signed. As this was a proof on concept, I'm not intending to go out and buy a certificate. This is further complicated by the fact that you can't buy a certificate for xxx.cloudapp.net!

Tip - to debug the custom policies you need Application Insights. Without that, your chances of solving the issues are effectively zero.

Enjoy!

ADFS : Issue with updating the SSL certificate

Using ADFS 4.0 and updating the SSL certificate.

This is on an Azure VM and I was accessing it remotely.

Ran the normal commands:

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint thumbprint

Set-AdfsSslCertificate -Thumbprint thumbprint

Error :

Set-AdfsSslCertificate -Thumbprint 24f...b35

Set-AdfsSslCertificate : PS0319: Validation task 'Test-_InternalAdfsSslCertificate' on AD FS server 'localhost' failed with error 'Connecting to remote server localhost failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

As per the message, running:

winrm qc

and then re-running the command fixed the problem.

Enjoy!

ADFS : SAML SLO

SLO = Single log out.

The way this is supposed to work is described in the SAML specification.

For one customer, they had 6 RP and one of then didn't do SLO properly and didn't return a logout response.

This stopped all the others getting called, clearing cookies etc. so it was a "half a logout" solution.

Eventually, I simply removed the SLO endpoint for the RP via the ADFS wizard.

Everything then worked correctly.

The RP with issues was still logged in and if you knew the URL you could still continue but at least the bigger picture worked.

I should point out that this RP was the only one that did not use an industry standard SAML stack and had instead tried to roll their own. You may draw your own conclusions :-)

Enjoy!

Identity : Breached passwords

Troy Hunt has an interesting feature over on Introducing 306 million freely downloadable pwned passwords.

All the passwords that have been in a breach are searchable.

If there is a hit, it's either out there or someone else make the same password selection as you did (decreasing security).

But there's also a section on how to utilise this for Identity Management.

When you ask the user to select a password, check it against this list and reject if there is a hit.

Azure AD uses a similar approach where they reject all "common" passwords.

Enjoy!