OTRS 4.0.10. We put on Ubuntu + AD + Kerberos + SSO (Part Two)
I continue the story about how to actually install this beast on Ubuntu and set up a transparent domain authorization, plus how to fasten some nice buns available in the free version of OTRS.
Part One: System Preparation
Part Two: Installing and Configuring OTRS
Part three: fix the shoals fasten buns
Well, the system is fully prepared, even more than we, with a clear conscience and a light heart, proceed to install directly OTRS.
')
We will install the last stable version, at the moment it is 4.0.10, in fact it is not significant, because we initially went the canonically correct way and did not use any gaskets and crutches such as NTLM, SSPI and other adams, and raised the full-fledged Kerberos authentication. And for it in the OTRS module HTTPBasicAuth is responsible, which has not undergone significant changes, so the described method will work on all versions of the system starting from at least 3.1.1.
What is the essence of the method? And the whole point is that OTRS in general does not perform any user authorization or authentication, but simply takes the name of the logged-in user from the $ _ENV environment variable ['Remote_User'] searches for it in its database and, if it finds it, opens the interface for it Custome in logged form. That is, the entire burden of verification of the user falls on Apache’s shoulders, which the Kerberos mechanism authenticates the user and, if he succeeds, then drives his login into the environment variable. Whence OTRS picks it up, considering that if there is something there, then the authentication has already been successful. So let's get started.
Excellent article about this here . The installation process is described in great detail.
Everything related to domain authorization and pass-through authentication has been gathered around the world and worked out through trial and error, so I can’t give any links.
Here is a list of packages that we will need at this stage:
Most of them are already in the system or we have already installed them, but in order not to go through each one, we will just give the command to install everything, those that already exist will simply be skipped by the package manager and that's it. So we execute
As already mentioned above, we will install version 4.0.10, the last one at the time of this writing. We swing OTRS itself:
Unpack the archive:
Move the unpacked OTRS folder / opt:
And create a symlink to it in the same folder:
Check whether we have put all the modules:
If we need some additional modules, we install (in the output of the previous command, there is a hint next to each module how to install it if it is not). We get the user for OTRS:
And we include it in the www-data group:
Keep in mind: our machine is included in the domain and winbind binded all users in the local user base, so you need to make sure that there is no user in the domain with the login “ otrs ”. If it is, delete it and reboot the Linux machine.
We create default configs for OTRS:
And we set up rights for a newly created user:
It remains to create a vhost Apache for OTRS and you can configure the system:
Turn on vhost OTRS:
And reread Apache configs:
Everything. Installation is complete, now we can do the configuration OTRS.
The initial configuration of the system takes place via the web interface. Go to helpdesk / otrs / installer.pl , see the OTRS installation wizard:
We press further and see the license agreement, read it carefully and click “accepted conditions”.
At the third stage, you need to select the database to use, in our case, the MySQL database, so click next. Here it is more interesting, you need to enter the login of that MySQL user root @ localhost, we created this password in step 6, when we set up the Apache and MySQL server.
OTRS will try to connect to the database server (localhost) and if everything is fine, it will create a database called otrs and user otrs, as well as with a very tricky password, we also remember it wherever we are in a notebook, just in case.
We configure mail. At the output, OTRS will report the password of the default user root @ localhost, remember its password.
We follow the link “home page” and see invitations to log in, this is where we enter only the recorded username and password. By and large, the OTRS installation is already complete, but this is not enough for us and we didn’t bother with Kerberos so much, we need integration with AD and pass-through authentication, so we go ahead.
And then turn to the respected rasa manual . We will draw something from there, something from the Internet, and we will invent our own way.
So for a start. In the domain, there should be one user who completely coincides with the OTRS administrator, we will have it and read the LDAP and we will get the rest of the OTRS admins through it. In my case, this is the otrs.admin user, by the way, for the installation period I gave him domain administrator rights and all domain manipulations, such as switching the machine into the domain, receiving tickets, etc., on behalf of this particular user, after installing these rights it can be selected, moreover, to prohibit him from logging into domain machines, he only needs to read information from LDAP, nothing more.
And so, in the interface of the OTRS Agent, go to the “Administration” tab, go to the “agents” section and see the only agent, click on it and change its credentials in accordance with the data of the user in the domain, as I said above, in my case This is the login otrs.admin and the corresponding domain password, click “send” at the bottom of the page and try to log out and log in again with the new credentials.
! ATTENTION! To match the data of the domain user must not only login, but also the password!
Now turn off the possibility of self-registration bush. “Administration” - “System Configuration” - (in the drop-down list on the left, select “Framework”) - “Frontend :: Customer” on the CustomerPanelCreateAccount select “No” and click on the “Update” button below. Here you can also correct the name of the organization that will be displayed at the bush meter in CustomerHeadline. There are a lot of other settings that can be twisted and tried, but this is later, now we are interested in integration with LDAP.
The OTRS integration with LDAP will be configured via the /opt/otrs/Kernel/Config.pm configuration file:
We find the line # insert your own config settings “here” # and insert the following config after it:
After that, you can save the file and try to log in as an agent under the domain account, which is included in the OTRSagents group in the domain.
Go to helpdesk.domain.ru/otrs/index.pl , enter the login and password of the domain account in the OTRSagents group. Should all ride. The newly logged agent will have no administration tab, you can enable it by logging in under the account of the original admin, in my case it is otrs.admin and having distributed access rights to the new agent.
Please note: agents are created in the OTRS database after the first login.
It is also necessary to check that OTRS pulled the Customers database from the LDAP. To do this, go to "Administration" - "Client Account" . Here we must see the full list of domain users in a table, login, name, email, etc.
Check whether everything successfully pulled up from the domain.
In order to access the Customers, a minor improvement is required, first of all, you need to enable Kerberos authentication on folders with scripts. The scripts are here / opt / otrs / bin / cgi-bin. .
Turning on Kerberos will require manipulations similar to those we performed in step 7 with the / var / www / html / php folder. Open the otrs virtual host config file:
And we see the following configurations of the location / otrs and directories / opt / otrs / bin / cgi-bin . The first piece:
And the second piece:
At first glance, everything is very clear and simple, but again it was not possible to comprehend this shamanism with a swoop. In a nutshell, certain directives are connected here depending on the presence or absence of certain Apache modules or on their versions. The developers piled all this up because they did not know in advance what conditions the system would work with, which packages and which versions of these packages. But we are with you already absolutely certain which packages and which versions we have in the system. Therefore, just mercilessly cut out all unnecessary and bring these two blocks to the following form:
The first piece:
The second piece:
Then we re-read Apache configs and restart it:
After these manipulations, when trying to access the OTRS scripts, Apache will try to authenticate the user and, if successful, will drive his login to the $ _ENV ['REMOTE_USER'] variable, from where the OTRS HTTPBasicAuth authentication module will find the user’s name, go through its database and if he finds such a user, This will open the Custome page in the logged-in form.
And everything seems to be nothing, here is just a Custom page, if we now try to enter it, tell us something completely strange, “Authorization was successful, but you could not find a user in the database.”
We are starting debugging. To do this, download a couple of scripts on pearl:
whoami.pl
test.pl
We drop them to the rest of the OTRS scripts in the / opt / otrs / bin / cgi-bin folder , expose them to the rights and the owner of the same one that is already there and try to open them in the browser.
The first script simply checks for the $ _ENV ['REMOTE_USER'] variable, and if there is something in it, it displays a message that we seem to be driven into the NT domain with such and such account, if it is, and it shows us the correct account, then everything is ok.
The second script shows us which line OTRS receives as user login. And it is here that we see that OTRS receives something like username@DOMAIN.RU , but we know that we use sAMAccountName as the login name , that is, just the username , without a domain, and in the list of Clients in the previous one stage, we also saw that we have logins without a domain name.
That's where the dog rummaged, so this situation happens, Apache worked, authorization was successful and everything was OK, but OTRS could not find the user in its database. It turns out that we need to somehow throw out the domain name from the user name before searching it in the OTRS database.
The blessing to fix it is quite simple, although while I figured out how, it took decently time and effort.
To do this, again go to the Agent interface, “Administration” - “System Configuration” - “Framework” - “Frontend :: Customer :: Auth” , find the parameter Customer :: AuthModule :: HTTPBasicAuth :: ReplaceRegExp , enable it, and in the for input we leave what is there, for those who erased the default, there should be such a regular
Unfortunately, regular expressions on Perle remain for me inaccessible magic and transcendent shamanism, so I cannot explain how it works (I will be extremely grateful if anyone gives explanations in the comments, and I will gladly add it to the article) But in a nutshell, it discards everything on behalf of the user after the “@” symbol inclusively.
Click "send" at the bottom of the page and stamp to the address of the Customer interface: helpdesk.domain.ru/otrs/customer.pl
Everything should work.
Regarding the magic of regular expression:
Everything turned out to be very simple, as they explained to me "compared to the magic of the regulars, this is so, a children's seance" (c).
symbol ^ - the beginning of the processed string
the $ character is the end of the string
Symbols () - show that as a result of processing you need to leave what is between them
? - any character
. + - recursive concatenation (as a result, the expression '. +?' - literally means any string)
The @ symbol is not a special character, therefore it is processed as part of a line (surprisingly, I never would have thought, I always thought that it was just a special character and needed to be escaped, just the absence of such an escape made me astray and prevented myself from understanding this expression )
And as a result, we get that the regular partition breaks the resulting string into two parts “everything before the @ character” and “everything after the @ character” and returns the first part (as it is in parentheses).
MA-A-A-A-A-Giya
Part One: System Preparation
Part Two: Installing and Configuring OTRS
Part three: fix the shoals fasten buns
6. Installing and configuring OTRS
Well, the system is fully prepared, even more than we, with a clear conscience and a light heart, proceed to install directly OTRS.
')
6.1. The essence of the proposed method and the necessary packages
We will install the last stable version, at the moment it is 4.0.10, in fact it is not significant, because we initially went the canonically correct way and did not use any gaskets and crutches such as NTLM, SSPI and other adams, and raised the full-fledged Kerberos authentication. And for it in the OTRS module HTTPBasicAuth is responsible, which has not undergone significant changes, so the described method will work on all versions of the system starting from at least 3.1.1.
What is the essence of the method? And the whole point is that OTRS in general does not perform any user authorization or authentication, but simply takes the name of the logged-in user from the $ _ENV environment variable ['Remote_User'] searches for it in its database and, if it finds it, opens the interface for it Custome in logged form. That is, the entire burden of verification of the user falls on Apache’s shoulders, which the Kerberos mechanism authenticates the user and, if he succeeds, then drives his login into the environment variable. Whence OTRS picks it up, considering that if there is something there, then the authentication has already been successful. So let's get started.
Excellent article about this here . The installation process is described in great detail.
Everything related to domain authorization and pass-through authentication has been gathered around the world and worked out through trial and error, so I can’t give any links.
Here is a list of packages that we will need at this stage:
- libapache2-mod-perl2
- libtemplate-perl
- libarchive-zip-perl
- libjson-xs-perl
- libmail-imapclient-perl
- libdbd-mysql-perl
- libnet-dns-perl
- libnet-ldap-perl
- libio-socket-ssl-perl
- libpdf-api2-perl
- libsoap-lite-perl
- libgd-text-perl
- libgd-graph-perl
- libapache-dbi-perl
- libyaml-libyaml-perl
- mysql-server
- wget
Most of them are already in the system or we have already installed them, but in order not to go through each one, we will just give the command to install everything, those that already exist will simply be skipped by the package manager and that's it. So we execute
apt-get install libapache2-mod-perl2 libtemplate-perl libarchive-zip-perl libjson-xs-perl libmail-imapclient-perl libdbd-mysql-perl libnet-dns-perl libnet-ldap-perl libio-socket-ssl-perl libpdf-api2-perl libsoap-lite-perl libgd-text-perl libgd-graph-perl libapache-dbi-perl libyaml-libyaml-perl mysql-server wget 6.2. We put OTRS
As already mentioned above, we will install version 4.0.10, the last one at the time of this writing. We swing OTRS itself:
cd ~ wget http://ftp.otrs.org/pub/otrs/otrs-4.0.10.tar.gz Unpack the archive:
tar zxf ./otrs-4.0.10.tar.gz Move the unpacked OTRS folder / opt:
mv ./otrs-4.0.10 /opt And create a symlink to it in the same folder:
ln -s /opt/otrs-4.0.10/ /opt/otrs Check whether we have put all the modules:
perl /opt/otrs/bin/otrs.CheckModules.pl If we need some additional modules, we install (in the output of the previous command, there is a hint next to each module how to install it if it is not). We get the user for OTRS:
useradd -r -d /opt/otrs/ -c 'OTRS user' otrs And we include it in the www-data group:
usermod -g www-data otrs Keep in mind: our machine is included in the domain and winbind binded all users in the local user base, so you need to make sure that there is no user in the domain with the login “ otrs ”. If it is, delete it and reboot the Linux machine.
We create default configs for OTRS:
cd /opt/otrs/Kernel cp Config.pm.dist Config.pm cp Config/GenericAgent.pm.dist Config/GenericAgent.pm And we set up rights for a newly created user:
cd /opt/otrs bin/otrs.SetPermissions.pl --otrs-user=otrs --web-group=www-data /opt/otrs It remains to create a vhost Apache for OTRS and you can configure the system:
cp /opt/otrs/scripts/apache2-httpd.include.conf /etc/apache2/sites-available/otrs.conf Turn on vhost OTRS:
a2ensite otrs And reread Apache configs:
service apache2 reload Everything. Installation is complete, now we can do the configuration OTRS.
6.3. Initial configuration of the OTRS system. LDAP Integration (in our case AD)
The initial configuration of the system takes place via the web interface. Go to helpdesk / otrs / installer.pl , see the OTRS installation wizard:
We press further and see the license agreement, read it carefully and click “accepted conditions”.
At the third stage, you need to select the database to use, in our case, the MySQL database, so click next. Here it is more interesting, you need to enter the login of that MySQL user root @ localhost, we created this password in step 6, when we set up the Apache and MySQL server.
OTRS will try to connect to the database server (localhost) and if everything is fine, it will create a database called otrs and user otrs, as well as with a very tricky password, we also remember it wherever we are in a notebook, just in case.
We configure mail. At the output, OTRS will report the password of the default user root @ localhost, remember its password.
We follow the link “home page” and see invitations to log in, this is where we enter only the recorded username and password. By and large, the OTRS installation is already complete, but this is not enough for us and we didn’t bother with Kerberos so much, we need integration with AD and pass-through authentication, so we go ahead.
And then turn to the respected rasa manual . We will draw something from there, something from the Internet, and we will invent our own way.
So for a start. In the domain, there should be one user who completely coincides with the OTRS administrator, we will have it and read the LDAP and we will get the rest of the OTRS admins through it. In my case, this is the otrs.admin user, by the way, for the installation period I gave him domain administrator rights and all domain manipulations, such as switching the machine into the domain, receiving tickets, etc., on behalf of this particular user, after installing these rights it can be selected, moreover, to prohibit him from logging into domain machines, he only needs to read information from LDAP, nothing more.
And so, in the interface of the OTRS Agent, go to the “Administration” tab, go to the “agents” section and see the only agent, click on it and change its credentials in accordance with the data of the user in the domain, as I said above, in my case This is the login otrs.admin and the corresponding domain password, click “send” at the bottom of the page and try to log out and log in again with the new credentials.
! ATTENTION! To match the data of the domain user must not only login, but also the password!
Now turn off the possibility of self-registration bush. “Administration” - “System Configuration” - (in the drop-down list on the left, select “Framework”) - “Frontend :: Customer” on the CustomerPanelCreateAccount select “No” and click on the “Update” button below. Here you can also correct the name of the organization that will be displayed at the bush meter in CustomerHeadline. There are a lot of other settings that can be twisted and tried, but this is later, now we are interested in integration with LDAP.
The OTRS integration with LDAP will be configured via the /opt/otrs/Kernel/Config.pm configuration file:
mcedit /opt/otrs/Kernel/Config.pm We find the line # insert your own config settings “here” # and insert the following config after it:
# LDAP # # LDAP # $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; # IP LDAP # $Self->{'AuthModule::LDAP::Host'} = '192.168.10.1'; # , LDAP # $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=domain,dc=ru'; # UID # $Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName'; # . OTRSagents OU organization # # , # $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=OTRSagents,ou=organization,dc=domain,dc=ru'; $Self->{'AuthModule::LDAP::AccessAttr'} = 'member'; $Self->{'AuthModule::LDAP::UserAttr'} = 'DN'; # LDAP # $Self->{'AuthModule::LDAP::SearchUserDN'} = 'otrs.admin@domain.ru'; $Self->{'AuthModule::LDAP::SearchUserPw'} = ' otrs.admin'; # LDAP# $Self->{'AuthModule::LDAP::AlwaysFilter'} = ''; $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, sscope => 'sub' }; # LDAP # # LDAP # # LDAP # $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP'; # IP LDAP # $Self->{'AuthSyncModule::LDAP::Host'} = '192.168.10.1'; # BaseDN # $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=domain, dc=ru'; # UID # $Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName'; # LDAP # $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'otrs.admin@domain.ru'; $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = ' otrs.admin'; # # $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = { UserFirstname => 'givenName', UserLastname => 'sn', UserEmail => 'mail', }; # # $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [ 'users', 'basic_admin', ]; # # # # # , HTTPBasicAuth # # HTTPBasicAuth # $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth'; # # $Self->{CustomerPanelLoginURL1} = 'http://helpdesk.domain.ru/otrs/customer.pl'; $Self->{CustomerPanelLogoutURL1} = 'http://helpdesk.domain.ru/otrs/customer.pl'; # # # LDAP # # # $Self->{CustomerUser} = { Module => 'Kernel::System::CustomerUser::LDAP', Params => { Host => '192.168.10.1', BaseDN => 'DC=domain,DC=ru', SSCOPE => 'sub', UserDN =>'otrs.admin@domain.ru', UserPw => ' otrs.admin', AlwaysFilter => '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))', SourceCharset => 'utf-8', DestCharset => 'utf-8', }, # # # , , # CustomerKey => 'sAMAccountName', CustomerID => 'mail', CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'], CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 10000, CustomerUserPostMasterSearchFields => ['mail'], CustomerUserNameFields => ['givenname', 'sn'], Map => [ # # # # # , : Login, Email CustomerID ! # [ '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' ], ], }; # # After that, you can save the file and try to log in as an agent under the domain account, which is included in the OTRSagents group in the domain.
Go to helpdesk.domain.ru/otrs/index.pl , enter the login and password of the domain account in the OTRSagents group. Should all ride. The newly logged agent will have no administration tab, you can enable it by logging in under the account of the original admin, in my case it is otrs.admin and having distributed access rights to the new agent.
Please note: agents are created in the OTRS database after the first login.
It is also necessary to check that OTRS pulled the Customers database from the LDAP. To do this, go to "Administration" - "Client Account" . Here we must see the full list of domain users in a table, login, name, email, etc.
Check whether everything successfully pulled up from the domain.
In order to access the Customers, a minor improvement is required, first of all, you need to enable Kerberos authentication on folders with scripts. The scripts are here / opt / otrs / bin / cgi-bin. .
Turning on Kerberos will require manipulations similar to those we performed in step 7 with the / var / www / html / php folder. Open the otrs virtual host config file:
mcedit /etc/apache2/site-available/otrs.conf And we see the following configurations of the location / otrs and directories / opt / otrs / bin / cgi-bin . The first piece:
<Location /otrs> # ErrorDocument 403 /otrs/customer.pl ErrorDocument 403 /otrs/index.pl SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders PerlOptions +SetupEnv <IfModule mod_version.c> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> <IfVersion >= 2.4> Require all granted </IfVersion> </IfModule> <IfModule !mod_version.c> Order allow,deny Allow from all </IfModule> </Location> And the second piece:
<Directory "/opt/otrs/bin/cgi-bin/"> AllowOverride None <IfModule mod_version.c> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> <IfVersion >= 2.4> Require all granted </IfVersion> </IfModule> <IfModule !mod_version.c> Order allow,deny Allow from all </IfModule> <IfModule mod_filter.c> <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/javascript application/javascript text/css text/xml application/json text/json </IfModule> </IfModule> # Make sure CSS and JS files are read as UTF8 by the browsers. AddCharset UTF-8 .css AddCharset UTF-8 .js # Set explicit mime type for woff fonts since it is relatively new and apache may not know about it. AddType application/font-woff .woff </Directory> At first glance, everything is very clear and simple, but again it was not possible to comprehend this shamanism with a swoop. In a nutshell, certain directives are connected here depending on the presence or absence of certain Apache modules or on their versions. The developers piled all this up because they did not know in advance what conditions the system would work with, which packages and which versions of these packages. But we are with you already absolutely certain which packages and which versions we have in the system. Therefore, just mercilessly cut out all unnecessary and bring these two blocks to the following form:
The first piece:
<Location /otrs> ErrorDocument 403 /otrs/index.pl SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders PerlOptions +SetupEnv AuthType Kerberos AuthName "Kerberos Authntication" KrbAuthRealms RUS.LOCAL Krb5Keytab /etc/httpd.keytab KrbMethodNegotiate On KrbSaveCredentials Off KrbVerifyKDC Off Require valid-user </Location> The second piece:
<Directory "/opt/otrs/bin/cgi-bin/"> AllowOverride All Options +ExecCGI -Includes AuthType Kerberos AuthName "Kerberos Authntication" KrbAuthRealms RUS.LOCAL Krb5Keytab /etc/httpd.keytab KrbMethodNegotiate On KrbSaveCredentials Off KrbVerifyKDC Off Require valid-user </Directory> Then we re-read Apache configs and restart it:
service apache2 reload service apache2 restart After these manipulations, when trying to access the OTRS scripts, Apache will try to authenticate the user and, if successful, will drive his login to the $ _ENV ['REMOTE_USER'] variable, from where the OTRS HTTPBasicAuth authentication module will find the user’s name, go through its database and if he finds such a user, This will open the Custome page in the logged-in form.
And everything seems to be nothing, here is just a Custom page, if we now try to enter it, tell us something completely strange, “Authorization was successful, but you could not find a user in the database.”
We are starting debugging. To do this, download a couple of scripts on pearl:
whoami.pl
test.pl
We drop them to the rest of the OTRS scripts in the / opt / otrs / bin / cgi-bin folder , expose them to the rights and the owner of the same one that is already there and try to open them in the browser.
The first script simply checks for the $ _ENV ['REMOTE_USER'] variable, and if there is something in it, it displays a message that we seem to be driven into the NT domain with such and such account, if it is, and it shows us the correct account, then everything is ok.
The second script shows us which line OTRS receives as user login. And it is here that we see that OTRS receives something like username@DOMAIN.RU , but we know that we use sAMAccountName as the login name , that is, just the username , without a domain, and in the list of Clients in the previous one stage, we also saw that we have logins without a domain name.
That's where the dog rummaged, so this situation happens, Apache worked, authorization was successful and everything was OK, but OTRS could not find the user in its database. It turns out that we need to somehow throw out the domain name from the user name before searching it in the OTRS database.
The blessing to fix it is quite simple, although while I figured out how, it took decently time and effort.
To do this, again go to the Agent interface, “Administration” - “System Configuration” - “Framework” - “Frontend :: Customer :: Auth” , find the parameter Customer :: AuthModule :: HTTPBasicAuth :: ReplaceRegExp , enable it, and in the for input we leave what is there, for those who erased the default, there should be such a regular
^(.+?)@.+?$
Unfortunately, regular expressions on Perle remain for me inaccessible magic and transcendent shamanism, so I cannot explain how it works (I will be extremely grateful if anyone gives explanations in the comments, and I will gladly add it to the article) But in a nutshell, it discards everything on behalf of the user after the “@” symbol inclusively.
Click "send" at the bottom of the page and stamp to the address of the Customer interface: helpdesk.domain.ru/otrs/customer.pl
Everything should work.
UPD.
Regarding the magic of regular expression:
^(.+?)@.+?$
Everything turned out to be very simple, as they explained to me "compared to the magic of the regulars, this is so, a children's seance" (c).
symbol ^ - the beginning of the processed string
the $ character is the end of the string
Symbols () - show that as a result of processing you need to leave what is between them
? - any character
. + - recursive concatenation (as a result, the expression '. +?' - literally means any string)
The @ symbol is not a special character, therefore it is processed as part of a line (surprisingly, I never would have thought, I always thought that it was just a special character and needed to be escaped, just the absence of such an escape made me astray and prevented myself from understanding this expression )
And as a result, we get that the regular partition breaks the resulting string into two parts “everything before the @ character” and “everything after the @ character” and returns the first part (as it is in parentheses).
MA-A-A-A-A-Giya
Source: https://habr.com/ru/post/265537/
All Articles