|
|
You're in the
iis security
group:Windows Integrated and the domain name
iis security:
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.
[quoted text, click to view]
On Sep 17, 10:56 am, "super1" <superbrownbro...@nospam.nospam> 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 //
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. [quoted text, click to view] "David Wang" <w3.4you@gmail.com> wrote in message
news:1190062151.083967.82030@g4g2000hsf.googlegroups.com... > On Sep 17, 10:56 am, "super1" <superbrownbro...@nospam.nospam> 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 > // >
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
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 // [quoted text, click to view] On Sep 18, 8:04 am, "super1" <superbrownbro...@nospam.nospam> 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" <w3.4...@gmail.com> wrote in message > > news:1190062151.083967.82030@g4g2000hsf.googlegroups.com... > > > > > On Sep 17, 10:56 am, "super1" <superbrownbro...@nospam.nospam> 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 -
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/default.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.
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. [quoted text, click to view] ""WenJun Zhang[msft]"" <wjzhang@online.microsoft.com> 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/default.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. >
"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 [quoted text, click to view] "super1" <superbrownbrown1@nospam.nospam> 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]"" <wjzhang@online.microsoft.com> 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/default.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. >> >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |