Alt linux подключение к домену windows

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

Внимание! Если Ваш домен имеет суффикс .local — необходимо отключить avahi-daemon (подробнее ниже, пункт 2 примечаний).

Параметры домена

Подготовка

Установка пакетов

Внимание! Аутентификация через winbind в новых сборках Samba не работает, используйте аутентификацию через task-auth-ad-sssd.

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

apt-get install task-auth-ad-sssd

apt-get install alterator-auth sssd-ad samba-common-tools

Требуемые версии:

• pam-config >= 1.7.0-alt1
• alterator-auth >= 0.26-alt1

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

Синхронизация времени

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

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

Способ 1: Через net time

net time set -S <имя домена>

Способ 2: По протоколу RFC 867

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

# chkconfig --list | grep daytime-tcp
        daytime-tcp:    вкл

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

chkconfig settime-rfc867 on
service settime-rfc867 start

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

Включите флажок «Получать точное время с NTP-сервера» и укажите в поле справа pool.ntp.org. После этого нажмите кнопку «Применить».

Способ 4: Через ntpdate

ntpdate pool.ntp.org

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

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

В Центре управления системой перейдите в раздел Пользователи → Аутентификация. Выберите пункт «Домен Active Directory» и заполните поля. Нажмите кнопку «Применить».

Ввод в домен в командной строке

# system-auth write ad school.alt host-15 school 'administrator' 'Pa$$word' [--windows2003] [--createcomputer="ou=COMPUTEROU"]
Joined 'HOST-15' to dns domain 'school.alt'

Настройка SSSD

См. статью SSSD/AD, Настройки SSSD в Alterator

Проверка работы

# getent passwd ivan
ivan:*:10005:10002:ivan:/home/SCHOOL/ivan:/bin/bash

# net ads info
LDAP server: 192.168.1.1
LDAP server name: c228.school.alt
Realm: SCHOOL.ALT
Bind Path: dc=SCHOOL,dc=ALT
LDAP port: 389
Server time: Ср, 22 апр 2015 16:22:47 MSK
KDC server: 192.168.1.1
Server time offset: -1

# net ads testjoin
Join is OK

Примечание: Вы не увидите пользователей из AD с помощью команды # getent passwd на клиентской машине. Этот функционал отключен по-умолчанию для того чтобы сократить нагрузку на серверы. Поэтому для проверки необходимо указать точное имя пользователя # getent passwd имя_пользователя . Список пользователей можно посмотреть на сервере командой # samba-tool user list

Примечания

1. Ограничение: имя домена должно указывать на DC. Если это не так, поправляйте /etc/krb5.conf и вводите вручную, либо в файл /etc/hosts добавьте строку с контроллером домена (кдц) ДОМЕН.local и перезапустите сеть. После этого проверьте из командной строки ping ДОМЕН.local и вводите в домен
2. При указании домена, имеющего суффикс .local, потребуется на сервере и подключаемых компьютерах под управлением Linux отключить службу avahi-daemon — # chkconfig avahi-daemon off; reboot (доменная зона «local.» используется в технологии zeroconf).
3. Следите за синхронизацией времени на клиенте и сервере.
4. Для предотвращения кэширования имён пользователя отключите службу nscd.
5. В новых версиях Samba до запуска службы winbind должна запускаться служба smb.
6. Если возникает проблема просмотра билетов Kerberos под доменным пользователем, скопируйте правильный krb5.conf из samba:

   rm -f /etc/krb5.conf
   cp /var/lib/samba/smb_krb5/krb5.conf* /etc/krb5.conf
   

7. Если у вас домен Windows 2003 (не R2), то в директивы default_tgs_enctypes, default_tkt_enctypes и preferred_enctypes файла /etc/krb5.conf добавьте ещё DES3-CBC-SHA1.
8. Для возможности входа в ОС под доменным пользователем при его недоступности можно включить опцию кэширования учетных данных в конфиге SSSD (подробнее тут, опция cache_credentials)

Настройка окна входа

Настройка LightDM

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

greeter-hide-users=true

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

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

show-language-selector=false

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

show-indicators=~a11y;~power

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

show-indicators=~a11y;~power;~session;~language

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

Примечание: Первые два пункта данного раздела выполняются автоматически, если АРМ вводится в домен с помощью task-auth-ad-sssd.

Установка модуля ролей

apt-get install libnss-role

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

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

# groupadd -r localadmins

Примечание: Лучше использовать группу localadmins (вместо admins) по избежание конфликта с группой admins во FreeIPA.

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

# groupadd -r remote

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

