I have an old laptop running WinXPpro and both IE8 and CoolNovo which can download an applet just fine from our Win2008 Server R2 SP1 x64 IIS 7.5.7600.16385. I have a new laptop (same hardware) with a x64 Windows7 and IE9 and CoolNovo which can't download the applet (.jar file) from the same server. I can download this .jar file directly as a url and I can download and run the applet over the internet from the .jar product provider on both laptops just fine. So it has something to do with my new laptop. If we add anonymous authentication to the web server, our app works on both too.
Using fiddler, I can see the NTLM authentication conversation on both laptops. On the old one, it works just fine:
A 401 with the WWW-Authenticat Header is present: Negotiate and one for NTLM
Then a 401 (challenge - NTLM type 2),
Followed by a 200 with the client sending the NTLM type 3 header
On the new laptop, I get the first two 401s, but no 200. It simply tries again with the 401s 2 more times.
Any ideas why the new Windows7 laptop would not be sending a 200 NTLM type3 response to the server or what the issue here might be?
Old Laptop: jre6: 1.6.0_30 checked as the user java runtime env. No System java runtime versions checked.
new Laptop: jre6: 1.6.0_31 checked as the user AND system java runtime env.
TVMIA.
I've encountered the same issue and after looking in server security log a have found two strange record just after each unsuccessful logon:
1. 4624 - successful logon. and just after that:
2. 4634 - successful logoff
Very strange... I've googled for these event codes and found this thread:
SCCM reporting not working on W2K8 R2 64-bit
And the solution to this problem is:
1. Open the IIS Manager and go to your site
2. Double click Authentication under IIS
3. Click on Windows Authentication and then choose "Providers..." under Actions
4. Add NTLM if it isn't there and move it to the top.
5. Click OK
It worked for me!
Related
I am working with microsoft bot emulator and everytime I make a request to an external link my office proxy blocks it and application returns 407 error. To work around this I tried following hacks.
Hack #1:
Used fiddler 4 with auto authenticate rule enabled. But I found it doesn't work for ntlm proxy.
I also found that the request which are completing with 200 status code has a proxy-authorization header with some encoded content. but I don't know how to set this header for all the requests.
Hack #2:
Installed and ran a cntlm proxy, still same error.
I am using Micosoft bot framework 4 with dotnet core and bot emulator 4.10, Os: windows 7
Please help let me know if I can somehow make it work around ntlm proxy.
Looks like the office network is very restricted when it comes to network access.
May be you should better talk to your IT department if you can't get a PC that is located in a different subnet that is less restrictive. Or if you are lucky the change the configuration for your PC so that you can access the required servers without proxy.
I have a C++ Windows application, developed using Visual studio 2017 on windows 10 system. This application uses cpprestsdk to post request to REST Server. My application works perfectly fine on windows 10 machine with properly posting request over ssl to rest server. I did not create any local certificate to make my application work on windows 10.
However same application when ported on windows 7 (64 bit), is not able to POST request with SSL protocol to rest server.
Same request works without SSL, (http://HOST/API works)
but (https://host/api fails)
by giving following error.
winhttpsendrequest 12029 a connection with the server could not be established.
From same windows 7, PostMan can successfully post https request.
No clue of what could be wrong with the implementation.
Can any one share what could be the reason of failing the POST request on windows 7?
I'm a bit late with the answer but I hope that it might help others who face the same problem ...
I think that your server insists on using tls version higher than 1.0 which is a default on Windows 7. Unfortunately cpprestsdk cannot be configured to use a specific tls version. On Windows cpprestsdk uses WinHTTP which exposes two handles but only one of them can be used to configure tls (I do not remember handle names at the moment). Unfortunately the native handle that cpprestsdk has access to cannot be used to configure tls.
The only workaround is to configure Windows 7 (and indirectly WinHTTP) to use a specific tls version as default. Instructions on how to do that can be found here: https://support.microsoft.com/en-ca/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi.
I recently upgraded my Intranet web server to Server 2008 x64 running IIS 7.5. The staff website that I maintain uses NTLM to tell which user is viewing the page and display appropriate content based on that. Since the upgrade or MAC clients can no longer connect through Safari and Firefox is no longer accepting the about:config setting of network.automatic-ntlm-auth.trusted-uris. I had to remove the FQDN from that entry for them to not get the 401 page only.
My development server is still a Server 2003 box with IIS6 and the MACs can authenticate to that both through Safari and firefox with no problems.
I checked on the new IIS7 server for the registry key LmCompatibilityLevel located in HKLM\SYSTEM\CurrentControlSet\Control\Lsa but this key is not there. So my understanding is that it will result in level 0 by default allowing LM, NTLM and NTLM v2 auth requests.
Any suggestions on how to get authentication back?
Had a similar problem with Safari forcing users to login innumerable times and this fixed it for me:
In IIS Manager (IIS 7), navigate to the website and right-click on Authentication to "Open feature".
Right-click on "Windows Authentication" and select "Providers" which should display Negotiate & NTLM
Remove "Negotiate" and restart the website and it should work with a single login prompt.
In my environment, my SharePoint 2010 is running on Windows Server 2008 R2 with IIS7. The expected behavior after adding SPNs was that the user was prompted 3 times by default. How to configure the prompt times? maybe 2 or 5 times?
It is decided in the browser, not in the server. Server returns HTTP401 status code in all of these requests, browser decides if the user should retry or not.
Anyway, when you have SPNs set up, passwords should work from the first time. It is worth rebooting the server after SPN setup.
I am using a digest like (but not digest) custom authentication scheme where the authentication header field of the http request contains username:encryptedtokendata
I do not have any problems with this scheme on on Windows 7 and Azure emulator. However when I deployed my service to Azure's Windows 2008 Server SP2 my authentication header fails to make it through to my wcf service. It is null.
IIS on Windows 7 & Windows 2008 Server has both anonymous and membership authentications enabled (because i use membership for certain authentications). Every other authentication is disabled.
Any ideas what might be causing this issue for me? I searched stack-overflow and google up and down without any luck.
I would check and make sure your authentication module is getting installed in Azure and that it is listed correctly in IIS there. You should be able to remote into the instance and troubleshoot it just like you would on premise.