1 2 Previous Next 10 Replies Latest reply on Jan 28, 2014 10:21 AM by Jon Scholten

    Starting with Kerberos

    bornheim

      Hi,

       

      I do need some help with Kerberos authentication. I had local database running, I had LDAP authentication running, with fallback. Fine. Now I'm reaching for Kerberos. I deactivated both user database and LDAP (fallback will be tested later) and added Kerberos as described in https://community.mcafee.com/docs/DOC-2682:

       

      NTP is active.

       

      I had the AD guys create a user (password cannot be changed and does not expire) and create a keytab file:

       

      ktpass

         -princ HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX>

         -mapuser <Username>

         -pass <********>

         -ptype KRB5_NT_PRINCIPAL

         -crypto AES256-SHA1

         -out <FILENAME>

       

      Mapping multiple SPNs seems not to be needed as I run 7.3.2.4.0.

       

      Imported authentication from the library, changed method to Kerberos and imported the keytab.

       

      Wireshark says that:

      - Client: requests site

      - MWG: 407/Proxy-Authenticate: Negotiate

      - Client: Proxy-Authorization: Negotiate ...

      - MWG: 407/Proxy-Authenticate: Negotiate (yes, again)

       

      With tcpdump I cannot catch a single packet connecting to the AD or even asking DNS for some name other than the site that the client requested.

       

      mwg-core.errors.log:

      [Auth] [KerberosAuthentication] 'SPNEGOExtractNegotiateToken' 'SPNEGO' error : 'SPNEGOExtractNegotiateToken() failed'

       

      mwg-core__Auth.debug.log:

      Kerberos (1687, 192.168.205.2) URL: https://autodiscover.<OUR_DOMAIN>

      Kerberos (1687, 192.168.205.2) Configuration: Kerberos Connection: 0x5f2fc70 RR: 0x614f790

      Kerberos (1687, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1687, 192.168.205.2) Authentication didn't return values, failure ID: 4, authentication failed: 0

      Kerberos (1688, 192.168.205.2) URL: https://autodiscover.<OUR_DOMAIN>

      Kerberos (1688, 192.168.205.2) Configuration: Kerberos Connection: 0x7f7884049590 RR: 0x152bd350

      Kerberos (1688, 192.168.205.2) Incoming credentials: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

      Kerberos (1688, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1688, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

      Kerberos (1689, 192.168.205.2) URL: https://autodiscover.<OUR_DOMAIN>

      Kerberos (1689, 192.168.205.2) Configuration: Kerberos Connection: 0x5f2f9f0 RR: 0x152bd240

      Kerberos (1689, 192.168.205.2) Incoming credentials: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

      Kerberos (1689, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1689, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

      Kerberos (1690, 192.168.205.2) URL: https://autodiscover.<OUR_DOMAIN>

      Kerberos (1690, 192.168.205.2) Configuration: Kerberos Connection: 0x7f7884049590 RR: 0x152bce00

      Kerberos (1690, 192.168.205.2) Incoming credentials: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

      Kerberos (1690, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1690, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

      Kerberos (1691, 192.168.205.2) URL: https://autodiscover.<OUR_DOMAIN>

      Kerberos (1691, 192.168.205.2) Configuration: Kerberos Connection: 0x5f2f9f0 RR: 0x152bd020

      Kerberos (1691, 192.168.205.2) Incoming credentials: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

      Kerberos (1691, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1691, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

      Kerberos (1692, 192.168.205.2) URL: http://autodiscover.<OUR_DOMAIN>/autodiscover/autodiscover.xml

      Kerberos (1692, 192.168.205.2) Configuration: Kerberos Connection: 0x7f78840491d0 RR: 0x152bd460

      Kerberos (1692, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1692, 192.168.205.2) Authentication didn't return values, failure ID: 4, authentication failed: 0

      Kerberos (1693, 192.168.205.2) URL: http://autodiscover.<OUR_DOMAIN>/autodiscover/autodiscover.xml

      Kerberos (1693, 192.168.205.2) Configuration: Kerberos Connection: 0x7f78840491d0 RR: 0x152bd350

      Kerberos (1693, 192.168.205.2) Incoming credentials: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

      Kerberos (1693, 192.168.205.2) Added authentication method: Negotiate

      Kerberos (1693, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

       

      Interestingly, /etc/krb5.conf looks pretty generic:

       

      # This file is managed by system configuration daemon

      # Manual changes to this file will be lost on next configuration change

       

      [domain_realm]

      mwgtst01 = "MY.KERBEROS.COM"

      mwgtst01. = "MY.KERBEROS.COM"

       

      [libdefaults]

      default_realm = "MY.KERBEROS.COM"

      default_keytab_name = /etc/krb5.mwg.keytab

      dns_lookup_kdc = false

      dns_lookup_realm = false

      rdns = false

      clockskew = 300

      krb5rcachetype = mem

       

      Shouldn't there be some more specific things?

       

      Any help is appreciated.

       

      Kind regards,

      Robert

        • 1. Re: Starting with Kerberos
          sroering

          After you create the failure, you can check to see if the client PC has pulled a ticket for the MWG from the command line using klist.  Look for the HTTP SPN.

           

          If you don't see the ticket, then it's likely that the client didn't trust the MWG for kerberos auth.  So make sure the mwg server is in trusted sites.

          If you see the ticket, then there could be a problem verifying the ticket. Could be a problem with the keytab file, such as missing the correct SPN.

          • 2. Re: Starting with Kerberos
            Jon Scholten

            Hi Robert,

             

            The response from the client indicates it could not get the ticket from the KDC.

             

            A typical negociate message starts with Yii, the text you recieved is NTLM:

            TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

             

            You should check the klist output from the keytab and check the ldif commands from the article to compare.

             

            Also, how are you getting to the MWG? Are you defining the MWG in the proxy settings? If so, what is the name you used? Does it match they keytab?

             

            All of these thingsa are very important.

             

            Best,

            Jon

            • 3. Re: Starting with Kerberos
              bornheim

              Hi Jon,

               

              well, shame on me: I should have tried with a client logged on to the domain in the first place. Ouch! :-)

               

              Now I'm getting:

               

              mwg-core.errors.log:

              [Auth] [KerberosAuthentication] 'SPNEGOExtractNegotiateToken' 'SPNEGO' error : 'SPNEGOExtractNegotiateToken() failed'

               

              mwg-core__Auth.debug.log:

              Kerberos (3482, 192.168.205.2) Configuration: Kerberos Connection: 0x7f7884048f50 RR: 0x614f680

              Kerberos (3482, 192.168.205.2) Incoming credentials: Negotiate YIIL2wYGKwYBBQUCoIILzzCCC8ugJDAiBgkqhkiC9xIBAgIG

              Kerberos: Authentication failed 'Wrong principal in request'

              Kerberos (3482, 192.168.205.2) Added authentication method: Negotiate

              Kerberos (3482, 192.168.205.2) Authentication didn't return values, failure ID: 0, authentication failed: 1

               

              # klist -tek /etc/krb5.mwg.keytab

              Keytab name: WRFILE:/etc/krb5.mwg.keytab

              KVNO Timestamp         Principal

              ---- ----------------- --------------------------------------------------------

                 3 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (aes256-cts-hmac-sha1-96)

               

              # klist

              klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

               

              ldifde -f c:\temp\ldifdump.txt -t 3268 -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*<FQDN_OF_MWG>*)"

              dn: CN=...,OU=...,OU=...,OU=...,DC=...,DC=...

              changetype: add

              sAMAccountName: ...

              userPrincipalName: HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX>

              servicePrincipalName: HTTP/<FQDN_OF_MWG>

              msDS-KeyVersionNumber: 3

               

              The proxy name I use in the client is <FQDN_OF_MWG>.

               

              Google leads me to think that 'Wrong principal in request' means there is a difference between <FQDN_OF_MWG> und the hostname of the system itself. "hostname -f" indeed returns something else: not fully qualified (without domain name) and a different host name. Would that be a problem? I'm asking because I will have a load balancer between clients and MWG, so the name of the MWG host will be different from the proxy name the clients re using all the time.

               

              Kind regards,

              Robert

              • 4. Re: Starting with Kerberos
                Jon Scholten

                Hi Robert,

                 

                In 7.3.2.4 Web Gateway doesnt care about the principal in the ticket matching it's hostname -f.

                 

                The only thing I can think of is that you need to add the additional ciphers in the keytab. You only have one listed.

                 

                When you generated the keytab, did you generate it with a -crypto All ? I'm guessing not...

                 

                Do you know the exact command you used when you generated the keytab? This process is very case sensative:

                 

                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

                 

                Best,

                Jon

                • 5. Re: Starting with Kerberos
                  bornheim

                  Hi Jon,

                   

                  the ktpass command I had the AD guys use is in my original post. Indeed I did not have "-crypto All". Heaven knows where that "-crypto AES256-SHA1" came from ..

                   

                  Will try with "-crypto All" tomorrow, thank you!

                   

                  Kind regards,

                  Robert

                  • 6. Re: Starting with Kerberos
                    Jon Scholten

                    I don't think crypto -all is necessary, but it's worth a shot to try it.

                     

                    Best,

                    jon

                    • 7. Re: Starting with Kerberos
                      bornheim

                      JHi Jon,

                       

                      "-crypto all" did the trick. Thank you for your support!

                       

                      Now heading for the goodies: getting groups, fallback, ... :-)

                       

                      Kind regards,

                      Robert

                       

                      Nachricht geändert durch bornheim on 27.01.14 07:30:20 CST
                      • 8. Re: Starting with Kerberos
                        bornheim

                        Hi Jon,

                         

                        I still don't get the hostname thing completely ...

                         

                        What I did at square one was something like this:

                        ktpass -princ HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX>

                         

                        FQDN_OF_MWG is known to DNS forwards and backwards

                        I "invented" a second name FQDN_OF_MWG2 and added it to DNS

                         

                        With a little firewall NAT trickery I made 4 tests (all against the same MWG host)

                        a.) Proxy FQDN_OF_MWG directly: Client uses Kerberos, OK

                        b.) Proxy FQDN_OF_MWG with an intermediate Squid proxy and MWG as parent proxy: Client uses Kerberos, OK

                        c.) Proxy FQDN_OF_MWG2 directly: Client uses NTLM, Authentication fails

                        d.) Proxy FQDN_OF_MWG2 with an intermediate Squid proxy and MWG as parent proxy: Client uses NTLM, Authentication fails

                         

                        What puzzles me:

                         

                        1.) How does the client "know" that FQDN_OF_MWG is Kerberos eligible and FQDN_OF_MWG2 is not? I do not see anything about the proxy name in the HTTP 407 reply. Does the client check with Active Directory if someone did a KTPASS or SETSPN for FQDN_OF_MWG2 in the past?

                         

                        I tried ktutil and add_entry, now my keytab reads:

                        # klist -tek /etc/krb5.mwg.keytab

                        Keytab name: WRFILE:/etc/krb5.mwg.keytab

                        KVNO Timestamp         Principal

                        ---- ----------------- --------------------------------------------------------

                           4 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (des-cbc-crc)

                           4 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (des-cbc-md5)

                           4 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (arcfour-hmac)

                           4 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (aes256-cts-hmac-sha1-96)

                           4 01/01/70 01:00:00 HTTP/<FQDN_OF_MWG>@<DOMAIN_NAME_WITH_SUFFIX> (aes128-cts-hmac-sha1-96)

                           4 01/28/14 11:49:19 HTTP/<FQDN_OF_MWG2>@<DOMAIN_NAME_WITH_SUFFIX> (des-cbc-crc)

                           4 01/28/14 11:51:14 HTTP/<FQDN_OF_MWG2>@<DOMAIN_NAME_WITH_SUFFIX> (des-cbc-md5)

                           4 01/28/14 11:51:14 HTTP/<FQDN_OF_MWG2>@<DOMAIN_NAME_WITH_SUFFIX> (arcfour-hmac)

                           4 01/28/14 11:51:14 HTTP/<FQDN_OF_MWG2>@<DOMAIN_NAME_WITH_SUFFIX> (aes256-cts-hmac-sha1-96)

                           4 01/28/14 11:51:14 HTTP/<FQDN_OF_MWG2>@<DOMAIN_NAME_WITH_SUFFIX> (aes128-cts-hmac-sha1-96)

                        but that doesn't help, the client simply refuses to do anything else than NTLM. Will try SETSPN now.

                         

                        2.) Why does b) work? http://en.wikipedia.org/wiki/Integrated_Windows_Authentication#Supported_web_bro wsers clearly states that it will not work over proxies.

                         

                        Kind regards,

                        Robert

                        • 9. Re: Starting with Kerberos
                          bornheim

                          Hi Jon,

                           

                          Found an AD guy who was still on duty. "SETSPN -a" with <FQDN_OF_MWG2> did the trick.

                           

                          Kind regards,

                          Robert

                          1 2 Previous Next