# control sshd-allow-groups enabled
# sed -i 's/AllowGroups.*/AllowGroups = remote/' /etc/openssh/sshd_config

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

# roleadd users cdwriter cdrom audio proc radio camera floppy xgrp scanner uucp fuse

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

# roleadd localadmins wheel remote vboxusers

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

# roleadd 'Domain Users' users

или

# roleadd 'Пользователи домена' users

Далее

# roleadd 'Domain Admins' localadmins

или

# roleadd 'Администраторы домена' localadmins

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

# rolelst
# id ivan

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

Дополнительные роли

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

# roleadd 'PC Admins' localadmins
# rolelst
users: cdwriter cdrom audio video proc radio camera floppy xgrp scanner uucp vboxusers fuse tsusers
localadmins: wheel
domain users: users
domain admins: localadmins
pc admins: localadmins

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

user@alt8 ~ $ su - petrov
Password: 
petrov@alt8 ~ $ id
uid=445010929(petrov) gid=445000513(domain users) группы=445000513(domain users),10(wheel),14(uucp),19(proc),
22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),100(users),458(tsusers), 459(localadmins),466(fuse),468(video),
480(camera),492(vboxusers),498(xgrp),499(scanner),445010930(pc admins)
petrov@alt8 ~ $ sudo apt-get update
Пароль:
Получено: 1 http://ftp.altlinux.org p8/branch/x86_64 release [880B]
Получено: 2 http://ftp.altlinux.org p8/branch/x86_64-i586 release [537B]
Получено: 3 http://ftp.altlinux.org p8/branch/noarch release [673B]
Получено 2090B за 0s (36,9kB/s).
Найдено http://ftp.altlinux.org p8/branch/x86_64/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/x86_64/classic release
Найдено http://ftp.altlinux.org p8/branch/x86_64-i586/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/x86_64-i586/classic release
Найдено http://ftp.altlinux.org p8/branch/noarch/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/noarch/classic release
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено

Подключение файловых ресурсов

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

Через gio

Примечание: Способ актуален для дистрибутивов, использующих gio (ранее — gvfs) (например, Кентавр, Simply Linux, Basealt Workstation, СПТ).

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

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

apt-get install fuse-gvfs gvfs-backend-smb libgio

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

gpasswd -a <пользователь> fuse

control fusermount public

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

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

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

gio mount smb://server/sysvol/

Примечание: Если необходимо открывать что-то с ресурса в WINE, в winecfg добавьте диск с путём /var/run/<uid_пользователя>/gvfs.

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

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

apt-get install pam_mount

Если осуществляется подключение файловых ресурсов по протоколу CIFS (SMB), то установите cifs-utils:

apt-get install cifs-utils

apt-get install systemd-settings-enable-kill-user-processes

2. Прописываем pam_mount в схему аутентификации по умолчанию. В конец файла (/etc/pam.d/system-auth) добавьте строки

session         [success=1 default=ignore] pam_succeed_if.so  service = systemd-user quiet
session         optional        pam_mount.so disable_interactive

Параметр disable_interactive нужен для того, чтобы pam_mount не спрашивал пароль. Первая строка предназначена для того, чтобы не монтировать дважды при запуске systemd —user. Подробнее: https://wiki.archlinux.org/title/pam_mount#Login_manager_configuration

Пример файла /etc/pam.d/system-auth при аутентификации доменного пользователя под SSSD:

#%PAM-1.0

