Linux настройка доменной аутентификации
Обновлено: 04.07.2024
Мне понадобилось настроить авторизацию доменный учетных записей Active Directory по ssh на linux сервер. В моем случае это будет система CentOS 7. Данная возможность будет очень удобна для организаций с внедренной доменной структурой Windows. С помощью групп доступа в AD вы сможете централизованно управлять доступом к linux серверам.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Подготовка сервера
Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему - установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду каcаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.
| xs.local | название домена |
| 10.1.3.4 | ip адрес контроллера домена |
| xs-winsrv.xs.local | полное имя контроллера домена |
| xs-centos7-test | имя сервера centos, который вводим в домен |
| administrator | учетная запись администратора домена |
| gr_linux_adm | группа в AD, для которой разрешено подключение к серверам по ssh |
| lin-user | учетная запись в AD для проверки подключений по ssh |
Настроим синхронизацию времени с контроллером домена. Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса.
Устанавливаем утилиту для синхронизации времени chrony:
Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.
Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.
Проверим, что с синхронизацией.
Все в порядке. Синхронизировали время с контроллером домена. По логу видно, что время на сервере убежало вперед на 56 минут, но мы это исправили.
Подключение CentOS 7 к домену
Устанавливаем софт, который нам понадобится, для корректного ввода centos в домен windows.
Вводим Centos 7 в домен:
Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.
Изменим немного конфиг sssd для того, чтобы не нужно было вводить полное имя домена при логине, а только username.
Разрешаем доменным пользователям создавать домашние директории:
Запускаем службу sssd и добавляем в автозагрузку:
Ограничение доступа ssh по группам и пользователям домена
На текущий момент подключиться к серверу может любой пользователь домена. Исправим это и разрешим подключаться только пользователям из группы gr_linux_adm. Для этого правим конфиг /etc/sssd/sssd.conf, добавляя туда новые параметры.
Обращаю внимание, что параметр access_provider у вас уже будет установлен в другое значение. Надо это изменить. Вы можете добавить разрешение как для конкретного пользователя, так и для целых групп. Сохраняйте конфиг и перезапускайте sssd.
Теперь подключиться по ssh к серверу сможет только пользователь домена user55 и все члены группы gr_linux_adm.
Для разбора полетов и решения проблем нужно использовать лог файл - /var/log/secure. Вот пример успешного подключения:
А вот кусок лога подключения доменного пользователя, для которого доступ по ssh закрыт.
Здесь видно, что идентификация пользователя прошла корректно, но доступ к серверу запрещен.
Ограничение доступа к sudo по доменным группам
Ограничение доступа к ssh по группам и пользователям настроили, теперь надо разрешить доменным учетным записям получать права суперпользователя в системе. Сейчас у них нет такой возможности.
Создаем новый файл в директории /etc/sudoers.d.
Обращаю внимание, что имя данного файла не должно содержать точки. Я сначала не знал об этом и сделал файл с именем xs.local и долго не мог понять, почему не работает. Когда изменил имя файла, все заработало.Выставляем минимальные права на файл:
Теперь вы можете зайти в систему доменной учетной записью из группы gr_linux_adm и получить полные права в системе.
Реализовать то же самое можно было через настройки sssd. В его конфиге можно было указать группы, которым разрешен доступ к sudo. Но в целом это не принципиально. Так, как сделал я, мне показалось проще. Не нужно использовать полные имена объектов в AD, в которых легко запутаться, особенно тем, кто не очень в этом ориентируется. Мне же понадобились только конечные имена групп. Более подробно об этом можно почитать в руководстве redhat. Ссылку приведу в конце.
Заключение
На этом все. Я рассмотрел наиболее типовую ситуацию, которая может быть полезной при использовании структуры AD совместно с linux серверами. При написании статьи использовал официальные руководства:
Почему-то из руководства по RHEL 7 раздел, посвещенный SSSD убрали, хотя в 5 и 6 есть. Может просто я не заметил, так как структура сильно поменялась. Люблю я CentOS в первую очередь за отличную документацию Redhat. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.
Онлайн курс Infrastructure as a code
- Познакомитесь с Terraform.
- Изучите систему управления конфигурацией Ansible.
- Познакомитесь с другими системами управления конфигурацией - Chef, Puppet, SaltStack.
- Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
- В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.Автор Zerox
48 комментариев
а с помощью этого способа заработает доменная авторизация для сервера 1с установленного на этом же centos?
Скорее всего нет. С 1С решать вопрос нужно будет отдельно. Я не знаю как, не занимался никогда.
а ограничил доступ группами ADDS, используя фильтр
ad_access_filter = (|(memberOf=cn=sudoers,ou=IT DEP,dc=example,dc=com)(memberOf=cn=sshers,ou=IT DEP,dc=example,dc=com))
где sudoers и sshers - имена групп, "IT DEP" - контейнер, в котором эти группы размещены. В общем, это полные distinguishedName этих групп, перечисленные через "или" - символ "|" сразу за первой скобкой.
Я не помню точно подробностей, но есть настройка на тему того, где проверять учетные записи. Сначала там должны быть указаны локальные учетки, потом все остальные. Кажется в /etc/nsswitch.conf.
Почему тут используется не полное название домена, а просто xs?
Не помню уже, но у меня работало с такими настройками.
Имя файла значения не имеет. Это просто файл. Как я понял, демон просто просматривает все файлы в директории, и считывает их. А имена - по боку.
С чем может быть связана эта ошибка сразу после realm join ?
Помогло добавление вручную этого компьютера в AD.
После этого realm join сработал.
Сорри, а где описана установка параметра hostname на сервере?
Не совсем понятно, в каком виде должен быть хостнейм на момент, когда сервер требуется ввести в домен
Он должен быть вида "name" или "name.domain" ?
name
Вы не можете включить в домен хост, который уже принадлежит домену.
Прочитал. В целом, в статье ничего сложного нет. Если удалось настроить по этой статье, то и по той тоже получится. По сути надо только сделать скрипт на ruby, проверить его работоспособность и добавить его в конфиг sshd, как указано у автора. Схема, судя по всему, рабочая получается, но реально костыльная. Я не знаю, насколько это все оправданно. Лично я не считаю авторизацию по сертификатам удобнее и безопаснее хороших паролей. Реально безопасно, это когда сертификат и пароль. А когда что-то одно из этого, то разницы принципиальной не вижу. Вопрос удобства. Лично я предпочитаю пароли.
К сожалению, я не смог найти второй пакет для установки, ruby-ldap , ruby и ruby-net-ldap ставятся, второй же не находится, пробовал добавлять репозитории, все по Вашим статьям, спасибо огромное, но этот пакет почему то не находит для установки. А скрипт у меня не работает, причина может быть в том, что не доставились нужные компоненты.
Да, тут уже разбираться надо более детально. Скорее всего пакет стал называться немного по-другому, или под текущую версию ruby его нет.
Подскажите, а как бы Вы реализовали подобную задачу? Соотнося с Вашей статьей по вводу CentoS 7 в AD?
Я пытался использовать его скрипт на Ваше подключение, но не работает, ключ не возвращается при запросе, видимо дело в разных переменных которые указаны в sssd.config у него и при добавление по Вашей инструкции. адаптировать же его скрипт у меня так и не получилось =( Вести пк в домен по его инструкции так же не вышло, куда не кинь, везде клин =(
Я бы так делать в принципе не стал. Пересекать linux и windows без крайней необходимости не стоит. Мне хватает того, что файловые сервера с samba периодически после обновления выпадают из домена или появляются проблемы с доступом и правами. Это все очень усложняет сопровождение.
А если вам все же это надо, то придется разбираться, причем именно самому от и до, чтобы потом получалось решать возникающие проблемы.
Добрый день!
Эксперемент завершился удачно, удалось настроить авторизацию по ssh ключам модернизировав скрип из той статьи.
Правда я чуть красивее сделал, добавил новый атрибут пользователям в AD назвал его sshPublicKeys, что б не городить огород с вкаладкой notes и прочее.
К сожалению, не от меня зависело, была задача, надо сделать, пришлось крутиться =)
Спасибо Вам большое! =)
P:S прошу прощения, случайно отправил в общую ленту еще. так получилось, если мешается, удалите, пожалуйста.
Можете свой скрипт привести? Это может быть полезно остальным.
Да, конечно. Хотя он не сильно отличается, вместо атрибута info указан атрибут sshPublicKeys и в config убрана папка, скрипт ищет по всему AD
require 'rubygems'
require 'net/ldap'
config = :host => "domain.com",
:port => 389,
:username => "administrator@domain.com",
:password => "password administrator",
:base => "DC=domain,DC=com",
>
ldap = Net::LDAP.new :host => config[:host],
:port => config[:port],
:auth => :method => :simple,
:username => config[:username],
:password => config[:password],
>
filter = Net::LDAP::Filter.eq "sAMAccountName", username
attributes = ["sshPublicKeys"]
ldap.search(:base => config[:base], :filter => filter, :attributes => attributes ) do |entry|
puts entry[:sshPublicKeys].first
end
И ф файле /etc/ssd/sshd_config раскоментим строки
AuthorizedKeysCommand /usr/bin/you_script
AuthorizedKeysCommandUser nobody
На контроллере домена, пользователям нужно добавить артибут sshPublicKeys и внести туда открытую часть ключа, ну или если не хочется мучиться с добавлением, можно указать ключ в поле Notes вкладки Telefones и в скрипте указать вместо sshPublicKeys атрибут info
А есть возможность еще расширить функционал? Хранить в домене ключи ssh и сделать авторизацию по ним?
Подскажите как перезавести ПК на Linux в домен еще раз, в том случае если удалил его из UA в домене?
Просто ввести его еще раз, точно так же, как и первый раз. На самой системе ничего делать не надо.
Что может послужить проблемой?
Мне помогло перезагрузить систему, ну так на сайте RedHad написали .
И снова здравствуйте, нужен совет, после внедрения ПК в домен возникла потребность выполнения скрипта, который при авторизации доменного пользователя в его директорию /home/(domain)/(user)/mounfolder монтировал определенную шару допустим \\NFS\(SomeGroup_folder). Просто для Виндовых юзеров есть NETLOGON\disk.bat в котором указано кому и какую шару подключать, а вот в Linux мне не особо понятно как это сделать. На просторах ближе всего подходит метод с библиотекой libpam-moun, но вопрос решит ли она мне эту проблему?
Точно не знаю. В винде это решается на уровне групповых политик домена windows. Соответственно, тут тоже должен быть какой-то инструмент, аналог этих политик, для выполнения каких-то действий при логине. Но если речь конкретно про подключение диска, которое можно описать простым sh скриптом, то можно попробовать реализовать запуск скрипта при логоне с помощью .bash_login или .bashrc, если используется оболочка bash. Если другая, то уже ее средствами.
вопрос решился прям сам по себе, так сказать сам задал вопрос и в нем было решение, помогла библиотека libpam-mount, в настройка pam_mount.conf.xml указал каким группам что подключать и все заработало, теперь в зависимости от того кто вошел в систему монтируются нужные ему ресурсы. Так я это дело вписал в скрипт, который вводит комп в домен - ставит нужные либы, спрашивает имя и айпи домена, настраивает скрим монтирования шар. теперь ввод *.nix ПК в домен занимает три минуты)))
Круто, можешь поделиться ссылкой, где это описано и рассказано? Посмотрю для общего образования.
Сборная солянка с головы и интернета, есть скрипт вот его текст, там я думаю разберешя
yum -y install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools sssd-libwbclient samba
[share]
comment = My shared folder
path = /data/share
public = yes
writeable = yes
browseable = yes
guest ok = yes
valid users = @"depit@example.com"
directory mask = 0775
create mask = 0664
vfs objects = acl_xattr
inherit permissions = yes
inherit acls = yes
map acl inherit = yes
store dos attributes = yes
Если шарится папка на ext*, то в параметры монтирования /etc/fstab надо дописать атрибуты acl и user_xattr. Должно хватить и acl, но мы же нанотехнологичные чуваки. Для XFS ничё не надо, всё «искоробки»:
UUID=dabdd229-52dc-49d6-add2-a10f9f582bf5 / ext4 defaults,acl,user_xattr 0 0
Разрешаем полный доступ на уровне ugo. Локально всё равно только по ssh можно цепляться (ну только если у вас не проходной двор), а демон самбы сам разрулит кому можно, а кто идёт пасти бобров.
chmod 777 /data/share
Конкретно в CentOS самба после установки сама не запускается. И ей даже не разрешено это делать. Так что разрешаем запускаться:
systemctl enable smb.service
Разрешаем firewalld пускать самбу в сеть:
firewall-cmd --permanent --zone=public --add-service=samba
Применить правила без разрыва соединений:
Через виндовые параметры безопасности права нормально выставляются? С этим часто бывают проблемы. Вообще, я много заводил файловых серверов под линуксом в виндовый домен. Мне не нравится, как это работает. Не очень стабильно, бывают глюки, иногда права через консоль приходится выставлять. Иногда были ситуации, когда права полностью или частично слетали. Я бы не рекомендовал такое решение, если есть возможность поставить файловый сервер под виндой.
Да соглашусь, недавно ввел в линукс файлсерве в домен, в определенный момент UID GID перемешались, а в некоторых случаях вообще слетели у определенных пользователях, но поднимать виндовый серв, который жрет в два раза больше оперативи на виртуалке не охота.
Да, да, именно такие проблемы у меня иногда бывают. Я не понимаю, из-за чего это происходит, но права в итоге слетают. Я много разбирался с этой ситуацией. У меня уже готов черновик статьи, где я настраиваю самбу в домене. Пытался настроить все через sssd, вместо winbind, но ничего не получилось. Пришлось вернуться к winbind. Буквально на днях будет статья, она уже фактически готова, но только проблемы, которые возникают, победить не получилось. Я не могу их сам спровоцировать, чтобы понять, в какой момент и из-за чего они слетают.
Есть мнение что это все из за тог что в настройках самбы есть параметр (winbind offline logon = yes) который препятствует срабатыванию обновления (getent passwd), так как параметр (winbind cache time = 300) игнорируется, но тут вопрос - ради эксперимента в домене добавил юзера "тест", по команде wbinfo -u он появился , но вот getent paswd не отработал. Получается что pam.d не передал данные, короче непонятно голова вспухла уже))))).
Только что снова вылетел баг, групы на шаре обновились и UID GID тупо напрочь обновились - стали другими, в следствии на шарах права стали в виде gid=10011, а не название группы, может в крон положить скрипт который будет обновлять раз в час или в сутки типа chown -R root:"domain admins" /srv/work, та и забить про эту проблему?
Подскажите вы можете, дописать статью как создать папки smb с авторизации по AD?
Заранее благодарен.
Давно собираюсь, но все времени не хватает. Там уже winbind надо будет настраивать а не sssd.
Проверял resolve:
[root@siteadmin
Ping к слову не идёт, но в компании говорят, что отключили возможность пингования со стороны сервера (но меня всё равно это смущает).
Мой вопрос:
- Команда "realm discover LOCAL.DOMAIN.RU" не говорит ли о том что доступ есть?
- Если команда "realm discover" видит сервер, то почему появляется ошибка "failed to lookup DC"?
"Аутентификация - происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса - проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация - перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права."
Как запомнить? Легко. Аутентификация - КТО ТЫ, авторизация - МОЖНО ЛИ.
Доброе.
Firewalld отключили, а про SELinux - ни слова. Или он в этом случае "не мешает" ?
Специально не проверял. Статья писалась с отключенным selinux. Я в начале статьи привел ссылку на настройку centos, там я отключаю selinux. Вообще, у меня во всех статьях он отключен. Вопрос настройки selinux я нигде не рассматриваю.
Если задача только в авторизации по ssh, то samba, группы в AD - лишнее. Достаточно модуля pam_krb5. Проще и надёжнее.
Да тут вроде тоже ничего сложного. Все очень быстро и просто делается. Это с winbind ковыряться долго, а sssd достаточно просто заводит в домен и все системные конфиги сам правит.
CentOS Linux 7 - Присоединение к домену Active Directory средствами realmd/SSSD и настройка аутентификации и авторизации через доменные группы безопасности
Процедура присоединения Linux-системы к домену Active Directory с помощью SSSD (System Security Services Daemon) и RealmD (Realm Discovery) подробно рассматривалась ранее на примере Debian GNU/Linux 8.6. Данная статья является «выжимкой» основных этапов присоединения к домену Active Directory для системы на базе CentOS Linux 7.4.
Предварительные условия
На нашей Linux-системе, для успешного присоединения и членства в домене Active Directory, должно быть соблюдено как минимум два условия:
Настроена синхронизация времени с контроллерами домена. Пример того, как это можно сделать описывался в статье Настройка службы синхронизации времени chronyd в CentOS Linux 7.4Присоединение к домену Active Directory
Устанавливаем необходимые для работы пакеты:
Проверяем успешность обнаружения домена:
Настраиваем параметры системы, которые будут использованы при присоединении к домену для заполнения атрибутов operatingSystem и operatingSystemVersion.
Выполняем присоединение к домену (в ходе присоединения будет запрошен пароль доменного пользователя с правами на ввод в домен, указанного в опции –user ):
Настройка Kerberos-клиента
Настраиваем конфигурационный файл, ранее установленного клиента Kerberos. Это может быть нужно в случае если мы захотим использовать удалённое Single sign-on (SSO) подключение через сервер SSHD (например через клиент Putty с Windows-системы, как это было описано ранее)
Пример готовой конфигурации:
Настройка SSSD
Настраиваем конфигурацию службы sssd
Пример готовой конфигурации:
Очищаем кэш sss и перезапускаем службу sssd:
Проверка взаимодействия с AD
Проверяем успешность получения информации о пользователе из AD по логину:
Проверяем успешность получения информации о пользователе из AD по UPN:
Проверяем успешность получения информации из AD о членах доменной группы безопасности:
Пробуем войти в сессию доменного пользователя:
Успешно войдя в сессию доменного пользователя пробуем получить информацию о текущем пользователе (должен быть возвращён набор доменных групп, в которые входит пользователь):
Доступ к SUDO
Настроим доступ к возможности вызывать команду sudo, основанный на членстве в доменной группе безопасности: Создадим в каталоге /etc/sudoers.d/ новый файл, в котором будут перчислены группы безопасности:
Наполним файл (каждая отдельная группа с правилами доступа в отдельной строчке. в нашем примере используется одна группа с полным доступом):
Войдём в сесcию доменного пользователя, входящего в группу, которой мы разрешили выполять sudo:
Успешно войдя в сессию доменного пользователя пробуем выполнить любую команду с правами администратора системы используя sudo:
Как видим, работает. Осталось ограничить доступ на редактирование файла, в котором описаны правила предоставления доступа к sudo:
Настройка SSHD
Насстроим службу sshd для того, чтобы можно было использовать SSO-подключение.
Включим опции конфигурационного файла:
Ограничение доступа к системе через PAM
Чтобы ограничить доступ к CentOS Linux 7 на базе доменных групп безопасности, создадим новый конфигурационный файл, в котором будут перечислены группы (как локальные так и доменные), которым нужно обеспечить вход в систему:
Обратите внимание на то, что настраивая ограничение локального входа лучше не забыть добавить локальные группы root и sudo, иначе с дальнейшем вход в систему под локальными административными учётными записями может стать невозможен.
Ограничим доступ к файлу:
Настроим в системном конфиге /etc/pam.d/login правила PAM таким образом, чтобы в ходе авторизации при локальном входе на консоль нашей Linux-системы использдвался созданный нами выше файл со списком разрешённых групп:
Вставляем перед строкой « account include system-auth » вызов проверки нашего файла с группами:
Теперь попробуем подключиться на консоль нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.
Теперь аналогичным образом настроим в конфиге, относящемся к обработке авторизации в SSHD ( /etc/pam.d/sshd ) правила PAM таким образом, чтобы в ходе авторизации при удалённом входе через SSH-сервер использовался созданный нами выше файл со списком разрешённых групп (в нашем примере используется тот же файл, что и для локального входа, хотя это могут быть разные файлы и группы доступа):
Вставляем перед строкой « account include password-auth » вызов проверки нашего файла с группами:
Теперь попробуем удалённо подключиться к SSH-серверу нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.
Если дополнительно требуется доменная аутентификация/авторизация в других сервисах CentOS Linux, например в веб-сервере Apache то, в качестве примера можно использовать статью Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD
Проверено на следующих конфигурациях:
| Версия ОС |
|---|
| CentOS Linux release 7.4.1708 (Core) |
| CentOS Linux release 7.5.1804 (Core) |
Автор первичной редакции:
Алексей Максимов
Время публикации: 22.03.2018 10:34
Если разрабатываемое веб-приложение предполагает аутентификацию в репозитории платформы под доменным пользователем, то для организации такой схемы работы потребуется дополнительная настройка как сервера СУБД, так и BI-сервера, установленного на Linux. Ниже приведен пример настройки доменной аутентификации на Ubuntu. Если используется СУБД Oracle, то указанные настройки актуальны для работы интегрированной доменной аутентификации.
Примечание . Для работы доменной аутентификации веб-приложение должно быть построено на базе веб-сервера Apache или Internet Information Services. Настройка доменной аутентификации на Apache Tomcat при работе в Linux не поддерживается.
Сервер СУБД
Доменная аутентификация доступна при организации сервера на базе СУБД Oracle версии 11.x и выше или PostgreSQL. При работе с Oracle сервер СУБД необходимо подготовить, используя одну из следующих инструкций:
При работе с PostgreSQL необходимо настроить аутентификацию по методу GSSAPI, руководствуясь документацией к СУБД.
Настройка BI-сервера продукта «Форсайт. Аналитическая платформа»
Предполагается, что сервер СУБД и BI-сервер располагаются на различных физических серверах.
Предварительно выполните следующие действия:
Установите BI-сервер (при установке также будут произведены необходимые настройки).
Установите и настройте клиент Oracle.
Скачайте клиент Oracle с официального сайта (требуются пакеты basic, devel, sqlplus в RPM-формате).
Рассмотрим установку на примере клиента Oracle версии 12.1. Выполните следующие действия:
при работе в Debian-подобном дистрибутиве:
- Конвертируйте RPM-пакеты в формат DEB с помощью утилиты alien:
- Установите полученные deb-пакеты (в терминале с помощью утилиты dpkg или её аналога) и вспомогательный пакет libaio:
sudo apt-get install alien
sudo alien oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm
sudo alien oracle-instantclient12.1-devel-12.1.0.2.0-1.x86_64.rpm
sudo alien oracle-instantclient12.1-sqlplus-12.1.0.2.0-1.x86_64.rpm
sudo apt-get install libaio1
sudo dpkg -i oracle-instantclient12.1*
при работе в RedHat-подобном дистрибутиве:
sudo yum localinstall oracle-instantclient*
После установки добавьте путь до библиотек клиента Oracle с помощью утилиты ldconfig в список поиска зависимых библиотек и обновите кэш:
/oracle.conf
sudo cp
/oracle.conf /etc/ld.so.conf.d/
sudo ldconfig
После установки BI-сервера в файл переменных окружения /etc/opt/ Foresight /fp9.x -biserver/envvars для экземпляра Apache2 потребуется добавить экспорт переменной TNS_ADMIN с указанием каталога, содержащего файл tnsnames.ora . У экземпляра Apache2 должен быть доступ к файлу, можно установить владельца www-data:www-data для файла tnsnames.ora .
Подробней про создание базы данных для репозитория читайте в подразделе «Подготовка сервера Oracle».
Настройка клиента Kerberos
Установите пакеты для протокола Kerberos:
sudo apt-get install krb5-user krb5-config
В /etc/krb5.conf добавьте информацию о домене, например:
При возникновении ошибки « kinit: Generic preauthentication failure while getting initial credentials » добавьте в /etc/krb5.conf:
default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
Настройка клиента Oracle
В slqnet.ora добавьте следующие строки:
Настройка Apache
Настройка модуля mod_auth_kerb :
На Ubuntu модуль доступен из стандартных репозиториев, для его установки выполните:
sudo apt-get install libapache2-mod-auth-kerb
После установки и активации модуля нужно скорректировать файл с настройками /etc/apache2/mods-enabled/auth_kerb.conf следующим образом (поменять <server> на имя сервера, на котором развернут BI-сервер продукта «Форсайт. Аналитическая платформа»):
В файле /etc/apache2/sites-enabled/000-default.conf (наименование может быть без .conf) следует добавить следующие строки:
Настройка mpm-модуля coworker:
Для корректной работы через Kerberos на Apache нужен модифицированный mpm-модуль coworker вместо worker. Это требуется для того, чтобы изолировать процессы аутентификации пользователей.
Распакуйте архив с mpm-модулем в /usr/lib/apache2 .
Сделайте символьную ссылку /usr/sbin/apache2 на /usr/lib/apache2/mpm-coworker/apache2 .
В /etc/apache2/apache2.conf добавьте настройки следующего вида:
Настройка LDAP
Для работы с Active Directory нужно установить следующие пакеты:
sudo apt-get install libldap-2.4-2 libsasl2-modules-gssapi-mit
Далее в файл /etc/ldap/ldap.conf добавить информацию об Active Directory:
Измените имя сервера, если это необходимо. Его можно задать в окне менеджера сервера:
Добавим службу Active Dirrectory и DNS на сервер. Для этого откроем окно добавления ролей в менеджере сервера:
В окне для выбора сервисов установим галочки "Active Directory Domain Services" и "DNS Server":
Во всех остальных пунктах даем согласие на установку.
После завершения установки сервисов вам надо перейти к настройке домена. Для этого откройте меню уведомлений и выберите пункт "Promote this server to a domain controller":
На первой вкладке укажите опцию для создания нового домена и укажите его название:
Введите пароль сброса:
На следующей вкладке оставляем все как есть., т.к. наш сервер сам является DNS сервером:
На следующих трёх вкладках также оставляем все как есть:
Перед запуском процесса установки ознакомимся с уведомлениями об ошибках.. И если необходимо, устраняем возникшие проблемы. В нашем случае уведомления не являются критичными:
После установки Active Directory сервер перезагрузится. Если настройка прошла успешно, то нас попросят войти в аккаунт на этот раз доменного пользователя:
Добавление новых пользователей:
Откроем утилиту управления пользователями и компьютерами домена:
Для удобства можно создать отдельную дирректорию Domain Users, где будем создавать доменных пользователей:
Добавим нового пользователя user:
Аналогичным образом добавьте остальных пользователей, которые должны быть в домене.
Установка центра сертификации Active Directory:
Установите драйверы для работы с Рутокеном на сервер. Их можно получить тут. После этого можно приступить к настройке центра сертификации и выдачи сертификатов для пользователей. Это можно сделать по данной инструкции. Настройку авторизации с помощью сертификатов можно воспроизвести по этой инструкции.
Для пользоватей Linux
Его можно получить здесь:
Настройка подключения к домену
Astra Linux Smolensk
Для Astra Linux Smolensk чтобы подключиться к домену (не настраивая двухфакторную аутентификацию), можно воспользоваться следующей инструкцией.
Если во время выполнения инструкции панель " Настройки клиента Active Directory " не будет запускаться, то введите в командной строке следующую команду:
Она предоставит пользователю root доступ к графическому интерфейсу среды.
В первую очередь настроим подключение к домену. Это можно сделать с помощью следующей последовательности команд:
Настройка автоматического создания домашней директории
Когда доменный пользователь аутентифицируется в системе необходимо чтобы для него автоматически создавался домашний каталог.
Это можно сделать в настройках pam. Для этого в файле
/etc/pam.d/common-session для систем основанных на Debian
/etc/pam.d/system-auth для систем основанных на Red Hat
/etc/pam.d/system-auth-sss-only для пользователей Alt linux
активируем модуль pam_mkhomedir.so, после pam_sss.so. Содержимое файла будет выглядеть следующем образом:
Проверка аутентификации под пользователем в домене без Рутокена
Если в домене есть пользователь user, под которым можно аутентифицироваться без смарт-карты, то можно проверить предыдущую надстройку аутентифицируясь под ним. Для начала можно попробовать аутнетифицироваться через командную строку:
Настройка клиента для аутентфикации в домене с помощью Рутокена
Упрощенная настройка
Для упрощенной настройки можно воспользоваться утилитой для работы с токенами. Описание упрощенной настройки можно прочитать тут.
Ручная настройка
Установка необходимых пакетов для работу:
Для ручной настройки также потребуется установить библиотеку librtpkcs11ecp. Ее можно получить тут. Установим данную библиотеку.
Читайте также: