Tag Archives: adfs

Notes from the field, tech

Kaspersky encrypted connection scanning breaks ADFS login, internet-facing Dynamics CRM

I was asked to look at a case where a user could not log in to Dynamics CRM. This is an internet-facing deployment which uses ADFS (Active Directory Federation Services). The user put in valid credentials but received a 401 – unauthorized: Access is denied due to invalid credentials.

The odd thing from the user’s perspective is that everything worked fine on other PCs; but switching web browsers did not fix it.

I noticed that Kaspersky anti-virus was installed.

image

Pausing Kaspersky made no difference to the error. However I came back to this after eliminating some other possible problems. I noticed that if you looked at the certificate on the ADFS site it was not from the site itself, but a Kaspersky certificate.

image

The reason for this is that Kaspersky wants to inspect encrypted traffic for malware.

I understand the rationale but I dislike this behaviour. Your security software should not hide the SSL certificate of the web site you are visiting. Of course it is particularly dislikeable if it breaks stuff, as in this case. I found the setting in Kaspersky and disabled both this feature, and another which injects script into web traffic (though this proved not to be the culprit here), for the sake of Kaspersky’s “URL Advisor”).

Personally I feel that encrypted traffic should only be decrypted in the recipient application. Kaspersky’s feature is an SSL Man-in-the-Middle attack and to my mind reduces rather than increases the security of the PC. However you made the decision to trust your anti-virus vendor when you installed the software.

There are other anti-virus solutions that also do this so Kaspersky is not alone. As to why it breaks ADFS I am not sure, but regard this as a good thing since the user’s SSL connection is compromised.

image

As it turns out, it isn’t essential to disable the feature entirely. You can simply set an exclusion for the ADFS site by clicking Manage exclusions.

Posted here in case others hit this issue.

.net, microsoft, professional, software development, visual studio, windows, windows 7

Cracks appear in Microsoft’s bundled installers for Visual Studio 2010 as I try ADFS

2 Comments

I am trying out Microsoft Active Directory Federation Services (ADFS), chasing the dream of single sign-on between on-premise Active Directory and the cloud.

Oddly, although ADFS has been around for a while, it feels more bleeding edge than it should. ADFS is critical to Microsoft’s cloud platform play, and it needs to build this stuff right into Windows Server and .NET rather than making it a downloadable add-on.

The big problem with installers, whether on Windows or elsewhere, is dependencies and versions. You get some variant of DLL Hell, when A requires the latest version of B, and C requires an old version of B, and you need both A and C installed. The issue on Windows has reduced over the years, partly because of more side-by-side installations where multiple versions co-exist, and partly because Microsoft has invested huge effort into its installers.

There are still issues though, and I ran into a few of them when trying ADFS. I have Visual Studio 2010 installed on Windows 7 64-bit, and it is up-to-date with Service Pack 1, released in April. However, after installing the Windows Identity Foundation (WIF) runtime and SDK, I got this error when attempting to start Visual Studio:

image

Only some of the Microsoft Visual Studio 2010 products on this computer have been upgraded to Service Pack 1. None will work correctly until all have been upgraded.

I’m guessing that the WIF components have not been updated to take account of SP1 and broke something. Never mind, I found my Visual Studio SP1 .ISO (I avoid the web installs where possible), ran setup, and choose to reapply the service pack. It trundled along until it decided that it needed to run or query the Silverlight 4 SDK setup:

image

A dialog asked for silverlight_sdk.msi. I wasted some time over this. Why is the installer looking for silverlight_sdk.msi in a location that does not exist? I’d guess because the Silverlight SDK installer is wrapped as an executable that unpacked the MSI there, ran it and then deleted it. Indeed, I discovered that both the Silverlight 4 SDK and the Silverlight 4 Tools for Visual Studio are .EXE files that wrap zip archives. You can rename them with a .zip or .7z extension and extract them with the open source 7 Zip, but not for some reason with the ZIP extractor built into Windows. Then you can get hold of silverlight_sdk.msi.

