Conference gyro::internet_toolss

    Try the username is the domain style format:
    
    {nt-domain-name}\{username}
    
    The server doesn't have a clue where to look for a username if you
    aren't using NT authentication.
    
    Be aware (for the anal security folks) that the NT password flys over the
    wire in clear text... just like ftp, VMS/UNIX logins, etc... and unlike
    Windows NT's challenge/response.
    
    --Ron

Re .1

>    Try the username is the domain style format:
>    
>    {nt-domain-name}\{username}
>    
>    The server doesn't have a clue where to look for a username if you
>    aren't using NT authentication.

That doesn't seem to work either :-(

Thanks for the suggestion - any more?

Richard

did you check to see why IIS is rejecting (any errors
being logged)?

I looked a bit in the docs, expecting to find that
you had to create a username/password database, 
since I don't see how a UNIX client would necessarily
have an NT domain account to be validated against,
but did not find anything helpful.

Re .3

>did you check to see why IIS is rejecting (any errors
>being logged)?

From the IIS server log...

16.36.80.128, -, 12/05/97, 09:27:22, W3SVC, WATSIT, 16.36.80.163, 7, 191, 145, 
401, 5, GET, /SPE/index.htm, -, 
16.36.80.128, readings, 12/05/97, 09:27:29, W3SVC, WATSIT, 16.36.80.163, 0, 234, 
145, 401, 5, GET, /SPE/index.htm, -, 

(anonymous access followed by user readings) but access denied.

In the security event log for the server I get a Failure Audit corresponding to  
the first (anonymous) attempt to access the page, but no security event for the  
second attempt (user readings). It would appear that IIS itself is rejecting the user 
name/password response for some reason.

>I looked a bit in the docs, expecting to find that
>you had to create a username/password database, 
>since I don't see how a UNIX client would necessarily
>have an NT domain account to be validated against,
>but did not find anything helpful.

I believe the browser is reissuing the anonymous request as a request with 
credentials, including the user name and password entered by the user. The 
server *should* then use those credentials to access the requested object (file) 
but this seems not to be happening, but I can't figure out why.

Richard

    Hi,
    
    I had the same situation as you that force me to use the Internet
    Explorer as the client. There is a post in WINTDOWS-NT conference and
    till now there is no any reply yet.
    
    Regards,
    						-Double

    I 've my IS setup using both NT challange and Basic.
    The NT is used by MIE client browsers, the basic by Netscape. This
    works perfectly.
    Why should you try to use either of both ?
    
    Eric

    Eric,
    
    I did try to use NT challange and basic. However, when choose "basic as
    an option. The IIS use it anyway. It will always prompt the client
    browser username and password. Say, even you are using IE, it still
    need to type the user data. 
    
    However, I saw strange behaviors, I did set a group of people to the
    protected page, but some of them failed to log on to the server. I
    don't know the reason and can't find out why, all of the people have the
    same privilage and they use IE, but when I disalbe the "basic" option,
    it work again. Suggestion?
    
    						-Double

>    
>    However, I saw strange behaviors, I did set a group of people to the
>    protected page, but some of them failed to log on to the server. I
>    don't know the reason and can't find out why, all of the people have the
>    same privilage and they use IE, but when I disalbe the "basic" option,
>    it work again. Suggestion?
>    
I've seen this behaviour on our webserver pages. There are public and non
public pages. (www-mcs.uto.dec.com - give it a try. Most is public- a the botom
'this server' is restricted').
On a non-public page a MSIE user gets username/passw box. I suspect that MSIE
gives it a second chance when noticing that there is no access via nt/
challange, then it falls over to basic text and provides the box....

eric

>I've seen this behaviour on our webserver pages. There are public and non
>public pages. (www-mcs.uto.dec.com - give it a try. Most is public- a the botom
>'this server' is restricted').

MSIE returns "Error: Access is Denied."

Netscape 3.01 requests User Name and Password. Looks like all the pages are 
private!

Richard

>                       -< www-mcs.uto.dec.com private? >-
>
>MSIE returns "Error: Access is Denied."

Most probebly caused by a wrong setup of the proxy server of the MSIE client
browser. Seen this on more than 50% of the Digital community !
The correct setting for proxy should be disable proxy use for *.dec.com.
Setting the intranet box enabled is NOT sufficient.

To correct (on V3.02) : VIEW > OPTIONS > CONNECTION > Exceptions fill *.dec.com

MSIE does send credentials. If going via a proxy server the credentials are
removed (that's what we want when going outside Digital firewalls).
As soon as a webserver does contain restricted information or a webpage does
use a underlying MSsql-server database, credentials are needed and allowing
anonimous is not possible.

>Netscape 3.01 requests User Name and Password. Looks like all the pages are 
>private!
Netscape does not understand windows/nt challange/response so needs to ask the
credentials to the user. The way it does it popping up this box.
The format is digital1\username (or DIGITAL2 or DIGITAL3 when you're outside
US)

Eric 

>Richard
>