auth            [success=4 perm_denied=ignore default=die]      pam_localuser.so
auth            [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
auth            [default=1]     pam_permit.so
auth            substack        system-auth-sss-only
auth            [default=1]     pam_permit.so
auth            substack        system-auth-local-only
auth            substack        system-auth-common

account         [success=4 perm_denied=ignore default=die]      pam_localuser.so
account         [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
account         [default=1]     pam_permit.so
account         substack        system-auth-sss-only
account         [default=1]     pam_permit.so
account         substack        system-auth-local-only
account         substack        system-auth-common

password        [success=4 perm_denied=ignore default=die]      pam_localuser.so
password        [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
password        [default=1]     pam_permit.so
password        substack        system-auth-sss-only
password        [default=1]     pam_permit.so
password        substack        system-auth-local-only
password        substack        system-auth-common

session         [success=4 perm_denied=ignore default=die]      pam_localuser.so
session         [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
session         [default=1]     pam_permit.so
session         substack        system-auth-sss-only
session         [default=1]     pam_permit.so
session         substack        system-auth-local-only
session         substack        system-auth-common
session         [success=1 default=ignore] pam_succeed_if.so  service = systemd-user
session         optional        pam_mount.so disable_interactive

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

<volume uid="10000-2000200000" fstype="cifs" server="c253.test.alt" path="sysvol" mountpoint="~/share" options="sec=krb5i,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />

где

• uid=»10000-2000200000″ — диапазон присваиваемых для доменных пользователей UID (подходит и для Winbind и для SSSD);
• server=»c253.test.alt» — имя сервера с ресурсом;
• path=»sysvol» — имя файлового ресурса;
• mountpoint=»~/share» — путь монтирования в домашней папке пользователя.

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

• sgrp=»group_name» — имя группы, при членстве пользователя в которой, папка будет примонтирована.

Внимание! Обязательно указывайте настоящее имя сервера в параметре server, а не имя домена

Параметр sec=krb5i более безопасный, но требует больше вычислительных ресурсов. Вместо него можно указать sec=krb5.

Пример файла /etc/security/pam_mount.conf.xml:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
        See pam_mount.conf(5) for a description.
-->

<pam_mount>

                <!-- debug should come before everything else,
                since this file is still processed in a single pass
                from top-to-bottom -->

<debug enable="0" />

                <!-- Volume definitions -->
<volume uid="10000-2000200000"
        fstype="cifs"
        server="c253.test.alt"
        path="sysvol"
        mountpoint="~/share"
        options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />

                <!-- pam_mount parameters: General tunables -->

<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,sec" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<!-- requires ofl from hxtools to be present -->
<logout wait="0" hup="no" term="no" kill="no" />

                <!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

Для отладки подключения замените в файле /etc/security/pam_mount.conf.xml

<debug enable="0" />

на

<debug enable="1" />

При этом отладочные сообщения будут показываться в журнале Journald.

Вы можете сменить механизм монтирования отдав его на откуп systemd. Для этого в pam_mount.xml.conf можно задатьпереопределить опции cifsmount, umount

 <cifsmount>systemd-mount -A -G -q -t cifs %(COMBOPATH) %(MNTPT) -o uid=%(USERUID),gid=%(USERGID),username=%(USER),%(OPTIONS)</cifsmount>
 <umount>systemd-mount -u %(MNTPT)</umount>

Через autofs

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

Основная статья AutoFS

https://www.altlinux.org/Autofs

Для дистрибутивов c KDE

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

apt-get install kde5-autofs-shares

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

Групповые политики

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

SSSD

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

Примечание: Планируется поддержка других групповых политик средствами подключаемых модулей

Примечание: Получение прав root см. root

Ссылки по групповым политикам

• https://fedoraproject.org/wiki/Changes/SssdGpoBasedAccessControl
• http://wiki.eri.ucsb.edu/stadm/AD_Samba4
• http://centrifying.blogspot.ru/2014/01/basics-using-group-policy-on-unixlinux.html
• https://www.youtube.com/watch?v=2cJWnUZ8qLI

Ссылки

• https://wiki.archlinux.org/index.php/Active_Directory_Integration
• Ввод в домен на базе Windows 2003
• https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
• https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member

1. Предварительно устанавливаем пакеты, необходимые для включения и более удобной настройки станции:
   samba-swat
   krb5-kinit
   libkrb5
   Для этого настраиваем службу управления пакетами apt для работы через прокси-сервер (если прокси-сервер используется в организации).
   В файле конфигурации /etc/apt/apt.conf прописываем строку:
   Acquire::ftp::Proxy»//root:password@127.0.0.1:8080″;
   и затем запускаем менеджер пакетов Synaptic через основное меню -> система -> менеджер пакетов. В меню «настройки» заходим в репозитории. Там ставим галочки напротив пунктов ftp://ftp.altlinux.org/pub/… И нажимаем OK. Затем жмем «получить сведения». Synaptic должен обновить список доступных пакетов из интернета. После чего через «поиск» ищем по ключевым словам нужные пакеты. В правой части окна появится список, где и надо выбрать нужные пакеты и нажать «применить». Пакеты установятся вместе с зависимостями.

2. Настраиваем сетевое окружение, после чего наш компьютер видит домен windows. В файле /etc/resolv.conf прописываем строку:
   nameserver ipaddr (где ipaddr — это ip адрес контроллера домена)

3. Делаем, чтобы сервис swat запускался автоматически: в файле /etc/xinet.d/swat
   меняем значение disable с yes на no и перезапускаем службу:
   
   service xinetd restart

4. Запускаем swat в браузере: http://localhost:901

5. Во вкладке GLOBALS ставим следующие значения:
   Security = ads (это режим domain member)
   Workgroup = WORKGROUP (or DOMAIN) ex. TEAM
   Realm = full domain name. ex. TEAM.LOCAL
   Netbios name = netbios имя нашего компьютера
   Подтверждаем изменения нажав кнопку commit changes наверху страницы.
   И последнее значение настраиваем, переключившись в режим advanced view:
   Password server = ip адрес контроллера домена
   Затем опять подтверждаем изменения.
   Далее во вкладке STATUS запускаем или перезапускаем службы smbd и nmbd.

6. Настраиваем службу аутентификации Kerberos.
   В файле /etc/krb5.conf ставим значек # перед всеми строками в разделе [libdefaults]. Этим мы заставляем Kerberos производить аутентификацию на контролере домена, а не на локальной машине. (# дает компилятору директиву не обрабатывать строку)

7. Подключаем станцию к домену. Выполняем команды:
   kinit administrator@realm (где администратор — это администратор домена и realm полное имя домена)
   net ads join -U administrator
   
   появляется приглашение о вводе пароля администратора, вводим его. После чего должны увидеть сообщение, что наш компьютер ввели в домен.

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

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

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

1. тип домена (ALT Linux, Active Directory, FreeIPA);
2. правильное название домена;
3. правильное имя рабочей группы;
4. имя компьютера.

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

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

   Системному администратору нужно изменить имя компьютера или оставить указанное при установке, проверить правильность домена и ввести компьютер в домен.

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

   В конфигурации по умолчанию права для ввода компьютера в домен есть у всех аутентифицированных пользователей домена (с ограничением в 10 компьютеров). У групп «Администраторы» домена и «Администраторы учета» этого ограничения нет.

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

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

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

   Достаточно выполнить несколько команд, чтобы убедиться в том, что компьютер был успешно включен в домен Active Directory:

• net ads info – выводит информацию о домене, в котором состоит компьютер 
• net ads testjoin – выводит информацию о проверки связи с доменом

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

1. Использование зарезервированного домена .local. Для успешного подключения в домен с суффиксом суффикс .local необходимо отключить на рабочей станции службу и сокет avahi—daemon.

1. «Невозможно найти KDC указанного домена». Компьютер, на котором установлена ОС АЛЬТ (клиент), не может достучаться до домен-контроллера на Windows. Нужно проверить работу DNS-сервиса, убедиться, что с клиента корректно разрешаются имя домен-контроллера, сам домен, а также необходимые SRV-записи. После этого компьютер без проблем попадает в домен.

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

Разработать модуль включения компьютеров в домен и настройки авторизации пользователей в системе централизованного управления конфигурациями и инфраструктурой на базе 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-клиента.

И снова – при десятках, сотнях и тысячах компьютеров подключить вручную сетевые ресурсы нереально. Начинают требоваться «костыли» или же трудозатраты становятся непомерными. Поэтому мы и тут используем разработанную нами централизованную систему управления конфигурациями и инфраструктурой на базе Puppet. Мы написали для нее модуль, помогающий автоматизировано, с минимальными затратами сил и времени, подключать сетевые ресурсы. При добавлении нового сетевого ресурса, достаточно будет объявить его в распространяемой конфигурации. Эта информация приходит на указанную администратором группу компьютеров. А пользователи видят сетевой ресурс на рабочих столах своих компьютеров — при следующем входе в систему.

Автор: Дмитрий Кияев, инженер DevOps в ALP Group

Следующий шаг после установки WPS офиса в списке был — ввод Linux в домен Windows

В данной статье будет рассмотрен вопрос 🔥🔥🔥 о том, как нужно вводить компьютер под управлением ALT Linux в домен который находится на Windows Server 2012 ✅ (но версия тут не играет роли) и подготовительные шаги для этого действия, а также до настройка с подключением сетевых дисков и окна с логином ⭐️

подписывайтесь на мой канал Яндекс дзена!Вы будете первым узнавать  о новых материалах!

Вводим в домен Alt Linux

Для того что ввести станцию в домен надо сначала подготовить ее к этому, для этого делаем след шаги:

1. Выставляем на станции точное время (или время равное с контроллером домена)
2. Редактируем файл /etc/resolv.conf и прописываем там ДНС контроллера домена
   

   search имяДомена.lcl
   nameserver ДНСконтроллераДомена

3. Еще проверяем ДНС тут /etc/net/ifaces/<interface>/resolv.conf 
4. проверяем файл HOST /etc/hosts  
   

   127.0.0.1 localhost.localdomain localhost
   127.0.0.1 имяКомпа.имяДомена имяКомпа

5. если вы во время установки системы не ввели имя станции, то можно переименовать компьютер сейчас /etc/sysconfig/network
6. Теперь надо установить пакеты которые позволят ввести станцию в домен (Поставить все обновления на linux перед этим не забудте)

   apt-get install task-auth-ad-sssd

7. Заходим в настройки системы (или из терминала набираем AAC) и заходим в меню Аутентификация
8. Переключаем чекбокс на пункт Active Directory и заполняем эти моля так:
   

   Домен: ИМЯДОМЕНА.LCL
   Рабочая группа: ИМЯДОМЕНА
   Имя компьютера: имя компьютера

   PS соблюдайте регистр!!!

9. Нажимаем ок, вводим логип и пароля администратора Домена
10. Перезагружаем компьютер и проверяем )

Сейчас каждый подумает, что это сложно и долго, но если присмотреться, то все эти же действия мы делаем когда вводим в домен нашу станцию под Windows))) так что все не так и сложно!

