Setup the Secure Web Gateway

Add/Modify Authentication Rules from Ruleset Library

We will import an existing Ruleset from the Ruleset library in order to set up the framework needed to authenticate users. Under the Policy, click the left-most "Add" button and select"Rule Set from Library...".

Once on the "Add from Rule Set Library" dialog, find the "Direct Proxy Authentication and Authorization" ruleset. This ruleset is the framework for which we can mold to our needs. Prior to adding the ruleset, you must solve any existing conflicts that may exist.

Here is a screenshot showing the newly added authentication ruleset placed with in default ruleset.

Once the ruleset is in place, we must update the criteria to use a Kerberos authentication engine.

After the criteria have been changed to use a Kerberos method, as a best practice you should update the rule names to make them representative of their purpose (performing authentication using Kerberos).

Get groups with NTLM (new as of 7.2)

As of Secure Web Gateway version 7.2 it is possible to have Secure Web Gateway retrieve group information via Windows Domain membership. To enable this, there are two prerequisites:

1. Secure Web Gateway must be joined to the domain (Configuration > Windows Domain Membership).
   
2. Within your Kerberos engine settings, you must enable the option for"Extract group membership IDs from the ticket" and "Lookup group names via NTLM". You must set both options in order to reference groups by name, otherwise if "Lookup group names via NTLM" is unchecked, you can only use the SID of the group (which isn't very memorable).
   

Create a new rule to get the user groups

In order to get the groups, we must add a rule after the "Authenticate with Kerberos" rule. If the authentication is successful, then we use the property of"Authentication.GetUserGroups" to actively seek out or get the user groups.Calling the "Authentication.GetUserGroups" property essentially tells the Secure Web Gateway to check against the specified Directory (in this case "LDAP - Vegas(AD)"). This is different from the Authentication.UserGroups, which would be filled with the group information if the Authentication type allows for group information to be passed back.

Setting up LDAP server to pull groups

As stated above we will need to create a LDAP server definition to pull the groups from AD for the authenticated Kerberos user, this will be specified in the "Settings" for the "Authentication.GetUserGroups" property. Below is an example of a working LDAP server definition working with AD. Please note that the credentials can be specified in full LDAP syntax, alternatively you can use username@domain.tld as well. In the example below I specified the full path to the administrator account (cn=administrator,cn=users,dc=vegas,dc=local).

Hints on using LDAPS

If you wish to use LDAPS you must do two things in order for it to work.

1. Obtain and trust the certificates presented by the LDAPS server. To obtain the certificates you can execute an OpenSSL command from the CLI and copy the certificates text to a file. Once saved to a file you can upload the certificates to the UI.

# openssl s_client -showcerts -connect LDAPS_SERVER_ADDRESS:PORT

openssl s_client -showcerts -connect wynn.vegas.local:636

2. Specify the LDAPS server as it appears on the certificate presented by the server (typically FQDN).

Finished "Get user groups" rule (LDAP)

Here is a final shot of the finished "Get user groups" rule, take note that the criteria have been joined with an "AND", the action is also "Continue".

Multi-domain configuration:

Now that we have a second realm/domain to authenticate against, you will need to create a second rule to pull groups from the second domain. To do this we must add a criteria of "Authentication.Realm equals [REALM-NAME]" to the existing criteria. See the screenshot below (keep in mind that order of the criteria matters! Authentication.GetUserGroups property must be last.

NTLM Fallback rule configuration

The rule configuration below will force the Secure Web Gateway to reject any Negotiate requests, which contain NTLM-related tokens (T1RM). Internet Explorer specifically will attempt to use Negotiate with NTLM tokens instead of NTLM with NTLM tokens (which results in prompts). 

Rule configuration (get groups via NTLM)

Rule configuration (get groups via NTLM)

Rule configuration (get groups via LDAP)

The order of the rules AND criteria is very important.

HTTP communication differences

Below is what the communication would look like depending on what the browser chooses (NTLM vs Kerberos). Some headers were removed for brevity's sake.

NTLM Fallback (with Negotiate withdraw)

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

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)

Host: google.com

HTTP/1.1 407 authenticationrequired

Proxy-Authenticate: Negotiate

Proxy-Authenticate: NTLM

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

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

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)

Host: google.com

Proxy-Authorization: NegotiateTlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==

Host: google.com

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)

Proxy-Authorization: NTLMTlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==

HTTP/1.1 407 authenticationrequired

Proxy-Authenticate: NTLMTlRMTVNTUAACAAAAAAAAAAAAAAAFgokAir3pyEnZXZoAAAAAAAAAAAQAAAAwAAAAAAAAAA==

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

Host: google.com

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)

Proxy-Authorization: NTLMTlRMTVNTUAADAAAAGAAYAH4AAAAYABgAlgAAAAoACgBIAAAAGgAaAFIAAAASABIAbAAAAAAAAACuAAAABYKIAgUCzg4AAAAPdgBlAGcAYQBzAGEAZABtaGkAbgBpAHMAdAByAGEAdABvAHIASgBTAEMASABPAEwAVABFAE4Arw/u1Z0aY8oAAAAAAAAAAAAAAAAAAAAAh2VVf2vHzvrSiSNpSqfI9MJpgOPVR/c8