OTRS works with many customer data attributes such as username, email address, phone number, etc. These attributes are displayed in both the Agent and the Customer frontends, and also used for the authentication of customers.
Customer data used or displayed within OTRS is highly customizable. The following information is however always needed for customer authentication:
User login
Email address
Customer ID
Use the following SysConfig parameters if you want to display customer information in your agent interface.
# Ticket::Frontend::CustomerInfo*
# (show customer info on Compose (Phone and Email), Zoom and
# Queue view)
$Self->{'Ticket::Frontend::CustomerInfoCompose'} = 1;
$Self->{'Ticket::Frontend::CustomerInfoZoom'} = 1;
Script: SysConfig configuration parameters.
You can use two types of customer backends, DB and LDAP. If you already have another customer backend (e.g. SAP), it is of course possible to write a module that uses it.
The Example below shows the configuration of a DB customer backend, which uses customer data stored in the OTRS database.
Example 4.7. Configuring a DB customer backend
# CustomerUser (customer database backend and settings)
$Self->{CustomerUser} = {
Name => 'Database Datasource',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
# if you want to use an external database, add the required settings
# DSN => 'DBI:odbc:yourdsn',
# Type => 'mssql', # only for ODBC connections
# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
# User => '',
# Password => '',
Table => 'customer_user',
# CaseSensitive will control if the SQL statements need LOWER()
# function calls to work case insensitively. Setting this to
# 1 will improve performance dramatically on large databases.
CaseSensitive => 0,
},
# customer unique id
CustomerKey => 'login',
# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',
CustomerUserListFields => ['first_name', 'last_name', 'email'],
CustomerUserSearchFields => ['login', 'last_name', 'customer_id'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['email'],
CustomerUserNameFields => ['title','first_name','last_name'],
CustomerUserEmailUniqCheck => 1,
# # show not own tickets in customer panel, CompanyTickets
# CustomerUserExcludePrimaryCustomerID => 0,
# # generate auto logins
# AutoLoginCreation => 0,
# AutoLoginCreationPrefix => 'auto',
# # admin can change customer preferences
# AdminSetPreferences => 1,
# # cache time to live in sec. - cache any database queries
# CacheTTL => 0,
# # just a read only source
# ReadOnly => 1,
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],
[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],
[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],
[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],
[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],
[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],
# [ 'UserEmail', Translatable('Email'), 'email', 1, 1, 'var', '[% Env("CGIHandle") %]?Action=AgentTicketCompose;ResponseID=1;TicketID=[% Data.TicketID | uri %];ArticleID=[% Data.ArticleID | uri %]', 0, '', 'AsPopup OTRSPopup_TicketAction' ],
[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],
# [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],
[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],
[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],
[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],
[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],
[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],
[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],
[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],
[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],
[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],
# Dynamic field example
# [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef, ],
],
# default selections
Selections => {
UserTitle => {
'Mr.' => 'Mr.',
'Mrs.' => 'Mrs.',
},
},
};
If you want to customize the customer data, change the column headers or add new ones to the customer_user table in the OTRS database. As an example, the script below shows how to add a new field for room number.
linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 116 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD room VARCHAR (250); Query OK, 1 rows affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~#
Script: Adding a room field to the customer_user table.
Now add the new column to the MAP array in Kernel/Config.pm, as shown in the following script.
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[...]
[ 'UserRoom', 'Room', 'room', 0, 1, 'var', '', 0 ],
Script: Adding a room field to the Kernel/Config.pm file.
It is also possible to edit all of this customer information via the Customers link in the Agent interface.
Please note that you may omit http-link-target and link
class keys in map array elements, if they are not to be used. These keys add
target="" and class="" attributes to the HTTP link
element, respectively. They are ignored if http-link is not set.
It is possible to assign more than one customer ID to a customer. This can be useful if a customer must access tickets of other customers, e.g. a supervisor wants to watch the tickets of his assistants. If a customer can access the tickets of another customer, the company ticket feature of OTRS is used. Company tickets can be accessed via the "Company Tickets" link in the customer panel.
To use company tickets, a new column with the IDs that should be accessible for a customer, has to be added to the customer_user table in the OTRS database (see Script below).
linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 124 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD customer_ids VARCHAR (250); Query OK, 1 rows affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~#
Script: Adding a customer_ids field to the customer_user table.
Now the new column has to be added to the MAP array in Kernel/Config.pm, as shown in the script below.
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[...]
[ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],
Script: Adding a UserCustomerIDs field to the Kernel/Config.pm file.
Now, the new column for the multiple customer IDs can be edited via the Agent interface, in the section for the customer management.
To ensure that one customer can access the tickets of other customers, add the IDs of these other users into the new field for the multiple customer IDs. Each ID has to be separated by a semicolon (see Example below).
Example 4.8. Using Company Tickets with a DB Backend
The customers A, B and C exist in your system, and A wants to have access to the tickets of B and C via the customer panel. B and C should have no access to the tickets of other users.
To realize this setup, change the customer_user table and the mapping in Kernel/Config.pm as described above. Then load the settings for customer A via the Customers link in the Agent interface or via the Admin page. If the settings are displayed, add into the field for CustomerIDs the values "B;C;".
If you have an LDAP directory with your customer data, you can use it as the customer backend with OTRS, as shown in Example below.
Example 4.9. Configuring an LDAP customer backend
# CustomerUser
# (customer ldap backend and settings)
$Self->{CustomerUser} = {
Name => 'LDAP Data Source',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
# ldap host
Host => 'bay.csuhayward.edu',
# ldap base dn
BaseDN => 'ou=seas,o=csuh',
# search scope (one|sub)
SSCOPE => 'sub',
# The following is valid but would only be necessary if the
# anonymous user does NOT have permission to read from the LDAP tree
UserDN => '',
UserPw => '',
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
AlwaysFilter => '',
# if the charset of your ldap server is iso-8859-1, use this:
# SourceCharset => 'iso-8859-1',
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
# customer unique id
CustomerKey => 'uid',
# customer #
CustomerID => 'mail',
CustomerUserListFields => ['cn', 'mail'],
CustomerUserSearchFields => ['uid', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
# show not own tickets in customer panel, CompanyTickets
CustomerUserExcludePrimaryCustomerID => 0,
# add an ldap filter for valid users (expert setting)
# CustomerUserValidFilter => '(!(description=locked))',
# administrator can't change customer preferences
AdminSetPreferences => 0,
# # cache time to live in sec. - cache any database queries
# CacheTTL => 0,
Map => [
# note: Login, Email and CustomerID are mandatory!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ],
[ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ],
# [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],
[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ],
[ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ],
],
};
If additional customer attributes are stored in your LDAP directory, such as a manager's name, a mobile phone number, or a department, and if you want to display this information in OTRS, just expand the MAP array in Kernel/Config.pm with the entries for these attributes, as shown in the following script.
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[...]
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],
Script: Adding new fields to the Kernel/Config.pm file.
It is possible to assign more than one Customer ID to a customer, when using an LDAP backend. To use company tickets, a new field has to be added to the LDAP directory that contains the IDs accessible by the customer.
If the new field in the LDAP directory has been created, the new entry has to be added to the MAP array in Kernel/Config.pm, as shown in the script below.
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
[...]
[ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],
Script: Maping new fields to the Kernel/Config.pm file.
The field for the multiple customer IDs has to be edited directly in the LDAP directory. OTRS can only read from LDAP, not write to it.
To ensure access by a customer to the tickets of other customers, add the customer IDs of the customers whose tickets should be accessed to the new field in your LDAP directory. Each ID has to be separated by a semicolon (see Example below).
Example 4.10. Using Company tickets with an LDAP backend
The customers A, B and C exist in your system, and A wants to have access to the tickets of B and C via the customer panel. B and C should have no access to the tickets of other users.
To realize this setup, change the LDAP directory and the mapping in Kernel/Config.pm as described above. Then add into the field for CustomerIDs the values "B;C;" for customer A in your LDAP directory.
If you want to utilize more than one customer data source used with OTRS (e.g. an LDAP and a database backend), the CustomerUser config parameter should be expanded with a number, e.g. "CustomerUser1", "CustomerUser2" (see Example below).
Example 4.11. Using more than one customer backend with OTRS
The following configuration example shows usage of both an LDAP and a database customer backend with OTRS.
# 1. Customer user backend: DB
# (customer database backend and settings)
$Self->{CustomerUser1} = {
Name => 'Customer Database',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
# if you want to use an external database, add the
# required settings
# DSN => 'DBI:odbc:yourdsn',
# Type => 'mssql', # only for ODBC connections
# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
# User => '',
# Password => '',
Table => 'customer_user',
},
# customer unique id
CustomerKey => 'login',
# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',
CustomerUserListFields => ['first_name', 'last_name', 'email'],
CustomerUserSearchFields => ['login', 'last_name', 'customer_id'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['email'],
CustomerUserNameFields => ['title','first_name','last_name'],
CustomerUserEmailUniqCheck => 1,
# # show not own tickets in customer panel, CompanyTickets
# CustomerUserExcludePrimaryCustomerID => 0,
# # generate auto logins
# AutoLoginCreation => 0,
# AutoLoginCreationPrefix => 'auto',
# # admin can change customer preferences
# AdminSetPreferences => 1,
# # cache time to live in sec. - cache any database queries
# CacheTTL => 0,
# # just a read only source
# ReadOnly => 1,
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target
[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],
[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],
[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],
[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],
[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],
[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],
[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],
[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],
[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],
[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],
[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],
[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],
[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],
[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],
[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],
[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],
],
# default selections
Selections => {
UserTitle => {
'Mr.' => 'Mr.',
'Mrs.' => 'Mrs.',
},
},
};
# 2. Customer user backend: LDAP
# (customer ldap backend and settings)
$Self->{CustomerUser2} = {
Name => 'LDAP Datasource',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
# ldap host
Host => 'bay.csuhayward.edu',
# ldap base dn
BaseDN => 'ou=seas,o=csuh',
# search scope (one|sub)
SSCOPE => 'sub',
# The following is valid but would only be necessary if the
# anonymous user does NOT have permission to read from the LDAP tree
UserDN => '',
UserPw => '',
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
AlwaysFilter => '',
# if the charset of your ldap server is iso-8859-1, use this:
# SourceCharset => 'iso-8859-1',
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
# customer unique id
CustomerKey => 'uid',
# customer #
CustomerID => 'mail',
CustomerUserListFields => ['cn', 'mail'],
CustomerUserSearchFields => ['uid', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
# show not own tickets in customer panel, CompanyTickets
CustomerUserExcludePrimaryCustomerID => 0,
# add a ldap filter for valid users (expert setting)
# CustomerUserValidFilter => '(!(description=locked))',
# admin can't change customer preferences
AdminSetPreferences => 0,
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ],
[ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ],
# [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],
[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ],
[ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ],
],
};
It is possible to integrate up to 10 different customer backends. Use the customer management interface in OTRS to view or edit (assuming write access is enabled) all customer data.
Sometimes it can be useful to also store CustomerUser data directly in dynamic fields of a ticket, for example to create special statistics on this data.
The dynamic field values are set when a ticket is created or when the customer of a ticket is changed. The values of the dynamic fields are taken from the customer data. This works for all backends, but is especially useful for LDAP-backends.
To activate this optional feature of OTRS, please activate the settings
Ticket::EventModulePost###950-DynamicFieldFromCustomerUser and
DynamicFieldFromCustomerUser::Mapping. The latter setting contains the
configuration of which CustomerUser field entry should be stored in which
ticket dynamic field. The fields must be present in the system and should be enabled for
AgentTicketFreeText, so that they can be set manually. They mustn't be enabled for
AgentTicketPhone, AgentTicketEmail and
AgentTicketCustomer. If they were, they would have precedence over the automatically set values.
OTRS offers the option to authenticate agents and customers against different backends.
The backend to authenticate agents which is used by default is the OTRS database. Agents can be added and edited via the agent management interface in the Admin page (see Example below).
Example 4.12. Authenticate agents against a DB backend
$Self->{'AuthModule'} = 'Kernel::System::Auth::DB';
If an LDAP directory has all your agent data stored, you can use the LDAP module to authenticate your users in OTRS (see Example below). This module has only read access to the LDAP tree, which means that you cannot edit your user data via the agent management interface.
Example 4.13. Authenticate agents against an LDAP backend
# This is an example configuration for an LDAP auth. backend.
# (Make sure Net::LDAP is installed!)
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
$Self->{'AuthModule::LDAP::Host'} = 'ldap.example.com';
$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';
$Self->{'AuthModule::LDAP::UID'} = 'uid';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
$Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com';
$Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid';
# for ldap posixGroups objectclass (just uid)
# $Self->{'AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (with full user dn)
# $Self->{'AuthModule::LDAP::UserAttr'} = 'DN';
# The following is valid but would only be necessary if the
# anonymous user do NOT have permission to read from the LDAP tree
$Self->{'AuthModule::LDAP::SearchUserDN'} = '';
$Self->{'AuthModule::LDAP::SearchUserPw'} = '';
# 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.com
# $Self->{'AuthModule::LDAP::UserSuffix'} = '@domain.com';
# 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,
};
The configuration parameters shown in the script below can be used to synchronize the user data from your LDAP directory into your local OTRS database. This reduces the number of requests to your LDAP server and speeds up the authentication with OTRS. The data synchronization is done when the agent authenticates the first time. Although the data can be syncronized into the local OTRS database, the LDAP directory is the last instance for the authentication, so an inactive user in the LDAP tree can't authenticate to OTRS, even when the account data is already stored in the OTRS database. The agent data in the LDAP directory can't be edited via the web interface of OTRS, so the data has to be managed directly in the LDAP tree.
# defines AuthSyncBackend (AuthSyncModule) for AuthModule
# if this key exists and is empty, there won't be a sync.
# example values: AuthSyncBackend, AuthSyncBackend2
$Self->{'AuthModule::UseSyncBackend'} = 'AuthSyncBackend';
# agent data sync against ldap
$Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';
$Self->{'AuthSyncModule::LDAP::Host'} = 'ldap://ldap.example.com/';
$Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=otrs, dc=org';
$Self->{'AuthSyncModule::LDAP::UID'} = 'uid';
$Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'uid=sys, ou=user, dc=otrs, dc=org';
$Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'some_pass';
$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',
];
Script: Synchronizing the user data from the LDAP directory into the OTRS database.
Alternatively, you can use LDAP groups to determine group memberships or roles in OTRS. For more information and examples, see Kernel/Config/Defaults.pm. Here is an example for synchronizing from LDAP into OTRS groups.
# Attributes needed for group syncs
# (attribute name for group value key)
$Self->{'AuthSyncModule::LDAP::AccessAttr'} = 'memberUid';
# (select the attribute for type of group content UID/DN for full ldap name)
# $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'UID';
# $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'DN';
AuthSyncModule::LDAP::UserSyncGroupsDefinition
# (If "LDAP" was selected for AuthModule and you want to sync LDAP
# groups to otrs groups, define the following.)
$Self->{'AuthSyncModule::LDAP::UserSyncGroupsDefinition'} = {
# your ldap group
'cn=agent,o=otrs' => {
# otrs group(s)
'admin' => {
# permission
rw => 1,
ro => 1,
},
'faq' => {
rw => 0,
ro => 1,
},
},
'cn=agent2,o=otrs' => {
'users' => {
rw => 1,
ro => 1,
},
}
};
If you want to implement a "single sign on" solution for all your agents, you can use HTTP basic authentication (for all your systems) and the HTTPBasicAuth module for OTRS (see Example below).
Example 4.14. Authenticate Agents using HTTPBasic
# This is an example configuration for an apache ($ENV{REMOTE_USER})
# auth. backend. Use it if you want to have a singe login through
# apache http-basic-auth
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
# Note:
#
# If you use this module, you should use as fallback
# the following configuration settings if the user is not authorized
# apache ($ENV{REMOTE_USER})
$Self->{LoginURL} = 'http://host.example.com/not-authorised-for-otrs.html';
$Self->{LogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';
The configuration parameters shown in Example below can be used to authenticate agents against a Radius server.
Example 4.15. Authenticate Agents against a Radius backend
# This is example configuration to auth. agents against a radius server
$Self->{'AuthModule'} = 'Kernel::System::Auth::Radius';
$Self->{'AuthModule::Radius::Host'} = 'radiushost';
$Self->{'AuthModule::Radius::Password'} = 'radiussecret';
The default user authentication backend for customers in OTRS is the OTRS database. With this backend, all customer data can be edited via the web interface of OTRS (see Example below).
Example 4.16. Customer user authentication against a DB backend
# This is the auth. module against the otrs db
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB';
$Self->{'Customer::AuthModule::DB::Table'} = 'customer_user';
$Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login';
$Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw';
#$Self->{'Customer::AuthModule::DB::DSN'} = "DBI:mysql:database=customerdb;host=customerdbhost";
#$Self->{'Customer::AuthModule::DB::User'} = "some_user";
#$Self->{'Customer::AuthModule::DB::Password'} = "some_password";
If you have an LDAP directory with all your customer data, you can use the LDAP module to authenticate your customers to OTRS (see Example below). Because this module has only read-access to the LDAP backend, it is not possible to edit the customer data via the OTRS web interface.
Example 4.17. Customer user authentication against an LDAP backend
# This is an example configuration for an LDAP auth. backend.
# (make sure Net::LDAP is installed!)
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
$Self->{'Customer::AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com';
$Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';
# for ldap posixGroups objectclass (just uid)
$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (full user dn)
#$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
# The following is valid but would only be necessary if the
# anonymous user does NOT have permission to read from the LDAP tree
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = '';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = '';
# 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->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '';
# in case you want to add a suffix to each customer login name, then
# you can use this option. e. g. user just want to use user but
# in your ldap directory exists user@domain.com
#$Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com';
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
$Self->{'Customer::AuthModule::LDAP::Params'} = {
port => 389,
timeout => 120,
async => 0,
version => 3,
};
If you want to implement a "single sign on" solution for all your customer users, you can use HTTPBasic authentication (for all your systems) and use the HTTPBasicAuth module with OTRS (no login is needed with OTRS any more). See Example below.
Example 4.18. Customer user authentication with HTTPBasic
# This is an example configuration for an apache ($ENV{REMOTE_USER})
# auth. backend. Use it if you want to have a singe login through
# apache http-basic-auth
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
# Note:
# If you use this module, you should use the following
# config settings as fallback, if user isn't login through
# apache ($ENV{REMOTE_USER})
$Self->{CustomerPanelLoginURL} = 'http://host.example.com/not-authorised-for-otrs.html';
$Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';
The settings shown in Example below can be used to authenticate your customers against a Radius server.
Example 4.19. Customer user authentication against a Radius backend
# This is a example configuration to auth. customer against a radius server
$Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::Radius';
$Self->{'Customer::AuthModule::Radius::Host'} = 'radiushost';
$Self->{'Customer::AuthModule::Radius::Password'} = 'radiussecret';
It is possible to customize the self-registration for new customers, accessible via the customer.pl panel. New optional or required fields, like room number, address or state can be added.
The following example shows how you can specify a required field in the customer database, in this case to store the room number of a customer.
To display the new field for the room number in the customer.pl web interface, the .tt file responsible for the layout in this interface has to be modified. Edit the Kernel/Output/HTML/Templates/Standard/CustomerLogin.tt file, adding the new field around line 130 (see Script below).
[...]
<div class="NewLine">
<label for="Room">[% Translate("Room{CustomerUser}") | html %]</label>
<input title="[% Translate("Room Number") | html %]" name="Room" type="text" id="UserRoom" maxlength="50" />
</div>
[...]
Script: Displaying a new field in the web interface.
In the next step, the customer mapping has to be expanded with the new entry for the room number. To ensure that the changes are not lost after an update, put the "CustomerUser" settings from the Kernel/Config/Defaults.pm into the Kernel/Config.pm. Now change the MAP array and add the new room number field, as shown in the script below.
# CustomerUser
# (customer database backend and settings)
$Self->{CustomerUser} = {
Name => 'Database Backend',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
# if you want to use an external database, add the
# required settings
# DSN => 'DBI:odbc:yourdsn',
# Type => 'mssql', # only for ODBC connections
# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
# User => '',
# Password => '',
Table => 'customer_user',
},
# customer unique id
CustomerKey => 'login',
# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',
CustomerUserListFields => ['first_name', 'last_name', 'email'],
# CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'],
CustomerUserSearchFields => ['login', 'last_name', 'customer_id'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['email'],
CustomerUserNameFields => ['title', 'first_name', 'last_name'],
CustomerUserEmailUniqCheck => 1,
# # show not own tickets in customer panel, CompanyTickets
# CustomerUserExcludePrimaryCustomerID => 0,
# # generate auto logins
# AutoLoginCreation => 0,
# AutoLoginCreationPrefix => 'auto',
# # admin can change customer preferences
# AdminSetPreferences => 1,
# # cache time to live in sec. - cache database queries
# CacheTTL => 0,
# # just a read only source
# ReadOnly => 1,
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target
[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],
[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],
[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],
[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],
[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],
[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],
[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],
[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],
[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],
[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],
[ 'UserRoom', 'Room', 'room', 1, 0, 'var', '', 0 ],
[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],
[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],
[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],
[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],
[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],
[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],
],
# default selections
Selections => {
UserTitle => {
'Mr.' => 'Mr.',
'Mrs.' => 'Mrs.',
},
},
};
Script: Changing the map array.
The last step is to add the new room number column to the customer_user table in the OTRS database (see Script below). In this column, the entries for the room numbers will be stored.
linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 6 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD room VARCHAR (200); Query OK, 3 rows affected (0.01 sec) Records: 3 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~#
Script: Adding a new column to the customer_user table.
Now the new field for the room should be displayed in the Customer Information panel if filled, and in the Customer User administration screens. Also, new customers should have to insert their room number if they register a new account.