Help me Milestone 5... you're my only hope...
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
And when is this going to be fixed? I just cannot believe that this is such
a big
problem to solve. :(
Comment 132 - "I'm actively working on it and it's scheduled for inclusion
in Milestone 5."
http://www.chromium.org/developers/design-documents/network-stack
Add label: Mstone-5
Thanks CBent! This is one of the last items to cross off before we can
deploy Chrome
in our enterprise.
Does not seem to be schedule for Mstone 5. Any update on this?
This ended up getting broken up into multiple sub-bugs which have been
labeled with
Milestone 5, for example issue 29862.
I'll make sure related bugs are updated.
Hi,
Just to let you know, I've just downloaded milestone 5 (version 5.0.307.1
dev) and this
problem still exists. Or is version 5.x != milestone 5 ?
Cheers
What is the ETA for working integrated authentication????? I would love to
roll
this out company wide but cannot without this working properly.
Extremely annoying pop up window indeer...especially when you like to
ctrl+click all
your favorites as soon as you open up chrome...then you realize you have 8+
credentials
pop ups...
Will this ever be fixed? :(
Come on people, I would like to deploy intranet application on Chrome ... :(
I'd like to confirm (for tracking purposes when this is fixed) that this
feature/issue would add the equivalent of the
network.automatic-ntlm-auth.trusted-uris,
network.negotiate-auth.trusted-uris, and
network.negotiate-auth.delegation-uris settings from Firefox into Chrome.
A support question refers to this issue:
http://www.google.com/support/forum/p/Chrome/thread?tid=109a40b1b6675295&hl=en&fid=109a40b1b6675295000481732e7f26b5
This is really taking forever to sort out. The issue was first opened in
Sep 2008! Can
some priority be given to it?
beethoven07: thanks for the bug report. That regression was introduced
in r42600 on 2010-03-25.
I checked in a fix for this issue today. Please test this build:
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/43140/
1. Download the chrome-win32.zip file.
2. Open the chrome-win32.zip file and extract all files.
3. If you're running Chrome, shut it down.
4. Change into the resulting chrome-win32 folder, and run the
chrome.exe file in that folder.
5. Type "about:version" in the location bar and verify it is
"5.0.366.0 (Developer Build 43140)".
Now, use a proxy server or visit an intranet server that requests HTTP
NTLM or Negotiate authentication. This Chrome build should perform
the authentication automatically without prompting you for a user
name and password.
Please let me know if this build works as expected. Thank you!
Optional testing:
If you want to test a "before" build that doesn't have the fix, try
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/42598/
"about:version" in this build should say "5.0.363.0 (Developer Build
42598)".
This build should prompt you for a user name and password.
I have tested your fix w...@chromium.org and it works fine for me on Windows
XP SP3.
Thank you very much for the update, I very much look forward to rolling out
Chrome 5
instead of Internet Explorer at our organisation in the future.
I have tested this build and it works fine, it even loads up images served
from my
companyweb site without prompting for authentication (which Firefox does)
It didn't work for me in Vista. Didn't even allowed me to
check 'about:version'.
Little while after opening it crashed. The error and the dump is attached.
Attachments:
WERBE07.tmp.appcompat.txt 36.5 KB
WERABDE.tmp.version.txt 456 bytes
WERBE76.tmp.mdmp 2.3 MB
Chrome.JPG 47.1 KB
Tested the build.
Works like a charm when browsing external Internet sites (i.e. it doesn't
ask to
authenticate with the proxy) but when browsing some internal applications I
still get
the following error:
Error Text: DPWWA2403E Your browser supplied NTLM authentication data. NTLM
is not
supported by WebSEAL. Please make sure your browser is configured to use
Integrated
Windows Authentication.
I ran the tests on Windows XP SP3.
Works great! When shall this be rolled into the dev channel of chrome?
I'm running Windows 7. can't even access intranet sites. chrome seems to
think they
don't exist. i get redirected to a google search
i can access the site through IE, but no luck with chrome
okay, so I'm running DirectAccess. I had to uncheck this option:
"Use DNS pre-fetching to improve page load performance"
and now I can access my intranet sites without having to specify
credentials.
is there a bug in the way that your fix interacts with the dns-preftecher ?
Works great on Windows XP Pro with SP3. All of my intranet sites that have
been setup
with Windows Authentication worked seamlessly.
Thank you so much!
This seems to work on our local intranet using Small Business Server 2008
as our proxy.
I'll check more soon!! Thanks!!
Yes! it`s work! waiting this fix is in stable relise version!
Works fine on a Windows XP SP3 client attached to a Windows Domain running
ISA Server
(Pre-2004 version). Had a little problem login to gmail thou, requering
explicity
retyping the gmail URL to avoid a loop on the login process, asking over
and over for
user and password (not proxy user but gmail user).
I'm much obliged for this fix. Awesome Job!
Works great for my use over the 5.0.342.8 beta I had. When does this
update make the
BETA Channel, 2-3 weeks or???
Thanks for the fix!!!
works great for intranet sites and accessing the internet (uses
domain\username) ntlm
authentication!
#163: I'll open a separate bug to track the issue you reported.
Works on Windows 7 Enterprise. Passes through Bluecoat too. Not that I
expected
otherwise, but just stating for the record.
I am still prompted by my site which is using active directory for
authentication. My
application is built using the ASP.NET MVC 1.0 framework and developed in
Visual Studio
2008 (C#). Oh I'm also using Windows 7.
Attachments:
Version.png 50.5 KB
Prompt.png 139 KB
Intranet & Internet working here too (win vista 32bits and corporate
proxy). At last !!
Thx so much for fixing. I'll be reporting if any bugs come up.
thx again, i can now trash 1) corporate IE bs, 2) freaking heavy and slow FF
\o/
Works perfectly here, XP SP3 clients and Windows 2003 server (iis 6.0 w/
asp.net and
MVC 2.0 apps) also we have a Mac 10.5 intranet server with mod_ntlm_winbind
and that
works too.
Tested on Windows 7 Enterprise 64bit and WinXP SP3 Professional works
perfect so
far. Will post if anything breaks.
Thanks to everyone for testing the new build.
To help cbentzel and I debug the problems with the new build, please
do not report new test successes.
Reporting Test Failures:
If the new build still prompts for a user name and password when visiting
an *intranet* server, please visit the same intranet server, with the exact
same URL, using Internet Explorer. Does IE also prompt for a user name and
password?
This new Chromium build uses IE/WinINet's registry settings to determine
if a URL is in the Local Intranet zone. So it is expected to match IE's
behavior regarding the prompt.
Testing Internet Zone:
If you visit a server on the Internet zone that requests NTLM/Negotiate
authentication, this new build should prompt for a user name and password
(so should IE). I am also interested in hearing about Internet zone test
results. It is expected to match IE's behavior regarding prompting.
I tested the exact same URL in IE after receiving the prompt still in the
new build and
IE works how it should, it doesn't prompt me at all. Note, Firefox also
prompts me to
enter a username and password.
w...@chromium.org: re: comment 187
I tried to replay de same case on the fixed version of chromium with no
success (I tried deleting all
browsing history and using Private mode), so I haven't tested the not-fixed
build.
Also, I found one more problem where I'm asked for proxy authentication
*again* after deleting
browsing history (all checks selected), closing chromium, reopening and
entering gmail. And also, I
cant replay sistematically this problem too...
One odd thing about this corporate proxy is that, even on IE6/IE8, once I
enter gmail it asks me for
proxy authentication (3 times) for something which I'm not allowed to
access (probably something
relative to the embedded gtalk panel, which states connection problems;
gmail itself works fine).
So in my case, not all proxy authentication request are succesful.
dariush.pietzrak: Excuse me, I'm a little confused from your description
how Chrome
is not working as expected.
My interpretation is that Chrome 5.0.366.0 is correctly doing SSO for the
Negotiate-
only server and is prompting for username/password on the Negotiate+NTLM
OWA server.
From the last line in the bug report, it sounds like IE8 is doing the same
as well.
Is my interpretation correct?
Thank you for all the test reports. To help us keep track of the known
issues, please do not post new test reports until we have a new test build.
We have identified a problem with the current test build. It does not
construct the "service principal name" (SPN) for the server. A correct SPN
is required for Kerberos. Therefore, the Negotiate authentication scheme
may fail if the server requires Kerberos and the host name in the URL is not
the server's SPN (which is the canonical, fully-qualified DNS name of the
server).
cbentzel is working on a fix for the SPN issue. We will announce when a new
test build is available.
Just tried it and still no success. Chrome still prompts for Username/
Password if
behind a proxy server.
I think this is now resolved. Build 5.0.375.3 does not ask for
authentication. Is this
issue resolved?
jadranko.dragoje: This is mostly supported but some users are still
reporting issues,
likely because we are not using the canonical name of the server in the SPN
we are
generating. See related bug 29862.
I've landed a few patches which change how the Kerberos SPN is generated by
Chrome,
which will hopefully fix the issues some of you are having with SSO
authentication.
I'll update the thread after there's a build available for you to test
with. Thanks
again for all the feedback.
todd.giles, dariush.pietrzak, and others: Would you be able to test whether
a test
build of Chromium solves your problem?
You can retrieve the build from
http://build.chromium.org/buildbot/snapshots/chromium-
rel-xp/44542/chrome-win32.zip
More detailed directions for testing.
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/44542
1. Download the chrome-win32.zip file.
2. Open the chrome-win32.zip file and extract all files.
3. If you're running Chrome, shut it down.
4. Change into the resulting chrome-win32 folder, and run the
chrome.exe file in that folder.
5. Type "about:version" in the location bar and verify it is
"5.0.378.0 (Developer Build 44542)".
I'm glad this is working for many of you. There's no need for any further
positive
acknowledgement. Please feel free to add additional comments if you are
still running
into problems.
dev channel: Working on it and I'll post back here once it's ready.
sypsyp: I'm pretty confused why you are being presented with a password
prompt if IE
thinks the server is in the local intranet zone. Please open another bug or
email me
off-list.
@francip, I'm having the same issue, and have narrowed it down to the
Negotiate
functionality. One of my sites only uses WWW-Authenticate: NTLM, and
handles
automatic login using integrated auth perfectly. Several other sites that
send both
WWW-Authenticate: Negotiate and WWW-Authenticate: NTLM prompt for
credentials.
This bug needs to be reopened until the Negotiate behavior is fixed.
Comment #252 on issue 19 by cbent...@chromium.org: Automatic integrated
windows authentication (aka automatic NTLM / Negotiate Auth support)
http://code.google.com/p/chromium/issues/detail?id=19
I'll reopen.
I've attached my annoyance due to this issue, it only happens with Chrome
(not IE or
Firefox). This is happening because Chrome doesn't fully implement NTLM
authentication,
correct?
3rd year's a charm --please fix! :)
Attachments:
iPrism_authentication.png 154 KB
(No comment was entered for this change.)
Attachments:
iPrism_authentication.png 173 KB
cbent...@chromium.org: Let me know when you have that utility ready as per
comment 246
Maybe this sounds weird, but sometimes I do need manual authentications..
How do I bring the user name and password prompt back to Chrome 5/6?
Yay! It's working for me as of these past couples of days. --v5.0.375.99
The dev channel (6.0.458.1) now crashes each time an internal NTLM site is
visited. I did not see this on previous dev builds.
Newest dev version 6.0.466.0 dev
HTTPS over NTLM doesn't work. Chrome didn't ask for credentials, it simply
doesn't work.
When I tried to use "--disable-auth-negotiate-cname-lookup" and tried to
refresh page whole browser crashed :-)
Steve: Do you think the SSLClientSocketPool crash is the cause of issues
for #263? This also sounds like an HttpProxyClientSocket issue with
tunneling and authentication.
Comment #265 on issue 19 by cbent...@chromium.org: Automatic integrated
windows authentication (aka automatic NTLM / Negotiate Auth support)
http://code.google.com/p/chromium/issues/detail?id=19
(No comment was entered for this change.)
Most recent build appears to have fixed the issue. I no longer crash when
using NTLM authentication.
458.1 dev just plain crashes all the time.
466.0 dev cannot access any SSL secured sites from work (behind NTLM proxy,
WebMarshal). I've logged an issue
http://code.google.com/p/chromium/issues/detail?id=49493.
All subsequent builds after 466.0 cannot access SSL secured sites with a
slightly different error. The last build that works for me is 453.1 dev.
roman.rodov: Thanks for the report. I will try to repro locally, although
with a SQUID proxy rather than WebMarshal. If that doesn't work I may ask
you for more detailed information.
If I don't have my proxy enabled, I cannot access SSL based sites, but I
can in IE or FF, I think its related to this patch, as I was getting the
crash error last week.
What can I do to get more details?
Sarkie: You can go to about:net-internals in chrome and click "Dump To
Text" to show output details. Rather than adding to this already long bug,
please send to van...@chromium.org and cben...@chromium.org. Also, please
scrub out any data you don't want us to see.
OSX and Linux users: Negotiate authentication has been added to Chrome, and
we'd appreciate it if you tested it and let us know of any issues.
This isn't in dev channel yet, but it is in the latest builds from the
Chromium trunk (after r53024)
http://build.chromium.org/buildbot/continuous/mac/LATEST/chrome-mac.zip
http://build.chromium.org/buildbot/continuous/linux/LATEST/chrome-linux.zip
http://build.chromium.org/buildbot/continuous/linux64/LATEST/chrome-linux.zip
The SVN revision should be r53024 or later.
You need to specify --auth-server-whitelist on the command line for servers
you want to authenticate to (proxies are automatically authenticated to).
For example, --auth-server-whitelist="*.intranet.example.com" will
whitelist any host in the intranet.example.com domain.
This dynamically loads your system GSSAPI library the first time a
Negotiate authentication challenge is seen: libgssapi_krb5.dylib on OSX,
and one of libgssapi_krb5.so.2, libgssapi.so.4, or libgssapi.so.1 on Linux.
Comment #274 on issue 19 by cbent...@chromium.org: Automatic integrated
windows authentication (aka automatic NTLM / Negotiate Auth support)
http://code.google.com/p/chromium/issues/detail?id=19
At this point I am going to declare this particular issue fixed. The
general feature has been implemented on all platforms. There are some known
issues, but they are being tracked in more tightly focused bugs.
If any of you encounter issues with the Negotiate authentication scheme or
Integrated Authentication in general, please enter specific bugs.
I took a chance and upgraded from Chrome v5 to Chrome v6.0.472.51 beta.
The installation was fine, but I can't access any sites. I'm behind a proxy
and normally a prompt would come up the first time I open Chrome asking
(and saving) my login details to go through the proxy.
Is it the Proxy or another bug?
There is now no prompt and I get the following error message:
This webpage is not available.
The webpage at http://mail.google.com/ might be temporarily down or it may
have moved permanently to a new web address.
More information on this error
Below is the original error message
Error 9 (net::ERR_UNEXPECTED): Unknown error.
Hello, this feature has stopped working for me over the last couple of
weeks.
I have been browsing for more than 3 hours to find a solutions and there is
not a solution. Chrome sucks im moving back to firefox.
in version 6.0.472.63 not promting to save Basic authetntication, which was
working fine in previous major version :(
nissan370zfan: Could you enter a separate bug for Chrome attempting to
retrieve favicon.ico for non-HTML pages [this is completely unrelated to
authentication, although there is a bug to disable authentication prompts
if there are problems retrieiving favicon].
HTML pages can specify a different location for favicon with <link
rel="icon"> elements, but by default they are at the root of the server.
It is related to authentication in my case because the users are
authenticated only off the subdomain and not the root; thus it is causing
authentication to pop-up. I will create a separate bug.
What you described was a sub-path. not a sub-domain.
Authentication to a local NTLM authenticated web site has stopped working
for me with dev channel release 9.0.587.0. It was working in the previous
version.
I now get a login dialog (but only once for each host) when it used to
authenticate automatically.
Ben.Lings: Thanks for the report, I'll try to repro locally. Just to
confirm, it's a server rather than proxy which is experiencing issues? Is
it https or http?
Just click the update to 9.0.587.0 and as Ben.Lings found out NTLM fails
against an intranet server :-(
http -> server
je...@jeffmartin.com: Have you specified --auth-server-whitelist (and
--auth-negotiate-delegate-whitelist from your description)?
i have tried both of those settings now... (at the same time) and set it to
servers specified by my IT dept for making firefox work (which it does)
their directions specify putting these servers in:
network.automatic-ntlm-auth.trusted-uris
network.negotiate-auth.trusted-uris
network.negotiate-auth.delegation-uris
They are all local intranet server addresses and it seems like they should
be in the intranet zone. The error message that comes back from bluecoat
doesn't have my username and that is seeming to indicate that my login
isn't being passed. Thanks for your help with this.
Thanks Jeff. I'll email you directly to help diagnose the problem.