невозможно подключиться к домену active directory alt linux

ActiveDirectory/Login

Инструкция по вводу рабочей станции под управлением ALT Linux в домен Active Directory (работающий под Windows или под Samba в режиме AD DC). Устаревшая инструкция: Ввод в домен на базе Windows 2003

Содержание

Подготовка [ править ]

Установка пакетов [ править ]

С версии alterator-auth-0.31-alt1

Возможно, следует обновить установленный дистрибутив из репозитория.

Синхронизация времени [ править ]

С версии alterator-auth 0.28 синхронизация времени производится автоматически с контроллером домена.

Для более ранних версий:

Способ 1: Через net time [ править ]

Способ 2: По протоколу RFC 867 [ править ]

На сервере включается через xinetd daytime-tcp [1] :

А на клиенте — служба settime-rfc867 :

Способ 3: Через Центр управления системой → Дата и время [ править ]

Способ 4: Через ntpdate [ править ]

Ввод в домен в Центре управления системой [ править ]

В Центре управления системой перейдите в раздел Пользователи → Аутентификация

Для ввода компьютера в Active Directory потребуется установить пакет task-auth-ad-sssd и все его зависимости.

Выберите пункт «Домен Active Directory» и заполните поля. Нажмите кнопку «Применить».

Ввод в домен в командной строке [ править ]

Настройка SSSD [ править ]

Проверка работы [ править ]

Примечания [ править ]

Настройка окна входа [ править ]

Настройка LightDM [ править ]

В /etc/lightdm/lightdm.conf раскомментируйте строку в группе [SeatDefaults] :

Это позволит вводить имя пользователя вручную, а не прокручивать огромный список доступных доменныx пользователей.

Также полезно выключить выбор языка. В файле /etc/lightdm/lightdm-gtk-greeter.conf в группе [greeter] укажите

В новых версиях lightdm-gtk-greeter можно указать кнопки явно:

Полный перечень доступных кнопок:

Отображение глобальных групп на локальные [ править ]

Установка модуля ролей [ править ]

Настройка ролей и привилегий [ править ]

Добавляем роль локальных администраторов:

Создаём привилегию на право удалённого доступа (по протоколу ssh):

Включаем удалённый доступ только для группы remote:

Настраиваем список привилегий для пользователей (для роли users):

Настраиваем список привилегий для администраторов (для роли admins):

Настраиваем отображение локальных привилегий, назначенных локальным ролям, на глобальные группы безопасности:

Просматриваем список назначенных ролей и привилегий:

Данная настройка назначает заданный список локальных групп (привилегий) всем пользователям, входящим в заданные локальные группы (роли). А также назначает локальные роли для глобальных групп в домене.

Дополнительные роли [ править ]

Соответственно, если надо выдать права администраторов АРМ пользователям, которые не являются Domain Admins, то нужно завести новую группу в AD (например, PC Admins), добавить туда необходимых пользователей. Затем на АРМ добавить роль для данной группы:

После этого (и после разрешения sudo для группы wheel) под пользователем входящим в группу PC Admins можно запускать команду повышения прав sudo.

Подключение файловых ресурсов [ править ]

Рассматриваемые способы позволяют подключать файловые ресурсы (file shares) для доменного пользователя без повторного ввода пароля (SSO, Single Sign-On).

Через gio [ править ]

Недостаток такого способа — необходимо открыть ресурс в файловом менеджере (Caja, Pcmanfm). Однако можно открывать любые ресурсы на любых серверах, входящие в домен Active Directory.

1. Устанавливаем необходимые пакеты (с правами root):

2. Включаем пользователя в группу fuse (с правами root):

3. Входим доменным пользователем

