The majority of ColdFusion deployments are on Windows boxes, and so it is no surprise that users have frequently requested a simple way to authenticate users against Active Directory and Windows domains. In the past this required the use of LDAP (and the tag), a process neither clean nor intuitive nor always available. And so in Blackstone we plan to introduce a new tag named which accepts a user id, a password, and a domain name, and returns a yes/no flag letting you know if authentication succeeded or not. Clean and simple, just the way we like it.

12 thoughts

  1. what about getting other attributes back, like group membership? Does that still have to be done via. LDAP?

  2. This is all fine, however take the case of an intranet. I’m logged onto my local machine in the local domain, should I have to re-enter my login details again?
    Shouldn’t there be a way of identifying if the user is logged onto the local domain already?
    Or can this already be done?

  3. I can’t go into exact syntax and specifics yet, but …
    Group membership can indeed be returned, no need for LDAP for that one.

  4. Tony, that is not trivial, and it is not a CF limitation. CF (or anything running on the server) cannot reach across the network connection to read your login info, that would be a major security hole, and so server-side stuff cannot get that data, and browsers won’t provide it. You could, of course, install an ActiveX control (or some other executable) on the client and have it return that information, but that has to be something you do, it can’t (and shouldn’t) happen automatically.

  5. "CF (or anything running on the server) cannot reach across the network connection to read your login info, that would be a major security hole, and so server-side stuff cannot get that data"
    This seems contradictory to the fact that this is exactly what ASP.NET does for windows authentication.

  6. Doug,
    I wouldn’t necessarily point at Microsoft designs and imply that they are secure just because. Don’t forget what Windows XP SP 2 was all about and apparently, even still didn’t cover security 100%.
    – Calvin

  7. If I’m not mistaken, doesn’t ASP.NET use MS Passport? I believe that when you set up a Passport account you can "link" it to your Windows account. So I think that is how an ASP.NET page is "seeing" that you are already logged in, it’s not really going across the network itself, it’s relying on the extra Passport connection to determine this.

  8. No, ASP.NET _can_ use passport. However, that is an entirely different authentication implementation from Windows Authentication.

  9. RE: ASP.NET and login information…
    I think what you may be thinking of is integrated Windows authentication. If the style of authentication required by the server is NT challenge-response, and the browser is Internet Explorer, then subject to certain security settings (based on the zone of the site being visited) the browser may automatically pass along the logon information.
    The big limitation here is the reliance on NT challenge-response. It is not an open protocol and Macromedia would have to reverse-engineer the protocol to make it work. It’s no surprise that ASP.NET, the Microsoft platform would have programmers with the necessary knowledge to make it work (or maybe just tighter integration with the operating system).
    If you are serving pages from IIS to an IE-only audience (on an intranet, for example), you can get this kind of functionality by turning off anonymous connections and requiring NT challenge-response authentication. This way, credentials will be checked by IIS and the user name (if authorization succeeds) will be passed to ColdFusion as CGI.AUTH_USER (IIRC). This is a limited solution and may not meet your needs, but I think it’s the closest you’re likely to get to automatic logon with ColdFusion.
    Hope this helped.

  10. Yes, IE can indeed pass this information to IIS. A special http header containing the user’s domain identifier is transmitted to the server by IE only if the request is made by IIS and has been configured to ask for it. (You can see this encoded identifier if you stick an http sniffer in between your IE request and your ASP.NET web response). This header is only sent when the user has already signed on to a domain successfully (which generally occurs when they log into their PC). So, this is (for now) an IIS/.NET/IE only solution.

  11. Are there any updates to this? Specifically, is it possible to avoid requiring users to enter their NT username/password again when on an intranet?

Leave a Reply