Single Sign-On vs SSL Proxy Authentication on Novell BorderManager

  • 3598432
  • 05-Feb-2007
  • 26-Apr-2012

Environment

Formerly Tid 2948916
Novell BorderManager 3.7
Novell BorderManager 3.8
Novell BorderManager 3.9

Situation

What is Single Sign On and SSL proxy authentication?

Resolution

Single Sign-on.

Single sign-on is the description given to the background verification of authentication that the Proxy will do when a request is received in order to verify that the requesting user is authenticated to the BorderManager server. It requires that the workstation be running Netware Client32 and CLNTRUST.EXE. You can put CLNTRUST.EXE and DWNTRUST.EXE on any server or workstation. For the Single sign-on to be successful, the workstation must be authenticated to the NDS tree where the BorderManager exists, and must be able (if it hasn't done so already) to make an NCP connection to the BorderManager server. When the BorderManager Proxy server, configured for single sign-on, receives a request from a workstation it uses port 3024 to contact the CLNTRUST running on the workstation. It passes to CLNTRUST the full context name of and tree name for the BorderManager server. CLNTRUST will then verify whether the workstation is authenticated to that NDS tree, and if it is connected to that BorderManager server. If it is not authenticated to the tree, a negative response is sent back to the BorderManager server and single sign-on fails. If it is authenticated to the tree, and it is connected to the BorderManager server, CLNTRUST will pass back the connection information. If it is authenticated to the tree, but not connected to the BorderManager server, CLNTRUST will request Client32 create an unlicensed connection to that server and the connection information is passed by CLNTRUST back to BorderManager. When BorderManager receives the connection information from CLNTRUST on a successful single sign-on, the server will remember that connection information and the IP address of the workstation. All requests from that workstation, for as long as the client's connection to the server is valid, are considered authentic. This single sign-on authentication is broken if the connection to the server is lost or the AUTHCHK.NLM is reloaded. DWNTRUST.EXE is used to unload the CLNTRUST.EXE from the workstation. It does not disconnect the client from the server, or logout of the NDS tree. So, even after DWNTRUST is run, requests to the Proxy, which have already been authenticated through Single Sign-on through CLNTRUST, are still considered authentic. (But if the connection has to be re-authenticated for any reason and CLNTRUST isn't running, authentication will then fail even if Client32 is running.) DWNTRUST is used, for example, in login scripts where you want to ensure that CLNTRUST is unloaded before trying to load it again. Single sign-on provides convenience for the users who don't have to re-enter authentication information when they make requests to the Proxy. It also provides security since you are sure that only the requests from workstations that have valid NCP connections will be allowed access to the Proxy. Single sign-on only works for the users that exist in the same tree as the BorderManager server. Users from other trees will have to use SSL to authenticate.

Proxy SSL Authentication.

Proxy SSL authentication occurs when a browser makes a request to the Proxy where authentication is enabled, and either single sign-on is not enabled, the workstation isn't running CLNTRUST, or single sign-on failed. It provides a secure method for users to enter their NDS authentication information. When the browser makes the request and the server requests SSL authentication, it does this by sending back a 302 redirect. That is, the browser makes a GET request to the proxy server. The proxy sends back a 302 redirect with the Location: made up of the URL to the BorderManager Proxy SSL login page, and the URL from the GET request as CGI data. The browser then requests the remaining graphics from the server to complete the page and displays it. When the user submits the authentication information, the BorderManager server attempts to create an unlicensed connection to itself using that authentication information. If, for example, the user enters the username "guest", if authentication is successful then "guest" will appear on the connection list as an unlicensed connection. Looking at the details of that unlicensed connection (eg. in Monitor) you will see that the network address of the connection is the server's own address. One limitation of the SSL authentication method is that there is no way for the browser to "logout", like Client32 can. Without a reverification timeout or a logout of some kind, requests from the authenticated workstation would be considered authentic for as long as AUTHCHK.NLM remains loaded. It is unreasonable to request reverification every time the browser makes a request, as that could be several times for each page requested (remember, each graphic on a page is a separate request). So BorderManager implements a timeout mechanism. When configuring Proxy SSL authentication, there is an option "Maximum idle time before requiring new login" which defaults to 3 minutes. This is a timer for SSL reverification of the user's authentication. If the browser does not send any requests to the Proxy for the time specified in this parameter, then the browser will be challenged by the proxy sending the 302 redirect to the BorderManager login page as explained above. The SSL authenticated workstation will remain valid until either the maximum idle time mentioned above has elapsed, AUTHCHK.NLM is reloaded. Clearing the unlicensed connection for the user is not sufficient. BorderManager will remember the workstation as authentic regardless of the unlicensed connection. When the user does re-authenticate on the same workstation, the unlicensed connection is reused. If that connection is cleared, when the user reauthenticates the BorderManager will try to reauthenticate on the same connection number. It will get a different connection number if the old connection number is in use by another user. Although you may see multiple licensed connections for the user (other workstations running CLNTRUST or logged into the server), you should only see one unlicensed connection per user. Authenticating as the same user from different workstations will use that same unlicensed connection. By default, a user authenticating through SSL would have to enter his fully qualified username and tree. For example, user "Fred" in context "mktg.acme" in tree "acme_Inc" would have to enter "fred.mktg.acme.acme_Inc" when authenticating via SSL. The deeper the tree is, and the longer or more complex the context names are, the more tedious it is to enter the authentication information. To provide a shortcut, a default context list can be created. When a user enters a username, the entries in the default context list are appended to it one at a time and NDS searched to see if the user exists. In the example above, I could have entered a default context of "mktg.acme" for tree "acme_Inc". Then the user would only have had to enter the username "Fred". However, there are some drawbacks to this approach which an administrator must be mindful of.
1-The first user found that is a match is used. There is no order to the default contexts list. The context may be searched in any order. This means that if you have two different user objects in two different contexts in the default context list, you never know which one of those BorderManager will try to authenticate against. It is very important to have unique usernames.
2-As the default context list grows, the chance of authentication failing because of timeout also grows. Remember, each context is a new NDS search. Most BorderManager servers are not going to have all the replicas for the entire tree. This means the bigger the list, and the bigger the tree, and the busier the network, the longer it is going to take to authenticate each user. It is not uncommon for large sites to have users complain that the browser is returning an error that it can't connect, and this is because the browser times out before the proxy can complete finding the user through searching the default context list.
3- Keep the default context list to a minimum.
4- Avoid using specific contexts.
5- Try using aliases. At one site we created a separate NDS partition with replicas on the BorderManager servers only. That partition contained several contexts where we created aliases for each user that would be authenticating to the BM server. The default context list only contained these contexts. - 6- Make sure your NDS tree is clean, free of any latency problems, and in sync. NDS problems and timesync problems are at the root of many proxy authentication problems..

Flow:


Additional Information


Formerly known as TID# 10013820