Please collect and attach a chrome://net-export log. Instructions can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.

Could you also paste the version string from chrome://version ?

Sorry - 70.0.3538.67

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Log attached. 

Deleted: chrome-net-export-log.json 1.3 MB

chrome-net-export-log.json 1.3 MB View Download

#5: Thanks for the log. But I don't see any server or proxy authentication challenges in that log. Could you verify that you saw authentication prompts while you were capturing these logs?

Or alternatively, capture a new log and ensure that at least one prompt was seen while network activity was being captured,

Here is the new log, and it definitely gave me a prompt instead of taking my valid Kerberos Ticket.

Deleted: chrome-net-export-log.json 1.7 MB

chrome-net-export-log.json 1.7 MB View Download

Deleted: Screen Shot 2018-10-22 at 4.11.29 PM.jpg 71.0 KB

	Screen Shot 2018-10-22 at 4.11.29 PM.jpg 71.0 KB View Download

The good news is that this isn't  issue 872665  since hostname canonicalization was done via the system resolver. However, following the name canonicalization, the code decided not to use 

A couple of questions:
* Can you confirm that adfs.shrm.org is in the whitelists?
* Does adfs.shrm.org use a CNAME pointer? I.e. Does 'dig adfs.shrm.org' show any CNAME records?
* Does HTTP/adfs.shrm.org@SHRM.ORG exist as a service ticket? I.e. 'kvno HTTP/adfs.shrm.org@SHRM.ORG' succeeds?
* Do other browsers successfully authenticate under these circumstances?

Hello,

My whitelist is here:

    AuthNegotiateDelegateWhitelist = "*shrm.org";
    AuthServerWhitelist = "*shrm.org";

adfs.shrm.org is a CNAME:

; <<>> DiG 9.10.6 <<>> adfs.shrm.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53070
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;adfs.shrm.org.			IN	A

;; ANSWER SECTION:
adfs.shrm.org.		28800	IN	CNAME	f5_adfs_internal_vip.shrm.org.
f5_adfs_internal_vip.shrm.org. 28800 IN	A	10.1.3.195

Safari does successfully authenticate under these circumstances.

I don't have kvno in 10.14. Is there an alternate command to use?

On a Mac, you should be able to do:

  kcc kvno HTTP/adfs.shrm.org@SHRM.ORG
  kcc kvno HTTP/f5_adfs_internal_vip.shrm.org@SHRM.ORG

You might have to follow that up with a klist to see which of those worked.

Here's the result of those commands:

Persephone:~ tom$ kcc kvno HTTP/adfs.shrm.org@SHRM.ORG
Persephone:~ tom$ kcc kvno HTTP/f5_adfs_internal_vip.shrm.org@SHRM.ORG
Persephone:~ tom$ klist
Credentials cache: API:F96EBFFC-8922-4B00-A801-9DAAE63858BF
        Principal: tbridge@SHRM.ORG

  Issued                Expires               Principal
Oct 23 10:07:16 2018  Oct 23 20:07:08 2018  krbtgt/SHRM.ORG@SHRM.ORG
Oct 23 10:47:13 2018  Oct 23 20:07:08 2018  ldap/dc01.shrm.org@SHRM.ORG

I don't get an error on those commands, but I don't get a service ticket.

If I open Safari and go to the login URL, I do get a service ticket:

Persephone:~ tom$ klist
Credentials cache: API:F96EBFFC-8922-4B00-A801-9DAAE63858BF
        Principal: tbridge@SHRM.ORG

  Issued                Expires               Principal
Oct 23 10:07:16 2018  Oct 23 20:07:08 2018  krbtgt/SHRM.ORG@SHRM.ORG
Oct 23 10:47:13 2018  Oct 23 20:07:08 2018  ldap/dc01.shrm.org@SHRM.ORG
Oct 23 10:48:17 2018  Oct 23 20:07:08 2018  HTTP/adfs.shrm.org@SHRM.ORG

Ah. Got it.

The protocol requirements for generating the SPN is that it should be based on the canonical hostname. In this case since adfs.shrm.org is a CNAME (i.e. doesn't own it's A record) and f5_adfs_internal_vip.shrm.org does have an A record (i.e. owns the A record), the SPN should be HTTP/f5_adfs_internal_vip.shrm.org@SHRM.ORG.

But you want it to use an SPN of HTTP/adfs.shrm.org@SHRM.ORG. In Chrome you can get that by setting the DisableAuthNegotiateCnameLookup policy (https://www.chromium.org/administrators/policy-list-3#DisableAuthNegotiateCnameLookup). 

Also https://support.google.com/chrome/a/answer/187202?hl=en would be informative in case you are unfamilar with enterprise policy.

So, if I read you correctly, I should set the DisableAuthNegotiateCnameLookup value of com.google.Chrome to be true, and that should resolve our situation?

    AuthNegotiateDelegateWhitelist = "*shrm.org";
    AuthServerWhitelist = "*shrm.org";
    DisableAuthNegotiateCnameLookup = 1;

With the above set, I still can't use my Kerb ticket to talk with our ADFS installation.

Tom

Ah. Note that the wildcard should be before a dot. Otherwise things like evilshrm.org would match.

But that's beside the point.

My next suspicion is that Chrome isn't finding the correct credentials cache. Could you try this?

    # Close Chrome. i.e. ⌘-Q
    # (note: You'll want to save this note somewhere before closing Chrome)
    # In a shell, do:

    klist
    # Note the Credentials cache location. In comment #15 this was API:F96EBFFC-8922-4B00-A801-9DAAE63858BF
 
    launchctl setenv KRB5CCNAME <the credentials cache location>
    open -a Chrome.app

See if things are better this time around.

I'd ask you to enable logging on Heimdal, but the library doesn't write much to the log :-(.

I have fixed the two keys with the incorrect dot notation!

I have done the commands listed and that DOES resolve the issue for the moment, my Kerb ticket was appropriately read and the browser logged in as intended.

I do have a couple questions:

1) What about Chrome 69+ made that break?
2) Is there a way to do this change programmatically for our userbase?

Tom

1) There were no behavior changes in M69+ that should've affected this that I'm aware of.

2) "kcc list -A --json" will spit out the caches in JSON form if it helps. How to do this programmatically for a heterogenous fleet of macOS devices is unfortunately beyond me :-/. Perhaps some of the enterprise folks in this issue might be able to help.

    Things that are relevant:

    1) Do you have SSO or do you perform a kinit after logging in?
    2) Do you push out a krb5.conf file for the organization?

In the meantime I'll see what needs to be done from Chrome's side to account for the cache location issue.

We don't push a krb5.conf file for the organization, we're getting our settings from NoMAD (nomad.menu), and we do have an SSO setup with NoMAD, and that's what gets the tickets placed in TicketViewer.

(Clearing Needs-Feedback per chat with Asanka.)