HTTP Authentication Methods

Introduction

About this Document

In this document, we explain how to easily recognize different authentication methods which you may encounter while configuring the AXS Guard reverse proxy server.

Tools and Requirements

In order of preference:

Chrome or Firefox Network Inspector. You can also use Wireshark or curl as an alternative.
Test login credentials to access the web service (this is optional for debugging).
The Internet Information Services Manager (if available).

Recognizing Authentication Methods

Basic Authentication

Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the word Basic followed by a space and a base64-encoded username:password string. It is the simplest technique to enforce access controls for web pages because it doesn’t require cookies, session identifiers or login pages. Basic authentication uses standard fields in the HTTP header and passes credentials in cleartext.

Basic Authentication Header Example

You can decode the credentials as follows on a Linux PC:

$ echo `echo aHR0cHdhdGNoOnRlc3Q= | base64 --decode`
httpwatch:test

Form-based Authentication

With form-based authentication, the logon mechanism does not make use of the HTML authentication methods built into in the header.

Instead, a regular HTTP POST message passes the username and password to the server. Just like basic authentication, the username and password are passed in cleartext.

Look for the form data in the POST message using the network inspector:

Form-based Authentication POST Example

NTLM (LAN Manager)

NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. See the official Microsoft documentation for additional information.

NTLM Network Inspector Example

curl example:

 curl -v http://192.168.10.5/index.html#start

* Trying 192.168.10.5...
* TCP_NODELAY set
* Connected to 192.168.10.5 (192.168.10.5) port 80 (#0)
> GET /scripts/index.html HTTP/1.1
> Host: 192.168.10.5
> User-Agent: curl/7.61.0
> Accept: * / *

< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/10.0
< WWW-Authenticate: NTLM
< X-Powered-By: ASP.NET
< Date: Wed, 26 Dec 2018 08:09:20 GMT
< Content-Length: 1293
....

Important

NTLM is not suitable for external authentication.

NTLM is suppressed by default by AXS Guard as it is a connection-oriented protocol which is considered insecure for external authentication. The authentication is associated with the TCP connection, rather than the individual HTTP requests it transports.

Using NTLM authentication over the Internet would jeopardize the security of your application server by allowing authenticated requests from a first client, followed by unauthenticated requests from a second client. This means the application server would wrongfully associate the privileges of the first client with those of the second client.

By allowing NTLM over the Internet, your application server would also be exposed to potential NTLM lockout attacks. If you have application servers which are configured for NTLM authentication, we strongly recommended that you reconfigure them to either enforce form-based or basic authentication.

Resource: http://www.securiteam.com/securityreviews/5OP0B2KGAC.html

Even microsoft advises against using NTLM over the internet. Alternatives for SSO: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect

Digest Authentication

With Digest Authentication, the user credentials are not sent across the wire in plaintext as opposed to Basic Authentication. Digest authentication is also immune to replay attacks, as it uses a one-time number from the server.

The server gives the client a one-time use number (a nonce) that it combines with the username, realm, password and the URI request. The client runs all of those fields through an MD5 hashing method to produce a hash key.

It then sends this hash key to the server along with the username and the realm to attempt to authenticate.

Digest Authentication is standardized in RFC 2617.

Digest Authentication Network Inspector Example

Using IIS Manager to identify Authentication Methods

Access your IIS Manager.
Review the authentication method for each web service.

Analyzing AXS Guard Logs

Log Types

With the reverse proxy manual and the examples above, you should be able to configure the correct authentication methods for the reverse proxy. If you encounter an issue, it is recommended to analyze the following reverse proxy logs:

Access log: shows the URLs as passed from the browser to the reverse proxy.
Rewrite log: shows how URLs are rewritten by the reverse proxy service.
Error log: shows additional debug information, such as information about established connections.

Example

Example of a common debugging scenario:

Assume you configured the correct authentication methods with valid credentials, but you are still unable to log in:

Note the full path as entered in the browser’s URL field (use the network inspector as shown in the examples above).
Go through the access logs and look for the login entry.
The rewrite log will also show this login URL; compare all three lines as they should match. Check for missing parts in the URL. If some parts are missing, adjust the RFC compliance check in the reverse proxy configuration or in the configuration of your application.