Tag Archive: ADFS


Scrap my last post… Today I found I could no longer login to sharepoint and other federated services were acting strangely. I tried to troubleshoot but ultimately gave up.

Finally came the time to see if my weekly VM backups (and nightly incrementals) were actually any good… 15 minutes later and everything’s back to how it was 2 night’s ago!

Screen Shot 2015-04-21 at 15.48.06

Thankfully Veeam worked a treat and ADFS was back working perfectly BUT we still have our expiring SSL warning.

Screen Shot 2015-04-21 at 21.00.32

My theory as to what went wrong before… Whilst I had updated my SSL certificates on my on-premise ADFS server (including the token signing certificate), I think the Office365 hosted servers also need this same matching certificate. So, let’s try a different approach.

This time I followed a different link http://www.kraak.com/?p=190. I started the same way as before, replacing the SSL certificate in IIS. However, I didn’t update the token-signing or token-decrypting certificates in ADFS. Instead I issued the following commands;

Connect-MsolService
Get-MsolFederationProperty -DomainName tickett.net

At this stage, I can essentially see that both the ADFS Server (on-premise) and Microsoft Office 365 (hosted) certificates match;

Screen Shot 2015-04-21 at 21.16.46

At this point I noticed that, not only did they (obviously) bare the old dates, but they also bare the internal server name (and not the FQDN of either my old or new SSL certificates for IIS). This further backs up my theory that using the same certificate for IIS and ADFS yesterday was wrong. And in fact, it appears ADFS generates it’s own certificates when instructed to do so;

Update-ADFSCertificate -CertificateType: Token-Signing -Urgent:$true
Get-MsolFederationProperty -DomainName tickett.net

Screen Shot 2015-04-21 at 21.24.05

Right, we’re part way there. The ADFS Server certificate has now been renewed, but the Microsoft Office 365 certificate now needs to be updated;

Update-MsolFederatedDomain -DomainName tickett.net
Get-MsolFederationProperty -DomainName tickett.net

Bingo, now they both match! Exactly the same sequence of commands now needs to be executed for the token-decrypting certificate;

Update-ADFSCertificate -CertificateType: Token-Decrypting -Urgent:$true
Update-MsolFederatedDomain -DomainName tickett.net

And voila! I can now login perfectly to all my federated/SSO application/sites and Office365 webmail no longer warns me about a certificate approaching expiry.

Advertisements

*EDIT* This turned out to fail, please read the follow-up post; https://tickett.wordpress.com/2015/04/21/second-attempt-updating-adfs-ssl-certificate-on-windows-server-2012-r2/ 

I noticed a warning in Office 365 webmail that my SSL certificate was due to expire soon and hoped updating it would be a trivial task.

As always, I used https://www.startssl.com/ to generate a new certificate. I fired up IIS on the ADFS server and imported the new certificate (Server Certificates, Import). When I tried to bind the certificate to the ADFS https site I received a warning/error about a missing intermediate CA certificate. This was easily fixed by downloading the “Class 2 Intermediate Server CA” certificate from StartSSL and importing into the windows certificate store under Intermediate Certificate Authorities (Launched from the start menu by searching for “Manage computer certificates”);

Screen Shot 2015-04-20 at 17.07.17

Binding to the site in IIS was now successful. However, none of my federated applications were working. Just an ADFS error;

Screen Shot 2015-04-20 at 17.14.57

And some errors to match in the event log;

Screen Shot 2015-04-20 at 17.17.14

On each login attempted I was received the following 3 events;

Event: 111

The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.microsoft.com/idfx/requesttype/issue

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)

Event: 1000

An error occurred during processing of a token request. The data in this event may have the identity of the caller (application) that made this request. The data includes an Activity ID that you can cross-reference to error or warning events to help diagnose the problem that caused this error.

Additional Data

Caller:
TICKETT\lee

OnBehalfOf user:

ActAs user:

Target Relying Party:
http://adfs.tickett.net/adfs/services/trust

Device identity:

User action:
Use the Activity ID data in this message to search and correlate the data to events in the Event log using Event Viewer. This Activity ID will also be shown as additional information in the error page when an error occurs in the federation passive Web application.

Event: 364

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSingOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSingOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)

The earlier Office365 warning did link to a page which also included instructions for updating the certificates within ADFS, so I went ahead and did that too (In ADFS Manager, Set Service Communications Certificate, Add Token-Signing Certificate and Add Token-Decrypting Certificate). But still nothing… restarting didn’t help either.

Eventually I found an article with a few powershell commands; http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/13/replace-certificates-on-adfs-3-0.aspx

Get-AdfsSslCertificate

Screen Shot 2015-04-20 at 17.24.02

Comparing this to the new certificate, I can see that it doesn’t match;

Screen Shot 2015-04-20 at 17.25.20

Set-AdfsSslCertificate -Thumbprint NEWSSLCERTIFICATETHUMBPRINT

Screen Shot 2015-04-20 at 17.26.18

