Single Signon for RT using Active Directory

Over on Blah Blah Blog, Nathan has come up with what he describes as the “Holy Grail” of RT authentication in a Windows environment:

A lot of people use RT to track helpdesk requests, problem reports and other incident data at their jobs. An even larger number of people use or are forced to use Microsoft Active Directory as the central repository of username and password information at their jobs. As a result, probably the single most-asked question on the rt-users mailing list is “how do I unify logins between RT and ActiveDirectory?” Following close on behind that is “how do I get RT to use Windows authentication so people don’t have to type in their password twice?” Strangely, these are questions that seemed to lack any authoritative answers.
Until now.

Link to article on Blah Blah Blog

About

A wandering geek. Toys, shiny things, pursuits and distractions.

View all posts by

34 thoughts on “Single Signon for RT using Active Directory”

  1. In any application, one would be better off using LDAP for authentication than some home-brew thing.

    Microsoft wisely saw fit to make the AD an LDAP server as well, so if your app does the ‘DAP, you simply point it at the DC and have at it.

    Reply

  2. Bryan–

    The first cut of my article actually used the apache mod_authz_ldap module for authentication, and when I have some spare cycles I’m going to write up a section on how to do this without touching apache at all, but using only Net::LDAP from inside RT.

    That said, there are a couple of advantages to using NTLM instead of LDAP.

    First and foremost, it’s much more intuitive for users: they log in once to Windows itself, and then RT (or whatever the website is) “just works” when they browse to it, and they don’t have to re-authenticate. Considering that my helpdesk staff tends to field at least 2-3 requests a week from users who can’t seem to retain the idea that their Windows password can be used in other places, this is not insignificant.

    Secondly… ADS speaks something that can charitably be called a dialect of LDAP, but it’s got some extremely strange quirks that can bite you on the ass in production. For instance, if a Windows user is a member of two or more LDAP groups, only the second or subsequent group will be returned as a “memberOf” attribute by an LDAP search. So if, for instance, you want to restrict access to members of the “Domain Users” group (cn=Domain Users, cn=Users, dc=site, dc=com), then every single one of those users had better also be a member or at least one other group, or your ldap search for “(&(sAMAccountName=foo)(memberOf=Domain Users))” will fail.

    Also, LDAP queries are by default in cleartext, and at least in Server 2000, Microsoft’s TLS support is sorely lacking. NTLMv2 is a reasonably secure (and amply documented) challenge-response protocol. This also frees you from having to use SSL on the apache side to secure the password exchange between the user and the webserver, before ADS even gets involved.

    Faced with issues like that, I don’t think it’s necessarily a bad idea to fall back to using NTLM and SMB: they’re in no sense deprecated in favor of LDAP by Microsoft, the view of ADS’ internal structure they present is somtimes a bit less obfuscated, and the experience for the user can be a less frustrating one.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.