So, oddly I can duplicate in firefox, but not chrome. :(

I wonder if this is a firefox bug. It definitely used to work...

cc @praiskup

Working here with firefox-99.0-1.fc36.x86_64 without firejail.

In command line can be tested with:

KRB5_TRACE=/dev/stderr curl -u : --negotiate  https://copr.fedorainfracloud.org/api_3/gssapi_login/

Debian 11's Firefox 91.8.0esr

I can not easily test this configuration ^^^. I know that in Fedora we have configured FAST which seems to be last useful log entry in the log above.

My log continues like:

[3104056] 1651209857.017887: Decoding FAST response
[3104056] 1651209857.017888: FAST reply key: aes256-cts/7DAE
[3104056] 1651209857.017889: TGS reply is for praiskup@FEDORAPROJECT.ORG -> HTTP/copr-fe.aws.fedoraproject.org@FEDORAPROJECT.ORG with session key aes256-cts/BF2E
[3104056] 1651209857.017890: TGS request result: 0/Success
...

Configuration is here and this conf plugin.

For taking tickets, we use fkinit script. (I have two-auth enabled)

$ klist
Ticket cache: KCM:17122
Default principal: praiskup@FEDORAPROJECT.ORG

Valid starting       Expires              Service principal
04/29/2022 07:21:22  04/30/2022 07:21:07  krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG
        renew until 05/06/2022 07:21:07

I'm not sure otherwise, perhaps some expert @abbra ?

@kevin wrote:

So, oddly I can duplicate in firefox, but not chrome. :(

Meh, but you are on Fedora I guess, with the pre-installed fedora-packager configuration.
Therefore I'm lost here :-/

From logs in the comments above, the difference is in the client behavior to not follow CNAME resolution and using HTTP/copr... principal instead of resolving a CNAME of copr.... hostname and using HTTP/copr-fe... target principal.

I am using dns_canonicalize_hostname = fallback and I am failing to get the HTTP/copr.fedorainfracloud.org ticket but succeeding with HTTP/copr-fe.aws... one because of the fallback.

[I initially sent this in a mail reply, and that got bounced by pagure for some unspecified policy violation -- heaven knows what. I'll make a separate issue for that anyway.]

Thanks for the hints. I'm a bit confused now how the temporary profile
I was trying with was configured. I thought I was following
https://fedoraproject.org/wiki/Infrastructure/Kerberos but I think I
must have had network.negotiate-auth.trusted-uris set somehow.

Anyhow, if I set trusted-uris to
'.fedoraproject.org,.fedorainfracloud.org,.redhat.com (the
instructions for copr do actually mention adding to it) and remove
dns_canonicalize_hostname = false from krb5.conf, I can do gssapi to
copr. However, I still get the 500 error subsequently trying to access
bugzilla.

I also looked at RHEL8 (a bit painful) on the remote VM I use with an
under-resourced laptop this end. That works, and I found that
trusted-uris for its firefox installation is set to https://, which
the wiki page above says is only necessary for old firefox. It looks as
if that page needs review, at least for that and the
dns_canonicalize_hostname setting.

The main thing I don't understand is the significance of trusted-uris,
and specifically whether it's a security issue to have it set to allow
all sites, if that's what https:// means; I'd assume it is, given the
need to set it, but I know there are Red Hat experts. (Obviously not
your problem, but it's not even documented anywhere I've found what
format is accepted in the firefox config, which is obviously not just
URIs...)

HTH. Let me know if there's anything I can do to diagnose the bugzilla
problem. It's not a big deal being able to have spnego working in this
case, of course, but it's a nuisance if having it in one place breaks
another.

I have said years ago that we should be using just 'https://' as a prefix and we did at that as a default in Fedora and RHEL. It is secure enough because the only point who will ever see you are attempting to talk to an out of realm host is your KDC. If your KDC does not have cross realm trust with something that owns the principal you are asking for, the whole processing would stop here. The target host would never see it.

Red Hat IT folks ignored our recommendations and went for more complex configuration. It is their choice, as they have to support it you definitely don't need to set individual domains.

FYI, bugzilla auth should be fixed now. (It has nothing to do with kerberos, it's using SAML2 and there's a bug on our side that sometimes causes the SAML2 data to be empty. I've refreshed it and will be looking to figure out again how it happened)

So, it sounds like this is fixed now? (Except I am not sure why I am seeing this with firefox)

ok, I got a new TGT and everything is working fine for me with firefox now too.

I think this is solved now? please re-open if there's further work to be done.