Окно авторизации с логином

После ввода в домен станции, следующая глобальная проблема была с тем, что постоянно приходилось вводить логин и пароль и это очень не нравилось юзерам, а хотелось, что бы было как в windows , что бы в окне авторизации автоматически стоял логин пользователя и оставалось ввести только пароль.

что бы в В Alt Linux такое сделать нужно сделать след:

1. открыть файл /etc/lightdm/lightdm.conf
2. находим строчку greeter-hide-users и после = пишем false (greeter-hide-users = false)
   

Теперь, после того как вы зайдете в систему под юзером, он запомнит его и при повторном входе у вас уже будет заполнено поле логин. все)

ActiveDirectory/Login

Улучшение этой статьи обсуждается на метастранице

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

Содержание

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

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

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

• pam-config >= 1.7.0-alt1
• alterator-auth >= 0.26-alt1

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

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

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

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

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

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

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

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

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

Включите флажок «Получать точное время с NTP-сервера» и укажите в поле справа pool.ntp.org . После этого нажмите кнопку «Применить».

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

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

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

В Центре управления системой перейдите в раздел Пользователи → Аутентификация . Выберите пункт «Домен Active Directory» и заполните поля. Нажмите кнопку «Применить».

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

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

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

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

1. Ограничение: имя домена должно указывать на DC. Если это не так, поправляйте /etc/krb5.conf и вводите вручную, либо в файл /etc/hosts добавьте строку с контроллером домена (кдц) ДОМЕН.local и перезапустите сеть. После этого проверьте из командной строки ping ДОМЕН.local и вводите в домен
2. При указании домена, имеющего суффикс .local, потребуется на сервере и подключаемых компьютерах под управлением Linux отключить службу avahi-daemon — # chkconfig avahi-daemon off; reboot (доменная зона «local.» используется в технологии zeroconf).
3. Следите за синхронизацией времени на клиенте и сервере.
4. Для предотвращения кэширования имён пользователя отключите службу nscd .
5. В новых версиях Samba до запуска службы winbind должна запускаться служба smb .
6. Если возникает проблема просмотра билетов Kerberos под доменным пользователем, скопируйте правильный krb5.conf из samba:

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

