Calrification on how Authentication works

[User98955603]

I am looking for clarification on how user Authentication works in Web Gateway since I did not manage to find any in-depth explanation.

Product Guides instruct to use the 'Authentication.Authenticate' criteria to authenticate users. What I would like to know is:

1) Does this actually authenticate the user using the selected method? According to the description yes, but this is defined in Rule Criteria (not Action), which I find confusing.

2) Why is it set to 'false'? What does the true/false value do?

3) What is the difference between the action 'Authenticate' and the Rule Criteria 'Authentication.Authenticate'?

I would appreciate any feedback.

[aloksard · Accepted solution]

Hi,

Hope you are doing well.

Your general authentication rule criteria is Authentication.Autenticate<Auth profile> equals false and action as Authenticate

Inside the Auth profile you can select authentication method as NTLM/User database, Kerberos, NTLM-Agent, LDAP etc

You general top level criteria for say your explicit proxy auth rule is as below:-

Authentication.IsAuthenticated equals False AND Authentication.Failed equals false.

Ruleset will only apply if the user has not already authenticated (Authentication.IsAuthenticated equals false) and they have not already failed authentication (Authentication.Failed equals false).

Only if above criteria matches it then goes and hit your rule with criteria Authentication.Autenticate<Auth profile> equals false and action as Authenticate.

The Authentication.Authenticate property is using an authentication engine that has been created and configured.Authentication.Authenticate property sets authentication method which is used to get credentials/ticket from client side for authenticating them.Authentication.Authenticate property is generally to Authenticate user and get groups.

Now say you have NTLM authentication enabled on MWG. Request from client comes in and triggers the authentication rule in this case MWG sends 407 response code with supported authentication mechanism in it.Credentials for authentication are retrieved via MWG-Authentication 'Authentication.Authenticate(NTLM)'

Authenticate action has below decription:-

Stops processing the rules in the current cycle.

Sends an authentication request to the client of the user who requested access to a web object.

Continues processing with the next cycle.

Below is an example:-

CONNECT mobile.pipe.aria.microsoft.com:443 HTTP/1.0
User-Agent: AriaSDK Client
Host: mobile.pipe.aria.microsoft.com:443
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache

HTTP/1.0 407 authenticationrequired
Date: Tue, 05 May 2020 07:26:31 GMT
Content-Type: text/html
Cache-Control: no-cache
Content-Length: 5733
X-Frame-Options: deny
Proxy-Connection: Keep-Alive
Proxy-Authenticate: NTLM

After this starts NTLM negotiation process. Below is how NTLM Authentication works in general:-

1. The client will open a new connection to the proxy and send a web request.
2. The proxy sends back an HTTP status code 407 Proxy Authentication Required (unless of course your rules have a bypass) along with the types of authentication allowed, which would be NTLM in this case.
3. If the application/client supports NTLM authentication, it will send over the same request again with an NTLM negotiate message.
4. The proxy sends back an NTLM challenge response.
5. The Client sends over the NTLM auth message. This contains the username, password (not visible as it is encrypted), machine name, domain and other information.
6. Once the auth message has been sent the Web Gateway will send a query to the Domain Controller asking if the user is who they say they are based on the information that was provided.
7. If successful, the request will then be served and this connection to the proxy can be reused without sending credentials for every single request.

All of the requests in steps 1, 3 & 5 must be in order and for the same URL. Authentication also only needs to happen one time per tcp connection

Was my reply helpful? If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Regards
Alok Sarda

[User98955603]

Hi. Thanks for the in-depth explanation.

Attached are the policies I created according to the Ultimate Kerberos Guide. If I understand correctly, this should work correctly, trying different auth methods in succession if the previous one was unsuccessful.

[aloksard]

Hi,

I see a rule named Authenticate with User Database has criteria Client.IP is in rage list DMZ-Server AND Authentication.Authenticate<User Database> equals false with action Continue, can you let me know the purpose of this rule?

You plan to have Kerberos and NTLM authentication fallback  rule implemented, correct?

Generally with Kerberos and NTLM authentication fallback, when a  request comes , MWG sends 407 response as per below:-

GET http://google.com/ HTTP/1.1

Host: google.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ( .NET CLR 3.5.30729; .NET4.0E)

HTTP/1.1 407 authenticationrequired

Proxy-Authenticate: Negotiate

Proxy-Authenticate: NTLM

Proxy-Authenticate: Basic realm="McAfee Web Gateway"

Proxy-Authenticate: Negotiate

Proxy-Authenticate: NTLM

Mow it is up to client side to choose which authentication method it wants to use.

NTLM Offering rule configuration:-

The  rule configuration will make it so the Web Gateway offers NTLM in addition to Kerberos (Negotiate). The client browser must choose which method it would like (NTLM or Negotiate)

NTLM Fallback/NTLM Offering Rulesets

Often it may be desired to force fallback to NTLM, or simply offer NTLM in case the client does not support Kerberos for proxy authentication (for example IE6)

If client shows NTLM for authentication it will send below:-

Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAAAAAAAAFgokAir3pyEnZXZoAAAAAAAAAAAQAAAAwAAAAAAAAAA==

It client chooses for Kerberos for authentication it will send below:-

Proxy-Authorization: Negotiate YIIHbQYGKwYBBQUCoIIHYTCCB12gJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBzMEggcvYIIHKwYJKoZIhvcSAQICAQBuggcaMIIHFqADAgEFoQMCAQ6iBwMFACAAAACjggY+YYIGOjCCBjagAwIBBaENGwtWRUdBUy5MT0NBTKIeMBygAwIBAqEVMBMbBEhUVFAbCzEwLjEwLjY5Ljc...+Ox/v5

Regards

Alok Sarda

[User98955603]

Hi

---

@aloksard wrote:

I see a rule named Authenticate with User Database has criteria Client.IP is in rage list DMZ-Server AND Authentication.Authenticate<User Database> equals false with action Continue, can you let me know the purpose of this rule?

Only hosts from a specific subnet within our infrastructure authenticate against a local user database. That is what this rule is for.

---

@aloksard wrote:

You plan to have Kerberos and NTLM authentication fallback rule implemented, correct?

---

That is correct. Some applications could not authenticate when Kerberos was configured as the only option.

[swilkens1]

If it were me, I would simplify it like this:

Kerberos/NTLM fallback + user db

The Stop Rule Set rules in the NTLM fallback policy is from an 'older' way of doing it and are not necessary. I don't see much difference functionally, but this is a little cleaner.