We have started working with some customers who are looking into implementing The New Dynamics AX (aka AX 7) and one of the very useful features in AX are integration with the Microsoft Office. This has historically been done using an Office Addin which has been installed from the AX Install CD (of deployed by IT). In the new AX version this is done a little differently. You need to install a plugin from the Office Store (which I talk about here).
The other day one of my colleagues came to me and told me that it did work to use the Excel workbook creator… the login failed . The login started, the user was redirected to our ADFS site and it was visible for a moment and then it was redirected to a blank place with the address: https://az689774.vo.msecnd.net/dynamicsofficeapp/v220.127.116.11/App/DynamicsApp.html#id_token
This is an issue with Office and how Office handles ADFS logins according to this article. According to Microsoft this has been fixed in the 16.0.6868.2060 build of Office 2016. This build is at the moment (2016-05-20) only available for Office Insiders which means that if you are using Office 365 your admin needs to enable you for Current Channel and you need to reinstall Office.
I have a Microsoft Account which is the same as my company account… normally this works very good and you get to choose which one to use (not right now though and that is why there is no screenshot). At this moment I do not get to choose and I immediately end up on my company ADFS logon page.
To try to get around this I found a link (long live Google) which sends me directly to a page where I log on using Microsoft Account
Sign in here and then click home and you will be taken to the Azure Portal
Today I spent the day at a customers looking at a XP computer (I know they are supposed to be extinct) having problems authenticating using ADFS. As we know XP is using IE8 and IE8 in combination with XP does not support Server Name Indication. Turns out SNI is on by default in ADFS 3.0… bummer
Fortunately it is fixable:
Start by getting information about the SST Certificate using:
netsh http show sslcert
The we bind the IP:port combination to the SSL cert using (in an elevated command prompt):
netsh http add sslcert ipport=[ipaddress : port from above] certhash=[Certificate Hash from above] appid=[appid from above] certstorename=MY
These steps needs to be taken on both the ADFS server and the Web Application Proxy
IMPORTANT: This works as long as the Web Application proxy is not doing anything else but working as a “ADFS Proxy”