SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a public Internet facing site running on SHarePoint 2010 using NTLM authentication. Users using FireFox/Chrome/Safari are able to log into the site using just their username and password. Internet Explorer users, however, are forced to log in with domain\username. If the domain is left out the site will not grant the user access.

I have been instructing users to try to use another browser but most of our user base uses IE. We have two separate domains. Internal users belong to DomainA and External users are in DomainB. I am not sure why IE is forcing the inclusion of the domain in the username while the others do not. I need users to be able to log in with just username and password only. Has anyone seen this before? Thanks!

share|improve this question
Does this affect all IE users, i.e., those accessing the site from inside the company firewall as well as from outside or is it limited to one group? – Dave Wise Jul 12 '11 at 18:34
This affects all IE users both internal and external – Mike B Jul 12 '11 at 22:01
In IE, you can't set the intranet site as a Trusted Site? – Trido Nov 13 '13 at 23:07

Try using "\\" before the username when you login to the sharepoint website from client machines.

share|improve this answer
I used a single "\" and that seemed to do the trick. – Jack Marchetti Oct 30 '15 at 15:16
I tried one "\" but that did not do it for me but two "\\" did, thanks! IE9 and SP 2013. – Martin Larsson Jan 18 at 9:03

A Couple of things you can try:

  1. In internet explorer, uncheck the "Enable Integrated Windows Authentication" box in the security options page.

    This doesn't actually disable it, it just forces NTLM. When the checkbox is clicked it will try to use Kerberos first, than it is supposed to fall back to NTLM (IE7+).

  2. I would also suggest loading up fiddler and comparing the authentication headers when you use the other browsers with the one generated by IE.

Does this happen to both internal (users on same domain as server) and external (trusted domain)? How are the authentication option in the WebApp configured (IIS settings)?

share|improve this answer
This happens for all IE users in both the trusted and the domain the web server exists on. We actually did switch from NTLM to kerberos in order to use forms based authentication. The IIS Settings for authentication have both forms based (HTTP 302 login/redirect) and windows(http 401 challenge) authentication enabled. I will run the fiddler trace and make a comparison. THanks! – Mike B Jul 12 '11 at 22:10
I'm not sure I'm following you, Kerberos and FBA are two different authentication methods, independent of each other. You may want to try and switch back to NTLM. – Jesus Shelby Jul 13 '11 at 12:37

We had the same problem, but as it turns out our clients are in a different domain than our sharepoint server. When authentication takes place, the client computer implicitly sends your complete authentication information, i.e. your domain\username and password. When the authentication request arrives at the server, it realizes the user doesn't belong the same domain as it does. Consider configuring a trust between your domain for transparent authentication. Greetings.

share|improve this answer
Thanks for the response. The external users are on DomainB which is the same domain as the Sharepoint server. There is also a one way trust between DomainA and DomainB where DomainB trusts DomainA. ALso, This only happens in internet Explorer. This does not happen in FireFox, Chrome, or Safari – Mike B Jul 11 '11 at 22:56

In IIS under the ISS Site -> Authentication -> Windows Authentication

Right click and select Advanced settings. Under the advanced settings check the box labeled "Enable Kernal-Mode Authentication" and then reset IIS.

share|improve this answer

try domain\username and ythen you may get somewhere and also your password

share|improve this answer
And that was exactly what OP did not want to do :) – Robert Lindgren Jul 25 '13 at 5:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.