Internet Enable your Applications using WebSEAL with Active Directory Authentication

Let’s say you have a set of applications you use within your organization that you want to make available for access from the Internet. Let’s further say you want remote users to login using their Active Directory credentials. That way, there is no additional password maintenance to worry about – for users or for support staff.

Sounds great, but can you pull it off without exposing your organization to the countless threats lurking out there on the Internet?

In most cases, it can be achieved with minimal risk to your systems and applications. Furthermore, PathMaker can help you design and deploy a solution, as well as help you analyze your applications and infrastructure for potential vulnerabilities.

Getting Started

First, it would be a good idea to do some preliminary penetration testing of your applications to make sure they are Internet-ready. Penetration testing is one of the many services PathMaker Group offers, so please, contact us to help you with this important step.

Secondly, you need to look at each application you are planning to deploy and assess what the risks are to the organization if a single user’s password is hacked. If the damage tends to be confined to the user, then this application is probably OK for Internet deployment with simple password login. However, if high value or high liability information could be leaked, or if a hacker could gain access to administrative capabilities, you probably don’t want this application out on the Internet; at least, not without a stronger form of authentication than user-chosen passwords.

So, assuming the project is still a “go”, you will want to deploy an authenticating HTTP reverse proxy in the DMZ to isolate your application servers from direct Internet access and uninvited guests. Firewall rules should be restrictive, allowing only HTTP/HTTPS connections from the Internet to the proxy; and from the proxy to the application server. Even better, allow only HTTPS connections and eliminate the need to selectively manage the use of encryption.

Finally, you’ll want to make sure you implement password policies that will minimize the probability of a successful Internet-based attack, but will not create excessive burden on users and support staff.

Now, let’s get specific.

WebSEAL, HTTP Reverse Proxy

IBM has a great HTTP reverse proxy product for securing web applications: Tivoli Access Manager (TAM) WebSEAL. WebSEAL comes with many built-in security features, and guards against common web threats, such as cross-site scripting. It also provides a flexible authentication and authorization model, including support of stronger authentication techniques than simple passwords – for example, the use of client certificates or RSA SecurID. And most importantly for our scenario, it supports multiple ways to integrate with Active Directory. We’ll look at two of them here.

Integration with Active Directory as the User Registry

A core component of any TAM deployment is the user registry. It holds the user accounts, passwords and policy data. Active Directory (AD) is supported, out-of-the-box, as one of several options for the TAM user registry. TAM can utilize all your existing AD users and groups, but you control which ones become part of TAM. So, you can exclude accounts, such as Administrator, and never have to worry about “Administrator” logging in from the Internet to access your applications.

You also control which users from which groups can access which applications, and can support multiple levels of authentication. So, for instance, if you choose to expose a more security-sensitive application, it could be configured to trigger a secondary authentication challenge for an RSA token or client certificate before granting the access.

External Authentication for Active Directory Integration

Some organizations may not want such tight coupling with their Active Directory, or may have a security policy disallowing the connection that would be required from WebSEAL in the DMZ to the Active Directory Domain Controller. For such cases, there is another option: the WebSEAL External Authentication Interface (EAI).

WebSEAL EAI allows you to supply your own authentication modules. There is a native interface, for supporting plug-in authentication modules, as well as a higher level interface utilizing HTTP communications. Either of these could be used to support Active Directory password authentication without the need for TAM to have write permissions in the directory. The latter approach allows you to move the authentication module out of the DMZ, thereby preventing the direct connection that would be required to AD from the DMZ. Furthermore, PathMaker provides a ready-made EAI module for Active Directory authentication so you don’t have to develop your own.

It should be noted that the use of EAI does not preclude the use of other authentication mechanisms. You could still utilize secondary authentication for client certificates or RSA tokens to protect certain pages or applications.

Password Policy

The main goal of any password policy is to prevent an attacker from breaking into accounts by successfully guessing passwords. And, when you expose your applications to the Internet, the probability that accounts will be attacked is a virtual certainty, so it is more important than ever that you have good password policies in place.

Fortunately, both Active Directory and Tivoli Access Manager support the creation and enforcement of password policies. And, the great thing here is that you can combine the two to work together to optimize your protection from Internet-based attacks.

The temptation is to configure Active Directory to lockout accounts after a small number of login failures, but that would be the wrong place to enforce lockout. The last thing you want is for an Internet-based attack to start locking out all of your AD accounts so that nobody can login. Instead, the strategy should be to set the account lockout in TAM, at the point of entry.

Here are the two critical settings you’ll want to configure to prevent this potential account lockout issue:

1. In TAM, configure a lockout threshold (max-login-failures) to a small number – for instance, 3 – and more importantly, less than any lockout threshold you might set in Active Directory. That way, the Internet-based attack can be shut down quickly by WebSEAL, without affecting internal users.
2. In Active Directory – assuming you configure an account lockout threshold – also configure the “Reset account lockout after” setting. This setting tells Active Directory to automatically reset the counter that tracks failed logon attempts after waiting the specified number of minutes. By setting this to a short interval – no more than 30 minutes – you will prevent any failed login attempts from the Internet from accumulating in AD that would eventually lockout the real user. And, if you also configure the TAM account to automatically recover (by setting a disable-time-interval value), make sure the TAM disable time is longer than either the Active Directory “Reset account lockout after” or “lockout duration” settings. This will ensure that the internal account has recovered before opening the gate for new attacks from the Internet.

In addition, you will want to configure these settings in Active Directory to prevent overly simple passwords, so a password attacker – automated or human – will have to attempt many guesses before having a reasonable chance of success:

–          Enable password complexity requirements, a setting that requires passwords to contain characters from three of the five categories: upper case, lower case, digits, punctuation or Unicode.

–          Set minimum password length, preferably to a value of 8 to 12, or more… the longer the better. (Think “pass-phrases” instead of passwords.)

So, now that you know the key points, give us a call to help you with the rest of the details. And don’t forget to do a final penetration test of the entire solution.