Question

Thanks for reading and for your thoughts; this is a hairy problem, so I thought I’d share to see if it is actually a fair challenge for more seasoned developers than ourselves.

We’re developing a web application for a corporate Microsoft Active Directory environment, and we use Windows Authentication provided by IIS to authenticate users for single-sign-on, alongside Forms Authentication. I know IIS complains when both are enabled, but it works very well, and every site we’ve deployed at has had no weird quirks to work around – until now.

The new site has “shared” machines, logged in permanently with a generic account that has read-only access to the applications they need to use. This means that we can’t differentiate between users who should have different permissions to the application; we need some way of prompting the user for authentication details.

First try was some serious googling; nobody else in the world seemed to have our problem except for a few misguided souls who had asked questions into the ether and received no response.

After a bit of brainstorming and nutting out the way IIS’s authentication works, it seemed that the most straightforward way to approach the problem was to issue a 401 Unauthorized in response to a user known to be a shared account. Initial tests here seemed fruitful, yielding successful changes of username inside the browser, however a prototype at the site did not prompt for credentials, and the browser kept the same account details. We also hit on the IE-specific javascript

document.execCommand("ClearAuthenticationCache")

which, again, worked in the lab but not onsite. Further experiments with IE security settings onsite revealed that the browser would automatically reauthenticate if the webapp site was excluded from the Intranet Zone, regardless of the method used to trick the browser into prompting the user for new account details.

Now we’re stuck. We’ve got workaround options for getting it going on time, but they’re definitely not the “right” answers:

• require users to log out of the shared account before logging into our app (…yuck)
• exclude our webapp from Intranet Zone on all machines
• provide a non-SSO login service for users

I’m convinced that there’s a canonical way to do this – a known pattern, a common base problem that’s already been solved, something like that – and I’m very interested to hear what sort of inventive methods there are to solve this sort of problem, and if anyone else has actually ever experienced anything remotely like it.

Answer 1

We ended up settling on a solution that submits a query to the LDAP directory the server knows about. It means having to accept the user’s password, but no other solution was solid enough to run in a production environment.

Hopefully this helps someone. .NET Framework 3.5+ required.

using System.DirectoryServices.AccountManagement;

private static bool IsLdapAuthenticated(string username, string password)
{
    PrincipalContext context;
    UserPrincipal principal;

    try
    {
        context = new PrincipalContext(ContextType.Domain);
        principal = Principal.FindByIdentity(context, IdentityType.SamAccountName, username) as UserPrincipal;
    }
    catch (Exception ex)
    {
        // handle server failure / user not found / etc
    }

    return context.ValidateCredentials(principal.UserPrincipalName, password);
}