This document is the extended Kerberos guide which includes full background and context. If you do not have hours to read through this guide, please check out the simplified Kerberos guide: , please also check out the a tool meant to simplify the Kerberos setup process.
This document was written to assist with setting up Web Gateway to perform Kerberos for Proxy Authentication. It also provides background information on the different processes involved with Kerberos, the information in this document should shed light on all of the complexities involved with the protocol. Please read through this document thoroughly and if you find any room for improvement please leave a comment.
Install the Microsoft package for support tools which includes ktpass which is required to generate the keytab files.
To start, you must first create a user in AD. This user will later be associated with your keytab within a later step. Make sure the account has the following items enabled:
On the user account you will want to enable the options for support of AES128 or AES256 for Kerberos Authentication:
Once the user is created, we need to generate a keytab based on that user.
The syntax can vary based on security restrictions within your domain, and based on your domain controller type (2003/2008).
Example (Server 2003):
ktpass -princ HTTP/[fqdn-of-appliance_lowercase]@[DOMAIN_UPPERCASE] -mapuser [USERNAME] -pass [PASSWORD] -ptype KRB5_NT_PRINCIPAL -out [OUTPUT-FILENAME].keytab
ktpass -princ HTTP/mandarin.vegas.local@VEGAS.LOCAL -mapuser mwg-kerb-user -pass password -ptype KRB5_NT_PRINCIPAL -out mandarin.vegas.local.keytab
Example (Server 2008):
ktpass -princ HTTP/[fqdn-of-appliance_lowercase]@[DOMAIN_UPPERCASE] -mapuser [USERNAME] -pass [PASSWORD] -ptype KRB5_NT_PRINCIPAL -crypto All -out [OUTPUT-FILENAME].keytab
ktpass -princ HTTP/mandarin.vegas.local@VEGAS.LOCAL -mapuser mwg-kerb-user -pass password -ptype KRB5_NT_PRINCIPAL -crypto All -out mandarin.vegas.local.keytab
Possible -crypto:
Possible -ptype:
When generating the keytab, it will output important information that you will need to take note of for later steps (mapping additional SPNs). Please see the text highlighted in RED.
In Windows 2008, there will be much more output to the screen. This is because -crypto All was specified so all supported methods will be output.
If you have your clients pointed to the Web Gateway in different fashions, you must make sure that you have a keytab that includes each convention (FQDN / Alias):
1. As noted in the Keytab generation step, copy the command output from above, it will be used in commands on the Web Gateway.
2. Then use the setspn command to associate any new SPNs with the keytab user (mwg-kerb-user in this case).
# For HTTP
> setspn -a HTTP/mwg-alias.vegas.local mwg-kerb-user
# For SOCKS
> setspn -a RCMD/mandarin.vegas.local mwg-kerb-user
> setspn -a RCMD/mwg-alias.vegas.local mwg-kerb-user
7.3.x Note: As of version Web Gateway 7.3, there is no need to add additional SPNs via the CLI. Web Gateway's kerberos library was updated to a more modern approach, where if the client presents a ticket, the Web Gateway will attempt to decrypt it using the availabe keys in the keytab. This reduces the need to add other SPNs to the keytab. You will still need to run the setspn commands from AD.
1. Transfer the .keytab to the Web Gateway filesystem (using a tool such as WinSCP). Note: This is not for importing, only for mapping/merging purposes.
2. Login over SSH (using a tool such as putty).
3. Install krb5-workstation tools, this includes the utility ktutil:
# yum install krb5-workstation
4. Move to the /usr/kerberos/sbin directory:
# cd /usr/kerberos/sbin (for older versions)
# cd /usr/bin
5. Use ktutil, in order to add SPNs to the keytab generated above (in my example the .keytab is in the /root folder).
The commands used to add my alias:
# ./ktutil
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e DES-CBC-MD5
[ktutil will prompt for key (from keytab generation)]
wkt /root/mandarin.vegas.local.keytab
q
See below screenshot for example:
Server 2008: See below for commands needed when updating a keytab generated on Server 2008. Please note, the encryption names used from the keytab generation output may differ from the ktutil input (For example AES128-SHA1 = AES128-CTS and AES256-SHA1 = AES256-CTS).
# ./ktutil
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e DES-CBC-CRC
68014fec5e2a911c
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e DES-CBC-MD5
68014fec5e2a911c
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e RC4-HMAC
64f12cddaa88057e06a81b54e73b949b
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e AES256-CTS
bc1b21c47f6ae9c16afe8f033ed2a9236af1b4c5031761a091d635304300e6bc
add_entry -key -p HTTP/mwg-alias.vegas.local@VEGAS.LOCAL -k 4 -e AES128-CTS
b181ffe3bf83f076e29c106028f01226
wkt /root/mandarin.vegas.local.keytab
q
6. Transfer the resulting .keytab file back to your workstation (/root/mandarin.vegas.local.keytab).
In the event that you have multiple domains, it may be necessary to create users and generate keytabs on both domains. You will then need to merge the keytab before importing into the Web Gateway, this will allow the Web Gateway to authenticate users in multiple domains.
If you have an environment with multiple domains the following would be good reasons to perform these steps:
Scenario 1:
Scenario 2:
Perhaps your company has a number of regions with domain controllers in each location, the following would apply:
1. Transfer both of the keytab files to the Web Gateway using WinSCP or related tool (if it was not already done in Mapping SPN process).
2. Install krb5-workstation tools (if it was not done already):
# yum install krb5-workstation
3. To merge the keytabs we will use the utility ktutil. The following commands will merge stpaul.minnesota.local and mandarin.vegas.local, into a file called merged.keytab.
# ktutil
rkt /root/stpaul.minnesota.local.keytab
rkt /root/mandarin.vegas.local.keytab
wkt /root/merged.keytab
q
/usr/kerberos/bin/klist -k /root/merged.keytab
Now you should have one keytab that can be imported into the Web Gateway GUI.
Navigate to Configuration > Kerberos Administration, click "Browse..." and upload the keytab file generated.
We will import an existing Ruleset from the Ruleset library in order to setup 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 within default ruleset.
Once the ruleset is in place, we must update the criteria to use a Kerberos authentication engine.
After the criteria has been changed to use a Kerberos method, as a best practice you should update the rule names to make them representative to their purpose (performing authentication using Kerberos).
As of Web Gateway version 7.2 functionality was added which allows the Web Gateway to pull group information out of the user's kerberos ticket (SIDs) and subsequently MWG can lookup the groups via NTLM (Windows Domain Membership). If you do not with to join the MWG to the domain, you can continue with the existing method of LDAP lookups, for which MWG will lookup the username in LDAP and extract the groups associated with that user.
As of Web Gateway version 7.2 it is possible to have MWG retrieve group information via Windows Domain membership. To enable this, there are two prerequisites:
1. 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 isnt very memorable).
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 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.
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).
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)
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 screenshot below (keep in mind that order of the criteria matters! Authentication.GetUserGroups property must be last😞
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.
The rule configuration below will force the 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). This issue and a solution was covered in a community discussion (https://community.mcafee.com/message/260303). The rules have been cleaned up since that discussion.
Ruleset: Download the example ruleset here.
The below 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). In some cases the browser chooses a method which is incorrect, which is why the above method would be preferred.
The order for the rules AND criteria are very important.
Check out another McAfee Community article on assigning policy based on group membership, How To: Creating a "Web Mapping" ruleset (https://community.mcafee.com/docs/DOC-2210) and How To: Creating a "Policy Assignment" ruleset (formerly "Web Mapping") (https://community.mcafee.co....
With the rules add for NTLM fallback, this will essentially change what forms of authentication the 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"
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.
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: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==
HTTP/1.1 407 authenticationrequired
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAAAAAAAAFgokAir3pyEnZXZoAAAAAAAAAAAQAAAAwAAAAAAAAAA==
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: NTLM TlRMTVNTUAADAAAAGAAYAH4AAAAYABgAlgAAAAoACgBIAAAAGgAaAFIAAAASABIAbAAAAAAAAACuAAAABYKIAgUCzg4AAAAPdgBlAGcAYQBzAGEAZABtaGkAbgBpAHMAdAByAGEAdABvAHIASgBTAEMASABPAEwAVABFAE4Arw/u1Z0aY8oAAAAAAAAAAAAAAAAAAAAAh2VVf2vHzvrSiSNpSqfI9MJpgOPVR/c8
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 CLR 3.0.4506.2152; .NET CLR 3.5.30729)
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; 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 CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: google.com
Proxy-Authorization: Negotiate YIIHbQYGKwYBBQUCoIIHYTCCB12gJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBzMEggcvYIIHKwYJKoZIhvcSAQICAQBuggcaMIIHFqADAgEFoQMCAQ6iBwMFACAAAACjggY+YYIGOjCCBjagAwIBBaENGwtWRUdBUy5MT0NBTKIeMBygAwIBAqEVMBMbBEhUVFAbCzEwLjEwLjY5Ljc...+Ox/v5
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: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==
HTTP/1.1 407 authenticationrequired
Proxy-Authenticate: NTLM
GET http://google.com/ HTTP/1.1
Host: google.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==
HTTP/1.1 407 authenticationrequired
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAAAAAAAAFgokAir3pyEnZXZoAAAAAAAAAAAQAAAAwAAAAAAAAAA==
GET http://google.com/ HTTP/1.1
Host: google.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAH4AAAAYABgAlgAAAAoACgBIAAAAGgAaAFIAAAASABIAbAAAAAAAAACuAAAABYKIAgUCzg4AAAAPdgBlAGcAYQBzAGEAZABtaGkAbgBpAHMAdAByAGEAdABvAHIASgBTAEMASABPAEwAVABFAE4Arw/u1Z0aY8oAAAAAAAAAAAAAAAAAAAAAh2VVf2vHzvrSiSNpSqfI9MJpgOPVR/c8
Kerberos is a very secure protocol, with that security comes important environmental variables for which it relies on to function.
If an IP is used in the proxy settings then the browser will fail to perform kerberos authentication (IE only). As a result it is a best practice to use kerberos with the hostname/FQDN.
When generating the keytab, it is essential that you pay attention to the syntax. A very common syntactial mistake is forgetting to use ALL CAPS in the realm (VEGAS.LOCAL).
If the password for the user account (mwg-kerb-user) has changed, then the version number will change, requiring the keytab to be re-generated. To check for a version mismatch, you must check the keytab and the user account. Keep in mind that version numbers can change for a number of different reasons (regenerate keytab file, password change, etc...).
# yum install krb5-workstation
# klist -tek /etc/krb5.mwg.keytab
# /usr/kerberos/bin/klist -tek /etc/krb5.mwg.keytab (on 7.2.x or older)
To check the user account version, there are a couple of different ways to do this. The easiest I found was using a tool called ldifde, the command below will output a file containing attributes based on the search string you enter (replace SPN-SEARCH-STRING with your SPN). Included in the output is the version number associated with the user.
ldifde -f c:\dump.txt -t 3268 -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"
ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"
Example output:
> ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*mandarin.vegas.local*)"
c:\dump.txt:
dn: CN=mwg-kerb-user,CN=Users,DC=vegas,DC=local
changetype: add
sAMAccountName: mwg-kerb-user
userPrincipalName: HTTP/mandarin.vegas.local@VEGAS.LOCAL
servicePrincipalName: HTTP/mandarin.vegas.local
servicePrincipalName: HTTP/mwg-alias.vegas.local
msDS-KeyVersionNumber: 6
In a production environment this may not be a common problem, but during testing you may create multiple user accounts and associate the same SPN with each of those user accounts. If you do this, then this could result in issues. You must be sure that your SPN is unique. To check for duplicates, you can use ldifde again! Same command as above. In addition Server 2008, the setspn utility comes with options for checking for duplicates as well.
ldifde -f c:\dump.txt -t 3268 -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"
ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"
setspn -X SPN-SEARCH-STRING (Only works in Server 2008 this will work, but ldifde output is better for troubleshooting)
Time is a huge deal with Kerberos, if the time is off, your ticket may not be valid. It is very important to ensure that ALL parties involved (all workstations, KDCs, and the Web Gateway) have their time in sync, the best way to do this is with NTP.
If the time between the Web Gateway and the KDC is off, you can easily correct this. First, check the time on the Web Gateway (using the date command from the CLI).
Then in the user interface under Configuration > Date and Time, set the Web Gateway up to use a NTP server (the same server that the KDC, and the clients are using).
Once the NTP server is set, we can sync the Web Gateway immediately with the time server, by issuing the ntpd -s command. Afterwards, check the date again to make sure the time is what you expected.
In addition to setting the system clock (date), the hardware clock (hwclock) should also be set correctly. To sync the system clock and the hardware clock, issue the hwclock --systohc command, which means "write the system clock to the hardware clock".
# Check current time values
date;hwclock
# 7.3.x and higher, update software clock (date) using NTP
service ntpd stop
service ntpdate start
service ntpd start
# 7.2.x and lower, update software clock (date) using NTP
ntpd -s
# Check current time values
date;hwclock
# If 'date' is correct, but 'hwclock' is off, update the hardware clock with the software clock time
hwclock --systohc
How you generated the keytab file, controls how you should access the proxy. In the example keytab ktpass syntax above, I specified the principal as: HTTP/mandarin.vegas.local@VEGAS.LOCAL
Which means that the proxy settings should be set to mandarin.vegas.local, NOT the IP-address. If I wanted to use the IP address, the keytab ktpass syntax would be changed to reflect the IP of the Web Gateway: HTTP/10.10.69.72@VEGAS.LOCAL
If you do not specify the proxy settings to match what was entered into the keytab file, this will likely result in authentication prompts from the browser.
Follow previous sections on "Generating the keytab" and "Mapping multiple SPNs to one user/keytab", if you want to generate the keytab for different ways of generating the keytab file.
DNS is also very important, you must be able to forward/reverse resolve the Web Gateway, as well as the KDC. To check for this, you can type:
nslookup hostname.domain.tld
nslookup x.x.x.x
Internet Explorer 6 does not support Kerberos with proxy authentication (but does support NTLM).
ipconfig /flushdns
klist purge
tail /opt/mwg/log/mwg-errors/mwg-core.errors.log
How you are accessing the proxy, does not match what you specified in the keytab:
[Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Key table entry not found'
Keytab was most likely regenerated, and current keytab (uploaded to the Web Gateway) is no longer valid:
[Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Key version number for principal in key table is incorrect'
[Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Ticket not yet valid'
Client provided a invalid token (in my test, this was a non-domain user, using Firefox):
[Auth] [KerberosAuthentication] 'SPNEGOExtractNegotiateToken' 'SPNEGO' error : 'SPNEGOExtractNegotiateToken() failed'
With the use of the blockpages, you can add many different variables to the blockpage content in order to debug any situation. For example, you can add anyone of the Authentication.* properties to determine why a rule may not be matching as you would expect.
An additional linux package is offered on the update server for troubleshooting different items. This package is installed into the /usr/kerberos directory, the different tools are in the /usr/kerberos/bin or the /usr/kerberos/sbin directory.
yum install krb5-workstation
/usr/kerberos/bin/klist -h (on older versions)
klist -h
Client side -- Obtaining a wireshark capture on the client machine (not the Web Gateway) will show the communication between the KDC to see what tickets have been issued and if there are any errors.
By the end of this document, you should understand how to setup Kerberos on MWG. If you have MWGs in a pool/cluster, you should still only need one keytab file and one user account in AD. All the aliases for the pool/cluster or individual MWGs can be added to the AD user account, no modification needs to be done to the keytab (unless you really want to). All necessary troubleshooting steps are listed in this document. Depending on the situation, klist output, ldifde output, and a client side capture will be the most useful.
7.5.2 brings support for SID compression on Server 2012 (http://social.technet.microsoft.com/wiki/contents/articles/20886.kdc-resource-sid-compression.aspx). This means that SID compression can be left enabled on the DC.
No major changes.
Web Gateway's kerberos library was updated to a more modern version. In this version SPN checks are no longer necessary to validate/decrypt a ticket. This means that if the Web Gateway receives a kerberos ticket from a user, the Web Gateway will attempt to decyrpt the ticket using the available keys in the keytab. Previously the Web Gateway would only decrypt tickets if it found corresponding SPN entries in the keytab. The steps to add any and all SPNs to the keytab (see: Map multiple SPNs to keytab) is no longer required in 7.3.x and newer. It is still required to run the setspn commands (see: Map multiple SPNs to user).
Web Gateway added the ability to lookup the group information (SIDs) provided in the Kerberos tickets, via NTLM. For more information see: Get groups with NTLM (new as of 7.2)
Hi Jon,
a real great document.
But how about Mulit Kerberos when authenticating users from different domains with kerberos??
Best Regards,
Thorsten
I did not explore that, I will do so, and add in my findings. Thanks for the question, let me know if there is anything else we need covered.
~Jon
Multi-domain details have been added, let me know if I missed anything.
~Jon
Added LDAPS hints.
~Jon
This was very helpful
I just wonder if you really need an user account in AD. If I have Web Gateway joined the domain and have a computer account is it possible to use the computer account for keytab generation?
Hi blazej, When you join the Web Gateway to the domain that creates a new computer account on the domain, it does not create a user account so I imagine you DO need a new user account specifically for kerberos. Also, I wouldnt want to change the computer account used for NTLM as I'm not sure what adverse effects that may have on NTLM authentication.
~Jon
Hi Jon,
Thank you for this great exhautive document.
Vincent.
Hi Jon
Great work!
I have aProblem with the LDAP query. If I'm searching for the user and then query thememberOf attribute I just get the groups which are directly assigned. So if Iuse nested groups in AD it won't work.
For example: All users of a Team are in the group "Team-1". All users ofthis team have the same right to access the internet - and there are otherteams which have the same rights - I would just put this groups (ex. Team-1,Team-4, etc.) in another group like Inet-Access_Type_1.
If I query the memberOf Attribute I just get "user A = group Team-1" and for"user B = group Team-4".
Is there away to follow the nested groups so that I get "Inet-Access_Type_1"?
Stefan
Hi Stefan,
I have not explicitly tested with nested groups, so I'm not sure if it would work. MWG is only querying AD for the attributes of the given object, not any sub-objects.
~Jon
Hi Jon
I am absolutly not an LDAP specialist. Would it not be possible to use "Matching rule OID: 1.2.840.113556.1.4.1941 - LDAP_MATCHING_RULE_IN_CHAIN" like it is described at http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx ?
If there is no way to follow the group membership with LDAP in MWG I can not use Kerberos for authentication and I have to switch back to NTLM. With NTLM I get all the goups.
Thank you
Stefan
regarding "Generating the keytab Syntax"...
for me on 2008R2 the keytab has to be mapped to the user as
-mapuser [DOMAIN\username]
and not just
-mapuser [username]
at least this was necessary when ktpass is executed on a non-DC which is also possible (necessary, when fiddling around with samba4 )
great guide!
~Stephan
Hello All!
I have updated the document to include new information. I have revised the content to have a bit of better order (keytab/user setup in order, then web gateway/rule configuration in their own steps).
Please also take a look at the new NTLM lookup information!
Let me know if you see any errors or areas for improvement!
Best,
Jon
Made correction regarding ktutil input syntax when adding additional SPNs:
AES128-SHA1 = AES128-CTS
AES256-SHA1 = AES256-CTS
Hi jon!
I need your help!
I need to configure three proxy servers mwg-5000 in HA with authentication Kerberos, I already did the keytab.dat setup , but I am in doubt about the operation, I intend to use the wpad.dat - DNS, so, my question is the following: We will need to do some more specific configuration of kerberos to work with HA?
Regards.
Will.
Hi Will,
There isnt anything special about your setup, it is very common.
You will simply need to generate the keytab, and add any additional SPNs (aliases) to the user and to the keytab (as outlined above). Then you should be working!
Best regards,
~Jon
Hi to all,
I have a particular need.
I need to authenticate different users with different metod.
Some user with NTLM (because i need to get AD group).
And other with Kerberos for that users that do not support NTLM.
Can you help me with a rule set to achieve this goal?
Sorry for my english.
Hi generaltesta,
Typically if a browser does not support kerberos, it will pick the highest method it does support (such as NTLM or basic).
IE6 for example doesnt support kerberos, so it will ignore the negociate method, and choose NTLM.
So the examples and completed rules above should work with your goal.
Best,
Jon
For future reference, in case someone googles this and gets the same problem, I had a hard time running KTPASS until i turned off UAC.
I was getting an error that said unable to set servicePrincipalName even if i ran the command as Administrator.
Basically good guide, made it with kerberos finally, but one point I skipped to get things working.
First, for "klist" the kerberos server packet is needed (yum install krb5-server).
Second, if I do the "ktutil" step the webgateway throws the "Key version number for principal in key table is incorrect"-error, and klist shows up like this:
[root@webgateway etc]# klist -k /etc/krb5.mwg.keytab
Keytab name: FILE:/etc/krb5.mwg.keytab
KVNO Principal
---- --------------------------------------------------------------------------
17 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
17 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
17 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
17 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
17 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
4 HTTP/webgateway.mydomain.local@MYDOMAIN.LOCAL
[root@webgateway etc]
So I simply skipped that step, and at least kerberos is working fine now.
But now I face another problem, the NTLM-fallback is not working (the user/pass window always pops up).
My guess is that the ruleset above does not work using NTLM-Agent-Authentication.
Finally, for the secure LDAP connection a webgateways client certificate must be passed to the ldap-server(s), I guess.
Any hints?
Thanks,
Phil
Hi Phil!
I have to make some updates to the klist commands and NTLM fallback section, I created a better ruleset with the help of others, for more info see this discussion: https://community.mcafee.com/message/260303
As far as using the NTLM-Agent... I'm not sure. The group lookups feature would probably not work (you could do that with LDAP instead), but the fallback should work just fine using the ruleset listed in the above discussion.
For the secure LDAP connection, the Web Gateway does not use client certificates for establishing the secure LDAP connection. Rather, it must know of the LDAP server certificate in order to successfully establish a connection to the server, hence the need to create a certificate list.
Best,
Jon
Hi Jon,
perfect! Kerberos authentication with NTLM-Fallback works like a charm now, thank you very much!
Secure LDAP still does not work, but I think this issue is homed server side, at least there aren't any errors on the gateway except the LDAP connection errors. I am still after this and will post results if related to the webgateway.
Regards,
Phil
Hi Jon.
I am trying to get the new 7.2 features working, by retriving the group information from Kerberos and using NTLM to look up the "sensible" name, however, I dont seem to get any group information back as you can see below
tail -f mwg-core__Auth.debug.log
2013-02-12 11:33:51.759 +00:00] [27753] Kerberos (12, 10.128.54.170) Authenticated: 1
[2013-02-12 11:33:51.759 +00:00] [27753] Kerberos (12, 10.128.54.170) Method: Kerberos
[2013-02-12 11:33:51.759 +00:00] [27753] Kerberos (12, 10.128.54.170) Realm: XXX.ADS.XX.COM
[2013-02-12 11:33:51.759 +00:00] [27753] Kerberos (12, 10.128.54.170) User: myusername
[2013-02-12 11:33:51.759 +00:00] [27753] Kerberos (12, 10.128.54.170) Groups: <-- NO GROUPS !
Earlier in the log a MWG restart shows that I am connected to the domain (two in my case, I added the prod domain as a test but this didnt resolve my problem).
[2013-02-12 11:24:16.637 +00:00] [27682] NTLM: Registered account for domain XX
[2013-02-12 11:24:16.637 +00:00] [27682] NTLM: Registered account for domain XXUAT
[2013-02-12 11:24:16.673 +00:00] [27682] NTLM: Connected to DC xxx.xxx.xxx.xxx in domain XXX
[2013-02-12 11:24:16.676 +00:00] [27682] NTLM: Updated list of trusted domains for domain XXX
[2013-02-12 11:24:18.054 +00:00] [27682] NTLM: Connected to DC xxx.xxx.xxx.xxx in domain XXUAT
[2013-02-12 11:24:18.137 +00:00] [27682] NTLM: Updated list of trusted domains for domain XXUAT
Any ideas ?
Hi Antee!
Well... from the output I can only guess.
What happens if you disable the group lookup via NTLM, and output the groups to a block page? Does it show the SID for the groups?
If so, then that leads me to believe there is some sort of issue with NTLM lookups.
If not, then the groups are not included in the kerberos ticket, there for MWG would not have the ability to look the groups up over NTLM. As a result you could use LDAP.
If you have an SR open, let me know and I can check it out. Feedback file, rule trace, tcpdumps would be helpful.
Best,
Jon
Hi again Antee,
Are you running 7.2 or running 7.3. I had assumed 7.2, but re-reading your response I'm not sure.
There was a bug in 7.3.0.0 where groups were not filled resulting in the same behavior you have shown (empty groups). This was quickly fixed in 7.3.0.1+
Best,
Jon
Hi Jon, 3-2775267923, I am running 7.2.0.7.0. I will check if the SID's exist, currenly I am using LDAP, I would prefer not to !.
Thanks
Ant
Hello,
thanks for the HowTo above. It is very good.
Now Authentication over Kerberos is working partially. It works if I use as proxyname on the browser FQDN and hostname but not when I use the IP address.
Here the entries from debug file mwg-core__Auth.debug.log om the MWG 7.3.0.2.0.14242:
[2013-04-08 14:08:26.162 +00:00] [4053] Kerberos (26, X.X.X.X) URL: http://www.google.de/
[2013-04-08 14:08:26.162 +00:00] [4053] Kerberos (26, X.X.X.X) Configuration: Kerberos Connection: 0xXXXXXXXXXX RR: 0xXXXXX
[2013-04-08 14:08:26.162 +00:00] [4053] Kerberos (26, X.X.X.X) Added authentication method: Negotiate
[2013-04-08 14:08:26.162 +00:00] [4053] Kerberos (26, X.X.X.X) Authentication didn't return values, failure ID: 4, authentication failed: 0
[2013-04-08 14:08:26.181 +00:00] [4065] Kerberos (27, X.X.X.X) URL: http://www.google.de/
[2013-04-08 14:08:26.181 +00:00] [4065] Kerberos (27, X.X.X.X) Configuration: Kerberos Connection: 0xXXXXXXXXX RR: 0xXXXXXXXXXXXXXX
[2013-04-08 14:08:26.181 +00:00] [4065] Kerberos (27, X.X.X.X) Incoming credentials: Negotiate TlRMTVNTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[2013-04-08 14:08:26.181 +00:00] [4065] Kerberos (27, X.X.X.X) Added authentication method: Negotiate
[2013-04-08 14:08:26.181 +00:00] [4065] Kerberos (27, X.X.X.X) Authentication didn't return values, failure ID: 0, authentication failed: 1
And from file mwg-core.errors.log:
[2013-04-08 14:08:26.181 +00:00] [Auth] [KerberosAuthentication] 'SPNEGOExtractNegotiateToken' 'SPNEGO' error : 'SPNEGOExtractNegotiateToken() failed'
Used Browser: IE8, IE9
So any idea for this problem?
Thanks
Mgarten
Hi Mgarten,
unfortunately thats a known restriction in IE. We don't know why Microsoft desided not to allow IPs, but we know hostnames work. Thats what you will have to do to make IE work.
Jon is already working on updating the guide to reflect this one and some other restrictions we have learned about.
Regards
Sven
Added much needed updates to the article. See change logs for full list of changes.
Most notabley I added notes regarding NTLM fallback, as well as the mapping of SPN process has changed in 7.3 (no longer needed in most cases).
Best,
Jon
Hi,
why would I use Kerberos over NTLM? I know it's more secure, but what other advantages do I get? And are there any drawbacks compared to using NTLM?
Thanks
Kerberos can allow for an isolated MWG to function without communication to a DC.
NTLM for example requires communication with a DC (either by joining it to the domain, or using the NTLM agent).
However with Kerberos you would need to rely on the UIDs of the groups in order to use them on the MWG.
However, yes, the biggest benefit is that it is much more secure.
Best,
jon
Great stuff Jon, only thing missing is a quick overview of how the whole client to gateway to domain controller authentication process works. I believe it goes something like this:
I'll see if I can work this in, I thought about it in the past, but we decided not to.
That is the correct order of events.
Just a note on Windows Server 2012 and Kerberos, which impacts group lookup functionality via NTLM.
Windows Server 2012, introduces SID compression. Group lookups via NTLM will fail as Web Gateway does not currently support SID compression.
For further reading on SID compression, see the following Microsoft articles:
http://support.microsoft.com/kb/2774190
http://social.technet.microsoft.com/wiki/contents/articles/20886.kdc-resource-sid-compression.aspx
To disable SID compression, set the following key to 1 (default is 0):
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters\DisableResourceGroupsFields
I will add a note on this in the next revision (unless Web Gateway begins to support compressed SIDs aka RIDs).
I have an addition to "Hints on using LDAPS".
The approach using "openssl s_client" to retrieve the certificates will not work if LDAPS is served by an Active Directory: AD does not present its CA certificate, instead you will see something like "verify error:num=20:unable to get local issuer certificate".
I got that hint from here: http://serverfault.com/questions/225449/ssl-certificate-error-verify-errornum-20unable-to-get-local-...
You can retrieve the ADs CA certificate from any workstation logged in to the domain. Go to Control panel > Internet Options > Content > Certificates > Intermediate Certificate Authorities. There you should find your ADs CA certificate. Export in CER format and upload to the UI.
Thank you for this great article.
I have a question on the part that explain how "map multiple SPNs to the user". If use an external Load Balancer in a multiple Web Gateway deployment with central management setting active, the client have as browser proxy setting to point for example load balancer FQDN "proxy.risorse.local" .
How can map multiple SPNs to the user?
Simone
Thank you for this article, I'm using this implementation whitout problems.
simone79 you can configure serviceprincipalname with ADSI Edit in Active Directory. You must put all the A, CNAME records of the proxies. Go to user object and click in properties and go to servicePrincipalName
Click in Add to add all the proxies names.
Thanks
I posted this on the simplified guide as well, but:
For anyone reading this, if you are planning on enabling AES128|256 encryption on the account, do it after the keytab is generated. In limited testing I can't seem to get the account functioning if encryption was enabled prior to generating the keytab. This means you will need to generate the keytab twice. Will update with more details when I'm able to isolate the problem further.
Added SOCKS example setspn command.
Hello. I followed both this guide and the simplified guide and was able to get this set up. I hope I never have to set it up again, but it works.
I noticed that my auth_failed.logs that I was saving are only getting entries from applications that fall back to NTLM and any Kerberos auth failures never show up.
My criteria look like this:
Write auth_failed.log
Authentication.Failed equals true AND
Authentication.FailureReason.ID is not in list AuthFailReasonID: Exclude Codes AND
Authentication.UserName does not match *$
where AuthFailReasonID: Exclude Codes contains 0 and 1.
Is this expected behavior? I have users who want to know what system or application is locking them out but I don't have the auth_failed.log to check.
Hi JDP,
I'm glad you were able to get things setup! Now you're an expert!
As far as the authentication failures go, Kerberos doesnt currently have its own failure IDs (which is not something I had thought about until now).
All errors related to Kerberos are written to the mwg-core errors log, this is due to the MWG software relying on the kerberos library.
Best Regards,
Jon
Support for SID compression was added in 7.5.2, so the above DC change is not needed. Will add to the change log as well.
Thanks for the confirmation. I knew there were Kerberos messages in the mwg-core.log file, but they don't seem very useful for the type of troubleshooting I wanted to keep doing (Why are the proxies locking out my account over and over!!!). I was hoping there were proper failure IDs that I could map back to a particular user and a particular IP address.
[2015-07-17 02:59:46.799 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_API' error : 'Unspecified GSS failure. Minor code may provide more information'
[2015-07-17 02:59:46.800 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Request is a replay'
[2015-07-17 09:29:30.780 -04:00] [Auth] [KerberosAuthentication] 'SPNEGOExtractNegotiateToken' 'SPNEGO' error : 'SPNEGOExtractNegotiateToken() failed'
[2015-07-17 09:56:12.234 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_API' error : 'No credentials were supplied, or the credentials were unavailable or inaccessible'
[2015-07-17 09:56:12.235 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Unknown error'
[2015-07-17 12:39:02.703 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_API' error : 'Unspecified GSS failure. Minor code may provide more information'
[2015-07-17 12:39:02.704 -04:00] [Auth] [KerberosAuthentication] 'gss_accept_sec_context' 'GSS_MECH' error : 'Clock skew too great'
That's what they all look like.
If you do know of anything I can look for, please let me know.
Thanks!
Jasey
Hi Jasey,
I don't know if this is your only use case, but Kerberos should never lockout a user account like NTLM could. If a user did get locked out related to Kerberos, the client's workstation would be the perp, not the MWG. Errors should show up on the DC about the client workstation.
Is that what you were wondering about? It may be a good idea to start a new discussion thread if other questions come up
Best Regards,
Jon
That makes sense. Thanks.
I had already been wondering how someone could still be getting locked out by the proxies since it isn't actually "authenticating" as much as "taking Kerberos' word for it" now.
For the specific incident I had, it turned out to be something running on a server that the person didn't remember logging in to. I guess it was using NTLM.
I never would have gotten Kerberos working without the two guides. I could cut and paste bits of the instructions and send them to the AD admins without needing to explain much because they recognized the commands for their parts. I was very explicit at filling in the commands with all my DNS names and going "here, run exactly this."
Sure, it took about three days, but we got it working thanks to you.
Thanks again!
Jasey
This is exactly why I structured the guide like I did. It's also why I created the simplified guide. There's always a separation between the AD admins and the MWG admins so having your ducks in a row is a must.
Hi Jon,
Any change we could get some examples of how to do this using FreeIPA or the like? Not all of us use AD for authentication!
Regards,
Tris
Hi Tris,
Probably not likley very soon (lot of other projects going on), do the concepts above not at least assist in whats required for other directory tools?
Best Regards,
Jon
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA