My Webserver has different names (DNS names) and my Integrated Authentication Fails – what to do

Explanation:

Kerberos Authentication Requires SPNs for Multiple Worker Processes

You
can isolate Web sites that are in different worker processes and
running under different identities; however, unexpected IIS behavior
might occur if you use Integrated Windows authentication. Integrated
Windows authentication attempts to use Kerberos authentication, which
might not work, depending upon the identity of the worker process. To
use Kerberos authentication, a service must register its Service
Principal Name (SPN) in the account in the Microsoft Active Directory®
directory service under which the service is running. By default,
Active Directory registers the NetBIOS name or computer name and allows
the Network Service or LocalSystem user accounts to use Kerberos.
However, for Kerberos to work with the following configurations, you
must first register an SPN:

If
your site is referenced by a Windows Internet Name Service (WINS) or
Domain Name System (DNS) name that is different from the computer name
of the server running IIS (a Web farm, for example), authentication
defaults to NTLM (which is also known as Microsoft Windows NT®
Challenge/Response authentication).

If
you configure the worker process for the Web site to run as a domain
account, and you did not use a WINS or DNS name, authentication will
fail. This is because the SPN can be found, but it is registered for
the Network Service and LocalSystem user accounts, not for the domain
account under which the worker process is running.

You
can use the Setspn.exe command-line tool to register an SPN on the
account under which the worker process is running. You must be a domain
administrator to set an SPN. The Setspn.exe tool is included in
Resource Kit Tools for Windows Server 2003, available on the Windows Server 2003 Deployment Kit companion CD, or on the Web at http://www.microsoft.com/reskit.

obtained from: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/77cf4a99-9e0e-42be-8c2e-eaa4cb24c200.mspx?mfr=true

RESOLUTION

loadTOCNode(1, 'resolution');

If
this behavior occurs when the application pool is running under a local
account, follow the steps in the "Workaround" section.

To
resolve this behavior when the application pool is running under a
domain user account, set up an HTTP SPN with the NetBIOS name and the
fully qualified domain name (FQDN) of the domain user account that the
application pool is running under. To do this, follow these steps on a
domain controller:

Important An SPN for a service can
only be associated with one account. Therefore, if you use this
suggested resolution, any other application pool that is running under
a different domain user account cannot be used with Integrated Windows
authentication only.

1. Install the Setspn.exe tool. To obtain the Microsoft Windows 2000 version of the tool, visit the following Microsoft Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en)

The
Microsoft Windows Server 2003 version of the Setspn.exe command-line
tool is available in the Windows Server 2003 Support Tools that are
included on your Windows Server 2003 CD. To install the tools,
double-click the Suptools.msi file in the Support/Tools folder.

2. Start a command prompt, and then change to the directory where you installed Setspn.exe.
3. At the command prompt, type the following commands. Press ENTER after each command:

setspn.exe -a http/IIS_computer's_NetBIOS_name DomainNameUserName

setspn.exe -a http/IIS_computer's_FQDN DomainNameUserName

Note UserName is the user account that the application pool is running under.

After
you set the SPN for the HTTP service to the domain user account that
the application pool is running under, you can successfully connect to
the Web site without being prompted for your user credentials.

WORKAROUND

loadTOCNode(1, 'workaround');To
work around this behavior if you have multiple application pools that
run under different domain user accounts, you must force IIS to use
NTLM as your authentication mechanism if you want to use Integrated
Windows authentication only. To do this, follow these steps on the
server that is running IIS:

1. Start a command prompt.
2. Locate
and then change to the directory that contains the Adsutil.vbs file. By
default, this directory is C:InetpubAdminscripts.
3. Type the following command, and then press ENTER:

cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"
4. To verify that the NtAuthenticationProviders metabase property is set to NTLM, type the following command, and then press ENTER:

cscript adsutil.vbs get w3svc/NTAuthenticationProviders

The following text should be returned:

NTAuthenticationProviders       : (STRING) "NTLM"

obtained from:
http://support.microsoft.com/default.aspx?scid=kb;en-us;871179

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: