Friday, December 9. 2016

When you are, like me, in the middle of a Office 365 deployment after a extensive period of testing, you don't expect serious issues to arise anymore. Well, it will happen, bet on it!

Which issues came up, you ask? Ok, let's start:

First we had some Active Directory Federation Services authentication issues, like described in this article. Those issues were, to be honost, a configuration issue which should have been tackled by Microsoft itself in the first place!

A second issue is that not all messages Office 365 generates makes sense. Like when trying to mount a corrupted .PST file. It starts with a message that the Outlook profile cannot be loaded and a end with a message that not enough system resources are available? The solution for this is to rename all of the .PST files, start Outlook, remove all the archives mounted within Outlook, rename the .PST files to their original name and mount them one by one to find out which one is corrupt.. Atime-consumingway if you ask me!

A third issue we were running into is that you can test days, weeks or even months, but somehow suddenly a program pops up, according to the user a critical application, which cannot be started, cannot spawn Word 365 or cannot print. And all of the problems are due to the Office 365 installation!? Even when the application is from the stoneage, like 2006 er earlier?

Don't misunderstand me, 95% of the deployment process is running smoothly with no issues whatsoever. Only, that last 5% takes so much time to please, solve, convince and migrate..

Sunday, November 20. 2016

After configuring Active Directory Federation Services to synchronize the company AD to Azure AD it's time to start Office 365. Suprisingly sometimes an error occurs when a user is connecting to the configured company ADFS server, stating the connection failed with an error AADSTS50107?

This error is only affecting specific AD users which seem to synchronized correct to the Azure AD. Even creating a copy of the same user recreates the samen issue? So how to solve this?

Rejected Solution

To solve this issue one must determine which AD group or groups are responsible for this issue. So dump all AD groups the user is member of and split those AD groups in somewhat equal chunks. After that, delete all AD groups from that user and start importing the chunks one by one. Test the Office 365 logon between the imports. In my case there was one AD group which was member of a lot of subsequent AD groups. At first I thought this caused the token to grow beyond the maximum size used by ADFS resulting in blocking the user from correct authentication, so I deleted the group from the user.

Real Solution

I'm not really sure the token size was to big to interact with ADFS, but adding that one AD group back to the user recreated the issue, deleting it from the user solved the issue. Last week I ran into a similar issue with another user and again I could pinpoint the issue to a specific AD group (another AD group as above). I decided to try the same, so I deleted the AD group from the user and he could access the Office with no issue. Adding the group back to the user resulted in the same error! Not happy with the solution used earlier I deciced to investigate the issue further. I changed the name with no improvements. I added my own account to the AD group and yes, the same issue! I than decided to delete the AD group and recreate the AD group with the same name, members and properties (it was a security AD group used to set NTFS rights). Issue solved! It looks that the ADFS issue can have something to do with specific AD groups conflicting with ADFS!

After some testing with the AD group casuing the issue, restored using Veeam, I found out the issue is described in this article. Within ADFS there is a rule searching for a group ending on *515, which can return not only the Domain Computers group but also all other groups ending on 515. Putting a '-' before the 515 solves the issue!

There are not a lot of articles out there about this issue, so if this article helps you, please share it.

Thursday, July 28. 2016

First I'm not saying I am a specialist about Active Directory Federation Services (ADFS), but I've been busy with Office 365 and ADFS lately. There are a lot of great sites out there describing the installation and configuration of ADFS, but some issues are nowhere mentioned. For instance, use the Azure AD Connect tool to setup and configure the Azure AD synchronization (one way synchronization from your own Active Directory towards Azure Active Directory). If, like in our case, an ADFS is needed for provisioned Citrix Servers, and a specific server is placed in DMZ to facilitate this, the Azure AD Connect also provides the necessary functionality to create an ADFS configuration. It also provides functionality to create federation for more than one (standard) domain!

One other thing worth mentioning; to be able to log on automatically within a browser one need to configure the logon settings. As an example the settings for Internet Explorer (also possible using a GPO):

Go to Security tab, Internet

Choose Custom Level

Scroll down to User Authentication, Logon and choose Automatic logon with current user name and password