News & comment tagged ‘iis’
● The risks of an IIS front end
posted by John B on 5th November 2011
Why are organisations using a Microsoft IIS front end to Tomcat?
The standard BMC Mid Tier deployment has encouraged the use of Microsoft IIS as a front end to Apache Tomcat. For the majority of people, this adds no value to the deployment because IIS is doing nothing more than passing requests to Tomcat.
The illusion of SSO
IIS can perform Integrated Windows Authentication and force browsers to authenticate, providing a solution that has the appearance of SSO. Sadly, it's not quite that simple because it leaves open the prospect for a third party (ie attacker) connecting directly to Tomcat and passing any random username.
The problem with this approach is that the SSO tokens sent by the browser are not being authenticated in the Java web server.
It has come to our attention that some BMC resellers - including one BMC Elite Partner - are misleading customers into believing this is a good solution as their primary aim is to sell consulting days instead of a quality solution.
SSO without IIS
Whilst SSO Plugin supports an IIS front end, we actively encourage the use of the SSO Plugin built-in Active Directory integration. This integration will bind SSO Plugin directly to the Active Directory so the SSO tokens sent by the browser can be validated with the AD, bringing the security into the Java web server.
The use of built-in Active Directory integration also removes the need for IIS, and hence simplifies the solution.
With fewer components to go wrong, and a more secure solution, why would you want to deploy SSO for Windows in any other way?
How to switch from IIS to built-in Active Directory authentication
Switching is not a difficult task but there is a pre-requisite. Each SSO Plugin installation requires a computer service account in the Active Directory, as per Microsoft design, so it can process SSO tokens sent by browsers.
There are two ways of obtaining an account:
A script called set-service-account.cmd is provided in the SSO Plugin installation set, which will create the account in user friendly fashion. This has to be run by the Active Directory administrator.
For those who do not want to run the script, manual steps are provided in the configuring Mid Tier and Web Tier installation guide.
Once an account has been achieved, simply go to the SSO Plugin setup page and follow these instructions:
1. Select the built-in Active Directory authentication type.
2. Enter the fully qualified hostname of an Active Directory, and not a load balancer hostname - multiple ADs can be provided via a comma-separated list.
3. Enter the fully qualified Windows DNS domain name. This can be discovered by opening a command prompt and typing net config workstation.
4. Enter the computer service account name and password.
5. Press set configuration and test the solution.
If there are any questions or concerns, contact the JSS support team.
Please note: The instructions detailed above are at a very high level and are no substitute to reviewing the extremely thorough documentation provided with SSO Plugin.
● What's a Service Principal Name (SPN)?
posted by John B on 2nd January 2011
The SSO Plugin supports Integrated Windows Authentication, so users can open IE and sign directly into the BMC Midtier without logging in. There are two ways in which this can be achieved: Using IIS or by directly integrating with the Active Directory. Both methods require a Service Principal Name (SPN) to be correctly configured to allow a browser to use the Kerberos protocol (IWA requires two protocols, Kerberos and NTLMv2, and this is discussed in another article).
To instruct a browser to perform SSO against the Midtier, an SPN must be assigned to an account in LDAP/Active Directory to associate a Service (such as a web site, ie the Midtier) with a Principal (an account) that is authorised to authenticate users of that Service.
So for site 'http://site.example.com/', the Principal name 'HTTP/site.example.com' is used. The client browser looks up objects in Active Directory that have this name set as an SPN, and uses data from those objects as part of the signing process to generate the ticket sent to the web server. Without an SPN set for a given site, the browser cannot send Kerberos authentication tokens. Adding an SPN has no security impact because the authenticating service doesn't get to see any sensitive information about the user. However the account with the SPN must match the account that the authenticating service is operating under - typically, in Active Directory, the Computer object of the machine running IIS.
If a site is accessible under multiple names, eg 'site.example.com' and just 'site', then multiple SPNs must be set on the same account, one for each Principal name under which the site will be accessed.
Typically, an IIS instance will already have an SPN configured, but when you are integrating SSO Plugin with the AD using the "built-in AD" integration type, an SPN needs to be created and associated with the required Computer Account in the AD. We provide a script to automate this process for you, and manual instructions are provided in the documentation.