Windows Integrated and the domain name

Windows Integrated authentication works great, but when it fails (because
the user doesn't have the site in the intranet sites for example) they are
prompted for credentials. Unfortunatly, instead of defaulting to DOMAIN\ it
is COMPPUTER\ and of course that never works.

Why in the world would you want this domain based service to default to the
local machine SAM? Anyway, how can I set the default to be DOMAIN\ when the
user does not provide the domain information?

This seems like a silly default setting to me.

Re: Windows Integrated and the domain name

On Sep 17, 10:56 am, "super1" wrote:
> Windows Integrated authentication works great, but when it fails (because
> the user doesn't have the site in the intranet sites for example) they are
> prompted for credentials. Unfortunatly, instead of defaulting to DOMAIN\ it
> is COMPPUTER\ and of course that never works.
>
> Why in the world would you want this domain based service to default to the
> local machine SAM? Anyway, how can I set the default to be DOMAIN\ when the
> user does not provide the domain information?
>
> This seems like a silly default setting to me.


Actually, the problem has nothing to do with "defaults". Setting
defaults to be DOMAIN\ is not the solution.

Windows Integrated authentication does NOT allow you to set the
default DOMAIN. Domain information is encrypted inside the actual
authentication token/handshake and cannot be altered by the server
(unlike Basic authentication, which allows this default because it
passes the username/password around). Thus, when you see COMPUTER
\username, that is actually caused by the client and has nothing to do
with the server.

Now, why would the client do this? Well, by default, the client will
automatically authenticate with the current logged-in credentials
(domain credentials if you're logged on as such) to websites that it
is configured to auto-login. Intranet websites are one such category.

Thus, when you see the browser pop up COMPUTER\username, it means that
it's either already tried domain credentials and failed, or it is
going to a website that it is not allowed to auto-login and it has no
idea what the "domain" is. Seems perfectly reasonable to me. If you
want details, go look at the raw HTTP interactions and the answer is
clear.

If you want to avoid login prompts, then please properly configure
your web clients.

Don't blame the protocol or deride the "default" settings because they
have nothing to do with the issue. Lots of people don't even have this
issue, so the problem is clearly with this specific deployment's
configuration.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: Windows Integrated and the domain name

Configuring the web clients is not an option with such a diverse and large
organization.
It seems Microsoft could do something to improve this scenario. Firefox
actually works fine when the user does not provide the domain information.
Something even so simple as a domain field they could fill out. Users just
aren't familiar with putting DOMAIN\ in front of their usernames.
No matter how you look at it, it creates a poor user experience.




"David Wang" wrote in message
news:1190062151.083967.82030@g4g2000hsf.googlegroups.com...
> On Sep 17, 10:56 am, "super1" wrote:
>> Windows Integrated authentication works great, but when it fails (because
>> the user doesn't have the site in the intranet sites for example) they
>> are
>> prompted for credentials. Unfortunatly, instead of defaulting to DOMAIN\
>> it
>> is COMPPUTER\ and of course that never works.
>>
>> Why in the world would you want this domain based service to default to
>> the
>> local machine SAM? Anyway, how can I set the default to be DOMAIN\ when
>> the
>> user does not provide the domain information?
>>
>> This seems like a silly default setting to me.
>
>
> Actually, the problem has nothing to do with "defaults". Setting
> defaults to be DOMAIN\ is not the solution.
>
> Windows Integrated authentication does NOT allow you to set the
> default DOMAIN. Domain information is encrypted inside the actual
> authentication token/handshake and cannot be altered by the server
> (unlike Basic authentication, which allows this default because it
> passes the username/password around). Thus, when you see COMPUTER
> \username, that is actually caused by the client and has nothing to do
> with the server.
>
> Now, why would the client do this? Well, by default, the client will
> automatically authenticate with the current logged-in credentials
> (domain credentials if you're logged on as such) to websites that it
> is configured to auto-login. Intranet websites are one such category.
>
> Thus, when you see the browser pop up COMPUTER\username, it means that
> it's either already tried domain credentials and failed, or it is
> going to a website that it is not allowed to auto-login and it has no
> idea what the "domain" is. Seems perfectly reasonable to me. If you
> want details, go look at the raw HTTP interactions and the answer is
> clear.
>
> If you want to avoid login prompts, then please properly configure
> your web clients.
>
> Don't blame the protocol or deride the "default" settings because they
> have nothing to do with the issue. Lots of people don't even have this
> issue, so the problem is clearly with this specific deployment's
> configuration.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

Re: Windows Integrated and the domain name

super1,

I agree with David. "Configuring the web clientes" is as simple as
creating a GPO (Group Policy Object) that sets the required hostnames
in the trusted sites or intranet sites.

Its not about changing the way web clients "help" the end user or
improve the user experience, because ultimately presetting the domain
could be the wrong option. If there was the option of not providing
the domain, how would the browser differentiate a domain user from a
local user? Remember that in NTLM you have the shadow (or mirror)
account feature.

I believe the ultimate goal is to provide enterprise level tools (like
AD tools) to affect the enterprise as a whole, such as having the
ability to change the browser settings of every desktop under a
certain OU.

Tiago Halm

Re: Windows Integrated and the domain name

Microsoft has already optimized your scenario. If you see the popup
dialog, it either means you did not configure your Domain properly, or
you did not configure the browser to auto-login properly.

In domain scenarios, IE will automatically login using the user's
credentials (either local or domain, whichever is more relevant) to
the server that its security zones allow.

This completely automates and optimizes the manual "innovations" of
Firefox that you are talking about. If user wants to login, they login
as themselves by default, with or without domain is magically
determined. Users never bother with putting DOMAIN\ in front of their
usernames nor do they need to be pre-filled -- how insecure! Is
Firefox really doing that?

So, pardon me for being blunt, but I just don't see Microsoft creating
a poor user experience, nor do I see the Firefox experience as
"better". I simply see your domain administrators misconfiguring and
creating a poor user experience, and you are strangely "blaming"
Microsoft and not the administrators for not improving the scenario.
To make it more amusing, you are also holding up the Firefox "hack" as
the desired solution...


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Sep 18, 8:04 am, "super1" wrote:
> Configuring the web clients is not an option with such a diverse and large
> organization.
> It seems Microsoft could do something to improve this scenario. Firefox
> actually works fine when the user does not provide the domain information.
> Something even so simple as a domain field they could fill out. Users just
> aren't familiar with putting DOMAIN\ in front of their usernames.
> No matter how you look at it, it creates a poor user experience.
>
> "David Wang" wrote in message
>
> news:1190062151.083967.82030@g4g2000hsf.googlegroups.com...
>
>
>
> > On Sep 17, 10:56 am, "super1" wrote:
> >> Windows Integrated authentication works great, but when it fails (because
> >> the user doesn't have the site in the intranet sites for example) they
> >> are
> >> prompted for credentials. Unfortunatly, instead of defaulting to DOMAIN\
> >> it
> >> is COMPPUTER\ and of course that never works.
>
> >> Why in the world would you want this domain based service to default to
> >> the
> >> local machine SAM? Anyway, how can I set the default to be DOMAIN\ when
> >> the
> >> user does not provide the domain information?
>
> >> This seems like a silly default setting to me.
>
> > Actually, the problem has nothing to do with "defaults". Setting
> > defaults to be DOMAIN\ is not the solution.
>
> > Windows Integrated authentication does NOT allow you to set the
> > default DOMAIN. Domain information is encrypted inside the actual
> > authentication token/handshake and cannot be altered by the server
> > (unlike Basic authentication, which allows this default because it
> > passes the username/password around). Thus, when you see COMPUTER
> > \username, that is actually caused by the client and has nothing to do
> > with the server.
>
> > Now, why would the client do this? Well, by default, the client will
> > automatically authenticate with the current logged-in credentials
> > (domain credentials if you're logged on as such) to websites that it
> > is configured to auto-login. Intranet websites are one such category.
>
> > Thus, when you see the browser pop up COMPUTER\username, it means that
> > it's either already tried domain credentials and failed, or it is
> > going to a website that it is not allowed to auto-login and it has no
> > idea what the "domain" is. Seems perfectly reasonable to me. If you
> > want details, go look at the raw HTTP interactions and the answer is
> > clear.
>
> > If you want to avoid login prompts, then please properly configure
> > your web clients.
>
> > Don't blame the protocol or deride the "default" settings because they
> > have nothing to do with the issue. Lots of people don't even have this
> > issue, so the problem is clearly with this specific deployment's
> > configuration.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -

Re: Windows Integrated and the domain name

Hi,

Just as David and Tiago mentioned, this is actually a pure IE bahavior or
Windows domain related issue. As for IIS server side, it will never control
how client browser will cache computer\username or domain\username for
authentication.

Based on my experience, for a direct integrated windows authentication
between IIS and IE, if the automatical logon attempt fails, IE will just
prompt up a blank authentication dialog without a default user
account(neither computer\username nor domain\username). So I also suspect
the issue is somewhat related to your domain configuration. A typical case
is the client need to pass through a third machine to access the site, for
example: an ISA proxy in the middle.

Therefore I'd like to suggest you post the issue to our IE or Windows AD
newsgroup to clarify: in which cases, IE will attach computer\username or
domain\username as default account name for authentication:

microsoft.public.internetexplorer.general
microsoft.public.windows.server.active_directory

For your reference, the following article list the possible causes of why
IE fails to auto finish an integrated window authentication with IIS and
prompt for password.

Internet Explorer May Prompt You for a Password
http://support.microsoft.com/?id=258063

Thanks and have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Windows Integrated and the domain name

This thread is not turning out to be very helpful. Try thinking like a user
and then try to get past the fact that "It works in FireFox."

You can explain it all day, but when someone else's product appears to work
better you lose.

This is not an error in the domain. This is a huge domain with hundreds of
SharePoint sites and hundreds of IT administrators. Getting all of them to
put all the SharePoint sites in all computers intranet sites is just not
going to happen.

If anyone has any other constructive ideas please post.



""WenJun Zhang[msft]"" wrote in message
news:3U28sy4%23HHA.4200@TK2MSFTNGHUB02.phx.gbl...
> Hi,
>
> Just as David and Tiago mentioned, this is actually a pure IE bahavior or
> Windows domain related issue. As for IIS server side, it will never
> control
> how client browser will cache computer\username or domain\username for
> authentication.
>
> Based on my experience, for a direct integrated windows authentication
> between IIS and IE, if the automatical logon attempt fails, IE will just
> prompt up a blank authentication dialog without a default user
> account(neither computer\username nor domain\username). So I also suspect
> the issue is somewhat related to your domain configuration. A typical case
> is the client need to pass through a third machine to access the site, for
> example: an ISA proxy in the middle.
>
> Therefore I'd like to suggest you post the issue to our IE or Windows AD
> newsgroup to clarify: in which cases, IE will attach computer\username or
> domain\username as default account name for authentication:
>
> microsoft.public.internetexplorer.general
> microsoft.public.windows.server.active_directory
>
> For your reference, the following article list the possible causes of why
> IE fails to auto finish an integrated window authentication with IIS and
> prompt for password.
>
> Internet Explorer May Prompt You for a Password
> http://support.microsoft.com/?id=258063
>
> Thanks and have a nice day.
>
> Sincerely,
>
> WenJun Zhang
>
> Microsoft Online Community Support
>
> ==================================================
>
> Get notification to my posts through email? Please refer to:
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at:
>
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

Re: Windows Integrated and the domain name

"try thinking like a user" is a cop-out. It's one of those catch-all phrases
that people throw out when something doesn't work the way they want it to
work.

a) Configuring GPOs isn't really all that difficult. You can use *wildcards*
to put every site in a particular domain into the Intranet security zone if
you wish. That shouldn't take too long to do. If you want to talk about
"enterprise" then you should use the enterprise tools available to you for
management

b) Just because Firefox prepends some domain name prior to sending this off
doesn't really help your users if you have multiple domains - it just causes
problems for people who need to use alternate credentials.

c) Both NTLM and Kerberos authentication require the full realm and
username - that's unfortunately the way both of those two protocols work.
There are ways to have IE automatically submit the user's credentials (as
others have noted) or you can have the user manually enter Realm\Username or
user@upn.suffix. Microsoft has been encouraging the latter since Windows
2000 (only 7 years)

Cheers
Ken

"super1" wrote in message
news:%23p45keG$HHA.4784@TK2MSFTNGP05.phx.gbl...
> This thread is not turning out to be very helpful. Try thinking like a
> user and then try to get past the fact that "It works in FireFox."
>
> You can explain it all day, but when someone else's product appears to
> work better you lose.
>
> This is not an error in the domain. This is a huge domain with hundreds
> of SharePoint sites and hundreds of IT administrators. Getting all of
> them to put all the SharePoint sites in all computers intranet sites is
> just not going to happen.
>
> If anyone has any other constructive ideas please post.
>
>
>
> ""WenJun Zhang[msft]"" wrote in message
> news:3U28sy4%23HHA.4200@TK2MSFTNGHUB02.phx.gbl...
>> Hi,
>>
>> Just as David and Tiago mentioned, this is actually a pure IE bahavior or
>> Windows domain related issue. As for IIS server side, it will never
>> control
>> how client browser will cache computer\username or domain\username for
>> authentication.
>>
>> Based on my experience, for a direct integrated windows authentication
>> between IIS and IE, if the automatical logon attempt fails, IE will just
>> prompt up a blank authentication dialog without a default user
>> account(neither computer\username nor domain\username). So I also suspect
>> the issue is somewhat related to your domain configuration. A typical
>> case
>> is the client need to pass through a third machine to access the site,
>> for
>> example: an ISA proxy in the middle.
>>
>> Therefore I'd like to suggest you post the issue to our IE or Windows AD
>> newsgroup to clarify: in which cases, IE will attach computer\username or
>> domain\username as default account name for authentication:
>>
>> microsoft.public.internetexplorer.general
>> microsoft.public.windows.server.active_directory
>>
>> For your reference, the following article list the possible causes of why
>> IE fails to auto finish an integrated window authentication with IIS and
>> prompt for password.
>>
>> Internet Explorer May Prompt You for a Password
>> http://support.microsoft.com/?id=258063
>>
>> Thanks and have a nice day.
>>
>> Sincerely,
>>
>> WenJun Zhang
>>
>> Microsoft Online Community Support
>>
>> ==================================================
>>
>> Get notification to my posts through email? Please refer to:
>> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
>> ications.
>>
>> Note: The MSDN Managed Newsgroup support offering is for non-urgent
>> issues
>> where an initial response from the community or a Microsoft Support
>> Engineer within 1 business day is acceptable. Please note that each
>> follow
>> up response may take approximately 2 business days as the support
>> professional working with you may need further investigation to reach the
>> most efficient resolution. The offering is not appropriate for situations
>> that require urgent, real-time or phone-based interactions or complex
>> project analysis and dump analysis issues. Issues of this nature are best
>> handled working with a dedicated Microsoft Support Engineer by contacting
>> Microsoft Customer Support Services (CSS) at:
>>
>> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>>
>> ==================================================
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>