Re: Cannot Default Domain?
From: Bernard (qbernard_at_hotmail.com.discuss)
Date: Wed, 8 Dec 2004 12:05:10 +0800
"your problem is that your server is configured in such a way that security
API is not using the server's domain in its operations. "
where and why it is not using the server's domain ?
-- Regards, Bernard Cheah http://www.tryiis.com/ http://support.microsoft.com/ http://www.msmvps.com/bernard/ "David Wang [Msft]" <firstname.lastname@example.org> wrote in message news:#L67YnM3EHA.524@TK2MSFTNGP09.phx.gbl... > The requirement of a domain (or equivalent information) is really a function > of the authentication protocol you use and is outside of IIS control. IIS > is simply a middleman. > > The ability to "default domain" actually means that IIS (or anyone else) can > perform man-in-the-middle security attacks against the protocol -- not > exactly peace of mind, I'd say. > > For example, with Basic authentication: > 1. user sends their username and password to IIS > 2. IIS can add in a "default domain" if the user didn't send any > 3. IIS calls LogonUser using domain\username:password to get a user token > and continue processing the request > > With Integrated Authentication (NTLM, Kerberos) > 1. user sends hashed data blob to IIS. The user must use > domain\username:password to create the hashed data blob > 2. IIS obviously cannot add in a "default domain" -- it doesn't know what > the data blob is. > 3. IIS calls security API calls which understand the blob and does its thing > 4. IIS either gets a "OK" from the security API to then call another > security API to fetch a user token, or it gets a blob to send back to the > client to continue authentication > > > So, your problem is not that IIS cannot default domain -- your problem is > that your server is configured in such a way that security API is not using > the server's domain in its operations. This is not really an IIS issue at > this point... > > I'm suspecting that use of IP instead of sername is a part of the issue. > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Scott McCarthy" <ScottMcCarthy@discussions.microsoft.com> wrote in message > news:074DAEAE-7C68-4249-8C97-CE3F6C070963@microsoft.com... > David, I did set it to basic and it finally did work. Is basic the only way > to default a domain? The http link is just an internal IP address accessed > by > internal machines (IE. http://192.168.0.3/website) > > Scott > > > "David Wang [Msft]" wrote: > > > What you describe should have worked for Basic authentication -- assuming > > the client/server negotiated Basic instead of something else. Make sure > you > > have ONLY Basic auth enabled and try again -- it should work. > > > > > http://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/sec_auth_setdeflogon.mspx > > > > You should not see any authentication dialogs with Integrated > Authentication > > (IE will automatically negotiate the credentials depending on the security > > zone your server is perceived by it). So, something else seems > > misconfigured. > > > > What sort of request URL are you using to access the web server. > > > > -- > > //David > > IIS > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > // > > "Scott McCarthy" <Scott McCarthy@discussions.microsoft.com> wrote in > message > > news:F85BBCA9-1367-481F-9A2D-D8D4F11D7605@microsoft.com... > > I have a web server (Windows 2003 IIS6) that is joined into our domain. I > > have it setup with Windows Integrated Auth. and have also tried Digest and > > Basic. > > > > I cannot get the webserver to authenticate the accounts to theh domain. > > Everytime you try to login to a web page with a domain username and > > password, > > the dialog comes back with the IP Address\username and the user has to > > manually type DOMAIN\username to authenticate. > > > > Is there anyway to fix this issue or force the server to authenticate > > against the domain it is joined into? I have tried Basic Auth with the > > default domain set to the main domain with no luck - Same result. > > > > Thanks in advance. > > > > Scott McCarthy > > email@example.com > > > > > > > >