1

I've installed Windows Server 2003 R2 and IIS role (no Active Directory role). I've setup a virtual directory named 'test' and under Security tab of the 'test' Virtual Directory I've disabled the Anonymous login and enabled Integrated Windows Authentication. The server is on the local network. What I do is I access the test/ directory on the server using the browser. Here is the log:

**IE on Server**
localhost   - works
127.0.0.1   - works, asks for password, 8 second delay
domain.com  - fails, asks for password, after 3 seconds asks for 
             a password again, the username field changes to: domain.com\username
172.28.28.100   - works, asks for password, 8 second delay

.

**Firefox on Server**
same as above
    domain.com          - the 'Remember the password' tooltip displays for
                          a fraction of a second and then the browser asks
                          for the password again

.

**IE on other LAN host**
    172.28.28.100   - works, asks for password, 8 sec delay
    domain.com  - works, asks for password, 8 sec delay
**Firefox on other LAN host**
                    - same as above, no delay

I'm obviously doing something wrong, but I don't know what is it. I've read about SPNs, but when I use setspn -L localhost, there are no SPNs displayed (I guess it's because the server is not a DC). Why can't I login on the server using Windows Integrated Authentication on domain.com?

2
  • Can you capture the authentication conversation with something like wireshark? Jan 4, 2012 at 23:25
  • As @trismarck commented below... Neither of the computers in this question are members of an Active Directory domain. So SPNs, Kerberos, Negotiate, Integrated Auth, etc. do not apply. Jan 27, 2012 at 18:28

2 Answers 2

1

Completely misread the question, so here's try 2.

Assuming:

  • the server is an AD 2000+ domain member
  • the client is a domain member

When you type "domain.com", IE's going to build a Service Principal Name of http/domain.com and ask a DC to give it a ticket for that.

If domain.com is something real, i.e. your AD domain name, that's not going to fly. At least, I assume not.

Try this for guidance on SPNs. Take the first piece of advice too, and use the 2008 version of SetSPN to do the SPN stuff.

In short, you take the App Pool account (if it's IIS 6, it's Network Service by default, so the computer account 'webserver$') and register an SPN against it:

SETSPN -S http/example.com DOMAIN\WebServer$

In theory, at this point, it all works.

I assume FireFox doesn't do Kerb auth against the server, and that IE takes longer to fail because it's trying to.

5
  • 1
    The setspn.exe should probably specify the service for the SPN: setspn -S HTTP/domain.com ADDomainName\servername Jan 5, 2012 at 1:34
  • @TristanK, well, actually both computers aren't part of a domain ;) After further reading about SPNs and service propagation I guess this information is relevant.
    – colemik
    Jan 5, 2012 at 3:59
  • And sorry if my answer dissapointed you ;).
    – colemik
    Jan 5, 2012 at 4:16
  • @RyanFisher good catch!
    – TristanK
    Jan 5, 2012 at 6:46
  • @trismarck Yep, that's relevant. It means Kerberos isn't usable, so you're stuck with only NTLM authentication for local user accounts. Once it's authenticated once, it should get faster for subsequent connections, but we're back to traces being required to diagnose the initial slowness.
    – TristanK
    Jan 5, 2012 at 7:23
0

Several issues to address with this question:

  • You cannot authenticate with domain.com\username or
    domain\username if there is not an Active Directory or NT domain
    called domain.com to authenticate to.

  • You may have to specifically force the use of a local account by using *IIS Computer Name*\username as your logon ID to successfully authenticate against a local account on the IIS server.

  • You probably will want to set your site NTAuthenticationProviders to disable the Negotiate authentication process and force IIS to use NTLM:
    cscript adsutil.vbs set w3svc/__YourWebSite__/root/NTAuthenticationProviders "NTLM"

  • Your simplest, fastest method is going to be using "Basic Auth", but there are security issues with that if you aren't protecting your logon traffic with SSL.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .