Thanks for the fantastic info Mike... it's much appreciated! I spent some time with User_Local.pm and did a little debugging. I didn't have much luck, but on a whim, in RT_SiteConfig.pm, I changed...
Set($LdapGroupAttr, 'uniqueMember'); ...to: Set($LdapGroupAttr, 'member'); I haven't been able to dig up how these two attributes differ yet, but I confirmed that group-based authentication is working as intended. I'm going to come back to this and nail the issue down when I find a little time. Thanks again Mike. Sorry for the earlier barrage, List; Gmail appears to have thrown a fit when I sent the message. -Matt On 3/1/08, Mike Peachey <[EMAIL PROTECTED]> wrote: > > RT Lists wrote: > > These are the lines for our LDAP group settings in RT_SiteConfig.pm: > > > > # If you set these, only members of this group can auth via LDAP > > Set($LdapGroup, 'cn=RT,ou=ITST,ou=Everyone,dc=domain,dc=tld'); > > Set($LdapGroupAttr, 'uniqueMember'); > > > > The group RT in the OU ITST in the OU Everyone in the AD root definitely > > exists. It contains users that can log in just fine if those lines are > > commented out and RT is restarted. When we try to log in with these > > settings uncommented, the web interface says "Error: Your username or > > password is incorrect" and we get these lines in the debug logs: > > > > <snip> > > > > Feb 29 12:32:26 stilgar RT: Trying LDAP authentication > > Feb 29 12:32:26 stilgar RT: RT::User::IsLDAPPassword Found LDAP DN: > > CN=rttestuser,OU=ITST,OU=Everyone,DC=domain,dc=tld > > Feb 29 12:32:26 stilgar RT: RT::User::IsLDAPPassword AUTH FAILED: > rttestuser > > <snip> > > > > > I've been banging my head against the wall on this for a while and am > > starting to run out of ideas. If any of you fine folks can offer a > > suggestion, it would be highly appreciated :) > > > This is something for which you are going to need to debug the code > yourself. You need to add a few new debugging statements to the LDAP > groups code to work out exactly where the authentication is failing. It > may be that the code isn't doing group checking in the way you'd expect > for AD because AD is a poor bastardisation of good LDAP. To be honest I > can't remember exactly right now.. perhaps when I get back to work on > Monday I'll be in a position to check. > > Bottom line is, the code that does the group checking is unbelievably > small and simple and with even the most basic programming knowledge, you > should be able to fix it yourself. > > The code in question is inside IsLdapPassword inside > $RTHOME/local/lib/RT/User_Local.pm: > > # Is there an LDAP Group to check? > if ($ldap_group) { > $filter = > Net::LDAP::Filter->new("(${ldap_group_attr}=${ldap_dn})"); > > $ldap_msg = $ldap->search(base => $ldap_group, > filter => $filter, > attrs => ['dn'], > scope => 'base'); > > unless ($ldap_msg->code == LDAP_SUCCESS || > $ldap_msg->code == LDAP_PARTIAL_RESULTS) { > $RT::Logger->critical((caller(0))[3], > "Search for", $filter->as_string, > "failed:", > ldap_error_name($ldap_msg->code), > $ldap_msg->code); > return; > } > > unless ($ldap_msg->count == 1) { > $RT::Logger->info((caller(0))[3], "AUTH FAILED:", > $self->Name); > return; > } > } > > Recommendations I would make would be: > 1. Insert "use Data::Dumper" at the top of the file. > 2. For each variable that you're not TOTALLY sure what it does and what > it's set to within the block of code above, insert > "$RT::Logger->debug("\$VARIABLE = $VARIABLE);" > 3. Check your AD schema to ensure that if you were to search for > $ldap_group, using the $filter with a base scope, looking for dn attrs, > that you would return a single group. > 4. If you want to be sure what the ldap search results in: > "$RT::Logger("Ldap Result:\n",Dumper($ldap_msg));" straight after the > search directive. > 5. Finally, don't forget that, as shown in the code above, the group > authorisation is confirmed if the LDAP search results in one and only > one result. If it gives more than one result, the auth fails. You may > want to code your way around this if you need to have multiple possible > groups results. > > As a general tip for coding in IsLdapPassword: Authorisation is > successful if the method runs to the end wihout interruption. All the > checks within it return 0 (default for return statement) if the user is > to be denied access or just continue on to the next check if a failure > wasn't detected. > > Have fun... > > Don't forget.. when you're done making a change to User_Local.pm: > $ apachectl stop > $ rm -rvf $RTHOME/var/mason_data/obj/* > $ apachectl start > -- > Kind Regards, > > ___________________________________________________ > > Mike Peachey, IT > Tel: +44 (0) 114 281 2655 > Fax: +44 (0) 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > http://www.jennic.com > Confidential > ___________________________________________________ >
_______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com