Настройка 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 :

Если осуществляется подключение файловых ресурсов по протоколу CIFS (SMB), то установите cifs-utils :

2. Прописываем pam_mount в схему аутентификации по умолчанию. В конец файла ( /etc/pam.d/system-auth ) добавьте строки

Параметр disable_interactive нужен для того, чтобы pam_mount не спрашивал пароль. Первая строка предназначена для того, чтобы не монтировать дважды при запуске systemd —user . Подробнее: https://wiki.archlinux.org/title/pam_mount#Login_manager_configuration

Пример файла /etc/pam.d/system-auth при аутентификации доменного пользователя под SSSD:

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

• uid=»10000-2000200000″ — диапазон присваиваемых для доменных пользователей UID (подходит и для Winbind и для SSSD);
• server=»c253.test.alt» — имя сервера с ресурсом;
• path=»sysvol» — имя файлового ресурса;
• mountpoint=»

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

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

• sgrp=»group_name» — имя группы, при членстве пользователя в которой, папка будет примонтирована.

Параметр sec=krb5i более безопасный, но требует больше вычислительных ресурсов. Вместо него можно указать sec=krb5.

Пример файла /etc/security/pam_mount.conf.xml :

Для отладки подключения замените в файле /etc/security/pam_mount.conf.xml

При этом отладочные сообщения будут показываться в журнале Journald.

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

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

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

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

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

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

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

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

SSSD [ править ]

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

Источник

Участник:AlenkaGlukhovskaya/ActiveDirectory/Login

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

Содержание

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

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

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

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

• pam-config >= 1.7.0-alt1
• alterator-auth >= 0.26-alt1

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

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

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

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

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

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

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

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

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

