I have Googled and screwed around with Config.pm for hours. The configuration is creating agents in the database appropriately, but it is not creating users in the customer database. I am using this as in internal system only, so there is no outside access. I want any user to be able to use their AD credentials to log on. If there is not an account in OTRS, it should create one for them.
Anyone have any thoughts on what I am overlooking? Here is my /opt/otrs/Kernel/Config.pm. I copied and pasted from several Google results and modified for my own information. It does validate the password is correct for the customer, but does not add them to the database if they don’t exist.
# ---------------------------------------------------- #
# http://wiki.otterhub.org/index.php?title=Using_OTRS_with_Active_Directory_as_a_source_for_agents #
# ---------------------------------------------------- #
# This is an example configuration for using an MS AD backend
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
$Self->{'AuthModule::LDAP::Host'} = '172.16.10.21';
$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=domain,dc=com';
$Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group OTRS_Agents to use otrs)
$Self->{'AuthModule::LDAP::GroupDN'} = 'CN=Corp_Admin_MIS,OU=level2,OU=level1,DC=domain,DC=com';
$Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
$Self->{'AuthModule::LDAP::UserAttr'} = 'DN';
# Bind credentials to log into AD
$Self->{'AuthModule::LDAP::SearchUserDN'} = 'CN=OTRS Dev,OU=level2,OU=level1,DC=domain,DC=com';
$Self->{'AuthModule::LDAP::SearchUserPw'} = 'password';
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
$Self->{'AuthModule::LDAP::AlwaysFilter'} = '';
# in case you want to add a suffix to each login name, then
# you can use this option. e. g. user just want to use user but
# in your ldap directory exists user@domain.
#$Self->{'AuthModule::LDAP::UserSuffix'} = '';
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
$Self->{'AuthModule::LDAP::Params'} = {
port => 389,
timeout => 120,
async => 0,
version => 3,
};
# Now sync data with OTRS DB
$Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';
$Self->{'AuthSyncModule::LDAP::Host'} = '172.16.10.21';
$Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=domain, dc=com';
$Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'CN=OTRS Dev,OU=level2,OU=level1,DC=domain,DC=com';
$Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'password';
$Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
# DB -> LDAP
UserFirstname => 'givenName',
UserLastname => 'sn',
UserEmail => 'mail',
};
# AuthSyncModule::LDAP::UserSyncInitialGroups
# (sync following group with rw permission after initial create of first agent
# login)
$Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
'users',
];
# ---------------------------------------------------- #
# Customer authentication section #
# ---------------------------------------------------- #
$Self->{'SecureMode'} = '1';
# The name to be used for this server when constructing URLs in email
$Self-> {'FQDN'} = 'otrsdev.domain.com';
#Enable LDAP authentication for Customers / Users
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host'} = '172.16.10.21';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'DC=domain,DC=com';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=OTRS Dev,OU=level2,OU=level1,DC=domain,DC=com';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'password';
$Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '(objectclass=user)';
$Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '';
# $Self->{'AuthModule::LDAP::Die'} = 1;
#CustomerUser
#(customer user database backend and settings)
$Self->{CustomerUser} = {
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => '172.16.10.21',
BaseDN => 'DC=domain,DC=com',
async => 0,
port => 389,
sscope => 'sub',
timeout => 120,
version => 3,
UserDN => 'CN=OTRS Dev,OU=level2,OU=level1,DC=domain,DC=com';
UserPw => 'password',
},
# Unique customer key/id
CustomerKey => 'sAMAccountName',
CustomerID => 'sAMAccountName',
CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown, required, storage-type
#[ 'UserSalutation', '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' ],
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
#[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
#[ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
],
};
# ---------------------------------------------------- #
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
My Config.pm appears to be configured correctly, but it does not work. I have looked at the articles in your links along with dozens of others. All of them have the exact same configuration as what I posted in my initial email unless there is a character somewhere I am missing. I copied and pasted the configurations changing my DN, CN, OU, DC in accordance with my AD structure. It is obviously authenticating, so I am fairly certain I did it right. The sAMAccountName and mail settings have been changed various times to try to get it working. Until just before I posted my message, they were both set to ‘mail’.
One user wrote that the Customer::Auth page needed to be modified in SysConfig. http://deckerix.com/blog/configura-tu-otrs-con-soporte-ldap/ I did this as well and verified the settings in ZZZauto.pm.
From how I read your email (“OTRS will not populate your customer_user database”), I am going to have to hand enter 500 user accounts for the potential employees that can enter tickets or they will not be able to use the system. If I understand you correctly, that is a project killer.
If the system can create the agent accounts based on settings in the Config.pm file, why would it not be able to do so with customers?
Come to think of it, if it does not add the customers to the database, the feature is pretty worthless. Why validate against LDAP/AD at all for customers if everything has to exist in the database? That would just be adding useless complexity.
My view of “does not work” means that I can successfully authenticate the user using LDAP, but it tells me tough luck because the user does not exist in the internal DB. (see the subject line). If it does not need to see the customer backend, awesome. I was trying to get everything to authenticate with LDAP. That WAS the goal. I could care less about the database in this instance. But that is not what the error message is telling me. It tells me it needs both.
1. If I use a correct user name and password, I get the error in the subject line telling me that authentication succeeded, but it will still not log in because the customer is not in the database.
2. If I use a correct user name and bad password, I receive a “Login Failed! Your user name or password was entered incorrectly.”
This tells me that it is reading LDAP correctly and verifying the password properly; HOWEVER, I never get beyond the "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator." Why do I need to care about the customer backend?
Per your statement “the lower case Params should be with in another Params hash”, I have revised that section as such (based on the information in the link you provided).
#CustomerUser
#(customer user database backend and settings)
$Self->{CustomerUser} = {
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => '172.16.10.21’,
BaseDN => 'DC=domain,DC=com',
SSCOPE => 'sub',
UserDN => 'CN=OTRS Dev,OU=level2,OU=level1,DC=domain,DC=com',
UserPw => 'password',
Params {
async => 0,
port => 389,
timeout => 120,
version => 3,
},
},
Authentication and authorization are two different things (one is “can you access this system”, the other is “what are you allowed to do”). I agree that on first authentication, OTRS should create a stub record in the database for the authorized entity, but I actually think the “no privileges until explicitly assigned” is a good thing in that you don’t accidentally disclose things that that customer has no business seeing.
I think the compromise approach would be to use the authorization exit to check whether the customer is in the database and then add a default entry from a site-assigned template (queue access, permissions, etc).
From: otrs-b...@otrs.org [mailto:otrs-b...@otrs.org]
On Behalf Of Marty Hillman
Sent: Tuesday, March 19, 2013 4:06 PM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator."
Come to think of it, if it does not add the customers to the database, the feature is pretty worthless. Why validate against LDAP/AD at all for customers if everything has to exist in the database? That would just be adding useless complexity.
Ok. I am going to start over from scratch with a fresh Config.pm and report back. Brand new day. The ultimate goal would be for the site to automatically log the user in based on the context of the user logged in to the workstation. This would allow me to embed the customer.pl page (more specifically a new ticket form) directly into SharePoint (gasp!) so that we have full integration within our intranet. Again, there will be no access for non-employees as this is exclusively internal facing. Am I being too unrealistic?
Thanks for all of the pointers everyone. I will use these links to try again and let you know.
No. I do this all the time. Sso, even.
Ok. I am going to start over from scratch with a fresh Config.pm and report back. Brand new day. The ultimate goal would be for the site to automatically log the user in based on the context of the user logged in to the workstation.
Adding GSSAPI support to OTRS has been on my to-do list for quite a while. That would allow security and identity tokens (like the Kerberos 5 principal and service tickets that Windows uses) to be securely passed from lots of different authentication sources w/o special code for each.
Ok. I am going to start over from scratch with a fresh Config.pm and report back. Brand new day. The ultimate goal would be for the site to automatically log the user in based on the context of the user logged in to the workstation.
Adding GSSAPI support to OTRS has been on my to-do list for quite a while. That would allow security and identity tokens (like the Kerberos 5 principal and service tickets that Windows uses) to be securely passed from lots of different authentication sources w/o special code for each.
I've done this... it works nicely.
Goody! Is the code committed? I’ll have some VERY happy people here if it is.
I've done this... it works nicely.
Goody! Is the code committed? I’ll have some VERY happy people here if it is.
That’s not GSSAPI. That’s using mod_kerb to supply the user information via basic mode. Not the same animal, although it produces a similar-looking effect.
From: otrs-b...@otrs.org [mailto:otrs-b...@otrs.org]
On Behalf Of Gerald Young
Sent: Wednesday, March 20, 2013 11:33 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator."
Yes. Those settings are all there.
It is showing LDAP in FrontEnd::Customer::Auth. The settings on that page are all correct.
I did blow away the entire install including the database. I installed the OTRS from source and modified the Config.pm. I went through all of the steps of logging in as my AD user into the admin panel, commenting out the settings in Config.pm, logging back in as root@localhost, changing my user to admin, and removing the comment markers. Admin access for my security group works perfectly. It authenticates the user against AD and adds new users to the agent screen.
Once I was through with the admin portion, I added the lines for customer authentication. This should allow all users in my AD forest to authenticate. SearchUserDN and SearchUserPW are removed below for security, of course. These lines were taken from instructions found on the net. I am now back at the original issue of the message shown in the subject line. Authentication has succeeded, but it is not logging the user in. When looking at the customer listing, the user is not listed.
This should be a cleaner view of the configuration. What am I possibly missing?
# ---------------------------------------------------- #
# LDAP Configuration Settings for Customers #
# ---------------------------------------------------- #
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host'} = 'corpsms01.equuscs.com';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=equuscs,dc=com';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
$Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'member';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'user account';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'password';
$Self->{'Customer::AuthModule::LDAP::Params'} = {
port => 389,
timeout => 120,
async => 0,
version => 3,
};
$Self->{CustomerUser} = {
Name => 'LDAP Datasource',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => 'corpsms01.equuscs.com',
BaseDN => 'dc=equuscs,dc=com',
SSCOPE => 'sub',
UserDN => 'user account',
UserPW => 'password',
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
CustomerKey => 'sAMAccountName',
CustomerID => 'mail',
CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
CustomerUserExcludePrimaryCustomerID => 0,
AdminSetPreferences => 0,
Map => [
[ 'UserSalutation', 'Title', 'title', 1, 0, 'var'],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var'],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var'],
[ 'UserLogin', 'Username', 'sAMAccountName', 1, 1, 'var'],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var'],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var'],
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var'],
[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var'],
[ 'UserComment', 'Comment', 'description', 1, 0, 'var'],
],
};
And you would make me a very happy person if you got that done. :-)
From: otrs-b...@otrs.org [mailto:otrs-b...@otrs.org] On Behalf Of David Boyes
Sent: Wednesday, March 20, 2013 9:54 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] "Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator."
Ok. I am going to start over from scratch with a fresh Config.pm and report back. Brand new day. The ultimate goal would be for the site to automatically log the user in based on the context of the user logged in to the workstation.
I should incorporate the messages I am seeing in my logs. It looks like it is authenticating against AD and failing when trying to look up the user in OTRS using the Kernel::System::CustomerUser::SetPreferences module.
[Wed Mar 20 11:44:40 2013][Notice][Kernel::System::CustomerAuth::LDAP::Auth] CustomerUser: mhillman (CN=Marty Hillman,OU=Users,OU=blah, blah, blah) authentication ok (REMOTE_ADDR: 172.18.3.75).
[Wed Mar 20 11:44:40 2013][Error][Kernel::System::CustomerUser::SetPreferences][547] No such user 'mhillman'!
Gerald – Going back through last night’s emails.
The latest code has them nested. Even adding
Name => ‘LDAP Datasource’,
to Params does not seem to change things. And SSCOPE is now upper case.
I do see when looking at customers in the admin panel that LDAP Datasource is now a selection, but it did not add the user to that group.
I commented out mine and added yours with my DN settings. I get the same error. When looking in the backend, I now have a choice on Customers screen of Database Backend or LDAP Backend (under the Add Customer button), but there are no customers listed in either selection.
Previous emails have me a little confused. I promise I will stop asking. Am I supposed to manually add Customers, or should they be added much like Agents are? I would assume that if they do not exist, the system should add them based on the LDAP settings being parsed.
BTW, Using OTRS 3.2.3 on Ubuntu 12.04 LTS Server against a Windows 2003 LDAP, if that makes any difference.
Nope. Not true. I just ran LDIFDE against the server that I am querying for LDAP. For my user account, I have the following (edited for security). Based on the contents, I even commented out items in the map and left only UserFirstName, UserLastName, UserLogin, UserEmail, UserCustomerID.
dn: CN=Marty Hillman,OU=Users,OU=Corporate,OU=xxxxxxxx,OU=xxxxxxxx,OU=xxxxxxxx,DC=xxxxxxxxx,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Marty Hillman
sn: Hillman
c: US
l: Minnetonka
st: MN
title: Infrastructure Manager
description: IT Infrastructure Manager
postalCode: 55343
givenName: Marty
distinguishedName:
CN=Marty Hillman,OU=Users,OU=Corporate,OU=xxxxxxxx,OU=xxxxxxxx,OU=xxxxxxxx,DC=xxxxxxxx,DC=com
instanceType: 4
whenCreated: 20130219201501.0Z
whenChanged: 20130313151527.0Z
displayName: Marty Hillman
uSNCreated: XXXXXXXXXXX
memberOf:
*** Lots of groups deleted ***
uSNChanged: XXXXXXXXXXX
co: UNITED STATES
department: MIS
company: Equus Computer Systems, Inc.
homeMTA:
*** Exchange settings ***
proxyAddresses: smtp:xxxxxxxxxxxxx
proxyAddresses: smtp: xxxxxxxxxxxxx
proxyAddresses: smtp: xxxxxxxxxxxxx
proxyAddresses: smtp: xxxxxxxxxxxxx
proxyAddresses: smtp: xxxxxxxxxxxxx
proxyAddresses: smtp: xxxxxxxxxxxxx
proxyAddresses: SMTP:mhil...@equuscs.com
proxyAddresses: XXXXXXXXXXXXXXXXXXXXXXX
homeMDB:
*** Exchange Settings ***
mDBUseDefaults: TRUE
mailNickname: mhillman
name: Marty Hillman
objectGUID:: xxxxxxxxxxxxxxxxxxxxx
userAccountControl: XXXXXXXXXXXXX
badPwdCount: 0
codePage: 0
countryCode: 840
homeDirectory: \\xxxxxxxxxxxxx\xxxxxxxxxx
homeDrive: H:
badPasswordTime: XXXXXXXXXXXXXXXXXX
lastLogoff: 0
lastLogon: XXXXXXXXXXXXXXXXXXXXXX
scriptPath: smsls
logonHours:: ////////////////////////////
pwdLastSet: XXXXXXXXXXXXXXXXXX
primaryGroupID: XXXXXXX
userParameters::
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
objectSid:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
adminCount: 1
accountExpires: 0
logonCount: 249
sAMAccountName: mhillman
sAMAccountType: xxxxxxxxx
showInAddressBook:
*** Exchange Settings ***
userPrincipalName: mhil...@equuscs.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=equuscs,DC=com
mSMQSignCertificates::
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
mSMQDigests:: XXXXXXXXXXXXXXXXXXXXXXXXXXX
msNPAllowDialin: FALSE
lastLogonTimestamp: 130075656959202436
textEncodedORAddress: XXXXXXXXXXXXXXXXXXXXXXXXX
mail: mhil...@equuscs.com
msExchHomeServerName:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
msExchMailboxSecurityDescriptor::
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
msExchUserAccountControl: 0
msExchMailboxGuid:: XXXXXXXXXXXXXXXXXXXXXXX
msExchPoliciesIncluded:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
msExchUserCulture: en-US
msExchVersion: XXXXXXXXXXXXXXXXXXX
msExchMobileMailboxFlags: 1
msExchRecipientDisplayType: 1073741824
msExchRecipientTypeDetails: 1
That poses one question for me. What version are you using where it works? Then I promise to drop this particular issue.
But again, Thanks for all of your help. You have all been teaching me more than I ever thought I wanted to know about perl and OTRS. ;-)
From: Gerald Young [mailto:cryt...@gmail.com]
Sent: Wednesday, March 20, 2013 3:36 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."
There's not enough other information available for me to assist at this time. I've configured this and helped others configure it on multiple occasions, and have no other information that I can provide via the mailing list. It *could* be a bug in 3.2.3 (don't know) but at the moment, unless I'm looking right at your config, I don't know what else to say.
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.
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.