Kerberos authentication does not work with alias

RESOLVED FIXED in Firefox 35

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: b.de.kort, Assigned: dragana, NeedInfo)

Tracking

({dev-doc-complete, site-compat})

35 Branch
mozilla38
x86_64
Windows 7
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox35+ fixed, firefox36+ fixed, firefox37+ fixed, firefox38+ fixed, firefox-esr31-, relnote-firefox 35+)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

I tried to log on to websites using kerberos in Firefox beta 35.0.

Probably similar to https://bugzilla.mozilla.org/show_bug.cgi?id=804605


Actual results:

It fails when I use an alias (probably a CNAME, but I am not that good with terminology). It is succesful when I use the fully qualified hostname. Note that Kerberos was set up properly and worked fine where required until this build.

I am back on the release channel. Downgrading Firefox has resolved the issue for me.


Expected results:

I should have logged in on the (company/intranet) website.
(Reporter)

Updated

4 years ago
Version: 34 Branch → 35 Branch
Component: Untriaged → Networking
Product: Firefox → Core
Andrew, just if you would be interested..
Flags: needinfo?(abartlet)
andrew, can you let us know if you can take a look at this or not? Thanks!

Comment 4

4 years ago
Yes, I'm very happy to comment.  

As a first and simple diagnostic, can you verify that IE behaves any differently?  You may have to use a network monitor to confirm it isn't falling back to NTLM.

In general, access to a CNAME of a kerberos host that isn't registered as a servicePrincipalName (essentially an alias) in AD, or not registered otherwise (more complex, I would add a second principal with the same keys for simplicity) with the MIT KDC, requires steps (a reverse DNS lookup) that open up security attack vectors, slowness and unpredictability.  

The security weakness applies much more to protocols that leverage the mutual authentication aspects of Kerberos, I need to think harder as to if there is a practial value on HTTP.  Encrypted IMAP or SMTP might be more relevent.  In any case, the weakness is that you no longer have a direct mapping between the name you asked the access to, and the name you got the ticket from the KDC for. 

Sadly in MIT domains it is/was often used, with a setting of 'rdns' being set in krb5.conf files on Linux by default.  However, in AD domains, it is always exactly the wrong thing to do.  (Working reverse DNS is also quite rarely correct in an AD domain, because Windows essentially never uses it). 

Indeed, when doing other work in firefox for NTLM recently, I saw the code for bug #804605 and was saddened.  I think this much belongs in the Kerberos libs, and controlled globally by the krb5.conf, not additionally in each application.
Flags: needinfo?(abartlet)
(Reporter)

Comment 6

4 years ago
Comment on attachment 8534956 [details]
log.txt: (new profile; issue occurs when navigating to "intranet". Yes, the website, not the google search.)

NM, I hadn't set up my trusts yet. in these logs. Attaching new copy.
(Reporter)

Comment 7

4 years ago
New logs after actually trusting the intranet domains.

Comment 8

4 years ago
Since 35.0 has hit the release channel, this problem is now affecting me (and likely other people).

I've bisected the problem to:
Last good revision: 5bd6e09f074e
First bad revision: afc933adf723
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5bd6e09f074e&tochange=afc933adf723

Within that range https://hg.mozilla.org/mozilla-central/rev/4d21e0728967 seems most likely to me.

With NSPR_LOG_MODULES=negotiateauth:5, I get the following results:
====== Good ======
  service = friendly.example.com
  using negotiate-sspi
  nsAuthSSPI::Init
  InitSSPI
Using SPN of [HTTP/canonical.example.com]
AcquireCredentialsHandle() succeeded.
nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
entering nsAuthSSPI::GetNextToken()
InitializeSecurityContext: continue.
  Sending a token of length 2041
====== End ======

====== Bad ======
  service = friendly.example.com
  using negotiate-sspi
  nsAuthSSPI::Init
  InitSSPI
Using SPN of [HTTP/friendly.example.com]
AcquireCredentialsHandle() succeeded.
nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
entering nsAuthSSPI::GetNextToken()
InitializeSecurityContext: continue.
  Sending a token of length 40
====== End ======

The SPN does not have the canonical name like it does in the working version.

See also Bug #857291 which is where the fix was implemented last time this problem came up.

Comment 9

