Samba (LDAP) y RT 5

Hola,

My RT install has the following environment:

  • Debian 12.9
  • RT5 from APT (5.0.3+dfsg-3~deb12u2)
  • Samba at a different host (Ubuntu 22.04)

The installation was configured using debconf, allowing it to control the RT_SiteConfig settings. Given that, I’ve added the LDAP settings under /etc/request-tracker5/RT_SiteConfig.d/80-ldap.pm, which content is below.

What happens is that although I’m able to login successfully with RT’s root user with the said configuration. I’m not able to use any user from Samba’s LDAP database. All attempts return FAILED LOGIN error at RT. It doesn’t matter which format do I use for the username.

Set($LDAPCreatePrivileged, 1);
Set($LDAPUpdateUsers, 1);

Set($LDAPGroupMapping, { Name => 'cn', Member_Attr => 'member', Member_Attr_Value => 'dn' });
Set($LDAPGroupBase, 'CN=Users,DC=dominio,DC=red');

Set($LDAPGroupFilter, '(|(cn=Domain Users)(cn=Technical Operations)(cn=Management))');

Set($ExternalAuthPriority, ['My_LDAP', ]);
Set($ExternalInfoPriority, ['My_LDAP', ]);

Set($UserAutocreateDefaultsOnLogin, { Privileged => 1 });
Set($AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {
'My_LDAP' => {
        'type' => 'ldap',
        'tls' => 0,
        'server' => '192.168.1.5',
        'user' => 'rt_user@DOMINIO.RED',
        'pass' => 'nosecomparte',
        'base' => 'CN=Users,dc=dominio,dc=red',
        'filter' => '(objectClass=person)',
        'attr_match_list' => ['Name', 'EmailAddress', ],
        'attr_map' => {
                'Name' => 'sAMAccountName',
                'EmailAddress' => 'mail',
                'RealName' => 'cn',
                'WorkPhone' => 'telephoneNumber',
                'Address1' => 'streetAddress',
                'City' => 'l',
                'State' => 'st',
                'Zip' => 'postalCode',
                'Country' => 'co',
                },
        },
});

Samba’s log:

  auth_check_password_send: Checking password for unmapped user [DOMINIO]\[rt_user]@[ORDENADOR04]
  auth_check_password_send: user is: [DOMINIO]\[rt_user]@[ORDENADOR04]
Auth: [LDAP,simple bind] user [DOMINIO]\[rt_user@DOMINIO.RED] at [Fri, 24 Jan 2025 10:28:09.362469 -05] with [Plaintext] status [NT_STATUS_OK] workstation [ORDENADOR04] remote host [ipv4:192.168.1.13:54192] became [DOMINIO]\[rt_user] [S-1-5-21-2795409746-889793459-1347831397-1114]. local host [ipv4:192.168.1.5:389]

As you can see, the LDAP bind authentication is correct at Samba, but there is no trace of it using the webform credentials.
To discard incorrect credentials I can say that I’m able to authenticate correctly from the RT host to Samba using different credentials with ldapsearch. Here I’ve used the format user@DOMINIO.RED, as it is in the configuration, and DOMINIO\user.

Now, when I comment out the user/pass elements from RT_SiteConfig.d’s it is like the Login webform is not passing the user/password values to the LDAP authentication. Samba’s log that before displayed the configured user (rt_user) look totally empty for the auth settings.

RT’s log:

[error]: Can't locate object method "as_string" via package "(objectClass=person)" (perhaps you forgot to load "(objectClass=person)"?) at /usr/share/request-tracker5/lib/RT/Authen/ExternalAuth/LDAP.pm line 624.

Stack:
  [/usr/share/request-tracker5/lib/RT/Authen/ExternalAuth/LDAP.pm:624]
  [/usr/share/request-tracker5/lib/RT/Authen/ExternalAuth.pm:669]
  [/usr/share/request-tracker5/lib/RT/Authen/ExternalAuth.pm:408]
  [/usr/share/request-tracker5/html/Elements/DoAuth:57]
  [/usr/share/request-tracker5/lib/RT/Interface/Web.pm:356]
  [/usr/share/request-tracker5/html/autohandler:53] (/usr/share/request-tracker5/lib/RT/Interface/Web/Handler.pm:217)

Samba’s log:

  auth_check_password_send: Checking password for unmapped user []\[]@[ORDENADOR04]
  auth_check_password_send: user is: []\[]@[ORDENADOR04]

To me, it seems there is some misconfiguration or something that I’m missing at RT level.

Hey,

There is a bug in line 625 where “filter” should be “search_filter”. Fixed in commit e271ef77f806735317dfc6b12726be6970604ae8 . The debug line may provide a bit more information if you fix that bug and retry your test.

I don’t have experience using Samba has an auth source, but for authing to an LDAP server, what you have looks sensible to me.

Cheers,
Andrew

Hello Andrew,

thanks for the follow-up. It turned out that such bug was a stopper for further analysis. I’ve tweaked the code and managed to get it working smoothly. I’ll check the commit to validate and also talk to Debian maintainers about it.

After tweaking my filter settings I was also able to sync users and groups using the LDAP Import tool. However group memberships are not updated on RT-side. Essentially I’m importing users that are members of a couple of LDAP’s groups, that are being imported too.

Hey Rudy,

You’re in luck, I am one of the maintainers of the Debian packages. :wink: I thought I’d added this fix to our packages, when I checked yesterday I found that I hadn’t. Please raise a bug in the Debian Bug Tracking System against the request-tracker5 package.

I don’t import group membership from LDAP, so I can’t really help there. However, there are a few different ways to represent group membership in LDAP. Do you have RT configured using the method in use in Samba?

Cheers,
Andrew

Hello Andrew,

I’ll file a bug report then.

I don’t follow you here. What do you mean? Currently my RT settings are default plus the LDAP configuration that I’ve shared with tweaks for the LDAP Import tool.

Hello Andrew, I’ve managed to sync group membership using ldap-import, it was a misconfiguration on my side.

Are you aware of encoding issues when importing values that are utf-8? I’m facing this issue. RT db supports utf-8 and I understand Samba’s LDAP also does. Perhaps the Perl script is not aware of such encoding?

Update: I’ve found this related bug, but the latest update is from Feb, 2013!

I had a similar problem the first time. I added the following parameter to $LDAPOptions in the config file:

raw => qr/(\;binary)/,

Maybe this can helps you.

1 Like

Hello Eduardo,

thank you. It now decodes the characters correctly.

In case you are also using the LDAPUpdateUsers, you’d also want to add this setting to the net_ldap_args under the ExternalSettings configuration.