LDAP integration works great EXCEPT group membership test

RT Users
1

Good day all!

I’ve set up LDAP integration on a fresh RT 3.6.6 install to authenticate
with our Windows 2003 Active Directory, as per
ExternalAuthentication - Request Tracker Wiki. It seems to be working quite
nicely (including authentication and user record field population), with one
exception: enabling group membership checks breaks things.

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:

Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
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

Additional LDAP settings in RT_SiteConfig.pm:

Set($LdapServer, ‘dc.domain.tld’);
Set($LdapBase, ‘dc=domain,dc=tld’);
Set($LdapFilter, ‘(objectclass=*)’);
Set($LdapUser, ‘cn=ldapuser,ou=ITST,ou=Everyone,dc=domain,dc=tld’);
Set($LdapPass, ‘passwordgoeshere’);

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 :slight_smile:

-Matt

2

Good day all!

I’ve set up LDAP integration on a fresh RT 3.6.6 install to authenticate
with our Windows 2003 Active Directory, as per
ExternalAuthentication - Request Tracker Wiki. It seems to be working quite
nicely (including authentication and user record field population), with one
exception: enabling group membership checks breaks things.

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:

Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
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

Additional LDAP settings in RT_SiteConfig.pm:

Set($LdapServer, ‘dc.domain.tld’);
Set($LdapBase, ‘dc=domain,dc=tld’);
Set($LdapFilter, ‘(objectclass=*)’);
Set($LdapUser, ‘cn=ldapuser,ou=ITST,ou=Everyone,dc=domain,dc=tld’);
Set($LdapPass, ‘passwordgoeshere’);

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 :slight_smile:

-Matt

3

Good day all!

I’ve set up LDAP integration on a fresh RT 3.6.6 install to authenticate
with our Windows 2003 Active Directory, as per
ExternalAuthentication - Request Tracker Wiki. It seems to be working quite
nicely (including authentication and user record field population), with one
exception: enabling group membership checks breaks things.

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:

Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
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

Additional LDAP settings in RT_SiteConfig.pm:

Set($LdapServer, ‘dc.domain.tld’);
Set($LdapBase, ‘dc=domain,dc=tld’);
Set($LdapFilter, ‘(objectclass=*)’);
Set($LdapUser, ‘cn=ldapuser,ou=ITST,ou=Everyone,dc=domain,dc=tld’);
Set($LdapPass, ‘passwordgoeshere’);

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 :slight_smile:

-Matt

4

Good day all!

I’ve set up LDAP integration on a fresh RT 3.6.6 install to authenticate
with our Windows 2003 Active Directory, as per
ExternalAuthentication - Request Tracker Wiki. It seems to be working quite
nicely (including authentication and user record field population), with one
exception: enabling group membership checks breaks things.

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:

Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeUserInfo called by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 628 with: Name: rttestuser
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “sAMAccountName=rttestuser” by RT::User
/var/www/rt/local/lib/RT/User_Local.pm 404
Feb 29 12:32:26 stilgar RT: RT::User::CanonicalizeEmailAddress : called with
“rttestuser@domain.tld” by RT::User /var/www/rt/local/lib/RT/User_Local.pm
413
Feb 29 12:32:26 stilgar RT: RT::User::LookupExternalUserInfo called with
baseDN “dc=domain,dc=tld” and filter “mail=rttestuser@domain.tld” by
RT::User /var/www/rt/local/lib/RT/User_Local.pm 343
Feb 29 12:32:26 stilgar RT: FOUND OK
Feb 29 12:32:26 stilgar RT: UPDATED user rttestuser from LDAP
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

Additional LDAP settings in RT_SiteConfig.pm:

Set($LdapServer, ‘dc.domain.tld’);
Set($LdapBase, ‘dc=domain,dc=tld’);
Set($LdapFilter, ‘(objectclass=*)’);
Set($LdapUser, ‘cn=ldapuser,ou=ITST,ou=Everyone,dc=domain,dc=tld’);
Set($LdapPass, ‘passwordgoeshere’);

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 :slight_smile:

-Matt

5

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:

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

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 :slight_smile:

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

Confidential

6

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:

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

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 :slight_smile:

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

Confidential

7

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.

-MattOn 3/1/08, Mike Peachey mike.peachey@jennic.com 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:

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

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 :slight_smile:

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

8

RT Lists wrote:

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’);

Simple enough… AD is storing group members in the “member” attribute,
not the uniqueMember attribute. I should have noticed myself.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England