Integration of OTRS v4 with Active Directory. Configure Single Sign On Authentication
This guide is intended for the case when there is already a configured server with OTRS installed. A detailed guide on installing OTRS v4 in a Windows environment can be found here .
Before integrating OTRS with Active Directory, you need to decide on the accounts and their role. We will need the following accounts:
As an analogue in Active Directory for the root @ localhost account, we will use the “Admin OTRS” account with the login “root”.
In the Active Directory Users and Computers snap-in, we will create a new user.
When creating an account, do not forget to uncheck the "Require password change next time you log into the system."
We assume that accounts for the technical support specialist and for the user already exist. If not, we create them by analogy.
')
IMPORTANT : all users must have an email address. This is a must for all OTRS users.
In this example, all technical support specialists who will work in OTRS will be members of the OTRSagents group. This is an important point in the delimitation of access rights in the system.
We create the OTRSagents group in the Active Directory Users and Computers snap-in. Group scope is global. Group type - Security. We make members of the previously created OTRS administrator account (with root login) and the necessary technical support specialists as members.
It is also important to have an account with user rights, which will be used by the OTRS system to read the Active Directory directory. For convenience, the password validity period of this account should be unlimited.
Follow the link http: //localhost/otrs/index.pl and log in as root @ localhost.
Next, go to the Administration tab, Agent Management, Agents.
Select the root @ localhost account.
Make changes. It is important to remember that the login and password for this account must match the login and password for the Admin OTRS account (root login) that we created in Active Directory.
Change root @ localhost login to root, change password accordingly. We set the email address in the Email field (in this example, testdomain, among other things, acts as a mail server). Click the Submit button.
The last step is to edit the file c: \ otrs \ Kernel \ Config.pm.
In this example:
The following configuration is inserted after the line "insert your own config settings" here "".
Save the changes to the file, restart the Apache service. If there are problems, the service will not start. We read logs (c: \ otrs \ var \ log) and fix errors.
Follow the link http: //localhost/otrs/index.pl for the agent. Do not forget to check the root account. We also follow the link http: //localhost/otrs/customer.pl , we go under the account of a simple user.
Everything is working! Configuration of the OTRS integration with the active tree is completed.
Apache needs a keytab for authentication. To generate it, you need a protocol (HTTP), the full domain name of the OTRS server and the domain name. Protocol name and domain name must be in upper case. A regular domain user is also required.
In the command line on the domain controller, do the following:
At the output in the root of the C drive we get the file. Later, I renamed the file from helpdesksrv.keytab to apache.keytab and put it in the c: \ Apache2 \ conf \ folder (the file name does not play a role).
Download MIT Kerberos and install it.
Installation is simple, without any features.
Create an empty file c: \ Program Files (x86) \ MIT \ Kerberos \ krb.ini and fill it in, keep the register as in the example. Here TESTDC1 is the name of the domain controller.
Download mod_auth_kerb.so for Apache 2.2. *, Copy it to the c: \ Apache2 \ modules folder.
Modify the file c: \ Apache2 \ conf \ httpd.conf. Add the following lines and reboot:
Edit the file c: \ otrs \ Kernel \ Config.pm, add the lines:
Restart the Apache service. Checking http: //helpdesksrv/otrs/customer.pl . We will be redirected, the line in the address bar of the browser will change to http: //helpdesksrv/otrs/customer.pl? Action = CustomerTicketOverview; Subaction = MyTickets .
Create a request through the web interface by the user. We go to the agent interface and see that the username in the application is displayed incorrectly.
Apparently, the parameter insertion
in the file c: \ otrs \ Kernel \ Config.pm passes incorrectly.
Modify the file c: \ otrs \ Kernel \ cpan-lib \ Apache \ DBI.pm, add the lines:
Restart the Apache service.
Now the username is displayed correctly.
That's all. I hope that my experience will be useful to you.
Part 1. Setting up LDAP authentication.
Before integrating OTRS with Active Directory, you need to decide on the accounts and their role. We will need the following accounts:
- agent - technical support specialist;
- root-user (a very important point - the login and password of the root-user account must match the login and password of the administrator account in OTRS);
- Actually, the OTRS user, who will apply for technical support;
- account to read the Active Directory.
As an analogue in Active Directory for the root @ localhost account, we will use the “Admin OTRS” account with the login “root”.
In the Active Directory Users and Computers snap-in, we will create a new user.
When creating an account, do not forget to uncheck the "Require password change next time you log into the system."
We assume that accounts for the technical support specialist and for the user already exist. If not, we create them by analogy.
')
IMPORTANT : all users must have an email address. This is a must for all OTRS users.
In this example, all technical support specialists who will work in OTRS will be members of the OTRSagents group. This is an important point in the delimitation of access rights in the system.
We create the OTRSagents group in the Active Directory Users and Computers snap-in. Group scope is global. Group type - Security. We make members of the previously created OTRS administrator account (with root login) and the necessary technical support specialists as members.
It is also important to have an account with user rights, which will be used by the OTRS system to read the Active Directory directory. For convenience, the password validity period of this account should be unlimited.
Follow the link http: //localhost/otrs/index.pl and log in as root @ localhost.
Next, go to the Administration tab, Agent Management, Agents.
Select the root @ localhost account.
Make changes. It is important to remember that the login and password for this account must match the login and password for the Admin OTRS account (root login) that we created in Active Directory.
Change root @ localhost login to root, change password accordingly. We set the email address in the Email field (in this example, testdomain, among other things, acts as a mail server). Click the Submit button.
The last step is to edit the file c: \ otrs \ Kernel \ Config.pm.
In this example:
- Domain test.testdomain.ru
- Domain Controller IP - 10.0.0.11
- Account for reading Active Directory- helpdesk@test.testdomain.ru with password Qwerty123.
- OTRS Agent Group - OTRSagents in the Users container.
The following configuration is inserted after the line "insert your own config settings" here "".
Config.pm
# insert your own config settings "here" # # #-------------------LDAP-----------------# $Self->{'DefaultCharset'} = 'utf-8'; # LDAP $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = '10.0.0.11'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=test, dc= testdomain,dc=ru'; $Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName'; # , , , OTRS $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=OTRSagents,cn=Users,dc=test,dc=testdomain,dc=ru'; $Self->{'AuthModule::LDAP::AccessAttr'} = 'member'; $Self->{'AuthModule::LDAP::UserAttr'} = 'DN'; $Self->{'AuthModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru'; $Self->{'AuthModule::LDAP::SearchUserPw'} = 'Qwerty123'; $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, sscope => 'sub' }, # Agent data sync against LDAP $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP'; $Self->{'AuthSyncModule::LDAP::Host'} = '10.0.0.11'; $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=test, dc=testdomain,dc=ru'; $Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName'; $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru'; $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'Qwerty123'; $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = { UserFirstname => 'givenName', UserLastname => 'sn', UserEmail => 'mail', }; $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [ 'users', ]; # # # Authenticate customer users against an LDAP backend # $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP'; #LDAP $Self->{'Customer::AuthModule::LDAP::Host'} ='10.0.0.11'; $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=test, dc=testdomain,dc=ru'; $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName'; $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru'; $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'Qwerty123'; $Self->{CustomerUser} = { Module => 'Kernel::System::CustomerUser::LDAP', Params => { Host => '10.0.0.11', BaseDN => 'dc=test, dc=testdomain,dc=ru', SSCOPE => 'sub', UserDN => 'helpdesk@ test.testdomain.ru', UserPw => 'Qwerty123', AlwaysFilter => '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))', SourceCharset => 'utf-8', DestCharset => 'utf-8', }, ReadOnly => 1, CustomerKey => 'sAMAccountName', CustomerID => 'mail', CustomerUserListFields => ['givenname', 'sn', 'mail'], CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'], CustomerUserSearchFields => ['displayName','sAMAccountName','givenName', 'sn', 'mail','description'], CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 10000, CustomerUserPostMasterSearchFields => ['displayName','sAMAccountName','givenName','sn','mail','description'], CustomerUserNameFields => ['givenname', 'sn'], # CustomerUserExcludePrimaryCustomerID => 0, CacheTTL => 120, Map => [ # [ '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' ], ], }; #-------------------------------------------- Save the changes to the file, restart the Apache service. If there are problems, the service will not start. We read logs (c: \ otrs \ var \ log) and fix errors.
Follow the link http: //localhost/otrs/index.pl for the agent. Do not forget to check the root account. We also follow the link http: //localhost/otrs/customer.pl , we go under the account of a simple user.
Everything is working! Configuration of the OTRS integration with the active tree is completed.
Part 2. Setting end-to-end (Single Sign On) authentication.
Creating a Kerberos token
Apache needs a keytab for authentication. To generate it, you need a protocol (HTTP), the full domain name of the OTRS server and the domain name. Protocol name and domain name must be in upper case. A regular domain user is also required.
In the command line on the domain controller, do the following:
Ktpass -princ HTTP/helpdesksrv.test.testdomain.ru@TEST.TESTDOMAIN.RU -mapuser helpdesk@test.testdomain.ru -pass Qwerty123 -out C:\helpdesksrv.keytab At the output in the root of the C drive we get the file. Later, I renamed the file from helpdesksrv.keytab to apache.keytab and put it in the c: \ Apache2 \ conf \ folder (the file name does not play a role).
Installing MIT Kerberos for Windows 4.0.1
Download MIT Kerberos and install it.
Installation is simple, without any features.
Configuring MIT Kerberos
Create an empty file c: \ Program Files (x86) \ MIT \ Kerberos \ krb.ini and fill it in, keep the register as in the example. Here TESTDC1 is the name of the domain controller.
krb.ini
[logging] default = c:/otrs/var/log/krb5libs.log kdc = c:/otrs/var/log/krb5kdc.log admin_server = c:/otrs/var/log/kadmind.log [libdefaults] debug=true default_keytab_file = c:/Apache2/conf/apache.keytab default_realm = TEST.TESTDOMAIN.RU dns_lookup_kdc = false krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] TEST.TESTDOMAIN.RU = { kdc = TESTDC1.test.testdomain.ru admin_server = TESTDC1.test.testdomain.ru default_domain = test.testdomain.ru } [domain_realm] .test.testdomain.ru = TEST.TESTDOMAIN.RU test.testdomain.ru = TEST.TESTDOMAIN.RU [login] krb4_convert = true krb4_get_tickets = false [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } Download mod_auth_kerb.so for Apache 2.2. *, Copy it to the c: \ Apache2 \ modules folder.
Configure Apache
Modify the file c: \ Apache2 \ conf \ httpd.conf. Add the following lines and reboot:
httpd.conf
# LoadModule auth_kerb_module modules/mod_auth_kerb.so <Directory "c:/otrs/bin/cgi-bin/"> # OTRS c:/otrs AllowOverride None AuthType Kerberos AuthName "OTRS Kerberos Authentification" # keytab- Krb5Keytab c:/Apache2/conf/apache.keytab KrbAuthRealms TEST.TESTDOMAIN.RU KrbMethodNegotiate on KrbSaveCredentials off Require valid-user Options +ExecCGI -Includes Order allow,deny Allow from all </Directory> Configure OTRS
Edit the file c: \ otrs \ Kernel \ Config.pm, add the lines:
Config.pm
# + LDAP #+ single sign on # ------- --------- # $Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth'; # $Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} = '@TEST.TESTDOMAIN.RU'; # ------ --------- $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth'; $Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@ EST.TESTDOMAIN.RU'; $Self->{CustomerUser} = { Module => 'Kernel::System::CustomerUser::LDAP', Params => { Host => '10.0.0.11', BaseDN => 'dc=test, dc=testdomain,dc=ru', SSCOPE => 'sub', UserDN => 'helpdesk@test.testdomain.ru', UserPw => 'Qwerty123', SourceCharset => 'utf-8', DestCharset => 'utf-8', }, CustomerKey => 'sAMAccountName', CustomerID => 'mail', CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'], CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'], 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' ], ], }; Restart the Apache service. Checking http: //helpdesksrv/otrs/customer.pl . We will be redirected, the line in the address bar of the browser will change to http: //helpdesksrv/otrs/customer.pl? Action = CustomerTicketOverview; Subaction = MyTickets .
We eliminate cracks
Create a request through the web interface by the user. We go to the agent interface and see that the username in the application is displayed incorrectly.
Apparently, the parameter insertion
$Self->{'DefaultCharset'} = 'utf-8'; in the file c: \ otrs \ Kernel \ Config.pm passes incorrectly.
Modify the file c: \ otrs \ Kernel \ cpan-lib \ Apache \ DBI.pm, add the lines:
$dbh->{'mysql_enable_utf8'} = 1; $dbh->do('SET NAMES utf8'); Restart the Apache service.
Now the username is displayed correctly.
That's all. I hope that my experience will be useful to you.
Source: https://habr.com/ru/post/259339/
All Articles