Sonar  provides a number of authentication mechanisms that can be used to apply policy dynamically when logging in. These mechanisms range in security and function from simple HTML based forms to multi‐functional Single‐Sign‐On based applications. Each have their own advantages and disadvantages and can be can be used and tailored to suit the requirements of your organisation.


  1. AD Passthrough - often referred to as "clientless" authentication. This method of authentication runs as a Windows Service and logs users into Sonar when they log on to the Domain. It works out so essentially users should not be prompted for authentication unless the service cannot talk to the Active Directory for whatever reason. Requires a Windows 2008 R2 Domain Controller or later. 
  2. Basic - this is a session based authentication method. Because of this, it will literally prompt for every request the user makes. It may be useful for iOS devices for which the Sonar authentication client such as Secure AD or Simple cannot run concurrently with the web browser. You will have to make sure that your Wi-Fi network is sufficiently encrypted to protect against packet sniffers, because the user's credentials are passed in clear text. This method has generally been made redundant due to clientless
  3. Default - this wont require users to authenticate against Sonar while still providing limited internet access by establishing a default policy. The policy is enterprise-wide and applies when no other polices are applied to the user.
  4. Guest - this also will not prompt the user for any authentication whatsoever, in fact, users will not even be aware Sonar is there. Users who connect to your network will authenticate automatically as a guest if you have guest access set up, and will follow any group polices you have applied for them.
  5. None - pretty self explanatory. This does not enforce any kind of authentication against Sonar.
  6. NTLM/NTLM TS - The Microsoft standard, often referred to as Integrated Windows Authentication, the web browser authenticates with the domain controller through Sonar. The username and password are encrypted before being sent across the network. The NTLM authentication process consist of a three-way handshake in which the client first establishes a connection to the server, the server then responds with a challenge message to establish the client's identity, and finally the client responds with an authentication message. With NTLM TS, the whole authentication proces is started for each browser request. With NTLM, on the other hand, once the user has been successfully authenticated once, only the encrypted password is sent to Sonar. If no requests have been sent within 60 seconds, the full authentication process will be started or the next request. NTLM TS i generally used in a Thin Client environment or when computers are shared between users. This authentication method does not support Transparent Proxies.
  7. Secure AD/NDS - this is the Java client form of authentication. With Secure AD, user and domain from the Windows Kerberos credentials cache on the local machine is passed to the Sonar server for authentication. This method can also be used for computers that are logged in to an Apple Kerberos domain. With Secure NDS authentication, the user information in the NDS clients credentials cache on the local machine is passed on to the Sonar server for authentication. The user is prompted for their credentials in both authentication methods if the domain credentials are not available or invalid. Sonar authentication expires when the user logs out of the domain. Requires Java 1.6 or later.
  8. Secure AD/NDS SSO - these methods are similar to AD/NDS, but in the SSO method the user must have valid domain credentials to access the Internet or Email. If they are not available or invalid, the user will be prompted for their credentials. Sonar authentication expires when the user logs out of the domain. Requries Java 1.6 or later.
  9. Secure Token - the way this authentication method works is once the user's domain credentials have been successfully authenticated by Sonar, they are written to a token that is encrypted and stored in a secure location (which can be local or on the server). The user remains authenticated for the period of the token's validity (which by default is 30 days) and can be customised in the GUI via System -> System Settings. Require Java 1.6 or later.
  10. Secure Full -this is essentially Sercue AD/NDS, Secure AD/NDS SSO and Secure Token all rolled into one. In this method, all of those authentication methods are activated.
  11. Simple - Simple Auth is authentication via a web page. Users can visit the Sonar Auth Client page (<sonar's IP>servlet/SonarAuthServlet) and enter their credentials. It will then authenticate them in a session, which requires them to leave the authenticated page open when they browse the internet. This method authenticates via HTTP.
  12. Secure Simple - The same method as Simple Authentication, but authenticates over HTTPS rather then standard HTTP.
  13. Force IP/Force MAC - this authentication method is used mainly for systems that are not often attended, such as web and mail servers, but is also a way to allow mobile devices such as phones or iPads onto the network without authentication. Force IP can be applied to a range of IP's, whereas Force MAC requires a static IP address for each user account. Both Force IP and Force MAC do not get prompted for authentication.