So they question is, why isn't IIS inserting the domain name before the username? Hmmmmmmmmmm.
/scratches beard. Olly -----Original Message----- From: Ken Schaefer [mailto:[EMAIL PROTECTED] Sent: 27 August 2008 09:11 To: NT System Admin Issues Subject: RE: Sharepoint/IIS default domain in authentication It makes no difference if this is 2000/2003/2008 - the actual authN technologies aren't any different. If you are using Basic authentication, then setting the Domain and Realm fields should be enough. The user should be able to just enter "username" and IIS can insert the relevant Domain before the username. The actual authentication data that is sent to IIS is the actual password (Base64 encoded), and it has no dependency on the domain name, so when IIS inserts the domain name into the username field, there is no change that needs ot be made to the authN data supplied by the client. Cheers Ken > -----Original Message----- > From: Oliver Marshall [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 27 August 2008 6:02 PM > To: NT System Admin Issues > Subject: RE: Sharepoint/IIS default domain in authentication > > Thanks Ken. > > I keep forgetting about 2008 :) So I should say this is IIS6 on 2003. > > I've enabled basic authentication (SSL is in place) and I've seen that > either using \ or <mydomain> in the domain should make the user be able > to enter <user> as the username and have the default domain name > inserted. > > Olly > > -----Original Message----- > From: Ken Schaefer [mailto:[EMAIL PROTECTED] > Sent: 27 August 2008 08:55 > To: NT System Admin Issues > Subject: RE: Sharepoint/IIS default domain in authentication > > You need to understand how the underlying authentication technologies > work. > > Domain is for Basic authN > Realm is for Digest AuthN > (IE will use the Realm HTTP header sent back by IIS to populate the > "authenticating to..." part of the dialogue box, so it's useful to > populate both fields). > > Neither field will help you with NTLM or Kerberos authentication > however. When using NTLM auth, the server needs to send the hash to a DC > for authN, and the server can't just "alter" this value to insert a > domain if the user didn't supply one. > > Kerberos Auth is completely different again - the server gets the > service ticket from the client, which in turn procured it from a DC. The > server can't alter this in any way. > > I'll email you a chapter from my IIS 7.0 book offlist that covers how > this all works under the covers. > > Cheers > Ken > > > -----Original Message----- > > From: Oliver Marshall [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 27 August 2008 5:50 PM > > To: NT System Admin Issues > > Subject: Sharepoint/IIS default domain in authentication > > > > Hi chaps again. > > > > Can anyone think why I would be hitting so many problems when trying > to > > get a sharepoint site to use the default domain when users > authenticate? > > > > At the moment they have to enter <domain>\<user>, which while not a > > chore, appears to be more than most users can bare. Normally I'd just > > enter the domain in the default domain and realm boxes in the > > Authentication page of the sites properties in IIS. However, doing > that > > makes no difference in this case. If the users enter just <user> as > > their username it comes back with <machinename>\<user> and they have > to > > enter the domain name instead. > > > > Is sharepoint doing something other than just looking at IIS's > > authentication tab ? > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
