HTTP Authentication Methods
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 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
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.
You can decode the credentials as follows on a Linux PC:
$ echo `echo aHR0cHdhdGNoOnRlc3Q= | base64 --decode` httpwatch:test
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
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.
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 ....
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.
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
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.
Using IIS Manager to identify Authentication Methods
Access your IIS Manager.
Review the authentication method for each web service.
Analyzing AXS Guard Logs
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 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
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.