4 years ago
Running the nightly with build ID 20140923030204 and setting dns.ttl-experiment.variant to 2 or 3 produces a bit of improvement.  The first auth attempt still fails but reloading the page then succeeds.  Setting dns.ttl-experiment.variant=1 or dns.ttl-experiment.enabled=false yields the same broken behavior as in 35.0.  This seems like strong evidence that https://hg.mozilla.org/mozilla-central/rev/4d21e0728967 for Bug #1067679 is in fact responsible.

The config tweak is not effective on 35.0.  I'm assuming that the relevant code has been compiled out of the release builds.

Since this is stopping me from using intranet sites that I need for work, I'd like to get this fixed quickly if possible.  Last time this broke the fix was part of the next x.0.1 release.  Can anyone advise me on what to do next?  Is backing out the above change for 35.0.1 possible?  At the very least can someone change the status from UNCONFIRMED?
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1121654
(Assignee)

Comment 11

4 years ago
I found the error:

at http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/nsHostResolver.cpp#1403

GetAddrInfo is called with flags being PR_AI_ADDRCONFIG but inside GetAddrInfo and _GetAddrInfo_Portable they are treaded as nsHostResolver flags:
int prFlags = PR_AI_ADDRCONFIG;
if (!(aFlags & nsHostResolver::RES_CANON_NAME)) {
    prFlags |= PR_AI_NOCANONNAME;
}

therefore the flags are unset.

The patch is coming...
(Assignee)

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

4 years ago
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 12

4 years ago
Attachment #8549467 - Flags: review?(mcmanus)

Comment 13

4 years ago
Dragana, is this the same problem as bug 1121843 ?
Flags: needinfo?(dd.mozilla)
(Assignee)

Comment 14

4 years ago
According to comment 4 in mug 1121461, that bug is the same as this one.

Probably the 1121843 is also the same.
Flags: needinfo?(dd.mozilla)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1121843

Comment 16

4 years ago
Dragana - please excuse my ignorance. But how do we proceed? How do I get the problem in my stable version 35.0 released?
(Assignee)

Comment 17

4 years ago
There must be a new release to fix this problem in 35.0. But I do not know when.
Once this patch is reviewed (and has successfully run the automated tests on tryserver), it will be landed on mozilla-inbound, and then mozilla-central (currently 38). It then needs to be nominated for 'uplift' to earlier releases. Depending on the complexity of the fix and the severity of the problem, it may be accepted on aurora (currently 37) or even beta (currently 36).

If an unacceptable amount of people are affected, it may be grounds for a point release (35.0.1), or if a point release is already planned it may be taken for that as well. However, the risk/reward tradeoff goes up for each stage, so they may not take it.

Comment 19

4 years ago
Hello,

we also have this bug. Please fix it as soon as possible because this problem exists on most of our internal sites.

Thanks.
thanks Dragana.. looks like this suffered some kind of merge conflict - maybe in the backout of 820391.

I'd like steve to do the review
Attachment #8549467 - Flags: review?(mcmanus) → review?(sworkman)
Comment on attachment 8549467 [details] [diff] [review]
bug_1108971_v1.patch

Review of attachment 8549467 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch. r=me.
Attachment #8549467 - Flags: review?(sworkman) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1121950
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1122474

Comment 25

4 years ago
> If an unacceptable amount of people are affected, it may be grounds for a
> point release (35.0.1), or if a point release is already planned it may be
> taken for that as well. However, the risk/reward tradeoff goes up for each
> stage, so they may not take it.

