OTRS 4.0.10. Ставим на Ubuntu + AD + Kerberos + SSO (Часть вторая)

    Продолжаю повествование о том, как собственно установить сего зверя на Ubuntu и настроить прозрачную доменную авторизацию, плюс о том, как прикрутить некоторые приятные плюшки, доступные в бесплатной версии OTRS.

    Часть первая: подготовка системы
    Часть вторая: установка и настройка OTRS
    Часть третья: исправляем косяки прикручиваем плюшки

    6. Установка и настройка OTRS


    Ну вот, система полностью подготовлена, даже более чем и мы с чистой совестью и легким сердцем приступаем к установке непосредственно OTRS.

    6.1. Суть предлагаемого метода и необходимые пакеты

    Ставить мы будем последнюю стабильную версию, на данный момент это 4.0.10, на самом деле это не существенно, потому как мы изначально пошли канонически правильным путем и не стали использовать всякие прокладки и костыли типа адамтеров NTLM, SSPI и прочего, а подняли полноценную Kerberos аутентификацию. А за неё в OTRS отвечает модуль HTTPBasicAuth, который не претерпел существенных изменений, поэтому описываемый способ будет работать на всех версиях системы начиная как минимум с 3.1.1.

    В чем собственно суть способа? А вся суть заключается в том, что OTRS вообщем то и не проводит никакой авторизации и аутентификации пользователя, а просто берёт имя залогиневшегося пользователя из переменной окружения $_ENV['Remote_User'] ищет его в своей базе и если находит, то открывает для него интерфейс Кустомера в залогиненом виде. То есть вся нагрузка по верификации пользователя ложится на плечи Apache, который механизмом Kerberos аутентифицирует пользователя и если ему это удалось, то загоняет его логин в переменную окружения. Откуда его и подхватывает OTRS, считая, что если там что-то есть, то аутентификация уже прошла успешно. Итак, приступим.



    Отличная статья по этому поводу вот тут. Очень подробно описан процесс установки.

    Всё, что касается доменной авторизации и сквозной аутентификации, собрано с миру по нитке и выработано методом проб и ошибок, так что ссылок никаких дать не могу.

    Вот перечень пакетов, которые потребуются нам на этом этапе:
    • 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

    Большинство из них уже стоят в системе или мы их уже поставили, но что-бы не перебирать каждый, просто дадим команду поставить все, те что уже есть просто будут пропущенны менеджером пакетов и всё. Так что исполняем
    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. Ставим OTRS

    Как уже сказано выше ставить мы будет версию 4.0.10, последнюю на момент написания статьи. Качаем сам OTRS:
    cd ~
    wget http://ftp.otrs.org/pub/otrs/otrs-4.0.10.tar.gz
    

    Распаковываем архив:
    tar zxf ./otrs-4.0.10.tar.gz 
    

    Перемещаем распакованный OTRS папку /opt:
    mv ./otrs-4.0.10 /opt 
    

    И создаем симлинк на него в этой же папке:
    ln -s /opt/otrs-4.0.10/ /opt/otrs 
    

    Проверяем все ли модули мы поставили:
    perl /opt/otrs/bin/otrs.CheckModules.pl
    

    Если нужны какие то дополнительные модули ставим (в выводе предыдущей команды напротив каждого модуля есть подсказка как его установить, если его нет). Заводим пользователя для OTRS:
    useradd -r -d /opt/otrs/ -c 'OTRS user' otrs
    

    И включаем его в группу www-data:
    usermod -g www-data otrs
    

    Имейте ввиду: наша машина включена в домен и winbind биндит всех пользователей в локальную базу пользователей, поэтому надо проследить, что бы в домене не было пользователя с логином «otrs». Если он есть — удаляем его и перезагружаем линукс-машину.

    Создаем дефолтные конфиги для OTRS:
    cd /opt/otrs/Kernel
    cp Config.pm.dist Config.pm
    cp Config/GenericAgent.pm.dist Config/GenericAgent.pm
    

    И настраиваем права свеже созданному пользователю:
    cd /opt/otrs
    bin/otrs.SetPermissions.pl --otrs-user=otrs --web-group=www-data /opt/otrs
    

    Осталось создать vhost Апача для OTRS и можно конфигурировать систему:
    cp /opt/otrs/scripts/apache2-httpd.include.conf /etc/apache2/sites-available/otrs.conf 
    

    Включаем vhost OTRS:
    a2ensite otrs
    

    И перечитываем конфиги Apache:
    service apache2 reload
    

    Всё. Установка закончена, теперь можем занятся конфигурацией OTRS.

    6.3. Начальное конфигурирование системы OTRS. Интеграция с LDAP (в нашем случае AD)

    Начальное конфигурирование системы происходит через веб-интерфейс. Заходим по адресу helpdesk/otrs/installer.pl, видим мастер установки OTRS:



    Жмем далее и видим лицензионное соглашение, внимаааательно его читаем и жмем «принят условия».



    На третьем этапе надо выбрать используемую базу данных, в нашем случае база MySQL, так что жмем далее. Тут уже поинтереснее, надо ввести логин того самого пользователя MySQL root@localhost, этот пароль мы создавали на шаге 6, когда ставили Apache и MySQL сервер.

    OTRS попробует подключиться к серверу баз данных (localhost) и если всё нормально — создаст для себя базу с именем otrs и пользователем otrs, а так же с очень хитрым паролем, его мы тоже запоминаем куда ни будь в блокнотик, на всякий случай.



    Настраиваем почту. На выходе OTRS сообщит пароль дефолтного пользователя root@localhost, запоминаем его пароль.

    Переходим по ссылке «главная страница» и видим приглашения залогиниться, вот сюда-то и вводим только записанные логин и пароль. По большому счёту установка OTRS уже закончена, но нам ведь этого мало и не для того мы столько возились с Kerberos, нам нужна интеграция с AD и сквозная аутентификация, поэтому идем дальше.

    А дальше обращаемся к мануалу уважаемого rasa. Кое-что мы почерпнём оттуда, кое-что из интернета, и выдумаем свой путь.

    Итак для начала. В домене, должен быть один пользователь который полностью совпадает с администратором OTRS, он у нас будет и LDAP читать и остальных админов OTRS мы через него заведём. В моём случае это пользователь otrs.admin, кстати, на период установки я давал ему права администратора домена и все манипуляции на домене, как то включение машины в домен, получение тикетов и пр. проводил от имени именно этого пользователя, после установки эти права у него можно отобрать, более того, запретить ему логиниться на машины домена, ему надо только читать информацию из LDAP, не более того.

    И так, в интерфейсе Агента OTRS, переходим на вкладку «Администрирование», заходим в раздел «агенты» видим единственного агента, жмём на него и меняем его учетные данные в соответствии с данными пользователя в домене, как я уже сказал выше, в моём случае это логин otrs.admin и соответствующий ему доменный пароль, жмем «отправить» внизу страницы и пробуем выйти и зайти снова уже с новыми учетными данными.

    ! ВНИМАНИЕ! совпадать с данными доменного пользователя должен не только логин, но и пароль!

    Теперь отключим возможность самостоятельной регистрации кустомеров. «Администрирование»-«Конфигурация системы»-(в выпадающем списке слева выбираем «Framework»)-«Frontend::Customer» на CustomerPanelCreateAccount указываем «Нет» и жмем внизу кнопку «Обновить». Тут же можно поправить название организации которое будет высвечиваться у кустомеров в CustomerHeadline. Здесь ещё куча других настроек, которые можно будет покрутить и попробовать, но это позже, сейчас нас интересует интеграция с LDAP.

    Настройка интеграции OTRS с LDAP будет происходить через конфигурационный файл /opt/otrs/Kernel/Config.pm:
    mcedit /opt/otrs/Kernel/Config.pm
    

    Находим строчку # insert your own config settings «here» # и вставляем после неё вот такой конфиг:
    # Настройки 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' ], 
    ], 
    }; 
    # Конец конфига #
    

    После этого можно сохранить файл и попробовать авторизоваться в качестве агента под доменной учёткой, которая входит в группу OTRSagents в домене.

    Переходим по адресу helpdesk.domain.ru/otrs/index.pl, вводим логин и пароль доменной учётной записи состояще в группе OTRSagents. Должно всё прокатить. У вновь залогинившегося агента будет отсутствовать вкладка администрирования, включить её можно войдя под учёткой изначального админа, в моём случае это otrs.admin и раздав права доступа новому агенту.

    Обратите внимание: агенты создаются в базе OTRS после первого входа.

    Так же надо проверить, что OTRS подтянул из LDAP базу Кустомеров. Для этого переходим «Администрирование» — «Учётная запись клиента». Тут мы должны увидить полный перечень пользователей домена в табличном виде, логин, имя, email и т.д.

    Проверяем, всё ли успешно подтянулось из домена.

    Для доступа же Кустомеров потребуется ещё небольшая доработка, прежде всего потребуется включить Kerberos аутентификацию на папках со скриптами. Скрипты лежат тут /opt/otrs/bin/cgi-bin..

    Для включения Kerberos потребуются манипуляции аналогичные тем, что мы проводили на шаге 7 с папкой /var/www/html/php. Открываем файл конфига виртуального хоста otrs:
    mcedit /etc/apache2/site-available/otrs.conf
    

    И видим следующие конфигурации локейшена /otrs и директории /opt/otrs/bin/cgi-bin. Первый кусок:
    <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>
    

    И второй кусок:
    <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>
    

    На первый взгляд всё очень ясно и просто, но опять же постигнуть это шаманство с наскоку не удалось. В двух словах тут подключаются определенные директивы в зависимости от наличия или отсутствия определенных модулей Apache или же от их версий. Всё это разработчики нагородили потому как им заранее не извество в каких условиях будет работать система, с какими пакетами и какими версиями этих пакетов. Но нам-то с вами уже абсолютно точно известно какие пакеты и каких версий стоят у нас в системе. Поэтому просто нещадно вырезаем всё лишнее и приводи эти два блока к следующему виду:

    Первый кусок:
    <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>
    

    Второй кусок:
    <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>
    

    После чего перечитаем конфиги Апача и перезапустим его:
    service apache2 reload
    service apache2 restart
    

    После этих манипуляций, при попытке доступа к скриптам OTRS Apache попытается аутентифицировать пользователя и если успешно — загонит его логин в переменную $_ENV['REMOTE_USER'], откуда модуль аутентификации OTRS HTTPBasicAuth, считает имя пользователя, прошерстит свою базу и если найдет такого пользователя, то откроет страницу Кустомера в залогинененом виде.

    И всё вроде бы ничего, вот только страница Кустомера, если мы сейча попытаемся на неё зайти, скажет нам совсем странную вешь, «Авторизация прошла успешно, но не удалось найти пользователя в базе».

    Начинаем отладку. Для этого скачиваем пару скриптов на перле:
    whoami.pl
    test.pl

    Забрасываем их к остальным скриптам OTRS в папку /opt/otrs/bin/cgi-bin, выставляем им права и владельца аналогичного тем, что там уже лежат и пробуем их открыть в браузере.

    Первый скрипт просто проверяет наличие переменной $_ENV['REMOTE_USER'] и если в ней что-то есть, то выводит сообщение о том, что мы кажется загонились в домене NT c такой-то учёткой, если так и есть, и он показывает нам правильную учётку, то всё ок.

    Второй скрипт показывает нам какую строку получает OTRS в качестве логина пользователя. И вот тут-то и видим, что OTRS получает что-то типа username@DOMAIN.RU, но мы то знаем, что в качестве логина у нас используется sAMAccountName, то есть просто username, без домена, да и в списке Клиентов на предыдущем этапе мы так же видели, что логины у нас без имени домена.

    Вот где собака порылась, поэтому то и происходит такая ситуация, Apache отработал, авторизация прошла успешно и всё ок, а вот OTRS найти пользователя в своей базе не смог. Получается что нам надо как-то выкинуть из имени пользователя домен перед поиском его в базе OTRS.

    Благо поправить это совсем просто, хотя пока я разобрался как, ушло прилично сил и времени.

    Для этого опять идем в интерфейс Агента, «Администрирование» — «Конфигурация системы» — «Framework» — «Frontend::Customer::Auth», находим параметр Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp, включаем его, а в поле для ввода оставляем то что там есть, для тех кто стёр значение по умолчанию, там должна быть вот такая регулярка
    ^(.+?)@.+?$

    К сожалению регулярные выражения на Perle остаются для меня недоступной магией и запредельным шаманством, поэтому не могу пояснить как оно работает (буду крайне признателен, если кто ни будь даст пояснения в комментах, и я с удовольствием добавлю его в статью) Но в двух словах, оно отбрасывает от имени пользователя всё что после символа «@» включительно.

    Жмём «отправить» внизу страницы и топаем по адресу интерфейса Кустомера: helpdesk.domain.ru/otrs/customer.pl
    Всё должно работать.

    UPD.


    По поводу магии регулярного выражения:
    ^(.+?)@.+?$

    Всё оказалось очень просто, как мне пояснили «по сравнению с магией регулярок это так, детский спиритический сеанс» (с).
    символ ^ — начало обрабатываемой строки
    символ $ — конец обрабатываемой строки
    Символы () — показывают что в результате обработки нужно оставить то, что находится между ними
    ? — любой символ
    .+ — рекурсивная конкатенация (в результате выражение '.+?' — дословно означает любая строка)
    Символ @ — не является специсмволом, поэтому обрабатывается как часть строки (удивительно, никогда бы не подумал, всегда считал что он как раз таки спецсимвол и его нужно экранировать, как раз остутствие такого экранирования и ввело меня в заблуждение и помешало самому разобраться в этом выражении)

    И в результате получаем, что регулярка разбивает полученную строку на две части «всё что до символа @» и «всё что после символа @» и возвращает первую часть (так как она в скобочках).

    МА-А-А-А-А-гия
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 18

      0
      Осталось только напомнить о тонкой лицензионной политики MS и использованию AD через сторонние средства.
      те надо помнить про стандартные Windows Server CAL.

      и

      Лицензирование при подключении через промежуточное звено («мультиплексор»)

      более подробно тут www.microsoft.com/ru-ru/licensing/Products/cla.aspx

      Просто хочу предупредить, так как сами напоролись при написание своей системы документооборота с авторизацией через AD.
        0
        Мне кажется вы что-то путаете, на сколько я понимаю модель лицензирования мелкомягких, а совсем недавно мы приобретали SQLServer 2014 и пришлось основательно покопать в этом направлении, в данном случае CAL непричем, клиент не получает никаких данных от продукта и из его баз данных (в нашем случае контролоер АД). Тут можно только сам сервер Апач притянуть за уши как клиента и только. Но и в этом случае смутно. Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
        По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
          0
          Как раз ваш апач и выступает в роли мультиплексора. Пользователей же вы берете из AD?
          те получается цыпочка

          клиент>apache/kerberos>Domain Controller?

          Если подключение к серверу Microsoft происходит не напрямую, а через промежуточное звено («мультиплексор») – программное или аппаратное обеспечение, которое уменьшает количество прямых подключений к серверу – то правила лицензирования не меняются. Клиентские лицензии CAL требуются для каждого устройства /пользователя, работающего с мультиплексором.

          Например, ERP-система, обращающаяся к SQL-серверу, является таким мультиплексором. Т.е. подключения происходят не непосредственно к СУБД SQL, а опосредованно – через ERP-систему, а к SQL идет только одно прямое подключение – от ERP. Соответственно, компании необходимо приобрести клиентские лицензии на доступ к SQL (SQL Server CAL) по числу пользователей такой ERP-системы.


          Для IIS если мне не изменяет память, если не прошли авторизацию AD (те анонимны) — лицензия не требуется.
          Вообще с таким вопросом лучше обратится к грамотному интегратору или написать письмо в MS. При этом надо понимать, что это вопрос чисто юридический. Технически ограничений нет.

          Сам я сейчас то же особо много чего не скажу, это было уже 4 года назад и детали не особо помнятся.
          Но нужно помнить, что есть такая особенность — особенно если мы хотим быть лицензионно честны.
            0
            >Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
            Для клиентов в стандартной поставке server обычно идет или 5 или 10 cal лицензий. На каждого следующего в организации, если он обращаться к домену надо покупать лицензию. Если вы получаете данные с linux машин(ы), на нее то же надо лицензию + на всех клиентов если она используется как мультиплексор.

              0
              А, вы об этом. Тогда вопрос снят, у нас 5 штук Win2008R2 Interprise Edition лицензированные на ядра. Так что тут траблов не наблюдается.
                0
                По крайней мере в microsoft сказали что ограничений по кол-ву пользователей у нас нет.
                  0
                  Ограничений естественно нет, это вопрос лицензирования.
            0
            Да и в целом, статья не про лицензирование, а про настройку определённой системы в связке с АД, а как лицензировать пользователей в АД это уже личное дело каждого…
              0
              Я думаю лишнем это не будет, так как мало кто об этом задумывается до проверки, а потом как правило уже поздно.
            0
            Как удалось назначить сервисы для кастомеров притянутых из АД? Что происходит при добавлении нового юзера в АД, как назначается ему сервис?
              0
              Сервисы пока не назначали, да и вряд ли будем, у нас всего три очереди получается пока что, и все кастомеры имеют доступ к этим очередям. Но в остальном принцип работы должен остаться таким же как при работе с пользователями в базе. Никакой разницы быть не должно.
              0
              а SSO для агентов реализовать пробовали?
                0
                Пробовал. Никаких проблем, но делов том, что модуль HTTPBasicAuth, не предполагает какую ли бо проверку на наличие пользователя в определённом OU в домене, а значит любой Кастомер сможет быть и Агентом. Ему достаточно не ввести в конце адреса customer.pl (или стереть это окончание в адресной строке) и у него откроется залогиненый интерфейс агента (что как вы понимаете не есть гут.)

                Хотя чисто теоретически можно допилить уже Apache и Kerberos, что бы они занимались подобной фильтрацией, кому можно открывать index.pl и customer.pl, а кому только customer.pl. Подобный функционал есть. Даже знаю к каком направлении копать.
                  0
                  я ограничиваю вот так

                  /etc/apache2/sites-available/otrs.conf

                  <Location /otrs>

                  #Require valid-user
                  Require user test@DOMAIN.LOC test1@DOMAIN.LOC


                  щас играюсь с параметром
                  Require ldap-group

                    0
                    Всё верно, именно в это направлении я и хотел предложит поковырять. Если вас не напрягает добавлять сюда всех агентов и следить за актуальностью списка, то как решение вполне подходит.
                      0
                      решилось добавлением этих строк

                      AuthLDAPUrl ldap://dc.**********.local/DC=*******,DC=local?userPrincipalName
                      AuthLDAPBindDN CN=otrs,OU=IT,OU=users,OU=all,DC=******,DC=local
                      AuthLDAPBindPassword "********"
                      Require ldap-group CN=otrs-agent,OU=IT,OU=users,OU=all,DC=********,DC=local

                      теперь в АД в группу добавляем агентов
                        0
                        Как вариант, вполне и вполне. Получается, что апача авторизуется на ЛДАП с помошью учётки otrs@******.local и проверяет состоит ли пользователь в группе.
                0
                Создаете ещё один блок
                <Location /otrs/index.pl>
                бла-бла-бла про аутентификацию керберос
                Require ldap-group OTRSAgents


                Что-то типа такого

                Only users with full accounts can post comments. Log in, please.