Включите флажок «Получать точное время с NTP-сервера» и укажите в поле справа pool.ntp.org . После этого нажмите кнопку «Применить».

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

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

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

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

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

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

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

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

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

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

1. Ограничение: имя домена должно указывать на DC. Если это не так, поправляйте /etc/krb5.conf и вводите вручную, либо в файл /etc/hosts добавьте строку с контроллером домена (кдц) ДОМЕН.local и перезапустите сеть. После этого проверьте из командной строки ping ДОМЕН.local и вводите в домен
2. При указании домена, имеющего суффикс .local, потребуется на сервере и подключаемых компьютерах под управлением Linux отключить службу avahi-daemon — # chkconfig avahi-daemon off; reboot (доменная зона «local.» используется в технологии zeroconf).
3. Следите за синхронизацией времени на клиенте и сервере.
4. Для предотвращения кэширования имён пользователя отключите службу nscd .
5. В новых версиях Samba до запуска службы winbind должна запускаться служба smb .
6. Если возникает проблема просмотра билетов Kerberos под доменным пользователем, скопируйте правильный krb5.conf из samba:

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

Настройка 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 required pam_sss.so )

и в секцию session:

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

• uid=»10000-2000200000″ — диапазон присваиваемых для доменных пользователей UID (подходит и для Winbind и для SSSD)
• server=»c228″ — имя сервера с ресурсом
• path=»sysvol» — имя файлового ресурса
• mountpoint=»

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

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

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

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

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

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

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

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

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

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

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

SSSD [ править ]

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

Источник

Ввод в домен на базе Windows 2003

Содержание

Ввод в домен на базе Win 2003 рабочей станции под управлением Simply Linux [ править ]

Задача [ править ]

Ввести в домен на базе Winows Server 2003 машину под управлением Simply Linux.

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

Устанавливаем необходимые пакеты [ править ]

Настраиваем сетевое соединение [ править ]

Проверяем его доступность по ip-адресу:

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

Для того, чтобы узел отвечал по имени, необходимо указать домен поиска OFFICE.DOMEN.LOCAL. В Центре Управления Системой это указывается в настройках сетевого интерфейса в поле Домены поиска. Не забываем нажать Применить.

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

В файл /etc/hosts добавляем запись о нашей машине:

И соответственно в домен машину мы ввести не сможем. Ищем файл /etc/nsswitch.conf, в нем строку с hosts:

У по умолчанию она имеет вид:

И приводим ее к такому виду:

Сохраняем изменения и проверяем:

Настраиваем сервисы самбы [ править ]

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

Делаем то же самое для winbind:

Запускаем сервис самба:

Чтобы сервис swat запускался автоматически: в файле /etc/xinetd.d/swat меняем значение disable с yes на no и перезапускаем службу:

Запускаем swat в браузере: http://localhost:901 (либо же правим /etc/samba/smb.conf соотвественно)

Во вкладке GLOBALS ставим следующие значения:

Подтверждаем изменения нажав кнопку commit changes наверху страницы. И последние значения настраиваем, переключившись в режим advanced view (сложный):

Снова подтверждаем изменения (сохранить изменения). Далее во вкладке STATUS запускаем или перезапускаем службы, Restart All (замечу что winbindd на этом этапе еще не работает).

Настраиваем синхронизацию времени с нашим контроллером домена [ править ]

Проверяем уровни запуска службы:

Добавляем в конфигурационный файл /etc/ntpd.conf запись о сервере времени для синхронизации, все остальное комментируем:

Запускаем синхронизацию времени:

И только после этого запускаем службу:

Настраиваем службу аутентификации для получения билетов Kerberos [ править ]

Для того что бы Kerberos производил аутентификацию на контролере домена, а не на локальной машине, правим /etc/krb5.conf. Приводим его к виду (обратите внимание на регистр, где заглавными, так и должно быть):

Пробуем получить билет авторизации:

Если все прошло хорошо, в ответ на этот запрос вы ответа не получите.

Проверяем наличие билета командой klist, вывод должен быть примерно такой:

Правим /etc/nsswitch.conf примерно до такого вида:

Чтобы изменения в конфиге /etc/nsswitch.conf вступили в силу без перезагрузки, нужно от рута дать команду:

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

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

Для того, чтобы в нашу систему можно было логиниться под доменными аккаунтами и авторизация шла через winbind, необходимо оставить /etc/pam.d/gdm или /etc/pam.d/lightdm в прежнем виде:

(Для KDE4 это файл /etc/pam.d/kde4)

А /etc/pam.d/system-auth-winbind к виду (если его нет, то создать):

И /etc/pam.d/system-auth-use_first_pass-winbind к виду(если его нет, то создать):

Не забываем переключить авторизацию на winbind

С такими конфигами будет работать авторизация из gdm, gnome-screensaver, ssh.

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

Добавляем пользователей с административными привилегиям (sudo) [ править ]

Разрешаем всем вызывать sudo:

Разрешаем группе администраторов LinuxAdmins (должна быть создана) повышать свои привилегии без запроса пароля:

Настраиваем автомонтирование сетевых ресурсов [ править ]

Устанавливаем smbnetfs, samba, samba-client, fuse-smb.

Создаем /etc/fuse.conf и добавляем запись:

Добавляем в /etc/modules запись:

Копируем /usr/share/doc/smbnetfs/smbnetfs.conf в /home/%username%/.smb/

Копируем /etc/samba/smb.conf в /home/%username%/.smb/

Добавляем пользователя в группу fuse.

Создаем в домашнем каталоге каталог (например) /home/%username%/net

Создаем скрипт запуска в удобном для нас месте (например) /home/%username%/.smb/net со следующим содержанием:

Библиография [ править ]

Инструкция составлена с применением следующих ресурсов:

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

KDesktop [ править ]

На KDesktop мне не удалось настроить вход в домен AD используя

Взамен этого можно сделать некоторые ручные манипуляции

Доступ к локальным группам [ править ]

Чтобы все доменные пользователи были включены в определенные локальные группы (могли переключаться в root, запускать VirtualBOX и проч.) нужно добавить в /etc/security/group.conf

в конф. файл входа в систему( для KDE это /etc/pam.d/kde4)

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

После переустановки системы (при сохранении раздела /home) необходимо выставить владельца домашнего каталога доменного пользователя (владелец меняется)

Смена имени хоста [ править ]

Если нужно сменить имя хоста, править HOSTNAME в файле /etc/sysconfig/network

Два IP-адреса [ править ]

Замечены проблемы со входом доменного пользователя при наличии двух IP-адресов. На этапе первого входа пользователя лучше от второго IP временно отказаться.

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

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

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

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

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

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

Источник

Домен/Windows/Manual

Предполагается, что домен ALT Linux создан должным образом и работает.

Содержание

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

1. В секции [global] файла /etc/samba/smb.conf добавьте:

Внимание! При использовании домена в Windows будет использоваться имя рабочей группы WORKGROUP (параметр workgroup в /etc/samba/smb.conf). Вы можете поменять его на имя ALT-домена:

Если хотите автоматически подключать общую папку (ресурс share на сервере как диск S: ), то выполните следующее:

2. Перезапустите службу smb и запустите службу nmb:

Службу nmb нужно добавить в автоматический запуск:

3. Обновите ldap-user-tools до версии 0.8.0 или более позднее.

Создание групп и выдача административных привилегий [ править ]

2. В LDAP создайте группы через веб-интерфейс или из командной строки:

Эти группы понадобятся для привязки к группам домена согласно таблице:

Добавьте туда пользователей через веб-интерфейс или из командной строки:

3. Привяжите группы LDAP к группам домена

Примечание: Обратите внимание, пароль можно указывать у имени пользоватeля через «%».

4. Выдайте привилегии для группы Domain Admins :

Проверка (просмотр всех привилегий по группам):

Примечание: обратите внимание, что для заведения компьютера в домен нужно входить в группу с привилегией SeMachineAccountPrivilege.

5. Чтобы не было коллизий с системным пользователем root, после операции по назначению группы и привилегий этого пользователя нужно удалить или восстановить его UID:

6. Проверяем вход в домен администратора cas:

Примечание: проверять вход в домен на сервере следует от пользователя, входящего в группу ‘Domain Admins’. Остальным это запрещено. Список зарегистрированных компьютеров можно посмотреть командой:

Всё в порядке, можно вводить компьютеры с Windows в наш домен.

Права доступа [ править ]

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

Для пользователей, входящих в группу Domain Users (или группу Users в LDAP) имеется доступ на диск Z: (домашняя папка пользователя на сервере с создаваемым подкаталогом profile ).

Список входящих в эту группу:

Скрипт при входе [ править ]

При входе можно запускать скрипт в формате bat. Для этого в /etc/samba/smb.conf нужно добавить раздел описания ресурса netlogon :

Примечание: концы строк в файле bat должны быть в стиле dos (rn) (режим :set ff=dos в vim).

Решение проблем [ править ]

Если что-то пошло не так. [ править ]

Если в результате экспериментов сломались привилегии или что-нибудь ещё, нужно очистить внутренние базы Samba. Выполните