point release would be great. having our developers and marketing folks use firefox 34 for a couple of weeks is not exactly an exciting prospect...(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #18)

Comment 26

4 years ago
(In reply to j.zimmermann from comment #25)
> > If an unacceptable amount of people are affected, it may be grounds for a
> > point release (35.0.1), or if a point release is already planned it may be
> > taken for that as well. However, the risk/reward tradeoff goes up for each
> > stage, so they may not take it.
> 
> point release would be great. having our developers and marketing folks use
> firefox 34 for a couple of weeks is not exactly an exciting prospect...(In
> reply to Emanuel Hoogeveen [:ehoogeveen] from comment #18)

Looking at the general activity in this and duped bugs, I'd say a lot of people are affected - a point release is probably a very good idea to fix this ASAP for many corporate users.

Updated

4 years ago
Duplicate of this bug: 1122410

Comment 29

4 years ago
Added tracking for FF35 due to corporate users if a chemspill version is released.
Comment hidden (advocacy)
Will track and keep this in our queue in case we do a chemspill or dot release for 35.
https://hg.mozilla.org/mozilla-central/rev/d5092aaecfca
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Duplicate of this bug: 1122938

Updated

4 years ago
Duplicate of this bug: 1123254
Please nominate for uplift to Aurora/Beta/Release branches so we are prepared in the case of a dot release.
Flags: needinfo?(dd.mozilla)
(Assignee)

Comment 37

4 years ago
Comment on attachment 8549467 [details] [diff] [review]
bug_1108971_v1.patch

Approval Request Comment
[Feature/regressing bug #]: Bug 1067679
[User impact if declined]:Everything using network alias does not work, someproblems with authentication that use aliases.
[Describe test coverage new/current, TBPL]: comments 10, 12, 13 and 14 from bug 1121843
[Risks and why]: no risk, it revert to behavior that firefox had before bug 1067679. 
[String/UUID change made/needed]: none
Flags: needinfo?(dd.mozilla)
Attachment #8549467 - Flags: approval-mozilla-release?
Attachment #8549467 - Flags: approval-mozilla-beta?
Attachment #8549467 - Flags: approval-mozilla-aurora?
Attachment #8549467 - Flags: approval-mozilla-beta?
Attachment #8549467 - Flags: approval-mozilla-beta+
Attachment #8549467 - Flags: approval-mozilla-aurora?
Attachment #8549467 - Flags: approval-mozilla-aurora+
Comment hidden (advocacy)

Comment 40

4 years ago
Please make a patch release ASAP.  Could not work with ver 35 at all (it annoyingly kept asking for
the passwords here and there).  Had to downgrade to 34.0.5 (which works fine!), but now it constantly
wants to upgrade to 35.
(In reply to Anton Lavrentiev from comment #40)
> Please make a patch release ASAP.  Could not work with ver 35 at all (it
> annoyingly kept asking for
> the passwords here and there).  Had to downgrade to 34.0.5 (which works
> fine!), but now it constantly
> wants to upgrade to 35.

can you verify the latest nightly to make sure it resolves your problem?

I'm concerned that with your comment about "here and there" you are running into a different problem (bug 1121895)

Comment 43

4 years ago
"here and there" was to underscore that there're many resources I needed to access all of which suddenly stopped to let me in without the popup for credentials.
Comment on attachment 8549467 [details] [diff] [review]
bug_1108971_v1.patch

Taking it for a potential 35.0.1
Attachment #8549467 - Flags: approval-mozilla-release? → approval-mozilla-release+
Setting as qe-verify- since the fix was verified in bug 1121843 (comments: 10, 13, 14).
Flags: qe-verify-

Updated

4 years ago
Duplicate of this bug: 1124134

Comment 48

4 years ago
Works again for me with 35.0.1, thanks to all making this possible.
Will there be regression tests for this bug?

Comment 49

4 years ago
I can not confirm unfortunately. For me, it still doesn't work (comment 48). Firefox still asks for a user name - despite of SSO.

Comment 50

4 years ago
(In reply to Burghardt from comment #49)
> I can not confirm unfortunately. For me, it still doesn't work (comment 48).
> Firefox still asks for a user name - despite of SSO.

Are you actually using 35.0.1 yet? (check on about:support (Help > Troubleshooting information) )

If not, download from: https://www.mozilla.org/firefox/all/ .

The update was only released yesterday, and I don't know at what rate people are being updated right now. Please let us know the results of trying this.
Flags: needinfo?(burghardt.scholle)

Comment 51

4 years ago
Hi,

I can confirm proxy authentication via kerberos / sso is working here.

Regards
Carsten

Comment 52

4 years ago
it's again working here as well. thanks a lot!

Comment 53

4 years ago
(In reply to Gijs Kruitbosch from comment 50)
Yes - I'm acutally using the vesion 35.0.1 :-).
Flags: needinfo?(burghardt.scholle)

Comment 54

4 years ago
35.0.1 fixed the issue for me, thanks!  Also, NCBI is switching to ESR to (hopefully) avoid any such troubles in the future.
This was fixed in 35.0.1 and will be in the ESR 38 that's shipping in 8 weeks.

Comment 56

4 years ago
I am seeing this bug in beta of V40 as well

Comment 57

4 years ago
(In reply to kiran from comment #56)
> I am seeing this bug in beta of V40 as well

Dragana, any idea if this regressed?
Flags: needinfo?(dd.mozilla)
(Assignee)

Comment 58

4 years ago
Kiran, can you upload a log or send it to me via e-mail:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Thanks a lot!!!
Flags: needinfo?(dd.mozilla) → needinfo?(technocrattobe)
You need to log in before you can comment on or make changes to this bug.