There is no question that Access Management systems provide a host of benefits to the users and maintainers of web applications in large-scale environments. Yet, adding an access management system can also introduce a set of new potential points of failure. Even though infrastructure may be designed to maximize fault tolerance there is still risk because many security “eggs” are now in one basket. Systematic failure of any single component (LDAP directory, Virtual Directory, Access / Policy Server, web/application server plug-in, application integration code, etc.) can render applications unusable. As a result, system monitoring is often one of the most critical considerations in an Access Management deployment.

Thankfully, there are a number of network monitoring solutions that are capable of automatically monitoring applications and issuing notifications when a service become unavailable. We particularly like the open source Nagios system because it’s easily extensible, feature rich, and low cost. In order to make it more useful in the context of Access Management deployments we’ve developed a Nagios plug-in called CkFormLogin that monitors every point in the simple form login process common to most Access Management systems:

1. Initial request for a protected website URL – CkFormLogin verifies that the initial request receives a redirect to the login page.
2. Login page availability – CkFormLogin follows the redirect and performs a content check on the login page to ensure that it is accessible and no errors are returned.
3. Authentication – After login page verification CkFormLogin issues an HTTP Post request with the username, password, or any other credentials to a configurable authentication URL. This step tests the functionality of a web server plug-in like a WebGate, Web Agent, or Policy Agent and implicitly verifies the availability and functionality of any policy/access servers, LDAP directories and other supporting infrastructure components.
4. Content check – Assuming that authentication has succeeded CkFormLogin will follow the redirect back to the requested page and execute a custom content check on the page. By checking for the presence of some personalized text, or other identity specific data, the plug-in assures that application components have properly recognized and authorized the test user at runtime.

In short, this process provides a high level of assurance that secure/protected sites, and all of their externalized security dependencies, are actually available and functional to end-users. If any step in the login, authentication or authorization process fails the plug-in will return an error and the appropriate support staff can be notified by Nagios based on its configurable notification rules. When used in conjunction with other Nagios plug-ins for TCP/IP socket connections, LDAP, and HTTP services it can even help to pinpoint the root cause of a failure before a support technician even starts to troubleshoot.

The plug-in itself was written to validate the form login features of Oracle COREid Access Manager, but should also work with the usual suspects (Siteminder, Sun Access Manager, custom form based authentication) without significant modification. Its simple to install, requiring only Nagios, Perl and a few CPAN libraries. Like Nagios, CkFormLogin is released as open source software under the GNU Public License. Feel free to check it out.

As part of a large Identity & Access Management project we’ve beenmigrating a number of LDAP dependent systems from running under ASP.NET 1.1 to the 2.0 framework. The upgrade process has been remarkably painless, with the notable exception of a small but significant “breaking” change to authentication with System.DirectoryServices. In .NET 1.1 it is perfectly acceptable to issue an LDAP simple bind with code like this:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
/*...use entry for searching, etc, here...*/

However, execution of this code will fail under the .NET 2.0 framework unless it is modified to explicitly set the DirectoryEntry’s AuthenticationType property, because the class constructor no longer defaults the propertyto None. Here is what new 2.0 code should look like:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
<strong>entry.AuthenticationType = AuthenticationTypes.None;</strong>
/*...use entry for searching, etc, here...*/

Overall, its an easy fix, but finding every use of an authenticated DirectoryEntry in code can be tricky…

Microsoft ADAM provides a nice LDIF export tool, roughly equivalent to ldapsearch, called ldifde. However, the ADAM directory itself tracks a number of internal attributes that will cause a subsequent import of a generated LDIF to fail. In order to get a “clean” export, you need to selectively omit, via the -o command line flag, those operational attributes that you’re not interested in exporting (line breaks inserted for readability):