4. Открываем ресурс в файловом менеджере (например, по адресу smb://server/sysvol ). Ресурс смонтирован по пути /var/run/ /gvfs или /var/run/user/ /gvfs/smb-share:server=сервер,share=ресурс

Другой вариант (полезно для скриптов в автозапуске):

Через pam_mount [ править ]

В этом случае заданный ресурс подключается с заданного сервера автоматически при каждом входе доменным пользователем.

1. Устанавливаем pam_mount :

2. Прописываем pam_mount в схему /etc/pam.d/system-auth-sss :

(перед auth substack system-auth-sss-only )

и в секцию session:

3. Устанавливаем правило монтирования ресурса в файле /etc/security/pam_mount.conf.xml (перед тегом ):

/share» — путь монтирования в домашней папке пользователя

Опционально можно добавить

Для проверки можно попробовать смонтировать ресурс в сессии:

Также можно проверить доступность ресурса с помощью smbclient, например:

Через autofs [ править ]

В этом случае заданный ресурс подключается автоматически при каждом обращении пользователя. И отключается после определенного времени бездействия (определяется конфигуацией Autofs).

Основная статья AutoFS [ править ]

Для дистрибутивов c KDE [ править ]

1. Устанавливаем kde5-autofs-shares :

2. Следуем инструкции по подключению в разделе Альт_Рабочая_станция_К_8_советы.

Групповые политики [ править ]

Групповые политики (GPO) на Linux применяются только контроль входа через SSSD и средства Centrify.

SSSD [ править ]

SSSD имеет внутреннюю поддержку следующих групповых политик:

Источник

Домен/Решение проблем

Если что-то не работает, алгоритм следующий:

Содержание

Проверка сервера [ править ]

1.Проверяем правильность работы домена на сервере [ править ]

Проверяем на сервере домен и то, что он использует Kerberos:

Если проблемы с KDC, то следует выполнить следующий алгоритм действий:

Проверка создания пользователя [ править ]

Проверка клиента [ править ]

1. Проверяем доступные домены с сервера [ править ]

Служба avahi-daemon должна быть запущена на сервере и клиенте и там и там выдавать примерно следующее:

2. Проверяем схему аутентификации на клиенте [ править ]

Схема — krb5, выбран правильный домен. Примечание: на сервере используется схема ldap.

Если в модуле «Аутентификация» не показывается домен, то на клиенте нужно запустить службу avahi-daemon:

или добавить аутентификацию в домене вручную:

3. Смотрим доступность сервера по имени [ править ]

а) Если пишет ‘unknown host’, проверьте, прописан ли сервер как сервер DNS для этой машины. Рекомендуется сервер домена использовать как сервер DHCP и DNS для обслуживаемой подсети.

б) Если ping не идёт, проверьте сетевые подключения клиента и сервера и маршрутизацию сети.

4. Проверьте время на клиенте и сервере командой [ править ]

Оно не должно сильно отличаться. Kerberos очень чувствителен к разнице во времени.

5. Проверьте, виден ли клиент в LDAP [ править ]

6. Проверьте, видим ли пользователь через NSS на клиентской машине [ править ]

Если ничего не выдано, проверяйте имя домена и работу службы LDAP (slapd) на сервере.

7. Проверяем получение тикета Kerberos [ править ]

В первой команде нужно указать имя пользователя и его пароль. Команда klist должна показать полученный тикет.

Если по каким-то причинам запись в LDAP есть, а в Kerberos отсутствует (например, создавали домен без поддержки Kerberos), нужно явно завести в Kerberos:

8. Пробуем зайти под доменным пользователем [ править ]

В DM или консоли пробуем зайти доменным пользователем. В случае успеха аутентификация в домене работает. Если что-то не работает, то смотрите 12-ую консоль ( Ctrl+Alt+F12 ).

Разное [ править ]

Требования к именам пользователей [ править ]

При создании пользователя, содержащего в имени буквы в верхнем регистре, POP3 и IMAP-доступ к его почтовому ящику не будет работать. Рекомендуется создавать имена пользователей, состоящие из латинских букв в нижнем регистре, цифр, символов «_» и «-». Исправлено в ldap-user-tools с версии 0.8.2-alt2

Сообщения об ошибках входа: вероятные причины [ править ]

«Сбой при проверке подлинности» [ править ]

«Службе проверки подлинности не удаётся загрузить сведения аутентификации» [ править ]

Предположительно, остановка или недоступность службы KDC. Проверить состояние службы krb5kdc на контроллере домена.

В случае состояния stopped причина обнаружена. Попробовать перезапустить KDC

Если krb5kdc не запускается, пытаться устранить причину или (если возможно) восстановить работоспособное состояние сервера домена из резервной копии.

Источник

Как ввести компьютер с ОС АЛЬТ в домен Active Directory и сделать так, чтобы Linux-администратору было удобно с ним работать

