2

I am testing OTRS 6 with the ITSM module. Right now I'm only testing it on our DEV environment, so it would not be a problem to ditch everything and start from scratch if it's the easiest way. I intend to put it to production soon, tho.

I installed it "by the book" using the official docs and it worked like a charm! (EDIT: Installed on Ubuntu Server 18.04 LTS) I have all users authenticating locally using the User Database on MySQL. I had Customers, Agents and Admins all able to authenticate and being presented with the correct user panel.

After that, I have been able to successfully integrate OTRS with my AD, but with a catch: all my AD users are mapped as Customers, all my Domain Admins (who also belong to the OTRS_Admins AD Group) are Agents, and.... I'm left with no account to manage OTRS. No Admins at all.

What should I do? How can I map my Domain Admins to be OTRS Admins and not Agents? How to map some of my Domain Users to be Agents? Am I doing something wrong? I'm completely lost.

The oficial docs don´t help that much, and I couldn't find on Google anyone with my specific need.

My (redacted) Config.pm:

     $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';


        ### OTRS Admin Auth
        ### 
        $Self->{'AuthModule::LDAP::Host'} = '192.168.179.2';     # AD Server
        $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=test,DC=local'; # Domain
        $Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
        $Self->{'AuthModule::LDAP::GroupDN'} = 'CN=OTRS_Admins,CN=Users,DC=test,DC=local';   #OTRS Admin group
        $Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
        $Self->{'AuthModule::LDAP::UserAttr'} = 'DN';
        $Self->{'AuthModule::LDAP::SearchUserDN'} = 'svc_otrs'; #OTRS service user
        $Self->{'AuthModule::LDAP::SearchUserPw'} = 'Passw0rd'; #And its passwird
        $Self->{'AuthModule::LDAP::AlwaysFilter'} = '';
        $Self->{'AuthModule::LDAP::Params'} = {
                          port => 389,
                          timeout => 120,
                          async => 0,
                          version => 3,
                          sscope => 'sub'
                        };

        ### User Sync
        ### AD <==> DB OTRS (MySQL)
        $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';
        $Self->{'AuthSyncModule::LDAP::Host'} = '192.168.179.2';      # AD SRV
        $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=test,DC=local'; # Domain
        $Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName';
        $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'svc_otrs';         
        $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'Passw0rd';    
        $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
        # DB -> LDAP
        UserFirstname => 'givenName',
        UserLastname => 'sn',
        UserEmail => 'mail',
        };

        $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
        'users', 'basic_admin',
        ];
  $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
    $Self->{'Customer::AuthModule::LDAP::Host'} = '192.168.179.2';
    $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=test,DC=local';    
    $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
    $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'svc_otrs';     
    $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'Passw0rd';     
    $Self->{CustomerUser} = {
    Module => 'Kernel::System::CustomerUser::LDAP',
    Params => {
    Host => '192.168.179.2',     # AD Server
    BaseDN => 'dc=test,DC=local',      #Domain
    SSCOPE => 'sub',
    UserDN =>'svc_otrs',     #OTRS Service User
    UserPw => 'Passw0rd',    #its password
    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 => [
    # note: Login, Email and CustomerID needed!
    #[ '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' ],
    ],
    };
2

In fact this is a three-part problem:

  1. When I used the LDAP backend, I lost my users from the DB Backend (including the root@localhost superuser)
  2. Agent users from the LDAP backend didn't have Admin permissions
  3. OTRS Documentation is a little outdated here and there

Problem 1: lost my DB Backend In Config.pm, I had inserted the following line to select the Agent backend:

$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';

Well, what this line does, it overrides the original backend selector elsewhere in the system. So, in order to have the DB Backend Admin users and also the LDAP agent users, you should use OTRS' own (and documented!) way to have multiple backends, which is appending a numeral suffix to the module instance (please note de 1 right after AuthModule):

$Self->{'AuthModule1'} = 'Kernel::System::Auth::LDAP';

Of course, you have to put the numeral in all of the modules' properties:

$Self->{'AuthModule::LDAP::Host1'} = '192.168.xx.xx';    
$Self->{'AuthModule::LDAP::BaseDN1'} = 'dc=test,DC=local'; 
$Self->{'AuthModule::LDAP::UID1'} = 'sAMAccountName';
$Self->{'AuthModule::LDAP::GroupDN1'} = CN=GS_OTRS_Agents,CN=Users,DC=test,DC=local';
$Self->{'AuthModule::LDAP::AccessAttr1'} = 'member';
$Self->{'AuthModule::LDAP::UserAttr1'} = 'DN';
$Self->{'AuthModule::LDAP::SearchUserDN1'} = 'OTRS';    #OTRS LDAP User
$Self->{'AuthModule::LDAP::SearchUserPw1'} = 'somepass'; #Password for the LDAP User
$Self->{'AuthModule::LDAP::AlwaysFilter1'} = '';
$Self->{'AuthModule::LDAP::Params1'} = {
                  port => 389,
                  timeout => 120,
                  async => 0,
                  version => 3,
                  sscope => 'sub'
                };    

(Compare this to the code posted above, on the original question.)

To be fair, ther is a section on the OTRS Admin Manual explaining how to change de backend, and how to have more than one backend. But the information that if you use $Self->{'AuthModule'} instead of $Self->{'AuthModule1'} would override the native DB Backend, instead of running both side by side, is missing. Took a lot dead brain matter to figure this out.

This solved the problem of having lost my Admin users, who were all in the original DB Backend. All the LDAP Agents were not full admins, so they could answer tickets but not manage the OTRS system as admins. With this I had both kinds of users.

That leads us to the second problem.

Problem 2: Agent users from the LDAP backend didn't have Admin permissions

I mean, I must be able to create an Agent user on my AD and he/she should be able to be admins too. And they are!

`$Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
'users',
];`

If instead of just 'users', I had put also 'basic_admin' on that list, all my initial Agents would be also Admins. I could revoke their Admin priviledges later, but as I was locked outside OTRS with no Admin users due to problem 1, I couldn't grant or revoke any adminright to anyone.

I chose, after all, to leave it at it is, and create my Agents as just users, because I already have my original root@localhost user as admin (as I have solved Problem 1), and will grant admin rights manuyally for all my future admins. But this is another not very well documented detail on the OTRS Admin Manual.

Problem 3: OTRS Admin Manual not completely up to date

I understand that, with all OpenSource projects, this would happen from time to time. But there are, here there and everywhere, some pitfalls due to misleading information, inherited from previous versions of OTRS that were not updated. There are some properties, for example, that are mentioned in the manual but are not valid for version 6.

I stumbled upon one that was for version 5 and was not purged from version 6. I mean, the link to the properties' QuickRef page was removed, because the page - and the property - does not exist anymore, but it is still mentioned elsewhere in the manual, on important configuration sections.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.