Link to home
Start Free TrialLog in
Avatar of lthiry
lthiry

asked on

HTTP Authentification

Hello,

I have a little security problem on a Web server. It is not severe as nobody can enter the system ;-)
Let me explain.

I have a web server connected to the internet. This web server is in a domain called "A". On one page, I have restricted the access to some people. Inside the domain it is OK.

My problem is when someone on another domain wants to connect to this page usign the internet, he receives the message : HTTP 401.3 - Access denied by ACL on resource and the browser doesn't ask him his name/login !!!!

To complicate, I can also have the same user name as in the A domain but in the other domain, I have a different password !!!

Thanks,

Laurent.
Avatar of TTom
TTom

Laurent:

I have a feeling that your web server is configured to allow anonymous access.  I think if you remove that capability from the site, the browser will be forced to request login credentials.

Once that is accomplished, the user is free to enter a username which includes a domain designation.  In some cases (I am not sure exactly how this works) the login dialog has a specific input area for "domain"; in other cases, the domain can prefix the user name (domain\user).

HTH,

Tom
Avatar of lthiry

ASKER

Tom,

Your feeling is right, but some parts of the site have to be public and some have to be private. If I turn off the anonymous acces, I think I won't have the public access anymore ??

Laurent.
Avatar of lthiry

ASKER

Tom,

I have created another server and put the page. When I try to acces, it says HTTP 401.2 - Unauthorized: Logon failed due to server configuration
Internet Information Services
Thanks,

Laurnet.
Avatar of lthiry

ASKER

Tom,

On the microsoft Web site, I have found
HTTP 401.2 - Unauthorized: Logon failed due to server configuration
Internet Information Services
CAUSE
The authentication methods that were tried are either disabled, or you are attempting to use NTLM through a proxy server.

Which is about the case. I have no proxy, but a router/firewall before the web server !

regards,

Laurent.
Laurent:

With IIS, you can specify whether or not you want Anonymous access on each individual directory.  This setting coordinates with NT security.

If you want people to log in, set the IIS virtual directory to disallow Anonymous access and be sure that the NT file permissions on the appropriate directory are such that valid users can access the files.

If you need public access, enable Anonymous access and be sure the NT file permissions on the directory are set so that "Everyone" can read the files.

We will have to see what effect the firewall has on this, but, presumably, if your server is already viewable to the public, it should not be restricting access.

Tom
Avatar of lthiry

ASKER

I have removed the Anonymous acces and I get

HTTP 401.2 - Unauthorized: Logon failed due to server configuration

Laurent.
ASKER CERTIFIED SOLUTION
Avatar of TTom
TTom

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of lthiry

ASKER

Tom,

I have tried Basic authentification. It worked OK.
I have tried digest and it works, so I have turned basic and all is fine. Thank you very much,

Is Digest authentification secure ?

Laurent.
Hmmm.  Not sure about "Digest" authentication.  I am only familiar with Basic and NT Challenge/Response.  If NT C/R is synonymous with Digest, it is MORE secure than Basic.  If you are using Basic for ANY external communication, you MUST use SSL or your user information will be readily available to any hacker with a mind to get it.

The problem with NT C/R is that Netscape does not support it.

Tom
Avatar of lthiry

ASKER

Digest Authentication
A new feature of IIS 5.0, Digest authentication offers the same features as Basic authentication but involves a different way of transmitting the authentication credentials. The authentication credentials pass through a one-way process, often referred to as hashing. The result of this process is called a hash, or message digest, and it is not feasible to decrypt it. That is, the original text cannot be deciphered from the hash.

Digest authentication proceeds as follows:

The server sends the browser certain information which will be used in the authentication process.
The browser adds this information to its user name and password plus some other information and performs a hash on it. The additional information will help to prevent someone from copying of the hash value and using it over again.
The resulting hash is sent over the network to the server along with the additional information in clear text.
The server then adds the additional information to a plain text copy it has of the client's password and hashes all of the information.
The server than compares the hash value it received with the one it just made.
Access is granted only if the two numbers are absolutely identical.
The additional information is added to the password before hashing so that no one can capture the password hash and use it to impersonate the true client. Values are added that help to identify the client, the client's computer, and the realm, or domain, the client belongs to. As well, a time stamp is added to prevent a client from using a password after it has been revoked.

This a clear advantage over Basic authentication, in which the password can be intercepted and used by an unauthorized person. Digest authentication is structured to be usable across proxy servers and other firewall applications and is available to Web Distributed Authoring and Versioning (WebDAV). Because Digest authentication is a new HTTP 1.1 feature, not all browsers support it. If a non-compliant browser makes a request on a server that requires Digest authentication, the server will reject the request and send the client an error message. Digest authentication is supported only for domains a with Windows 2000 domain controller.

Important   Digest authentication will complete only if the domain server for which a request is made has a plain-text copy of the requesting user's password. Because the domain controller has plain-text copies of passwords, it must be secured from both physical and network attacks. For more information about securing a domain controller, see the Microsoft Windows 2000 Server Resource Kit.

Note   A hash value consists of a small amount of binary data, typically no more than 160 bits. This value is produced by using a hashing algorithm. All hash values share the following properties, regardless of the algorithm used:

Hash length The length of the hash value is determined by the type of algorithm used, and its length does not vary with the size of the message. The message can be several kilobytes or several gigabytes, it doesn't matter. The most common hash value lengths are either 128 or 160 bits.
Non-discoverability Every pair of nonidentical messages will translate into a completely different hash value, even if the two messages differ only by a single bit. Using today's technology, it is not feasible to discover a pair of messages that translate to the same hash value.
Repeatability Each time a particular message is hashed using the same algorithm, the exact same hash value will be produced.
Irreversibility All hashing algorithms are one-way. Given a hash value, it is impossible to recover the original message, even given the hashing algorithm. In fact, none of the properties of the original message can be determined given the hash value alone.

regards,

Laurent.