Print | posted on Saturday, December 14, 2019 10:06 PM
Here’s a quick update on the issue that occurred during my recent Azure AD and SharePoint sessions at SharePoint Saturday Lisbon and ESPC.
For those interested, once I had configured the AAD Enterprise Application and created a Trusted Identity Provider in SharePoint to use it – and attempted a (seemingly successful) login via AAD the glorious Yellow Page of Death was returned by the SharePoint Web Application.
It was, perhaps obviously, a basic error – albeit one that is not *that* obvious, especially when you are brutalised by a head cold and a very dodgy furry podium! :) After booting the machines and going thru the motions to reproduce the error with a clean configuration, the event log held the answer…
After the AAD login process, everyone’s third favourite ASP.NET event is logged – 1309. Useless in it’s own right, but the inner exception bubbles up is a “specified argument was out of the range of valid values” – from CreateSessionSecurityToken. Experience (mostly with legacy ADFS) told me straight away to check the system clock – and yes – the time is out by one hour. One hour ahead of the actual time. Thus the expected behaviour. It doesn’t work. Good! It’s not supposed to. it would be a pretty shitty authentication mechanism if time wasn’t part of the token!!
Alas, the SharePoint error is as much use as a fart in a spacesuit – but hey, this *is* SharePoint we are talking about – and as referenced in the presentation – there are no changes in the core of AuthN/Z within the On-premises product.
So, a rookie error – but it seems after a recent VMWare update the time sync had been disabled. As soon as I fixed the time and reattempted a login as Miles Davis, everything works, and I was taken back to the default Sharing/Request Access UX.
Simple. It always is. Totally my fault. But i’m blaming all the silly time zone madness I’ve had to accommodate over the last six months!
s.