Despite returning an error message referencing the old SSL certificate, you can see that the new one is now correctly assigned (by issuing the Get-AdfsSslCertificate command again).

And voila, I can now log in to my federated applications.

*EDIT* This turned out to fail, please read the follow-up post; https://tickett.wordpress.com/2015/04/21/second-attempt-updating-adfs-ssl-certificate-on-windows-server-2012-r2/ 

Office 365 Hosted Sharepoint

Hopefully a quick post…

My company is currently in the process of trying to document everything that’s currently stored in our heads. Initially we were using our helpdesk/ticketing software but decided, in some instances we would like to give our clients access to the documentation which relates to their organisation.

I use mediawiki for some other information sharing, but from what i’ve read, it isn’t really meant for this type of “role” driven access control and trying to use it in that way will ultimately end in failure. I don’t like “documents” (microsoft word etc) so really wanted to stick with a “wiki” style solution. I recall using Sharepoint on client sites historically and remember it handling this scenario pretty well- as we already have an Office 365 subscription it seemed a sensible avenue to explore.

Initial research had me concerned about the ability to share outside of our organisation (needing to purchase a license for every account that should be able to login)- but subsequently it turns out you can either;

-Create users without actually assigning licenses
-Grant access to anyone using their e-mail address (it will need to be linked to a microsoft account, but there is no charge and many already are)

So we have set our creating the Sharepoint sites and it’s coming together really well, but one thing was bothering me… When we login we are presented with a list of “sites”;

Screen Shot 2014-08-29 at 19.54.57

-“New Public Site”: http://tickett-public.sharepoint.com
-“Public Site”: http://tickett.sharepoint.com
-“Team Site”: http://tickett.sharepoint.com/TeamSite

If you clicked either of the first two links, hopefully you were redirected to http://tickett.net? But this wasn’t easy and I was pretty confused why I had two public URLs/sites and how could I edit them!

The “New Pubic Site” looked like;

new_public

And the “Public Site” like;

old_public

A bit of googling and I found a reasonable explanation of why I have two sites… Microsoft went through an upgrade at some point in time and to avoid breaking Sharepoint sites they kept all of the old ones and created new ones to site alongside.

As I already have a website I decided I don’t really need either of these so ideally would just like to redirect visitors to my existing site for now.

After a lot of poking around I somehow managed to get to the “New Public Site” in “edit mode” and add a little javascript to redirect visitors to our existing stie;

<script>window.location.href="http://tickett.net";</script>

After adding the code I was successfully redirected when I visited the site but anyone not logged in was not. So… armed with a handful of questions I decided it was time to raise a support ticket. Very quickly the phone ran and a technician was on the case;

#1- How do I edit the “New Public Site”

It didn’t take many minutes before I was informed that simply adding /_layouts/viewlsts.aspx after to the URL would take me to the “admin area” where I could manage the site. Easy… but surely there must be an easier way than typing the URL?

If you refer back to my earlier screenshot you’ll notice a “manage” link. Clicking this allows you to modify the links to the “New Public Site”, “Public Site” and “TeamSite”. Adding the suffix to the URL made sense so now when I login clicking on the site will take me to “edit mode” rather than “view”;

Screen Shot 2014-08-29 at 20.00.03

Well done Microsoft :)

#2- Why is the redirect only working for me?

Once #1 was solved and I was back in to “edit mode” the Microsoft engineer was very quick to pickup on the fact that my change was in draft;

Screen Shot 2014-08-29 at 20.04.04

 

Clicking the … (three dots / ellipsis) displays a menu, clicking the … (three dots / ellipsis) brings out another menu which gives the “Publish a Major Version” option and upon clicking this my change was live and everyone hitting the site was now getting redirected.

Well done Microsoft :)

#3- How do I edit the “Public Site”

So far Microsoft had done pretty well, but really struggled with this one. We have still yet to find a way to edit the site via a web interface.

Eventually, they suggested trying Sharepoint Designer. I’ve not used this before, but since installing have found it to be a pretty good alternative to the web UI. Unfortunately when I tried to open the site I got stuck at the login stage- it appears that Sharepoint Designer doesn’t support federated login (my Office365 logins are authenticated using my on-premise ADFS server). Doh!

But… there was hope… we “shared” the site through the web interface with my personal @gmail address (which is linked to a microsoft account) and I was successfully able to login to Sharepoint Designer- nearly there!

Next problem… the sites doesn’t appear to exist;

Screen Shot 2014-08-29 at 20.29.42

 

Determination and a lot more poking around eventually took us to a link on the front page “Edit site home page”;

Screen Shot 2014-08-29 at 20.53.53

Which threw yet another error, “This page does not contain any regions that you have permission to edit.”. But navigating back a few steps to “Website -> Web Pages” I was able to right click, open with, notepad;

Screen Shot 2014-08-29 at 20.55.47

And add in my script;

Screen Shot 2014-08-29 at 20.57.22 1

So far, so good.

Despite it being a little bit “trial and error”, with Microsoft’s help, we did get there in the end, and very soon after I first raised the support ticket- good job!

%d bloggers like this: