Настройка ldap windows server 2019

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

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

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

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

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

Для Alt Linux написана хорошая инструкция http://freesource.info/wiki/AltLinux/Dokumentacija/SambaInWin2kDomain?v=omo&

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

• Проверяем что Samba собрана с поддержкой Kerberos:

# smbd -b | grep KRB

   HAVE_KRB5_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_DECODE_KRB5_AP_REQ
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_C_ENCTYPE_COMPARE
   HAVE_KRB5_C_VERIFY_CHECKSUM
   HAVE_KRB5_ENCRYPT_BLOCK
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_FREE_AP_REQ
   HAVE_KRB5_FREE_DATA_CONTENTS
   HAVE_KRB5_FREE_KEYTAB_ENTRY_CONTENTS
   HAVE_KRB5_FREE_KTYPES
   HAVE_KRB5_FREE_UNPARSED_NAME
   HAVE_KRB5_GET_PERMITTED_ENCTYPES
   HAVE_KRB5_GET_RENEWED_CREDS
   HAVE_KRB5_KEYBLOCK_IN_CREDS
   HAVE_KRB5_KEYTAB_ENTRY_KEY
   HAVE_KRB5_KEYUSAGE_APP_DATA_CKSUM
   HAVE_KRB5_KT_FREE_ENTRY
   HAVE_KRB5_LOCATE_KDC
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL2SALT
   HAVE_KRB5_PRINC_COMPONENT
   HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
   HAVE_KRB5_SET_REAL_TIME
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_TKT_ENC_PART2
   HAVE_KRB5_USE_ENCTYPE
   HAVE_LIBGSSAPI_KRB5
   HAVE_LIBKRB5
   HAVE_MAGIC_IN_KRB5_ADDRESS
   HAVE_TICKET_POINTER_IN_KRB5_AP_REQ
   KRB5_VERIFY_CHECKSUM_ARGS

• Также проверим что поддерживается LDAP

# smbd -b | grep LDAP

   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_ADD_RESULT_ENTRY
   HAVE_LDAP_DN2AD_CANONICAL
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

• Для корректной работы Samba в домене Windows 2003 нужны версии MIT Kerberos version >=1.3.1. Проверим:

# dpkg -l | grep krb

ii  krb5-config    1.22                       Configuration files for Kerberos Version 5
ii  libkrb53       1.6.dfsg.4~beta1-5lenny1   MIT Kerberos runtime libraries

• Для корректной работы с Windows 2008 серверами сама Samba должна быть достаточно свежая:

# smbd -V

Version 3.2.5

Установка Samba

• Устанавливаем сервер и клиент samba.

# apt-get install samba samba-client krb5-config

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

Настройка Samba

• Для подключения к домену Active Directory удобно использовать утилиту Likewise-Open.

• Для администрирования Samba удобно использовать SWAT или webmin, которые предоставляют веб интерфейс. Попасть на него можно по адресу http://server_address:901 и https://server_address:10000 соответственно, указав для соединения пользователя root. Но будьте осторожны — он полностью переписывает smb.conf и некоторые параметры может просто игнорировать. Лучше предварительно сделать резервную копию файла. Я сначала использовал SWAT, а затем дорабатывал конфигурационный файл /etc/samba/smb.conf руками. Вот, что осталось у меня не закоментированным (принтеры к этому серверу не подключены):

[global]
        unix charset = LOCALE
        realm = WORKGROUP.DOMAIN.LOCAL
        server string = Storage samba server
        interfaces = eth0
        bind interfaces only = Yes
        security = ADS
        obey pam restrictions = Yes
        passdb backend = tdbsam
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .
        log level = 3
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 100
        name resolve order = lmhosts host wins bcast
        printcap name = CUPS
        local master = No
        domain master = No
        dns proxy = No        
        ldap ssl = no
        panic action = /usr/share/samba/panic-action %d
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        template shell = /bin/bash
        invalid users = root

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

[distrib]
        path = /data/distrib
        valid users = @WORKGROUP\DistribGroup
        write list = @WORKGROUP\DistribGroup
        read only = No
        create mask = 0777
        directory mask = 0777

[backup]
        path = /data/backup
        valid users = @WORKGROUP\BackupGroup
        write list = @WORKGROUP\BackupGroup
        read only = No
        create mask = 0777
        directory mask = 0777

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

• backup — доступ имеют только пользователи входящие в группу BackupGroup в Active Directory. Они могут создавать и удалять файлы/каталоги
• distrib — доступ имеют все пользователи входящие в группу DistribGroup в Active Directory

В приведённой конфигурации подразумевается, что eth0 — это сетевой интерфейс в локальную сеть, где домен имеет полное имя WORKGROUP.DOMAIN.LOCAL

• редактируем /etc/nsswitch:

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind

hosts:          files dns wins
networks:       files dns

protocols:      files
services:       files
ethers:         files
rpc:            files

netgroup:       files

• Проверим, что в /etc/hosts есть корректная запись для нашего сервера, также можно добавить записи для контроллеров доменов:

10.0.0.15      storage.domain.local storage
10.0.0.85      dcwg1.domain.local dcwg1
10.0.0.245     dcwg2.domain.local dcwg2

• Удаляем если есть (или переносим в резервные копии) файл /etc/samba/secrets.tdb и все файлы из /var/lib/samba/*.tdb

• Проверяем конфигурацию (не обязательно):

1. testparm -s

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

• Проверим как Samba-3 winbind общается с контроллером домена Active Directory посредством протокола Kerberos:

# net ads info

LDAP server: 10.0.0.85
LDAP server name: dcwg1.workgroup.domain.local
Realm: WORKGROUP.DOMAIN.LOCAL
Bind Path: dc=WORKGROUP,dc=DOMAIN,dc=LOCAL
LDAP port: 389
Server time: Срд, 03 Мар 2010 13:12:14 NOVT
KDC server: 10.0.0.85
Server time offset: -5

На рассхождение времени в секундах указывает строка «Server time offset: -5». Обратите внимание, что протокол Kerberos зависим от времени, и расхождение с часами контроллера домена допускается лишь незначительное, поэтому желательно настроить NTP клиент (см. статьи по настройке NTP). В Ubuntu это указывается в файле /etc/default/ntpdate:

NTPSERVERS="10.0.0.85 10.0.0.245"

• В Debian (и его сыновьях, таких как Ubuntu и внуках вроде Linux Mint) при установке пакета krb5-cofig сразу предлагается его настройка. Лучше всего попробовать работать с этими настройками, но если ничего предложено не было или мы хотим что-то изменить, то редактируем /etc/krb5.conf (я для более стабильной работы использовал ip адреса вместо имён серверов):

[libdefaults]
        default_realm = WORKGROUP.DOMAIN.LOCAL

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
#
#...
#
# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        WORKGROUP.DOMAIN.LOCAL = {
                kdc = 10.0.0.85
                kdc = 10.0.0.245
                admin_server = 10.0.0.85
        }
#
#...
#
[login]
        krb4_convert = true
        krb4_get_tickets = false

• Проверим работает ли Kerberos, постараемся получить билет и просмотреть его:

# kinit administrator@WORKGROUP.DOMAIN.LOCAL
Password for administrator@WORKGROUP.DOMAIN.LOCAL:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@WORKGROUP.DOMAIN.LOCAL

Valid starting     Expires            Service principal
03/06/10 14:51:41  03/07/10 00:51:47  krbtgt/WORKGROUP.DOMAIN.LOCAL@WORKGROUP.DOMAIN.LOCAL
        renew until 03/07/10 14:51:41

• Удалим полученный билет:

# kdestroy

• Присоединяемся к домену:

# net ads join -UAdministrator

Administrator's password:
Using short domain name -- WORKGROUP
Joined 'STORAGE' to realm 'WORKGROUP.DOMAIN.LOCAL'

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

[2010/03/06 15:04:00,  0] libads/kerberos.c:332(ads_kinit_password)
  kerberos_kinit_password STORAGE$@WORKGROUP.DOMAIN.LOCAL failed: Client not found in Kerberos database DNS update failed!

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

• Для удобства отладки сделаем ссылку на каталог журналов:

# ln -s /var/log/samba /etc/samba/log

• Запускаем samba и winbind:

# /etc/init.d/samba start
# /etc/init.d/winbind start

• Для проверки правильно ли подключение к домену можно посмотреть список пользователей и групп домена (не обязательно):

# wbinfo -u
# wbinfo -g

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

# wbinfo --set-auth-user=root%root_password
# wbinfo --all-domains
# wbinfo -D WORKGROUP
# wbinfo -t

• Проверяем, как работает NSS. Команда getent показывает инфо о пользователе, который может быть как в домене, так и юниксовый:

# getent passwd | grep pm
pm:x:15000:15000::/home/WORKGROUP/pm:/bin/false

# getent passwd | grep pavel
pavel:x:500:500:Pavel Malahov:/home/pavel:/bin/bash

• Теперь можно использовать ресурсы на линукс-сервере, на которые мы дали доступ, как обычные доменные ресурсы.

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

• Можно также сопоставить (но это не обязательно) локальные учётные данные и из домена Windows. Для сопоставления пользователей редактируем файл /etc/samba/smbusers.conf:

root = admin administrator

• для сопоставления (мапирования от англ. Map) групп домена и групп UNIX выполняем:

# net groupmap modify ntgroup="Domain Admins" unixgroup=root
# net groupmap modify ntgroup="Domain Users" unixgroup=users
# net groupmap modify ntgroup="Domain Guests" unixgroup=nobody

• После того как всё отлажено, можно понизить уровень записи в журнал до «1». В /etc/samba/smb.conf:

log level = 1

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

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

Пуск — Панель управления — Администрирование — Локальная политика безопасности — Локальные политики — Параметры безопасности

• Сетевая безопасность: минимальная сеансовая безопасность для клиентов на базе NTLM SSP — убрать галочку с «Требовать 128-битное шифрование». Таких параметра два — выполнить для обоих
• Сетевая безопасность: уровень проверки подлинности LAN Manager — выбрать в списке пункт «Отправлять LM- и NTML-ответы»

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

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

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

# /etc/init.d/winbind status
 * winbind is not running

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

[2010/03/06 13:54:34,  2] winbindd/winbindd_util.c:235(add_trusted_domain)
  Added domain BUILTIN  S-1-5-32
[2010/03/06 13:54:34,  2] winbindd/winbindd_util.c:235(add_trusted_domain)
  Added domain STORAGE  S-1-5-21-3963871611-1338977097-196861091
[2010/03/06 13:54:34,  0] winbindd/winbindd_util.c:782(init_domain_list)
  Could not fetch our SID - did we join?
[2010/03/06 13:54:34,  0] winbindd/winbindd.c:1385(main)
  unable to initialize domain list

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

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

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

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

kinit: KDC reply did not match expectations while getting initial credentials

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

Полезная ссылка: http://subscribe.ru/archive/comp.soft.win.linuxsa/200510/19115643.html

Полезные комманды

См. также

• Статья Samba даёт краткий общий обзор пакета Samba утилит для него, а также описывает простой (без авторизации в домене) способ предоставления каталогов в общий доступ.

Cсылки

• http://linux.yaroslavl.ru//docs/serv/samba/samba-win2000.html — Samba и доменная аутентификация Windows2000
• http://us6.samba.org/samba/docs/man/Samba-Guide/unixclients.html#adssdm- Active Directory Domain with Samba Domain Member Server — подробная инструкция как подключить Linux сервер с помощью Samba 3 к домену под управлением AD Windows 2003.
• http://us6.samba.org/samba/docs/man/Samba-Guide/kerberos.html#id397375 — пример настройки доступа для пользователей Active Directory
• Samba-HOWTO-Collection.pdf, стр.54-57 (поставляется с исходниками) или
• http://jcifs.samba.org/ntstatus.txt — описание статусов

Интеграция Linux-серверов в домен Windows Active Directory (AD) позволяет централизованно управлять пользователями и упростить аутентификацию. В этой статье мы рассмотрим, как добавить Debian в домен Windows AD, используя realmd и SSSD.

Описание используемых служб:

• Realmd (Realm Discovery) – сервис D-Bus, позволяющий производить настройку сетевой аутентификации и членства в домене (Active Directory) без сложных настроек. Информация о домене обнаруживается автоматически. Для аутентификации и проверки учетных записей realmd использует SSSD (через Kerberos и LDAP) или Winbind.
• SSSD (System Security Services Daemon) — это клиентский компонент централизованных решений для управления идентификацией, таких как Microsoft Active Directory, Kerberos, OpenLDAP  и других серверов каталогов. SSSD обслуживает и кэширует информацию, хранящуюся на удаленном сервере каталогов, и предоставляет услуги идентификации, аутентификации и авторизации хост-машине.

Исходные данные:

• Контроллер домена (DC1) на Windows Server 2019, домен JAKONDA.LOCAL (IP — 192.168.1.100)
• Linux система (debian) на Debian 11 Bullseye (IP — 192.168.1.10)

Подготовка системы

Перед началом убедитесь, что ваша система Debian обновлена:

apt-get update && apt-get upgrade -y

Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле /etc/hostname:

debian.jakonda.local

Файл /etc/hosts приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP хоста:

127.0.0.1	localhost
192.168.1.10	debian.jakonda.local debian

Настраиваем клиент DNS на хосте. Файл /etc/resolv.conf приводим к виду с учетом ваших данных:

domain jakonda.local
search jakonda.local
nameserver 192.168.1.100

Настройка синхронизации времени

Для корректной аутентификации по протоколу Kerberos необходимо синхронизировать время сервера и клиента. Если системные часы расходятся более чем на 5 минут, то аутентификация не будет выполнена.

Установим NTP сервер и выполним синхронизацию времени с контроллером домена:

apt-get install ntp ntpdate -y

ntpdate dc1.jakonda.local

Установка необходимых пакетов

Устанавливаем необходимые пакеты:

apt-get install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit -y

Проверка доступности домена

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

realm discover jakonda.local -v

 * Resolving: _ldap._tcp.jakonda.local
 * Performing LDAP DSE lookup on: 192.168.1.10
 * Successfully discovered: jakonda.local
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: no

Команда realm discover возвращает полную конфигурацию домена и список пакетов, которые необходимо установить, чтобы система была зарегистрирована в домене.

Предварительная настройка

Перед вводом в домен, можно настроить realmd переопределив настройки по-умолчанию. Это делается путем размещения настроек в файле /etc/realmd.conf¹.

Настройки в этом файле применяются только в момент присоединения к домену или области.

Для примера зададим атрибуты системы для объекта компьютера в Active Directory (атрибуты operatingSystem и operatingSystemVersion) и укажем в какую OU поместить объект:

[active-directory]
os-name = Debian GNU/Linux
os-version = 11.8 (Bullseye)

[jakonda.local] 
computer-ou = OU=Linux Computers,DC=jakonda,DC=local

Ввод в домен

Для ввода системы в домен выполните команду:

realm join jakonda.local -U Administrator
Password for Administrator:

Замените Administrator на учетную запись с правами на добавление компьютеров в домен.

Проверим, что система находится в домене:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@jakonda.local
  login-policy: allow-realm-logins

Инструмент realmd после ввода системы в домен, создает файл конфигурации — /etc/sssd/sssd.conf:

[sssd]
domains = jakonda.local
config_file_version = 2
services = nss, pam

[domain/jakonda.local]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = JAKONDA.LOCAL
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = jakonda.local
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Этих параметров достаточно для авторизации доменных пользователей в системе.

Важно помнить, что файл /etc/sssd/sssd.conf должен иметь разрешения 600 и root:root, иначе демон sssd не будет запускаться.

В случае внесения каких то изменений в файл конфигурации, то после этого всегда необходимо перезапускать SSSD:

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

Проверим, что учетные записи из домена доступны. Получим информацию о доменном пользователе — jakonda@jakonda.local.

getent passwd jakonda@jakonda.local
jakonda@jakonda.local:*:1851201887:1851200513:Jakonda:/home/jakonda@jakonda.local:/bin/bash

Проверим в каких группах пользователь jakonda@jakonda.local состоит:

groups jakonda@jakonda.local
jakonda@jakonda.local : domain users@jakonda.local domain admins@jakonda.local

Если вы только что изменили членство пользователя в группе, может пройти некоторое время, прежде чем sssd заметит это из-за кэширования.

Попробуем войти в систему:

sudo login

debian.jakonda.local имя пользователя: Jakonda
Пароль:
Linux debian.jakonda.local 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Создание каталога /home/jakonda@jakonda.local.

Автоматическое создание домашнего каталога

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

pam-auth-update --enable mkhomedir

Результатом выполнения команды будет, добавление в /etc/pam.d/common-session строки:

session optional                        pam_mkhomedir.so umask=0022 skel=/etc/skel

Управление разрешениями на вход для пользователей домена

Чтобы задать правила доступа, используйте следующие две команды:

• realm deny
• realm permit

Глобальные разрешения

Чтобы предоставить или запретить доступ для всех пользователей, используется команда с параметром --all:

realm permit --all
realm deny --all

Разрешения по пользователям

Чтобы предоставить доступ указанным пользователям, используется команда:

realm permit user@jakonda.local
realm permit 'JAKONDA.LOCAL\user'

Разрешения по группам безопасности

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

ream permit -g %Domain\admins@jakonda.local

Запрещающие правила

Чтобы запретить доступ указанным пользователям, используется команда с параметром -x:

realm permit -x user@jakonda.local

SUDO разрешения

Для разрешения определенным доменным пользователями возможность выполнения sudo, создадим отдельный файл в котором укажем доменную группу безопасности в которую уже будут входить нужные пользователи.

Создаем файл /etc/sudoers.d/admins со следующим содержанием:

%ServerAdmins ALL=(ALL) ALL

Хочу заместить если группа безопасности содержит пробелы, например — Domain admins, то указывать ее нужно в формате — %Domain\admins

Вывод из домена

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

Сперва выводим список сконфигурированных доменов:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-realm-logins

Для вывода системы из домена, выполняем команду:

realm leave -v -U Administrator@jakonda.local

Замените Administrator на учетную запись с правами на удаление компьютеров в домен и jakonda.local на свой домен.

Если в выводе сконфигурированных доменов присутствует две записи (две записи присутствуют при использовании двух client-software — winbind и sssd), к примеру вот так это выглядит:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: winbind
  required-package: winbind
  required-package: libpam-winbind
  required-package: samba-common-bin
  login-formats: JAKONDA\%U
  login-policy: allow-any-login
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-realm-logins

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

realm leave -v --client-software=sssd -U Administrator@jakonda.local
realm leave -v --client-software=winbind -U Administrator@jakonda.local

Очистка системы

После вывода системы из домена, удаляем кеш SSSD и Kerberos.

Останавливаем SSSD демон:

Удаляем SSSD кеш:

Удаляем Kerberos кеш:

1. Подробное описание realmd-conf — https://www.freedesktop.org/software/realmd/docs/realmd-conf.html ↩︎

1. Конфигурационные файлы.

Мы будем настраивать только доступ к серверу GNU/Linux с использованием Samba. Авторизация пользователей останется локальной, с использованием /etc/passwd.
Мы присвоим нашему новому серверу статический IP-адрес. Пусть им будет 192.168.7.9.
Для начала нужно проверить, какой сервер у нас используется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адрес сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен выглядеть следующим образом:

search lab.local
nameserver 192.168.7.2

Проверим, все ли работает:

#host 192.168.7.2
2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local.
#

Естественно, в Вашем случае имена будут другими. Обязательно сделайте в домене lab.local запись в DNS, ссылающуюся на наш новый сервер. Запись в DNS не означает того, что наш GNU/Linux сервер включен в домен. Проверим:

linux-test:~ # host 192.168.7.9
9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local.
linux-test:~ # host test-linux
test-linux.lab.local has address 192.168.7.9
linux-test:~ #

Для корректной работы в домене Windows требуется несколько служб: Kerberos, LDAP и Samba. В общем случае требуется только настройка Samba, настройка других служб не является обязательной. Но будет лучше, если мы их настроим – они могут пригодиться в будущем.
Kerberos настраивается просто – через один файл /etc/krb5.conf. Основными параметрами является REALM, указывающий на наш домен и адрес сервера Kerberos – это адрес контроллера домена. Файл /etc/krb5.conf выглядит примерно так:

linux-test:~ # more /etc/krb5.conf
[libdefaults]
        default_realm = LAB.LOCAL
        clockskew = 300
#       default_realm = EXAMPLE.COM

[realms]
LAB.LOCAL = {
        kdc = 192.168.7.2
        default_domain = lab.local
        admin_server = 192.168.7.2
}
#       EXAMPLE.COM = {
#                kdc = kerberos.example.com
#               admin_server = kerberos.example.com
#       }

[logging]
        kdc = FILE:/var/log/krb5/krb5kdc.log
        admin_server = FILE:/var/log/krb5/kadmind.log
        default = SYSLOG:NOTICE:DAEMON
[domain_realm]
        .lab.local = LAB.LOCAL
[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        minimum_uid = 1
        external = sshd
        use_shmem = sshd
        clockskew = 300
}

Секция [libdefaults] указывает на домен по умолчанию. У нас это LAB.LOCAL. Далее, в секции [realms] указываются параметры для LAB.LOCAL – имя домена и адрес сервера Kerberos. В нашем случае, в качестве сервера Kerbeors выступает контроллер домена. В секции [logging] указывается местоположение лог-файлов. Эти файлы пригодятся для процедуры поиска неисправности, если что-то пойдет не так.
Проверим работу Kerberos:

linux-test:~ # kinit Administrator@LAB.LOCAL
Password for Administrator@LAB.LOCAL:
linux-test:~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@LAB.LOCAL

Valid starting     Expires            Service principal
04/05/12 11:22:23  04/05/12 21:22:35  krbtgt/LAB.LOCAL@LAB.LOCAL
        renew until 04/06/12 11:22:23
linux-test:~ #

Команда kinit получает от сервера тикет, а klist показывает полученные тикеты от сервера. Выполнение kinit не является обязательным, но ведь нужно как-то проверить работу Kerberos?
Настройка LDAP тоже не является обязательной – Samba сама построит необходимые файлы и сделает нужные запросы. Но LDAP может пригодиться в дальнейшем. Конфигурация OpenLDAP хранится в файле /etc/openldap/ldap.conf. Обратите внимание – в системе может быть два файла ldap.conf. У них разные предназначения и даже немного разный синтаксис. В каталоге /etc/openldap лежит файл ldap.conf для OpenLDAP (и для Samba), а в файле /etc/ldap.conf хранится конфигурация для разрешения имен через LDAP (для nss_ldap). К файлу /etc/ldap.conf мы вернемся в других статьях, сейчас настроим /etc/openldap/ldap.conf

linux-test:~ # cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never
uri     ldap://192.168.7.2
base    DC=lab,DC=local
linux-test:~ #

Как видите, все очень просто – нужно указать URI сервера LDAP (это наш контроллер домена) и базу для поиска.
Теперь переходим к самому сложному – настройке Samba.
В состав Samba входят 3 демона – smbd, nmbd и winbind. Все они берут настройки из файла /etc/samba/smb.conf.
Smbd отвечает за доступ клиентов к службе SMB/CIFS (собственно это и есть сервер Samba). Nmbd – это служба разрешения имен для Netbios. Winbind – служба разрешения имен (и компьютеров и пользователей) через доменные службы Windows.
Во многих руководствах можно встретить упоминание того, что кроме Samba требуется настраивать и winbind – службу, отвечающую за отношения между GNU/Linux и контроллером домена Windows. В частном случае, когда нужно настроить только Samba, настройки winbind можно опустить. Winbind обеспечивает авторизацию в домене Windows самых различных служб, обеспечивая интерфейс между модулями PAM и контроллером домена Windows. При неработающем winbind Samba остается работоспособной. Но настроив winbind мы делаем возможным дальнейшее расширение нашего сервера за счет добавления различных служб, авторизующихся через контроллер домена.
Мы сделаем самый простой сервер, открыв всем пользователям доступ к некоторому общему каталогу файлов и к домашнему каталогу пользователей. Более подробно о настройке доступа к серверу Samba мы будем говорить в других статьях.
В файле /etc/samba/smb.conf мы должны указать следующие строки:

[global]
        workgroup = LAB
        passdb backend = ldapsam:ldap://192.168.7.2
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        logon path = \%Lprofiles.msprofile
        logon home = \%L%U.9xprofile
        logon drive = P:
        usershare allow guests = Yes

Здесь мы указываем сокращенное наименование нашего домена (LAB) и место, где хранятся пароли – параметр passdb backend, указывающий на то, что пароли находятся на сервере LDAP, в качестве которого выступает контроллер домена. Кстати, можно указать и несколько серверов, перечислив их через пробел. Это пригодится в том случае, если у нас несколько контроллеров домена. Строка usershare allow guests = Yes разрешает пользователям управлять доступом к своим папкам, открывая их для гостей. Остальные строки относятся к управлению печатью и процессу регистрации. В нашем случае они не являются обязательными и перекочевали из конфигурационного файла дистрибутива Samba.
Продолжим редактирование секции [global] файла smb.conf.

        domain logons = No
        domain master = No
        security = ADS
        encrypt passwords = yes

Строки domain logons и domain master разрешают использовать Samba в качестве контроллера домена. Это не наш случай и поэтому для них установлено No.
Строка security = ADS имеет ключевое значение. Тем самым мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt passwords = yes означает, что используются зашифрованные пароли.
Продолжим редактировать все ту же секцию [global].

        ldap admin dn = Administrator@lab.local
        ldap delete dn = No
        ldap group suffix = ou=Groups
        ldap idmap suffix = ou=Idmap
        ldap machine suffix = ou=Computers
        ldap passwd sync = Yes
        ldap ssl = No
        ldap suffix = DC=lab,DC=local
        ldap timeout = 5
        ldap user suffix = ou=Users

Эти строки относятся к управлению соединением с LDAP сервером. Заметьте, что форма записи DN администратора имеет форму user@domain – она должна совпадать с тем, что мы указывали при тестировании Kerberos. Остальные строки указывают суффиксы различных местоположений в AD.
Следующие строки относятся уже к Kerberos:

        realm = LAB.LOCAL
        template homedir = /home/%D/%U
        winbind refresh tickets = yes
        kerberos method = system keytab

Здесь мы указываем REALM и метод аутентификации в Kerberos.
Теперь строки, которые относятся к настройке winbind:

        winbind separator = /
        winbind enum users = yes
        winbind enum groups = yes
        winbind nested groups = yes
        winbind use default domain = No
        winbind nss info = rfc2307
        winbind offline logon = yes

Здесь указаны различные параметры работы Winbind – форма разделитя имен домена и пользователя, разрешение для winbind перечислять имена пользователей и групп, разрешение оффлайновой аутентификации и т.п. Эти настройки рекомендованы разработчиками Samba.
Секция глобальных настроек закончена. Обратите внимание, что у нас нет строк password server и idmap backend, которые можно встретить в других руководствах. Samba должна сама разобраться, откуда берутся пароли.
Переходим к настройке каталогов. Здесь все просто:

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        available = Yes
  [profiles]
        comment = Network Profiles Service
        path = %H
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
[users]
        comment = All users
        path = /home
        read only = No
        inherit acls = Yes
        veto files = /aquota.user/groups/shares/
[groups]
        comment = All groups
        path = /home/groups
        read only = No
        inherit acls = Yes
[SRV]
        comment = Common files
        path = /local
        write list = Administrator
        guest ok = Yes
        hosts allow = 192.168.7.

К стандартному списку разделяемых каталогов, распространяемому вместе с дистрибутивом Samba мы добавили только секцию [SRV] – общедоступный каталог.
Конфигурирование всех необходимых файлов закончено, и мы приступаем к проверке работоспособности нашего сервера.

2. Проверка работоспособности.

Здесь мы проверим корректность наших настроек и включим наш новый сервер в домен Windows. Сначала проверим корректность настройки Samba:
l

inux-test:~ # testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[users]"
Processing section "[groups]"
Processing section "[SRV]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

Как видно, каких либо серьезных предупреждений и ошибок конфигурации у нас нет.
Теперь запустим по очереди демоны smbd, nmbd и winbindd. Сделаем это через файлы /etc/init.d/smb, /etc/init.d/nmb и /etc/init.d/winbind. Можно выполнить это и вручную, что может оказаться полезным для получения различной дополнительной информации. О том, как это сделать можно прочесть во встроенных руководствах (man) по smbd, nmbd и winbindd.
Проверим состояние нашего домена и нашего сервера в домене. Состояние домена можно получить командой net ads info

linux-test:~ # net ads info
LDAP server: 192.168.7.2
LDAP server name: LAB-DC1.lab.local
Realm: LAB.LOCAL
Bind Path: dc=LAB,dc=LOCAL
LDAP port: 389
Server time: Thu, 05 Apr 2012 13:03:47 MSK
KDC server: 192.168.7.2
Server time offset: 4
linux-test:~ #

Как видно, все в порядке. Если какие-то параметры, выводимые командой не совпадают с нашим планом – надо искать причину. Теперь проверим состояние нашего сервера в домене:
l

inux-test:~ # net ads status -U Administrator
Enter Administrator's password:
No machine account for 'LINUX-TEST' found
linux-test:~ #

Отсюда следует, что наш сервер не включен в домен. Запрос к контроллеру домена делается от имени администратора, и пароль нужно указывать от учетной записи администратора домена Windows.
Теперь мы должны включить наш сервер в домен:
l

inux-test:~ # net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed!
linux-test:~ #

Итак, наш новый сервер включен в домен, о чем свидетельствуют строки:

Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'

Динамическое изменение DNS у нас не прошло. Это не страшно, поскольку оно и не планировалось. Теперь рекомендуется перезапустить все наши процессы – smbd, nmbd и winbindd. Заметим, что после перезапуска до дальнейших проверок должно пройти несколько минут.
Проверим статус нашего сервера в домене:

linux-test:~ # net ads status -U Administrator
Enter Administrator's password:

В ответ мы получим распечатку состояния нашего нового сервера в домене. Там будут указаны различные поля AD, относящиеся к нашему серверу. Так же наш сервер GNU/Linux мы увидим на вкладке Computers, запустив средство администратора AD на контроллере домена.

Можно проверить список пользователей домена:
l

inux-test:~ # net ads user -U Administrator
Enter Administrator's password:
Administrator
Guest
krbtgt
usertest
linux-test:~ #

И проверим работу winbind:

linux-test:~ # wbinfo -t
checking the trust secret for domain LAB via RPC calls succeeded
linux-test:~ #

И получим список пользователей в домене:
l

inux-test:~ # wbinfo -u
LAB/administrator
LAB/guest
LAB/krbtgt
LAB/usertest
linux-test:~ #

Можно проверить состояние домена через wbinfo:
l

inux-test:~ # wbinfo -D LAB
Name              : LAB
Alt_Name          : lab.local
SID               : S-1-5-21-3914562201-450990341-53424453
Active Directory  : Yes
Native            : Yes
Primary           : Yes
linux-test:~ # wbinfo -P
checking the NETLOGON dc connection succeeded
linux-test:~ #

Все в порядке. Теперь самая главная проверка – попробуем открыть каталоги на нашем новом сервере, используя рабочую станцию под управлением Windows 7. Наша рабочая станция включена в домен. Мы должны увидеть наш новый сервер на вкладке Network обозревателя Windows, либо указав имя или IP адрес:

Картинка с сайта: www.pvsm.ru

Теперь можно переходить к дальнейшим процедурам настройки нашего сервера. В дальнейшем мы рассмотрим некоторые нюансы описанного процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba.
Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Автор: SergeyKhorkov