Отладка Samba [ править ]

Полезно включить уровень отладки 5 в /etc/samba/smb.conf:

После этого необходимо перечитать конфигурацию:

Смена имени сервера Samba [ править ]

Так как при создании нового пользователя в домене для него прописывается SID, при смене имени сервера серверная часть SID меняется и пользователи со старыми SID уже недоступны, показывается примерно такое

При этом новые пользователи заводятся уже с правильным SID. Для исправления ситуации со старыми пользователями нужно выполнить следующий скрипт:

После этого команда

должна показать имена всех пользователей.

Нюансы реализации [ править ]

Известные проблемы [ править ]

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

Ещё проблема+решение ниже: при попытке подключения к samba-шаре по из-под Windows XP и с МФУ (т.н. сканирование в папку SMB) логин и пароль не принимаются, возникает ошибка:

Источник

Домен/Windows

Использование домена для аутентификации компьютеров с Windows. ALT-домен можно использовать для следующих возможностей:

Примечание: в конфигурации по умолчанию не предусмотрена работа с профилями.

Содержание

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

Создайте домен в модуле «Домен». При показе состояния домена в этом модуле показывается рабочая группа:

В скобках показывается установленное имя домена для Windows.

Права доступа [ править ]

По умолчанию в эту группу добавляются все новые пользователи.

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

1. Нажмите правой кнопкой мыши по значку «Мой компьютер» и выберите пункт «Свойства» (быстро этот можно сделать, нажав Win+Pause ).

2. В появившемся окне перейдите на вкладку «Имя компьютера» и нажмите кнопку «Изменить…»

5. При указании правильных данных появится диалоговое окно, подтверждающее регистрацию компьютера в домене.

7. В окне входа нажмите кнопку «Параметры >>»

8. В выпадающем списке «Вход в» выберите свой домен.

При указании правильного имени пользователя и пароля вы войдёте в систему и можете работать.

Вход в ALT-домен систем на Windows 7/8 [ править ]

Внимание! Перезагрузите Windows или перезапустите службу LanmanWorkstation после добавления этих параметров.

Если вы изменяли параметры Netlogon, проверьте, чтобы было установлено

После этого можно зарегистрироваться штатным способом.

Для снижения времени входа на Windows 7 рекомендуется поправить параметры:

Источник

Как ввести компьютер с ОС АЛЬТ в домен 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.

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

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

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

Источник

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 имеет внутреннюю поддержку следующих групповых политик:

Источник

• Ввод в домен AD
  • Ручной ввод в домен
  • Ввод в домен в графической сессии

Ручной ввод в домен¶

• Рекомендую всегда, перед таким манипуляциями обновлять систему до актуального состояния. ПО и ядро

  apt-get update
  apt-get dist-upgrade
  update-kernel
  

• установить необходимые пакеты

  apt-get install sssd sssd-ad samba
  

• отключить демон avahi (если у вас используется dns зона .local)

  systemctl stop avahi-daemon, systemctl disable avahi-daemon

• в файле /etc/nsswitch.conf
  в секциях passwd, shadow, group дописать sss

  passwd:     files mymachines sss
  shadow:     tcb files sss
  group:      files [SUCCESS=merge] sss role 

• файл /etc/sssd/sssd.conf довести до вида

  [sssd]
  config_file_version = 2
  user = root
  domains = ADM72.LOCAL
  services = pam,nss
  
  [nss]
  
  [pam]
  
  [domain/ADM72.LOCAL]
    id_provider = ad
    auth_provider = ad
    chpass_provider = ad
    default_shell = /bin/bash
    fallback_homedir = /home/%d/%u
    ad_server = dc-sovet61.adm72.local
    ad_backup_server = _srv_
    cache_credentials = true
    debug_level = 2
  

Запустить демон sssd — systemctl enable sssd ; systemctl start sssd

• в файле /etc/samba/smb.conf изменить секцию global, там где *** ИМЯ-КОМПЬЮТЕРА *** — поменять на имя под которым он заведен в AD

  
  [global]
          security = ads
          realm = ADM72.LOCAL
          workgroup = ADM72
          netbios name = *** ИМЯ-КОМПЬЮТЕРА ***
          template shell = /bin/bash
          kerberos method = system keytab
          wins support = no
          idmap config * : range = 10000-20000000
          idmap config * : backend = tdb
  

• ввести в домен используя учетную запись доменного администратора

  net ads join -U Administrator -S dc2-sovet61.adm72.local
  

  или

  system-auth write ad ADM72.LOCAL _hostname_ ADM72 'administrator' 'Pa$$word'