После установки ОС АЛЬТ в действующую ИТ-инфраструктуру или в тестовую среду, соответствующую продуктивной, ИТ-специалисты часто сталкиваются с вопросом: как ввести компьютер в домен службы каталогов. В основном, в Active Directory от Microsoft.

Чтобы избежать проблем с вводом в домен, системному администратору необходимо убедиться, что служба синхронизации времени работает. И время на рабочей станции соответствует времени на домен-контроллере. Также на рабочей станции должны быть указаны правильные DNS-серверы, в которых присутствуют корректные SRV-записи, указывающие на работающий домен-контроллер.

В ОС АЛЬТ компьютер можно ввести в домен с помощью графического интерфейса. Для этого необходимо установить пакет task-auth-ad-sssd. Операция по вводу в домен рабочей стации через графический интерфейс достаточна проста, нужно лишь правильно указать следующие пункты:

Если подготовка к вводу в домен была выполнена без ошибок, то процесс ввода компьютера в домен выглядит так:

Компьютер подготовлен к вводу в домен, у него есть все необходимые данные.

Появляется запрос на подтверждение полномочий пользователя на ввод в домен компьютера.

Появляется сообщение об успешном вводе в домен.

Проверка успешного ввода в домен.

Однако, трудности, все же бывают. Например:

Как еще можно быстро и просто включить компьютер в домен?

Разработать модуль включения компьютеров в домен и настройки авторизации пользователей в системе централизованного управления конфигурациями и инфраструктурой на базе Puppet, как это сделали мы. Модуль позволяет включать в домен компьютеры, которые объединены общим логическим признаком (например, «новые рабочие станции»).

Для использования модуля достаточно указать название домена и его тип (например, Active Directory). После включения компьютера в среду «новые рабочие станции», на нем автоматически применятся настройки, позволяющие ввести его в домен одной командой. Ввод команды обусловлен требованиями по информационной безопасности (передается пароль учетной записи, обладающей правами на ввод в домен).

Однако, для того, чтобы отечественное ПО в данном случае работало действительно хорошо, нужно снять два самых частых ограничения при работе компьютера с ОС АЛЬТ в домене Active Directory.

Ограничение №1. Сопоставление доменных групп безопасности с локальными

Ситуация. Администратору нужно выполнить настройки для сопоставления доменных групп безопасности с локальными группами. Чтобы у группы безопасности администраторов рабочих станций, применяемых к Windows-клиентам, были одновременно и права администратора и в ОС АЛЬТ. К примеру, если администратор входит в группу «Администраторы домена», он не будет добавлен в группу wheel. При этом выполнять настройки по сопоставлению нужно на каждом компьютере, вручную. Потому что групповые политики по добавлению группы безопасности из Active Directory в локальную группу на компьютере с ОС АЛЬТ не применяются.

Как снять ограничение. Использовать систему централизованного управления конфигурациями и инфраструктурой – например, на базе Puppet. С ее помощью можно распространить нужное состояние и параметры на любое количество компьютеров – в автоматизированном режиме.

Если добавляется доменная группа администратора рабочих станций, то система управления конфигурациями позволяет «раскатать» ее сразу на десятки, сотни или даже тысячи компьютеров. И администраторы рабочих станций на доменных рабочих станциях с ОС Windows, без проблем становятся еще и администраторами на компьютерах с ОС АЛЬТ. Не надо подключаться к каждому компьютеру, вводить последовательность команд вручную. Отпадает и необходимость в создании «костыльных» скриптов, которые полуавтоматизируют процесс, обладая при этом существенными недостатками (например, нет журналирования событий). Нужно просто описать, какое состояние рабочей станции необходимо получить. И дождаться результата. Группа компьютеров будет получать указанную администратором конфигурацию с серверов системы управления конфигурациями.

Ограничение №2. Подключение сетевых ресурсов

Ситуация. При организации файлового сервиса в Windows-инфраструктуре зачастую используются пространства DFS (Distributed File System). И публикация файловых ресурсов. При этом у многих системных администраторов возникает вопрос: «Как и под каким пользователем правильно подключить предоставляемый пользователю сетевой ресурс»?

