Issues with cfntauthenticate

I’ve been meaning to blog about <cfntauthenticate> for awhile, but I keep forgetting. However, someone had an issue with it today, and it spurred me on.

Disclaimer

I don’t work for Adobe, so I have no idea why they did anything they did. Any supposition posted here is just that my supposition. Additionally, it’s not meant as criticism, as for the most part <cfntauthenticate> does exactly what it is supposed to do.

We’re a Window shop that relies heavily on out Active Directory Domain. We use it for LDAP mail routing, Exchange, and single sign on across our environment. From time to time we’ve had issues with <cfntauthenticate> under certain outlier conditions. Let me take you through some of them.

Too Many Groups

Occasionally, we’ll run in to singular users that cannot log into some applications but can log in to others. We’ll tease out variations in form inputs, and ensure the username and password works, and still can’t figure it out. We’ll look at our logs that track the reason for failure, and we’ll see “UserNotInDirFailure.” Even turning on the throwError option of the tag doesn’t help.

Eventually we trace it back to the listGroups flag. Turn it off, it succeeds, turn it on, it fails. So it’s something with the groups. Try taking some groups away from the user. Voila it stops failing.

Turns out, there is some number, N, of groups over which some sort of uncaught error will start to be thrown. It gets caught by the default error code and gets thrown as “UserNotInDirFailure.” N is a little nebulous, as it is unclear to me what effects domain local groups versus global groups versus distribution groups has on N. But in my last set of tests, N was 23.

To workaround, if you aren’t using groups, don’t use listGroups, as you don’t need it. If you are using groups for let’s say, authorization, revert to using LDAP for retrieving groups information. Also you could just prune your group membership…

Service Account Issues

This is the one that happened today. Every user’s login was returning “UserNotInDirFailure,” but only for a particular server. No changes in underlying networking were made.

My default recommendation: restart the server. When the admin of that server did that the ColdFusion service didn’t start. A quick check of the system logs showed that the login for the account the ColdFusion service was running under was failing. Turns out someone changed the password of it and didn’t change it in the services configuration on the server. It took about 36 hours before the problem was noticed.

According to the documentation, “ColdFusion must run as a user that has the privilege to authenticate other users in the specified domain.” So problems with the service account would cause problems with the tag.

No workaround here, just manage your service accounts properly.

PDC emulator

Active Directory domain controllers are intended to be redundant. Except for something called Flexible Single Master Operations roles, or FSMO roles. Each FSMO role makes the domain controller that hosts it unique in a fashion. I’m not going to go into all of it, but suffice it to say one of those FSMO’s is “PDC Emulator.” PDC stands for Primary Domain Controller, and was a feature of NT 4 and below. Basically the PDC was the domain controller to which domain information was read from and written to. Other domain controllers only allowed read operations. When Microsoft moved to Active Directory and multiple domain controller model, they left the PDC Emulator role in order to provide backward compatibility with tools that used NT 4 API’s for various operations.

What does all this have to do with ColdFusion? It’s my theory that <cfntauthenticate> uses the vestigial NT 4 API’s. I base this theory on the fact that if your PDC emulator is inaccessible, <cfntauthenticate> will fail for all users. However, if you have throwError set to false, you won’t know what is going on you’ll get a “UserNotInDirFailure” error. However, if you set throwError to true, you will see the real message, “Could not find domain controller for this domain XXXX” Where XXXX is the name of your domain.

There’s not much you can do about this. If the PDC emulator is unreachable from your Coldfusion server, <cfntauthenticate> will not work. The only solution I have come up with to replace <cfntauthenticate> with an analogous CFC that uses Secure LDAP queries against the domain controller instead.

Conclusion

I blogged this because when I’ve gone looking for <cfntauthenticate> errors, I’ve only found my own random posts on CF-talk. Hopefully, someone else will be less mystified by errors with this very useful tag.