First of all are negotiate, ntlm and kerberos three different implementation of windows authentication?
IE sends this:
Authorization: Negotiate YIIFswYGKwYB ...
Firefox sends this:
Authorization: NTLM TlRMTVNTUAADAA ...
Do they use different protocols? If so how to configure iis 7.0 so that only ntlm would be used?
p.s. iis is configured to use windows auth, but both browsers throw login forms and login only succeeds for firefox.
Technically, no.
Practically, yes.
Technically Kerberos is the technological successor to NTLM. But you can use either to authenticate against a Windows domain/server. If you select negotiate, your browser will attempt to authenticate in whatever way is successful, which is sometimes NTLM.
Heads up...
Safari on iOS (from 7 to 7.0.2, and then 8 as well, it seems) has troubles with Kerberos, so if you have to support iPhones/iPads, disable Negotiate and only have NTLM.
Related
Using IIS server with NTLM authentication. Where can I modify the session timeout settings?.
I'm afraid it is almost impossible to control the lifetime of your NTLM ticket from server side.So windows authentication should be implemented in a trusted environment.
I think the only way to log out windows authentication is clean cache in server side and re-open web browser.
If you need kind of authentication that ticket timeout can be controlled all the time, you could use custom form authentication instead.
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-security/introduction/an-overview-of-forms-authentication-cs
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I am encountering the following issue when trying to configure an intranet ASP.NET site in IIS 8.5 for Windows authentication. I have the IIS Windows authentication provider settings set to:
Negotiate
NTLM
This works great for Windows-based browsers - users are logged in seamlessly. Mac-based browsers don't seem to support the Negotiate protocol; when accessing my site you are prompted for your domain credentials. Even when responding with correct credentials, the browser responds to the authentication challenge with "NTLM xxxxxxx...". IIS doesn't like this and always responds with a 401. This sends the browser into an authentication loop where you are prompted for your credentials endlessly. If you click "Cancel" (depending on which browser you are in), you will finally get a 401 response (not very useful).
If I modify the settings and remove the "Negotiate" provider, I am still prompted when accessing the site from a Mac browser, but this time the NTLM challenge succeeds and I can authenticate. The problem with this is I am now getting an authentication prompt from Windows browsers as well.
Is there a way to get around this (do I have Windows authentication misconfigured)? I am fine with having to answer a credential prompt from the Mac but as the vast majority of my users will be accessing from Windows, I would prefer they still get the "invisible" log on experience.
If I'm understanding your question correctly; Safari/Apple doesn't support Windows Authentication. Basic Authentication needs to be enabled within IIS in order for Safari to login.
We are using the Sharepoint.OpenDocuments.EditDocument2 ActiveX control and method.
The method is being called from JavaScript in an IE6 client on a Windows XP SP3 client (fully patched).
The server is running IIS6 on Windows Server 2003 SP1
Fronting the IIS server is Tivoli Access Manager (TAM) which proxies access to the web applications sitting behind it. Similar to forms authentication, it creates a session cookie for authentication purposes, that must be present for the HTTP request to reach the IIS server.
In front of TAM is an F5/BigIP load balancer and SSL encryption offloader, which enforces that incoming requests use the HTTPS protocol.
What is happening is that HTTP requests issued by this control do not contain any session cookies that were present in the browser. It drops the ASP.NET session cookie, the ASP.NET forms authentication cookie and the TAM cookie
Because the TAM cookie is missing the request is redirected to the TAM login page, which then shows up via HTML conversion in Word or Excel.
The API documentation at http://msdn.microsoft.com/en-us/library/ms440037.aspx mentions nothing about security or appropriate usage scenarios for this control.
Should these controls work in an ASP.Net Forms Authentication scenario or are they only supported with Windows Authentication. If Forms Authentication is supposed to function, how do we get the control to include the necessary session cookies in its requests?
The answer as provided by Microsoft Support.
This control merely forwards the URL of the document being retrieved to the appropriate office application.
The office application attempts to negotiate authentication with Sharepoint Server (full version). If no Sharepoint, the Office application does a simple get on the URL.
Ultimately, this means that this control does not support authentication scenarios that rely on session cookies.
We have a SQUID reverse proxy and a MOSS 2007 portal. All sites are using NTLM.
We cannot get it working with SQUID as a reverse proxy.
Any ideas where to start?
Can you switch to Kerberos instead of NTLM?
You're encountering the "Double-Hop Issue", whereby NTLM authentication cannot traverse proxies or servers.
This is outlined at this location:
http://blogs.msdn.com/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
And over here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;329986
Double-Hop Issue
The double-hop issue is when the ASPX page tries to use resources that are located on a server that is different from the IIS server. In our case, the first "hop" is from the web browser client to the IIS ASPX page; the second hop is to the AD. The AD requires a primary token. Therefore, the IIS server must know the password for the client to pass a primary token to the AD. If the IIS server has a secondary token, the NTAUTHORITY\ANONYMOUS account credentials are used. This account is not a domain account and has very limited access to the AD.
The double-hop using a secondary token occurs, for example, when the browser client is authenticated to the IIS ASPX page by using NTLM authentication. In this example, the IIS server has a hashed version of the password as a result of using NTLM. If IIS turns around and passes the credentials to the AD, IIS is passing a hashed password. The AD cannot verify the password and, instead, authenticates by using the NTAUTHORITY\ANONYMOUS LOGON.
On the other hand, if your browser client is authenticated to the IIS ASPX page by using Basic authentication, the IIS server has the client password and can make a primary token to pass to the AD. The AD can verify the password and does authenticate as the domain user.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
264921 (http://support.microsoft.com/kb/264921/) How IIS authenticates browser clients
If switching to Kerberos is not an option, have you investigated the Squid NTLM project?
http://devel.squid-cache.org/ntlm/
you can use HAProxy for load balancing