Казалось бы, для подключения сетевого ресурса можно использовать пользователя, который в данный момент работает за компьютером, или выделить отдельного, Но это не совсем корректно. Потому что за одним и тем же компьютером могут работать разные доменные пользователи, тогда прав на запись информации у них не будет. Или пароль отдельного пользователя будет храниться в файловой системе в открытом виде. В этом случае могут быть предоставлены некорректные права, дающие доступ к файлам для всех. Что небезопасно.

Как снять ограничение. Можно подключать сетевые ресурсы с помощью модуля PAM (Pluggable Authentication Modules) – pam_mount. Использование этого метода позволяет подключать сетевой ресурс от имени активного доменного пользователя с назначенными ему правами, вводя при этом пароль только раз – при входе в систему. К примеру, так мы подключаем сетевой ресурс «Консультант Плюс» на сервере Windows.

Мы подключаем его под доменным пользователем, который авторизовался на рабочей станции, и запуск «Консультанта» проходит без проблем. Для организации доступа к DFS-пространствам: при успешном входе пользователя сетевой ресурс автоматически подключается. Пользователь обладает всеми теми же правами, что и в случае подключения ресурса с Windows-клиента.

Расчёт стоимости

Чтобы предложить вашей компании все возможные решения, а также сделать ориентировочную бюджетную оценку импортозамещающего проекта, специалистам ALP Group необходимо проанализировать текущую архитектуру ее ИТ-сервисов. Анализ проводится на основании заполненных опросных листов, разработанных нашим Центром компетенции по импортозамещению и Open Source.

Точная стоимость импортозамещающего проекта зависит от плотности ИТ-сервисов в компании, количества и типа ИС. Ее можно правильно рассчитать только после ряда специализированных предпроектных обследований (инфраструктурные сервисы, функционал АРМ, АИС и др.).

Оставьте свои контактные данные, пожалуйста.

Наши специалисты обязательно свяжутся с вами, чтобы переслать и помочь заполнить опросные листы, уточнить всю информацию и предоставить расчет.

Источник

Linux в домене Active Directory

Содержание

Общая информация

Если вам нужно просто предоставить сетевой доступ к ресурсам Linux компьютера, то смотрите статью Samba.

В этой статье мы опишем как подключить Linux компьютер к домену под управлением Microsoft Active Directory и сделать из него файловый сервер.

После выполнения этой инструкции мы будем иметь в сети файловый сервер под управлением ОС Линукс, входящий в домен Windows 2003 и ничем не отличающийся от файлового сервера под Windows. Пользователи домена смогут обращаться к его ресурсам под своими учётными записями. Доступ регулируется группами домена AD.

По этой инструкции настраивались Debian (4, 5), Ubuntu 9.10, создавалась она на основе официальной документации и многих рекомендаций и инструкций из Интернета. Остальные Linux’ы настраиваются сходным образом.

Проверка требований

Установка Samba

При настройке krb5-config лучше указывать IP адреса контроллеров домена, а не их DNS имена.

Настройка Samba

Мы описали два общих каталога:

В Ubunto testparm находится в пакете samba-common-bin

Всё, компьютер включен в домен, что можно проверить на контроллере. Даже если после приведённых строк получили следующие:

Проверка работы и отладка

Если нас не понимают, то подсказываем пароль для wbinfo и смотрим: список доменов в сети, информацию о домене WORKGROUP, список пользователей и групп домена:

Дополнительная настройка

Доступ к Samba из Windows 7 и 2008 r2

Начиная с этих версий параметры авторизации у MS поменялись. Скорее всего Samba вскоре это учтёт, а пока подружить системы можно изменив на Win7 свойства сетевой безопасности:

Работа над ошибками

Winbind не запускается

При запуске Samba обнаруживаем, что winbind не запустился:

В журнале log.winbindd обнаруживаем запись:

Видим, что добавлен «встроенный домен» (BUILTIN) и домен «название компьютера» (STORAGE), подключиться к домену AD не удалось.

Решение: Переподключить компьютер в домен. Удалять придётся с самого контроллера, т.к. комадна net ads leave скорее всего не поможет.

Ошибка получения билета Kerberos

При попытке получить билет Kerberos получили:

Решение: указать имя домена в другом регистре. Скорее всего нужны все заглавные

Источник

ActiveDirectory/DC

