User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160623154057 Steps to reproduce: Open page in private mode with SSO configured in mozilla.cfg Actual results: page asks for credentials Expected results: SSO to page. It works in FF47 and older versions. Not tested with 48.x

SSO configured in mozilla.cfg using network.automatic-ntlm-auth.trusted-uris and network.negotiate-auth.trusted-uris In normal browsing all works fine

Arnis, could you tell me step by step to reproduce on my machine? If I create mozilla.cfg with the lines your provided, which website do I need to visit to repro the bug?

Use domain joined windows computer and webserver with integration to active directory 1. Make Firefox config for SSO using network.negotiate-auth.trusted-uris or network.automatic-ntlm-auth.trusted-uris depends on your webserver configuration. I configured this in mozilla.cfg file. 2. Test configuration in "normal" mode, open company website - should authenticate in company website(works fine for me). 3. Open new "Private" tab and open company website - it asks for signing credentials (this is problem, in earlier versions 47.x in private mode SSO works and automatically signs in company website)

Hum, it will be hard for me to reproduce the issue as I don't have any webserver with authentication to test.

This was made intentional. However, I may start thinking we may want to allow this for the trusted list of URIs and only completely disable SSO (via sspi) for non-trusted URIs (i.e. somewhat loose the restrictions added in bug 1248564.) Jan, what do you think?

The plan was to set network.negotiate-auth.trusted-uris to "https://", which basically sends authentication data to every https:// site which asks for them. Sending data also in Private browsing might be an unpleasant surprise for the user. We'd better ask for reasoning our man for SSO stuff who proposed that change.

If you would allow it only for network.negotiate-auth.trusted-uris, you would let Private Mode let loose against your enterprise infrastructure. Your domain controllers will know about the resources you access. This is of a less problem with NTLMSSP on Windows but it is still a sizable privacy leak. The real problem is that people confuse Privacy Mode with "Do not remember cookies and a history" mode. Honza, if you want to reduce restrictions for Private Mode, it would be good to have a knob that could be set by distributions to 'false' to disallow leaking privacy details to your enterprise domain controllers about the servers you access in the Privacy Mode.

I think if I as admin specify sites for which I need SSO in parameters: "network.negotiate-auth.trusted-uris" and "network.automatic-ntlm-auth.trusted-uris" using cfg file and set this sites as locked preference this is enough to trust to this resources and send autentification data to make SSO. I think that SSO if is configured must work in privacy mode too. If you think that this is problem make additional configuration parameter to allow or deny sending credentials in privacy mode.

(In reply to Alexander Bokovoy from comment #7) > Honza, if you want to reduce restrictions for Private Mode, it would be good > to have a knob that could be set by distributions to 'false' to disallow > leaking privacy details to your enterprise domain controllers about the > servers you access in the Privacy Mode. I agree. Let's add a pref and maybe turn it to false by default. See also bug 1315680 that may be related.

About proxy server authentication - yes it is problem, too. In private mode asks for credentials. For proxy settings in FF is use system settings.

(In reply to Arnis Rukis from comment #10) > About proxy server authentication - yes it is problem, too. In private mode > asks for credentials. For proxy settings in FF is use system settings. That's a good point too, actually. Proxy should go all the time. I think that's bug 1315680 at its whole glance. Thanks. I will incorporate it in the patch for this bug.

Comment on attachment 8808318 [details] [diff] [review] v1 (always sso to proxy, pref for sso to server in a PB window) Review of attachment 8808318 [details] [diff] [review]: ----------------------------------------------------------------- ::: extensions/auth/nsHttpNegotiateAuth.cpp @@ +78,5 @@ > } > > nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID); > if (!prefs) { > + return false; All the other error paths here return 'true'--and this specific test used to return false--are you sure you should have changed this to 'false' here? I guess this is mostly academic, because I assume if we can't get the PrefBranch service things will already be fairly messed up. ::: netwerk/protocol/http/nsIHttpAuthenticableChannel.idl @@ +107,5 @@ > void onAuthCancelled(in boolean userCancel); > + > + /** > + * Tells the channel to drop and close any sticky connection, since this > + * connection oriented schema cannot be negoticated second time on negotiated

(In reply to Jason Duell [:jduell] (needinfo me) from comment #13) > Comment on attachment 8808318 [details] [diff] [review] > v1 (always sso to proxy, pref for sso to server in a PB window) > > Review of attachment 8808318 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: extensions/auth/nsHttpNegotiateAuth.cpp > @@ +78,5 @@ > > } > > > > nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID); > > if (!prefs) { > > + return false; > > All the other error paths here return 'true'--and this specific test used to > return false--are you sure you should have changed this to 'false' here? I > guess this is mostly academic, because I assume if we can't get the > PrefBranch service things will already be fairly messed up. Actually, I think false is correct here. At this moment we've established that channel is in PB mode. We can only return true (i.e. to behave as if the channel were not in PB mode) when one of the privatebrowsing.autostart or private-browsing-sso prefs are set. But they can't be set, so return false. I can rewrite the patch to make this more clear. The code before was wrong.

I split out the part with sticky conn. It actually belongs to a different bug.

(not try, since there are no tests that would be affected)

Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/720a160f4c0c Pref to send default NTLM creds in PB, Always send default creds to proxies in PB. r=jduell