Hi,
I'm not sure I should be trying to explain much about OTRS or LDAP, but here are some of my humble experiences and a few snippets from my config.pm.
First of all, OTRS separates the authentication and the data backends. That means, when you authenticate a user (agent or customer), we further need some DATA about this user before we can let him in.
This data can come from the same backend or another. If you have none configured, OTRS will try its own internal DB.
Doing a plain OTRS (3.2.3) install and adding the customer LDAP authentication (only) to config.pm, causes the exact error message you list, since no customer data can be found in the built-in DB backend.
I then tried adding the customer DATA backend, and actually got the same error until I restarted the OTRS services (I'm not sure that should be necessary, but it's worth trying when troubleshooting).
So, in summary, from a total blank OTRS install, adding the following to config.pm:
# FIRST the authentication.
# Customer LDAP authentication backend.
$Self->{'Customer::AuthModule2'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host2'} = 'ldap.int.dom.test';
$Self->{'Customer::AuthModule::LDAP::BaseDN2'} = 'DC=int,DC=dom,DC=test';
$Self->{'Customer::AuthModule::LDAP::UID2'} = 'sAMAccountName';
# Check if member of AD group before customer login.
# Nested groups doesn't seem to work. Have to use a global one that most people are member of, "Domain Users" won't work, as it's a special group.
# Disable until further notice. Perhaps nested groups will work someday.
# Note to self: Try LDAP query for nested members (memberof:1.2.840.113556.1.4.1941:=<Full DN>).
# $Self->{'Customer::AuthModule::LDAP::GroupDN2'} = 'CN=OTRS Customers,OU=OTRS,DC=int,DC=dom,DC=test';
# $Self->{'Customer::AuthModule::LDAP::AccessAttr2'} = 'member';
# $Self->{'Customer::AuthModule::LDAP::UserAttr2'} = 'DN';
# LDAP Bind credentials.
$Self->{'Customer::AuthModule::LDAP::SearchUserDN2'} = 'CN=otrsusr,OU=Other,OU=System Integration,DC=int,DC=dom,DC=test';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw2'} = 'password';
# We only need to see users, not computers, and no disabled users either.
$Self->{'Customer::AuthModule::LDAP::AlwaysFilter2'} = '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))';
Causes the error message that you mention earlier ("No such user").
(The user gets authenticated, but we don't know anything about him, at least not enough to let him in)
Further adding this:
# THEN the data backend.
# Customer LDAP data backend.
$Self->{CustomerUser2} = {
# Just the display name in OTRS.
Name => 'LDAP - Backend',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => 'ldap.int.dom.test',
BaseDN => 'DC=int,DC=dom,DC=test',
# Search Scope.
SSCOPE => 'sub',
# LDAP Bind credentials.
UserDN => 'CN=otrsusr,OU=Other,OU=System Integration,DC=int,DC=dom,DC=test',
UserPw => 'password',
# This is needed to avoid issues with ae, oe, aa. Dunno what happens or if it's entirely correct.
SourceCharset => 'utf-8',
DestCharset => 'utf-8',
# We only need to see users, not computers, and no disabled users either.
AlwaysFilter => '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))',
},
CustomerKey => 'sAMAccountName',
CustomerID => 'mail',
# Show fields when searching customers in the admin interface.
# CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserListFields => ['cn', 'mail'],
# Search in these fields in LDAP.
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
CustomerUserSearchListLimit => '1000',
Map => [
# Note: Login, Email and CustomerID are required!
# 'var', 'frontend', 'storage', shown, required, 'storage-type'
# [ 'UserTitle', 'Title', 'title', 1, 0, 'var' ],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
[ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
[ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var'],
# [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
# [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
[ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
],
};
(and also restarting the OTRS services), I can then login successfully.
The above matches a 2003/2008 AD pretty good, I'd say.
But now that you mention it, I seem to recall some weird character issues years back, can't remember if it was the user or the password, though.
--
/Sune T.
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Marty Hillman
Sent: 20. marts 2013 22:49
To: User questions and discussions about OTRS.
Subject: Re: [otrs] FW: "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator."
I got it fixed, and I am pretty sure I know what the error was. There are some special characters that you can use in a password that it does not like at all in the Config.pm file. The password I had selected for the test account had an @ symbol in it. When I changed the password to one that was a mixture of cases and numbers, it seems to be working just fine. The Customer page in the admin file is populated with all sorts of AD users now.
From: Gerald Young [mailto:crythias@gmail.com]
Sent: Wednesday, March 20, 2013 3:56 PM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] FW: "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator."
I've set this on 2.7, 3.0, and 3.1. It *should* work on 3.2 or else there'd have been some wailing and gnashing of teeth and immediate bugfixes.
It doesn't look like the code has been changed appreciably in a while, just some code cleanup.
On Wed, Mar 20, 2013 at 4:40 PM, Marty Hillman