cancel
Showing results for 
Search instead for 
Did you mean: 
bornheim
Level 7

Starting with Kerberos

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
McAfee Employee

Re: Starting with Kerberos

Jump to solution

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

Best,

jon

0 Kudos
10 Replies
sroering
Level 13

Re: Starting with Kerberos

Jump to solution

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.

0 Kudos
McAfee Employee

Re: Starting with Kerberos

Jump to solution

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

0 Kudos
bornheim
Level 7

Re: Starting with Kerberos

Jump to solution

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

0 Kudos
McAfee Employee

Re: Starting with Kerberos

Jump to solution

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

0 Kudos
bornheim
Level 7

Re: Starting with Kerberos

Jump to solution

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

0 Kudos
McAfee Employee

Re: Starting with Kerberos

Jump to solution

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

Best,

jon

0 Kudos
bornheim
Level 7

Re: Starting with Kerberos

Jump to solution

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
0 Kudos
bornheim
Level 7

Re: Starting with Kerberos

Jump to solution

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_browsers clearly states that it will not work over proxies.

Kind regards,

Robert

0 Kudos
bornheim
Level 7

Re: Starting with Kerberos

Jump to solution

Hi Jon,

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

Kind regards,

Robert

0 Kudos