Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Setup the Secure Web Gateway

Upload keytab to the Secure Web Gateway

Navigate to Configuration > Kerberos Administration, click "Browse..." and upload the keytab file generated.

ntlm1.png

 

Configure the Rules

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...".

clipboard_edbfe82e8b2d3a4170cb61ea52d6b3092.png

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.

clipboard_e320e6670e47bd25a83086bcb431dd886.png

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

ntlm2.png

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

clipboard_e41e348d8592405e4845ce94cc4401a51.png

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).

ntlm3.png

Getting groups

As of Secure Web Gateway version 7.2 functionality was added which allows the Secure Web Gateway to pull group information out of the user's Kerberos ticket (SIDs) and subsequently Secure Web Gateway can lookup the groups via NTLM (Windows Domain Membership). If you do not with to join the Secure Web Gateway to the domain, you can continue with the existing method of LDAP lookups, for which Secure Web Gateway will lookup the username in LDAP and extract the groups associated with that user.

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).
    clipboard_efcf59e7ff28f34a484d0cf6954ff74c0.png
  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).
    clipboard_eb7b0afe8bdbf3fa0284a10d619ad9134.png

Get groups with LDAP (skip if using NTLM)

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.

clipboard_e3a05e8e82c4da73bbce15e4b9de29250.png

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).

clipboard_e9a0767a20c171d56ef099ddb7d3e8865.png

clipboard_ef2f434691ba3cdf59b07ef2591b761f5.png

clipboard_e2a7fb2be146f9371500a7c3ba6fd0622.png

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

clipboard_ed0289854d11cc66955520f1c536d87e2.png

clipboard_efe6d29601ffe5988248bb7d580806f73.png

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

clipboard_e6a4107e94bc0b737e23a279b31806717.png

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".

clipboard_ea3fa159bc6578749c9d95052132123fa.png

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.

clipboard_e09f77c185082a7abef98f9d337cdebfb.png

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). To do this, the rules we created above would need to be modified a bit.

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). 

clipboard_ec43a3bf9a9866e9b35bdd7995d4b1150.png

IMPORTANT: Download the example ruleset here: Kerberos with NTLM Fallback.xml. 

 

NTLM Offering rule configuration

The below rule configuration will make it so the Secure Web Gateway offers NTLM in addition to Kerberos (Negotiate). The client browser must choose which method it would like (NTLM or Negotiate). In some cases, the browser chooses a method that is incorrect, which is why the above method would be preferred.

Rule configuration (get groups via NTLM)

Rule configuration (get groups via NTLM)

clipboard_ef3ecd143e07e1fc4a4ad5783b5e16627.png

Rule configuration (get groups via LDAP)

clipboard_e3388f091106b7d3068a7cfdd4a2f7a10.png

The order of the rules AND criteria is very important.

HTTP Headers

With the rules add for NTLM fallback, this will essentially change what forms of authentication the Secure Web Gateway will offer, the HTTP headers will now be the following(assuming you allow basic authentication in the NTLM settings):

Proxy-Authenticate: Negotiate

Proxy-Authenticate: NTLM

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

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.

Browser choosing NTLM

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"

 

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)

Proxy-Authorization: NTLMTlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==

HTTP/1.1 407 authenticationrequired

Proxy-Authenticate: NTLMTlRMTVNTUAACAAAAAAAAAAAAAAAFgokAir3pyEnZXZoAAAAAAAAAAAQAAAAwAAAAAAAAAA==

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

Host: google.com

User-Agent:

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)

Proxy-Authorization: NTLMTlRMTVNTUAADAAAAGAAYAH4AAAAYABgAlgAAAAoACgBIAAAAGgAaAFIAAAASABIAbAAAAAAAAACuAAAABYKIAgUCzg4AAAAPdgBlAGcAYQBzAGEAZABtaGkAbgBpAHMAdAByAGEAdABvAHIASgBTAEMASABPAEwAVABFAE4Arw/u1Z0aY8oAAAAAAAAAAAAAAAAAAAAAh2VVf2vHzvrSiSNpSqfI9MJpgOPVR/c8

 

Browser choosing Negotiate (Kerberos)

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

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322;.NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR3.0.4506.2152; .NET CLR 3.5.30729)

Host: google.com

HTTP/1.1 407 authentication required

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; Windows NT 5.2; .NET CLR 1.1.4322;.NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR3.0.4506.2152; .NET CLR 3.5.30729)

Host: google.com

Proxy-Authorization: NegotiateYIIHbQYGKwYBBQUCoIIHYTCCB12gJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBzMEggcvYIIHKwYJKoZIhvcSAQICAQBuggcaMIIHFqADAgEFoQMCAQ6iBwMFACAAAACjggY+YYIGOjCCBjagAwIBBaENGwtWRUdBUy5MT0NBTKIeMBygAwIBAqEVMBMbBEhUVFAbCzEwLjEwLjY5Ljc...+Ox/v5

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

  • Was this article helpful?