web-dev-qa-db-ja.com

OTRS6-AD統合-OTRS管理者としてではなくエージェントとしてマッピングされたドメイン管理者ユーザー

私はITSMモジュールでOTRS6をテストしています。現在、私はDEV環境でのみテストしているので、最も簡単な方法であれば、すべてを捨てて最初から始めることは問題ではありません。私はそれをすぐに生産に移すつもりです、トー。

公式ドキュメントを使って「本で」インストールしましたが、とても魅力的でした！ （[〜＃〜] edit [〜＃〜]：Ubuntu Server 18.04 LTSにインストールされています）MySQLのユーザーデータベースを使用してローカルで認証するすべてのユーザーがいます。顧客、エージェント、および管理者全員が認証でき、正しいユーザーパネルが表示されました。

その後、OTRSをADとうまく統合することができましたが、キャッチがあります：すべてのADユーザーは顧客としてマップされ、すべてのドメイン管理者（OTRS_Admins ADグループにも属している）はエージェントであり、... .OTRSを管理するためのアカウントがありません。管理者はいません。

私は何をすべきか？ドメイン管理者をエージェントではなくOTRS管理者にマッピングするにはどうすればよいですか？一部のドメインユーザーをエージェントにマッピングするにはどうすればよいですか？私は何か間違ったことをしていますか？私は完全に迷子になっています。

公式のドキュメントはそれほど役に立ちません、そして私はグーグルで私の特定の必要性を持っている人を見つけることができませんでした。

私の（編集された）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' ],
    ],
    };
linuxactive-directoryldapubuntu-18.04otrs
1
Henrique

実際、これは3つの部分からなる問題です。

  1. LDAPバックエンドを使用したときに、DBバックエンドからユーザーを失いました（root @ localhostスーパーユーザーを含む）
  2. LDAPバックエンドのエージェントユーザーには管理者権限がありませんでした
  3. OTRSドキュメントはあちこちで少し時代遅れです

問題1：DBバックエンドが失われましたConfig.pmで、エージェントバックエンドを選択するために次の行を挿入しました。

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

さて、この行が何をするか、それはオーバーライドシステムの他の場所にある元のバックエンドセレクターです。したがって、DBバックエンド管理ユーザーとLDAPエージェントユーザーを含めるには、OTRS独自の（そして文書化された！）方法を使用して、モジュールインスタンスに数字のサフィックスを追加する複数のバックエンドを作成する必要があります（de-に注意してください） 1AuthModuleの直後）：

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

もちろん、モジュールのすべてのプロパティに数字を入力する必要があります。

$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'
                };

（これを、元の質問で上記に投稿されたコードと比較してください。）

公平を期すために、これらは、バックエンドを変更する方法と、複数のバックエンドを持つ方法を説明するOTRS管理マニュアルのセクションです。ただし、$Self->{'AuthModule'}の代わりに$Self->{'AuthModule1'}を使用すると、両方を並べて実行するのではなく、ネイティブDBバックエンドをオーバーライドするという情報が欠落しています。これを理解するために多くの死んだ脳の問題を取りました。

これにより、すべて元のDBバックエンドに含まれていた管理者ユーザーが失われるという問題が解決されました。すべてのLDAPエージェントは完全な管理者ではなかったので、彼らはチケットに答えることはできたが、管理者としてOTRSシステムを管理することはできなかった。これで私は両方の種類のユーザーがいました。

それが2番目の問題につながります。

問題2：LDAPバックエンドのエージェントユーザーに管理者権限がありませんでした

つまり、私は必須 ADでエージェントユーザーを作成でき、そのユーザーも管理者になることができるはずです。そして彼らは！

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

'users'だけでなく、 'basic_admin'もそのリストに追加した場合、最初のエージェントはすべてAdminsにもなります。後で彼らの管理者権限を取り消すことができましたが、問題1のために管理者ユーザーがいない状態でOTRSの外部にロックされていたため、誰にも管理者権限を付与または取り消すことができませんでした。

結局のところ、私はそれをそのままにして、エージェントを単なるユーザーとして作成することを選択しました。これは、元のroot @ localhostユーザーが管理者として既に存在し（問題1を解決したため）、すべてのユーザーに手動で管理者権限を付与するためです。私の将来の管理者。しかし、これはOTRS管理マニュアルにあまりよく文書化されていないもう1つの詳細です。

問題3：OTRS管理マニュアルが完全に最新ではない

私は、すべてのオープンソースプロジェクトで、これが時々発生することを理解しています。しかし、ここやいたるところに、更新されていない以前のバージョンのOTRSから継承された、誤解を招く情報によるいくつかの落とし穴があります。たとえば、マニュアルに記載されているがバージョン6では無効なプロパティがいくつかあります。

バージョン5用で、バージョン6から削除されていないものに出くわしました。つまり、ページ（およびプロパティ）がもう存在しないため、プロパティのQuickRefページへのリンクが削除されましたが、それでも他の場所で言及されていますマニュアルの重要な構成セクション。

1
Henrique