Issues with NTLM Authentication

Are there any issues with using NTLM authentication when doing SSO to a back end application ?

Update

10-31-2014 : With webNetwork 6.2.1.182 and higher there have been many updates made to handle NTLM v2 applications that do not also maintain a session cookie. The changes in

webNetwork deal with matching up webNetwork user with the proper connection back to the host server. This is what caused problems in the past when the NTLM app did not utilize a session cookie to track users.

One key point with doing SSO to an application that does NTLM Authentication through the portal. There are 2 ways that NTLM authentication works.

1) The first is that the back end application asks for users name and password using NTLM and records the users connection number to the IIS server. After initial authentication the username and password is not used anymore, only the connection number is used to know who the user is.

2) User authenticates using NTLM and the user is given a session id / cookie that is sent with every request to the IIS server.

If the application uses #1, then that typically does not work through webNetwork properly. This is because for efficiency we “pool” connections to the

back end server and share those connections with users on the front end. This means that more than one user has its data over the connection to the back end application and the IIS server gets confused as to who is who because it is tracking the connection number instead of a session id / cookie sent with each request.

The fix is to set the application on the IIS server to ALSO use basic authentication and on the webapplication object in webNetwork set the authentication to disable NTLM.

Depending on the application they may also support some type of form authentication

The symptoms that you have a problem are when one user is logged clicks into the portal, on the link for the application and then another user logs into the portal and clicks on the link and ends up seeing information from the first user.

Some common questions about adding basic authentication in addition to NTLM on the IIS server.

Question) I thought webNetwork supported NTLM ?

Answer) We do, but this is a special case and because we pool connection to the back end server, the IIS server gets confused as to what user is requesting information.

Question) Basic authentication is insecure.

Answer) True, but basic authentication is only being used from the stoneware server to the IIS server. The user NEVER sends their username and password, the Stoneware webNetwork relay sees that the IIS server requested BASIC authentication and intercepts that requests and sends it on behalf of the user. Thus if the Stoneware server and the IIS server are in the same data center, the password never leaves the data center.

Question) We want users on the inside of the LAN that are not using the portal to still use NTLM for authentication.

Answer) Adding basic authentication along with NTLM (windows authentication) on the IIS server will present the user with the option of NTLM or basic. The browser will choose NTLM when they are both offered.