ldifde -f c:\people.ldif 
  -d "ou=people,dc=xyz,dc=com" 
  -s localhost 
  -t 389 
  -r "(objectclass=*)" 
  -o   "whenCreated,whenChanged,uSNCreated,
          uSNChanged,name,objectGUID,badPwdCount,
          badPasswordTime,pwdLastSet,objectSid,objectCategory,
          dSCorePropagationData,lastLogonTimestamp,
          distinguishedName,instanceType,lockoutTime"

The output generated by the command can now be cleanly imported into another ldap directory, or into a separate ADAM instance using a simple import:

ldifde -i -f c:\people.ldif -s localhost -t 389

Matt Flynn, in a post about AD password sync, asks:

What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? … Would this be useful functionality in a virtual directory? Is it technically feasible?

+1 for virtual directory pass-through authentication.

It’s definitely technically feasible and works very well to drive consolidation of authentication services. From past experience it’s one of the most powerful benefits of virtual directory technology. In fact, this feature was key to the value proposition and purchasing decision for several of the prominent deployments I’ve worked on. It was also one of the key topics we discussed at the DIDW 2005 Virtual directory panel.

Yesterday we discovered 100+ notifications for spam messages contributed through an online form by a malicious bot. We usually get a few of these per day at identicentric, because of this blog and various other unauthenticated forms, but the volume has never been enough to warrant decisive action. Nevertheless, Friday night’s activity “stepped over a line” and, much to our chagrin, spam continued to pour in over the course of Saturday morning at a rate of 15-20 per hour.

There are several established approaches to battling form spam. Some techniques requiring a user to enter in random characters displayed in a embedded image on the page. Others rely on logging IP addresses on form load, so that the processing script can reject bulk form submissions. Some attempt to use mod-rewrite to block form spam based on missing or specific Referrers or known blacklisted IP segments, with mixed results.

We wanted a dead-simple, general purpose solution that could be used to block spam on any form submissions, without dependencies on the back-end processor. Conceptually, mod-rewrite seemed like a nice fit because it could be implemented on Unix or windows (using ISAPIRewrite), and it was completely externalized from the form-backing application. Yet, the referrer and IP filtering techniques were unsuitable as they could result in long rewrite configurations, frequent ongoing maintenance, or incompatibility with many personal-firewall packages.

Our solution wound up being very simple, and involved setting a cookie using JavaScript that could be detected using mod-rewrite. It relies on the fact that spam-bots are dumb, not cookie-aware, and certainly aren’t JavaScript aware.
Here’s how it works.

Start off by creating a small .js file and including it in the page with the form. Expose a single function called setFormAllowCookie(), or something similar. This function, when called, will set a browser cookie named “formallowed” to a value of “true”.

function setFormAllowCookie() {
  var cookieName = “formallowed”;
  var cookieValue = “true”;
  document.cookie= cookieName + “=” + escape(cookieValue) + “; path=/”;
  return true;
}

Include the .js file into the page with the form. This is easily embedded in practically any html page. Next, add an onload oronsubmit to the bodytag or formtag respectively that calls setFormAllowCookie().

The final step is to configure a rewrite rule that redirects form submissions to an error page if the cookie is not present in the request, like this (show protecting WordPress comments):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-comments-post.php
RewriteCond %{HTTP_COOKIE} !formallowed=true
RewriteRule (.*) http://blog.xyz.com/error.html
</IfModule>

Pros:

• This solution should continue to work until form-scrapers become cookie and JavaScript aware.
• This approach does not introduce dependencies on the form processing application.

Cons:

• Requires JavaScript and Cookies, potentially interfering with a subset of form submitters.
• Might not work against bots that are manually configured to attack a site, as a human could easily figure out the appropriate cookie to set.

It’s a judgement call as to whether the pros outweigh the cons with this approach, with the answer depending largely on the form’s target user base. In our minds the results speak for themselves: it took about 15 minutes to implement this approach to stop the initial barrage of spam and, according to logs, has operated with a 100% success rate against subsequent attempts.