Использование Samba 4 в роли контроллера домена Active Directory. Такой способ позволяет вводить Windows 7/8 в домен безо всяких манипуляций с реестром.

Содержание

Возможности [ править ]

Поддерживаются базовые возможности Active Directory:

Не поддерживается [ править ]

Не поддерживаются следующие возможности[1]:

Установка [ править ]

1. Установите пакет task-samba-dc с версии 4.3.1 для Samba DC на базе Heimdal Kerberos или task-samba-dc-mitkrb5 с версии 4.10.3-alt4 для Samba DC на базе MIT Kerberos, который установит необходимое.

По умолчанию в Samba используется dns-backend = SAMBA_INTERNAL, для возможности переключения режимов dns_backend для сервера SAMBA_INTERNAL/BIND9_DLZ требуется внести следующие изменения:

Установить необходимые пакеты на клиент: task-auth-ad-sssd

В smb.conf блок [global] (на сервере) добавить строку:

Подключить плагин BIND_DLZ:

Привести /etc/bind/options.conf к виду (вместо <> подставить свои параметры в «»):

При выполнении команды создания домена одной командой указать тип dns-backend = BIND_DLZ:

Выполнить остановку bind:

Создание нового домена [ править ]

Восстановление к начальному состоянию samba [ править ]

Очищаем базы и конфигурацию Samba (если уже создавался домен):

Выбор имени домена [ править ]

Имя домена для разворачиваемого DC должно состоять минимум из двух компонентов, разделённых точкой.

При этом должно быть установлено правильное имя узла и домена для сервера:

Создание домена одной командой [ править ]

Создание контроллера домена domain.alt с паролем администратора Pa$$word:

Интерактивное создание домена [ править ]

В примере показано создание домена domain.alt.

Запустите samba-tool domain provision :

При запросе ввода нажимайте Enter за исключением запроса пароля администратора («Administrator password:» и «Retype password:»).

Запуск службы [ править ]

Установите службу по умолчанию и запустите её:

Настройка Kerberos [ править ]

Откройте от имени суперпользователя файл /etc/krb5.conf.

Раскомментируйте строку «default realm» и введите название области заглавными буквами.

Ниже, под строкой [realms] вместо EXAMPLE.COM введите название области, а вместо example.com в «default domain» введите IP-адрес сервера с Samba.

Под строкой [domain_realm] example.com и EXAMPLE.COM замените на ваш домен сохраняя регистр.

Альтернативный вариант [ править ]

В момент создания домена Samba автоматически конфигурирует шаблон файла krb5.conf для вашего домена, и оставляет его в директории /var/lib/samba/private/krb5.conf

Как следствие, можно его просто скопировать с заменой:

Проверка работоспособности [ править ]

1. Общая информация о домене:

2. Просмотр предоставляемых служб:

3. Проверка конфигурации DNS

3.1 Убедитесь в наличии nameserver 127.0.0.1 в /etc/resolv.conf :

3.2 Проверяем имена хостов:

4. Проверка Kerberos:

Просмотр полученного билета:

Управление пользователями [ править ]

Создать пользователя с паролем[12], :

Просмотреть доступных пользователей:

Изменить пароль пользователя:

Не забудьте разблокировать пользователя:

Если компьютер с таким именем заведён, удалить его можно командой:

Добавить пользователя в группу:

Удалить пользователя из группы:

Смотрим значение memberOf.

Заведение вторичного DC [ править ]

Имя узла: dc2.domain.alt (192.168.1.106). Предполагается, что пакет task-samba-dc уже установлен.

2. На dc2.domain.alt правим файл /etc/krb5.conf :

3. Получаем билет и убеждаемся, что билет получен:

Если всё нормально, в конце видим:

5. После успешного ввода в домен в resolvconf необходимо сменить адрес PDC на адрес вторичного DC (в нашем примере 192.168.1.106).

6. Делаем службу samba запускаемой по умолчанию:

7. Запускаем службу, соответственно:

Репликация [ править ]

1. Реплицируем на вторичном DC (с первичного):

(сначала указывается приемник, затем источник, после этого реплицируемая ветка в LDAP).

2. Реплицируем на вторичном DC (на первичный):

(сначала указывается приемник, затем источник, после этого реплицируемая ветка в LDAP).

3. Просмотр статуса репликации на PDC:

Источник