How To: Setup Kerberos Authentication on Web Gateway 7.x

     

    Background

    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.

     

    Setup on the Domain Controller

    • Install "Support Tools"

    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:

      • The user cannot change the password
      • The password never expires

     

    kerb01.png kerb02.png

     

      • Higher encryption methods

         

        On the user account you will want to enable the options for support of AES128 or AES256 for Kerberos Authentication:

    kerberos-aes128-256.png

    • Generating the keytab

    Once the user is created, we need to generate a keytab based on that user.

     

      • Syntax

    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:

        • DES-CBC-CRC is used for compatibility.
        • DES-CBC-MD5 adheres more closely to the MIT implementation and is used for compatibility (default on 2003).
        • RC4-HMAC-NT employs 128-bit encryption.
        • AES256-SHA1 employs AES256-CTS-HMAC-SHA1-96 encryption.
        • AES128-SHA1 employs AES128-CTS-HMAC-SHA1-96 encryption.
        • All states that all supported cryptographic types can be used (recommended on 2008).

     

     

    Possible -ptype:

        • KRB5_NT_PRINCIPAL is the general principal type (recommended).
        • KRB5_NT_SRV_INST is the user service instance.
        • KRB5_NT_SRV_HST is the host service instance.
      • Keytab generation output

    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.

        • Output from Windows 2003 Server

     

    kerb03.png

        • Output from Windows 2008 Server

    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.

     

    kerb04-2.png

     

    • Mapping multiple SPNs to one user/keytab (optional)

      • Why it's important

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

    fqdn.png   kerb06.png  

      • Map multiple SPNs to the User (perfomed on AD server)

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

     

    > setspn -a HTTP/mwg-alias.vegas.local mwg-kerb-user

     

    kerb07.png

     

      • Map multiple SPNs to the Keytab (perfomed on MWG OS)

    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:

     

    kerb08.png

     

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

     

    • Multi-domain configuration (optional)

    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.

      • Why it's important

    If you have an environment with multiple domains the following would be good reasons to perform these steps:

        • Multiple domains with no trust relationship - If there is no trust relationship it is necessary to create a user and generate a keytab for each domain. You may also need to add any additional SPNs to the user/keytab, see scenario #2.

     

    Scenario 1:

            • Users proxy settings are set to "mwg.globo.corp".
            • User created in AD in both domains VEGAS.LOCAL and MINNESOTA.LOCAL.
            • Keytab contains two SPNs:
              • HTTP/mwg.globo.corp@VEGAS.LOCAL
              • HTTP/mwg.globo.corp@MINNESOTA.LOCAL

     

    kerb10-2.jpg

    Scenario 2:

            • Users proxy settings are set dependent on their domain. Users in VEGAS.LOCAL are pointed to "mandarin.vegas.local". Users in MINNESOTA.LOCAL are pointed to "stpaul.minnesota.local".
            • User created in AD in both domains VEGAS.LOCAL and MINNESOTA.LOCAL. Each user account has been associated with its corresponding SPN.
            • Keytab contains two SPNs:
              • HTTP/mandarin.vegas.local@VEGAS.LOCAL
              • HTTP/stpaul.minnesota.local@MINNESOTA.LOCAL

     

    kerb11-2.jpg

     

        • Multiple domains with trust relationship, but domain controllers are in different locations - If the DC's have a trust relationship but the DCs are distrubted across the world, it is a good idea to have the local DC generate tickets for users local to that DC. In this scenario one would need to generate a keytab in each sub-domain and merge the keytabs.

     

    Perhaps your company has a number of regions with domain controllers in each location, the following would apply:

            • Users proxy settings are set to "mwg.globo.corp".
            • User created in AD in both domains EUROPE.GLOBO.CORP and AMERICA.GLOBO.CORP.
            • Keytab contains two SPNs:
              • HTTP/mwg.globo.corp@AMERICA.GLOBO.CORP
              • HTTP/mwg.globo.corp@EUROPE.GLOBO.CORP

     

    kerb09-2.jpg

     

      • Merging keytabs

    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
    
    
    
    

     

    merging.png

      • Conclusion

    Now you should have one keytab that can be imported into the Web Gateway GUI.

     

    Setup on the Web Gateway

    • Uploading keytab to the Web Gateway

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

     

    upload-keytab.png

     

    • Configure the Rules

      • Adding/Modifying Authentication Rules from Ruleset Library

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

     

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

     

    addingrule.png

     

     

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

     

    1-before.png

     

     

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

     

    2-settings.png

     

     

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

     

    1-after.png

      • Getting groups

    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.

        • Get groups with NTLM (new as of 7.2)

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

     

    kerb13.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 isnt very memorable).

     

    kerb12.png

     

        • Get groups with LDAP (skip if using NTLM)

          • Creating 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 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.

     

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

     

    1-ldapsettings.png 2-ldapsettings.png 3-settings.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
    
    
    
    

     

    ldaps_1_2011-09-29_153418.png ldaps_2-2_2011-09-29_153654.png

     

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

     

    ldaps_4_2011-09-30_101637.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".

     

    kerb14.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 screenshot below (keep in mind that order of the criteria matters! Authentication.GetUserGroups property must be last):

     

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

     

    ntlmfallback.png

     

    Ruleset: Download the example ruleset here.

     

     

      • NTLM Offering rule configuration

    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.

     

        • Rule configuration (get groups via NTLM)

     

    kerb17.png

     

        • Rule configuration (get groups via LDAP)

     

    kerb16.png

     

    The order for the rules AND criteria are very important.

     

    • Using group information for policy

    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.com/docs/DOC-3649).

     

    • HTTP Headers

    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"
    
    
    
    
      • 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: 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
    
    
    
    
        • 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 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
    
    
    
    
        • 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: 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
    
    
    
    

     

    Common Issues

    Kerberos is a very secure protocol, with that security comes important environmental variables for which it relies on to function.

    • Browser quirks

    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.

    • Syntax (realm isnt all caps)

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

     

    • Keytab and user version out of sync

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

      • Check the keytab version (on the Web Gateway)

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

     

    x2013-07-30_153448.png

      • Check the user account version (on the DC)

    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
    
    
    
    

     

    • Duplicate SPNs

    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

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

     

    1-timeoff.png

     

     

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

     

    kerb22.png

     

     

    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.

     

    3-timegood.png

     

     

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

     

    6-timegoodbad.png

     

        • Commands to update time (MWG version specific)

     

    # 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 access the proxy

    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.

     

    proxysettings-higlighted.png

    • DNS

    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


    1-dnsfail.png2-dnsgood.png

    • IE6

    Internet Explorer 6 does not support Kerberos with proxy authentication (but does support NTLM).

    Troubleshooting

    • Flush DNS and Purge tickets on client

      If you recently added the DNS entry for the MWG, then you might need to flush the DNS cache on your workstation. Afterwards you can purge any existing Kerberos tickets as well.
    ipconfig /flushdns
    klist purge
    

     

     

    • Observed errors

      • mwg-core.errors.log

    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'
    
    
    
    

     

    Time is off:

    [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'


    • Use the blockpages

    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.

    • krb5-workstation

    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
    
    
    
    

     

    • Wireshark (tcpdump)

    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.

    • Network Identity Manager

      Client side -- To track down any potential client issues, a tool called "Network Identity Manager" has been useful for viewing the Kerberos tickets for users, this tool can be found at: http://www.secure-endpoints.com/netidmgr/v2/.

     

     

    Conclusion

     

    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.

     

     

    MWG changelog

    7.4.x

     

              No major changes.     

     

    7.3.x

     

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

     

    7.2.x

     

    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)

     

     

    Document changelog

     

    • 2014-Nov-17
      • Added flush DNS and klist purge command to troubleshooting section
    • 2014-Sep-18
      • Added note regarding AES128 and AES256 Encryption
    • 2014-Jun-24
      • Fixed typos
      • Added conclusion statement
    • 2013-Jul-31
      • Updated document to include document changelog section as well as software changelog (see above).
      • Added notes regarding adding additional SPNs not being necesssary on 7.3.x+.
      • Updated ruleset regarding NTLM fallback. New ruleset will withdraw authentication method Negotiate if client is behaving weird, allowing for true fall back to NTLM.
      • Added "browser quirks" section in the Common Issues section.
      • Updated ntp commands, 7.3.x commands are different from 7.2.x.
      • Added notes about kerberos utilities. 7.3.x, for example ktutil is located in the /usr/kerberos/sbin folder instead of /usr/kerberos/bin.
    • 2014-Jul-09
      • Fixed some grammarical errors
      • Removed irrelevent references and updated further reading section
      • Added conclusion section

     

     

    Further reading