Troubleshooting CRM Authentication on Windows Server 2008

Windows Server 2008 has been out for a little while now. Many of our installs are still on W2K3 boxes, but we’re starting to see more 2008 installations. I recently had the pleasure of having a very funky set of authentication issues in IIS 7. I decided to take a look at all my notes and compile a quick punchlist of items to run through when setting up (or troubleshooting) authentication for CRM on a 2008 server. This also is a good procedure for troubleshooting any Windows Authentication issue for IIS 7.

Make sure the Prerequisites are Met

Easier said than done! Since CRM 4.0 came out before Server 2008, the CRM install program doesn’t exactly check for the required components on a 2008 server. Luckily, Microsoft has released a great KB article that describes the necessary steps (and even how to work around known issues) when installing CRM.

Also, Internet Explorer needs to have it’s security setting to “Allow Automatic Logon in Intranet Zone”. This will allow the browser to automatically send the user’s Windows credentials to IIS for authentication. While this is nothing new, it is still often overlooked.

Invalid Authentication Headers

I’ve run into this error on a couple of boxes and both times, it was a different fix. As far and authentication in IIS 7, the only authentication settings you need to have enabled for an On-Premise CRM installation is ASP.NET Impersonation and Windows Authentication.

If you have these enabled and you still receive the “Invalid Authentication Header” error, then you likely will need to verify that the proper authentication providers are configured for the CRM website. Luckily, the same trick for IIS6 works for IIS7. Open a command prompt, navigate to the C:\inetpub\AdminScripts\ folder and type the following command:

cscript adsutil.vbs get w3svc/xxx/NTAuthenticationProviders

Replace the ‘xxx’ in the command with the “number” of the CRM website. You should receive the values “Negotiate,NTLM” in response. If not, then you’ll need to set the authentication providers to Negotiate and NTLM:

cscript adsutil.vbs set w3svc/xxx/NTAuthenticationProviders “Negotiate,NTLM”

So, now we’ve properly set our providers. This will likely fix the issue with authentication headers. If not, see the next section.

ApplicationHost.config File

In my situation, we had successfully resolved authentication issues with CRM. However, none of our custom code could hit the CRM services (Discovery, CrmService, metadata Service). At first, we suspected our code wasn’t working right, but it’s pretty robust code and follows all the recommended procedures outlined in the SDK. After performing some platform traces and actually trying to browse to the web services with IE, we discovered we were getting the exact same “invalid authentication header” issue on the /MSCRMServices/2007 folder. What gives?!?!?!

IIS 7 stores its configuration information in the C:\Windows\system32\inetsrv\config\applicationHost.config file. I decided to poke around this file to see if there were any settings that may be overriding the intended behavior. I found 2 sets of settings that seemed to be the culprit.

<key path="LM/W3SVC/1/ROOT/MSCRMServices/2007">
    <property id="1002" dataType="String" userType="1" attributes="None" value="IIsWebDirectory" />
</key>
<key path="LM/W3SVC/1/ROOT/MSCRMServices/2007/AD">
    <property id="1002" dataType="String" userType="1" attributes="None" value="IIsWebDirectory" />
</key>
<key path="LM/W3SVC/1/ROOT/MSCRMServices/2007/Passport">
    <property id="1002" dataType="String" userType="1" attributes="None" value="IIsWebDirectory" />
</key>
<key path="LM/W3SVC/1/ROOT/MSCRMServices/2007/SPLA">
    <property id="1002" dataType="String" userType="1" attributes="None" value="IIsWebDirectory" />
</key>
<key path="LM/W3SVC/1/ROOT/MSCRMServices/2007/CrmDeploymentService.asmx">
    <property id="1002" dataType="String" userType="1" attributes="None" value="IIsWebFile" />
</key>

The above settings basically tell IIS to treat the offending folders separate from the rest of the CRM website – not what we want. But this doesn’t really solve our issue. Further on in the config file, I found what I was looking for:

<location path="Microsoft Dynamics CRM/MSCRMServices/2007">
    <system.webServer>
        <security>
            <authentication>
                <digestAuthentication enabled="false" />
                <basicAuthentication enabled="false" />
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true">
                    <providers>
                        <clear />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</location>
<location path="Microsoft Dynamics CRM/MSCRMServices/2007/AD">
    <system.webServer>
        <security>
            <authentication>
                <digestAuthentication enabled="false" />
                <basicAuthentication enabled="false" />
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true">
                    <providers>
                        <clear />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</location>
<location path="Microsoft Dynamics CRM/MSCRMServices/2007/Passport">
    <system.webServer>
        <security>
            <authentication>
                <digestAuthentication enabled="false" />
                <basicAuthentication enabled="false" />
                <anonymousAuthentication enabled="true" />
                <windowsAuthentication enabled="false">
                    <providers>
                        <clear />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</location>
<location path="Microsoft Dynamics CRM/MSCRMServices/2007/SPLA">
    <system.webServer>
        <security>
            <authentication>
                <digestAuthentication enabled="false" />
                <basicAuthentication enabled="false" />
                <anonymousAuthentication enabled="true" />
                <windowsAuthentication enabled="false">
                    <providers>
                        <clear />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</location>
<location path="Microsoft Dynamics CRM/MSCRMServices/2007/CrmDeploymentService.asmx">
    <system.webServer>
        <security>
            <authentication>
                <digestAuthentication enabled="false" />
                <basicAuthentication enabled="false" />
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true">
                    <providers>
                        <clear />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</location>

These settings were telling IIS to override the default CRM authentication with the specified authentication (either anonymous, Windows (with no provider specified), etc). Commenting these lines out and performing the ‘iisreset’ cleared up all my authentication issues.

One mystery still remains – how did those entries show up and why? I’ve decided not to pursue that too much.

Hopefully, this article will help you in any authentication issues you may have with IIS 7, and maybe even offer a little glimpse into how IIS7 operates differently than IIS6.

Cheers!

Technorati Tags: Microsoft Dynamics CRM,CRM Authentication,CRM Windows Server 2008,CMR Invalid Authentication Headers

Comments

[Bert De Ridder]

Brilliant stuff...