I did this, but then discovered that silverlight_sdk.msi is also on the Visual Studio SP1 ISO. All I needed to do was to point the installer there, though it is odd that it cannot find the file of its own accord.

It also seems to me that this scenario should not occur. If the MSI for installation A might be needed later by installation B, it should not be put into a temporary location and then deleted.

The SPI repair continued, and I got a reprise of the same issue but with the Visual C++ runtimes. The following dialog appeared twice for x86, and twice for x64:

image

These files are also on the SP1 .ISO, so I pointed the installer there once again and setup continued.

Unfortunately something else was wrong. After a lengthy install, the SP1 installer started rollback without so much as a warning dialog, and then exited declaring that a fatal error had occurred. I looked at the logs

I rebooted, tried again, same result.

I was about to trawl the forums, but thought I should try running Visual Studio 2010 again, just in case. Everything was fine.

image

Logic tells me that the SP1 “rollback” was not quite a rollback, since it fixed the problem. Then again, bear in mind that it was rolling back the reapplication of the service pack which is different from the usual rollback scenario.

Visual Studio, .NET, myriad SDKs that each get updated at different times, developers who download and install these in an unpredictable order … it is not surprising that it goes wrong sometimes; in fact it is surprising that it does not go wrong more often. So I guess I should not beat up Microsoft too much about this. Even so this was an unwelcome reminder of a problem I have not seen much in the last few years, other then with beta installs which play by different rules.

azure, cloud computing, development, facebook, internet, javascript, php, professional, software development

Single sign-on from Active Directory to Windows Azure: big feature, still challenging

Microsoft has posted a white paper setting out what you need to do in order to have users who are signed on to a local Windows domain seamlessly use an Azure-hosted application, without having to sign in again.

I think this is a huge feature. Maintaining a single user directory is more secure and more robust than efforts to synchronise a local directory with a cloud-hosted directory, and this is a point of friction when it comes to adopting services such as Google Apps or Salesforce.com. Single sign-on with federated directory services takes that away. As an application developer, you can write code that looks the same as it would for a locally deployed application, but host it on Azure.

There is also a usability issue. Users hate having to sign in multiple times, and hate it even more if they have to maintain separate username/password combinations for different applications (though we all do).

The white paper explains how to use Active Directory Federation Services (ADFS) and Windows Identity Foundation (WIF, part of the .NET Framework) to achieve both single sign-on and access to user data across local network and cloud.

image

The snag? It is a complex process. The white paper has a walk-through, though to complete it you also need this guide on setting up ADFS and WIF. There are numerous steps, some of which are not obvious. Did you know that “.NET 4.0 has new behavior that, by default, will cause an error condition on a page request that contains a WS-Federation authentication token”?

Of course dealing with complexity is part of the job of a developer or system administrator. Then again, complexity also means more to remember and more to troubleshoot, and less incentive to try it out.

One of the reasons I am enthusiastic about Windows Small Business Server Essentials (codename Aurora) is that it promises to do single sign-on to the cloud in a truly user-friendly manner. According to a briefing I had from SBS technical product manager Michael Leworthy, cloud application vendors will supply “cloud integration modules,” connectors that you install into your SBS to get instant single sign-on integration.

SBS Essentials does run ADFS under the covers, but you will not need a 35-page guide to get it working, or so we are promised. I admit, I have not been able to test this feature yet, and aside from Microsoft’s BPOS/Office 365 I do not know how many online applications will support it.

Still, this is the kind of thing that will get single sign-on with Active Directory widely adopted.

Consider FaceBook Connect. Register your app with Facebook; write a few lines of JavaScript and PHP; and you can achieve the same results: single sign-on and access to user account information. Facebook knows that to get wide adoption for its identity platform it has to be easy to implement.

On Microsoft’s platform, another option is to join your Azure instance to the local domain. This is a feature of Azure Connect, currently in beta.

Are you using ADFS, with Azure or another platform? I would be interested to hear how it is going.