Active directory на linux для windows сетей - Доктор Windows

Состояние перевода: На этой странице представлен перевод статьи Active Directory integration. Дата последней синхронизации: 31 октября 2015. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Важно: Так как Arch Linux использует систему распространения rolling release,возможно,некоторая информация на странице может быть устаревшей из-за изменений в пакетах или конфигурациях,сделанных разработчиками. Никогда слепо не следуйте этой или любой другой инструкции. Когда в инструкции сказано изменить какой-либо файл, обязательно сделайте бэкап. Проверяйте дату последней проверки статьи.

Основной задачей системных администраторов являются попытки совместного изпользования разнообразных окружений. Мы имеем в виду смешивание разных серверных операционных систем (Обычно Microsoft Windows & Unix/Linux). Управление пользователями и аутентификацией на данный момент является наиболее сложной задачей. Популярнейший способ решения это задачи — Directory Server. Существует много открытых и коммерческих решений для разный типов *NIX; однако, только немногие решают проблему взаимодействия с Windows. Активный Каталог (AD) — служба каталогов созданная Microsoft для доменных сетей Windows. Он входит в большинство операционных систем Windows Server. Сервера,на которых запущен AD, называются контроллерами доменов(domain controllers)

Активный каталог используется как главное средство администрирования сети и безопасности.Он отвечает за аутентификацию и авторизацию все пользователей и компьютеров в доменной сети Windows, назначая и следя за правилами безопасности для всех компьютеров в сети, также устанавливая и обновляя ПО на компьютерах в этой сети. Например,когда пользователь авторизуется в компьютер,который является частью доменной сети, AD проверяет его пароль и яляется он обычным пользователем или же системным администратором.

Активный католог использует Lightweight Directory Access Protocol (LDAP) версий 2 и 3, Kerberos и DNS.
Эти же стандарты доступны в Linux, но их комбинирование — непростая задача. Эта статья поможет вам настроить хост Arch Linux для аутентификация в домене AD.

Эта статья объясняет, как интегрировать хост Arch Linux в сущестующий домен AD.
Перед продолжением у вас должен быть существующий домен AD, и пользователь с правами на добавление пользователей и компьютерных аккаунтов.
Эта сатья не предназначена ни как полное описание AD,ни как полно описание работы с Samba. Обратитесь к разделу ресурсов для дополнительной информации.

Терминология

Если вы не знакомы с AD, здесь приведены некоторые ключевые слова, которые будет полезно знать.

Домен(Domain) : Имя,используемое для группы компьютеров и аккаунтов.
SID : Каждый компьютер,присоединяющийся к сети должен иметь уникальный SID / Системный идентификатор.
SMB : Блок сообщения сервера.
NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
WINS: Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
Winbind: Protocol for windows authentication. Протокол для авторизации windows.

Настройка

Настройка AD

Важно: Эта часть не была проверена, продолжайте с отсторожностью.

Обновление GPO

Возможно, нужно будет отключить Digital Sign Communication (Always) в настройках групп AD. А именно:

Local policies -> Security policies -> Microsoft Network Server -> Digital sign communication (Always) -> выбрать define this policy и поставить «галочку» на disable.

Если вы используете Windows Server 2008 R2, то вам нужно настроить GPO в GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> Microsoft network client: Digitally sign communications (always)

Настройка Linux хоста

Следующие несколько шагов — начало конфигурации хоста. Вам понадобиться root или sudo доступ.

Установка

Установите следующие пакеты:

samba, см. Samba
pam-krb5
ntp или openntpd, см. также NTPd или OpenNTPD

Обновление DNS

AD сильно зависит от DNS. Вам нужно будет обновить /etc/resolv.conf, чтобы использовать контроллеры доменов AD:

/etc/resolv.conf

nameserver <IP1>
nameserver <IP2>

Замените <IP1> и <IP2> IP адресами для сервера AD.Есили ваши AD домены не позволяют использовать DNS форвардинг или рекурсию,возможно,придётся добавить некоторые вещи.
Если ваша машина имеет дуалбут Windows и Linux, стоит использовать разные имена DNS и netbios для linux,если обе операционные системы будут членами одного домена.

Настройка NTP

См. NTPd или OpenNTPD для инструкции по настройке NTP. Стоит отметить, что OpenNTPD больше не поддерживается.

При настройке используйте IP адреса серверов AD.Как альтернативу можно использовать другие NTP сервера,которые обеспечат синхронизацию AD в то же место.Тем не менее,AD обычно запускают NTP в качестве службы.

Убедитесь,что демон настроен на sync automatically on startup.

Kerberos

Допустим,что ваша AD называется example.com. Далее допустим что ваша AD управляется двумя доменными контроллерами, главным и вторичным, которые называются PDC и BDS, pdc.example.com и bdc.example.com соответственно. Их адреса будут,например, 192.168.1.2 и 192.168.1.3. Следите за написанием,верхний регистр очень важен.

/etc/krb5.conf

[libdefaults]
        default_realm 	= 	EXAMPLE.COM
	clockskew 	= 	300
	ticket_lifetime	=	1d
        forwardable     =       true
        proxiable       =       true
        dns_lookup_realm =      true
        dns_lookup_kdc  =       true
	
[realms]
	EXAMPLE.COM = {
		kdc 	= 	PDC.EXAMPLE.COM
                admin_server = PDC.EXAMPLE.COM
		default_domain = EXAMPLE.COM
	}
	
[domain_realm]
        .kerberos.server = EXAMPLE.COM
	.example.com = EXAMPLE.COM
	example.com = EXAMPLE.COM
	example	= EXAMPLE.COM

[appdefaults]
	pam = {
	ticket_lifetime 	= 1d
	renew_lifetime 		= 1d
	forwardable 		= true
	proxiable 		= false
	retain_after_close 	= false
	minimum_uid 		= 0
	debug 			= false
	}

[logging]
	default 		= FILE:/var/log/krb5libs.log
	kdc 			= FILE:/var/log/kdc.log
        admin_server            = FILE:/var/log/kadmind.log

Примечание: Heimdal 1.3.1 не принимает DES шифрование,которое необходимо для аутентификации AD до Windows Server 2008. Скорее всего вам придётся добавить

allow_weak_crypto = true

в раздел [libdefaults]

Создание ключа Kerberos

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

kinit administrator@EXAMPLE.COM

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

Подтверждение ключа

Запустите klist чтобы проверить,получили ли вы токен,должно быть нечто подобное:

# klist

 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: administrator@EXAMPLE.COM
 
 Valid starting    Expires           Service principal 
 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
         renew until 02/05/12 21:27:47

pam_winbind.conf

Если вы получаете ошибки «/etc/security/pam_winbind.conf не найден»,создайте этот файл и отредактируйте его следующим образом:

/etc/security/pam_winbind.conf

debug=no
debug_state=no
try_first_pass=yes
krb5_auth=yes
krb5_cache_type=FILE
cached_login=yes
silent=no
mkhomedir=yes

Samba

Samba — бесплатная реализация протокола SMB/CIFS. Также она включает инструменты для Linux машин,которые заставляют их вести себя будто Windows сервера и клиенты.

Примечание: Настройка может разниться в зависимости от конфигурации сервера Windows. Будьте готовы изучать и решать проблемы.

В этом разделе мы сначала сфокусируемся на работе аутентификации с помощью изменения секции ‘Global’. Далее, мы вернёмся к остальным.

/etc/samba/smb.conf

[Global]
  netbios name = MYARCHLINUX
  workgroup = EXAMPLE
  realm = EXAMPLE.COM
  server string = %h Arch Linux Host
  security = ads
  encrypt passwords = yes
  password server = pdc.example.com

  idmap config * : backend = rid
  idmap config * : range = 10000-20000

  winbind use default domain = Yes
  winbind enum users = Yes
  winbind enum groups = Yes
  winbind nested groups = Yes
  winbind separator = +
  winbind refresh tickets = yes

  template shell = /bin/bash
  template homedir = /home/%D/%U
   
  preferred master = no
  dns proxy = no
  wins server = pdc.example.com
  wins proxy = no

  inherit acls = Yes
  map acl inherit = Yes
  acl group control = yes

  load printers = no
  debug level = 3
  use sendfile = no

Теперь надо «объяснить» Samba, что мы будет использовать базы даннх PDC для аутенификации.Будем использовать winbindd, который входит в поставку Samba.Winbind указывает UID и GID Linux машины для AD. Winbind использует UNIX реализацию RPC вызовов, Pluggable Authentication Modules (aka PAM) и Name Service Switch (NSS), чтобы разрешить допуск пользователей и Windows AD на Linux-машинах. Лучшая часть winbindd то,что вам не нужно размечать самому, от вас требуется только указать диапазон UID и GID! Именно их мы объявили в smb.conf.

Обновите файл настроек samba чтобы включить демона winbind

/etc/conf.d/samba

 ##### /etc/conf.d/samba #####
 #SAMBA_DAEMONS=(smbd nmbd)
 SAMBA_DAEMONS=(smbd nmbd winbindd)

Далее, настройте samba так, для запуска вместе со стартом системы. См. Daemons для подробностей.

Запуск и проверка сервисов

Запуск Samba

Надеемся,вы ещё не перезагрузились! Хорошо. Если у вас запущена X-сессия — выходите из неё,чтобы проверить вход в другой терминал не выходя из своей сессии.

Запуск Samba (включая smbd, nmbd и winbindd):

Если вы проверите список процессов,то заметите,что на самом деле winbind не запустился. Быстрый осмотр логов говорит,что SID для этого хоста может быть получен от домена:

# tail /var/log/samba/log.winbindd

[2012/02/05 21:51:30.085574,  0] winbindd/winbindd_cache.c:3147(initialize_winbindd_cache)
  initialize_winbindd_cache: clearing cache and re-creating with version number 2
[2012/02/05 21:51:30.086137,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
  Added domain BUILTIN  S-1-5-32
[2012/02/05 21:51:30.086223,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
  Added domain MYARCHLINUX  S-1-5-21-3777857242-3272519233-2385508432
[2012/02/05 21:51:30.086254,  0] winbindd/winbindd_util.c:635(init_domain_list)
  Could not fetch our SID - did we join?
[2012/02/05 21:51:30.086408,  0] winbindd/winbindd.c:1105(winbindd_register_handlers)
  unable to initialize domain list

Присоединение к Домену

Вам нужен аккаунт администратора AD чтобы сделать это. Пусть наш логин: Administrator. Комана — ‘net ads join’

# net ads join -U Administrator

Administrator's password: xxx
Using short domain name -- EXAMPLE
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'

Перезапуск Samba

winbindd не смог запуститься потому,что пока что мы не домен.

Перезапустите сервис Samba и winbind тоже должен запуститься.

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

/etc/nsswitch.conf

 passwd:            files winbind
 shadow:            files winbind
 group:             files winbind 
 
 hosts:             files dns wins

Проверка Winbind

Проверим, может ли winbind получить доступ к AD. Следующие команды возвращают список пользователей AD:

# wbinfo -u

administrator
guest
krbtgt
test.user

Note мы создали пользователя AD ‘test.user’ в домменом контоллере.

Можно сделать то же самое для групп AD:

# wbinfo -g

domain computers
domain controllers
schema admins
enterprise admins
cert publishers
domain admins
domain users
domain guests
group policy creator owners
ras and ias servers
allowed rodc password replication group
denied rodc password replication group
read-only domain controllers
enterprise read-only domain controllers
dnsadmins
dnsupdateproxy

Проверка nsswitch

Дабы убедиться,что наш хост имеет доступ к домену для пользователей и групп, мы проверим настройки nsswitch, используя ‘getent’. Следующий вывод показывает,как оно дожно выглядеть на нетронутом Arch Linux:

# getent passwd

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
ftp:x:14:11:ftp:/srv/ftp:/bin/false
http:x:33:33:http:/srv/http:/bin/false
nobody:x:99:99:nobody:/:/bin/false
dbus:x:81:81:System message bus:/:/bin/false
ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false
avahi:x:84:84:avahi:/:/bin/false
administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash
guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash
krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash
test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash

Для групп:

# getent group

root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin
adm:x:4:root,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon
mem:x:8:
kmem:x:9:
wheel:x:10:root
ftp:x:11:
mail:x:12:
uucp:x:14:
log:x:19:root
utmp:x:20:
locate:x:21:
rfkill:x:24:
smmsp:x:25:
http:x:33:
games:x:50:
network:x:90:
video:x:91:
audio:x:92:
optical:x:93:
floppy:x:94:
storage:x:95:
scanner:x:96:
power:x:98:
nobody:x:99:
users:x:100:
dbus:x:81:
ntp:x:87:
avahi:x:84:
domain computers:x:10008:
domain controllers:x:10009:
schema admins:x:10010:administrator
enterprise admins:x:10011:administrator
cert publishers:x:10012:
domain admins:x:10013:test.user,administrator
domain users:x:10006:
domain guests:x:10007:
group policy creator owners:x:10014:administrator
ras and ias servers:x:10015:
allowed rodc password replication group:x:10016:
denied rodc password replication group:x:10017:krbtgt
read-only domain controllers:x:10018:
enterprise read-only domain controllers:x:10019:
dnsadmins:x:10020:
dnsupdateproxy:x:10021:

Проверка команд Samba

Попробуйте некоторые команды,чтобу увидеть,может ли Samba взаимодействовать с AD:

# net ads info

[2012/02/05 20:21:36.473559,  0] param/loadparm.c:7599(lp_do_parameter)
  Ignoring unknown parameter "idmapd backend"
LDAP server: 192.168.1.2
LDAP server name: PDC.example.com
Realm: EXAMPLE.COM
Bind Path: dc=EXAMPLE,dc=COM
LDAP port: 389
Server time: Sun, 05 Feb 2012 20:21:33 CST
KDC server: 192.168.1.2
Server time offset: -3

# net ads lookup

[2012/02/05 20:22:39.298823,  0] param/loadparm.c:7599(lp_do_parameter)
  Ignoring unknown parameter "idmapd backend"
Information for Domain Controller: 192.168.1.2

Response Type: LOGON_SAM_LOGON_RESPONSE_EX
GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad
Flags:
        Is a PDC:                                   yes
        Is a GC of the forest:                      yes
        Is an LDAP server:                          yes
        Supports DS:                                yes
        Is running a KDC:                           yes
        Is running time services:                   yes
        Is the closest DC:                          yes
        Is writable:                                yes
        Has a hardware clock:                       yes
        Is a non-domain NC serviced by LDAP server: no
        Is NT6 DC that has some secrets:            no
        Is NT6 DC that has all secrets:             yes
Forest:                 example.com
Domain:                 example.com
Domain Controller:      PDC.example.com
Pre-Win2k Domain:       EXAMPLE
Pre-Win2k Hostname:     PDC
Server Site Name :              Office
Client Site Name :              Office
NT Version: 5
LMNT Token: ffff
LM20 Token: ffff

# net ads status -U administrator | less

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: myarchlinux
distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc
instanceType: 4
whenCreated: 20120206043413.0Z
whenChanged: 20120206043414.0Z
uSNCreated: 16556
uSNChanged: 16563
name: myarchlinux
objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 129729780312632000
localPolicyFlags: 0
pwdLastSet: 129729764538848000
primaryGroupID: 515
objectSid: S-1-5-21-719106045-3766251393-3909931865-1105
...<snip>...

Настройка PAM

Теперь мы будем менять разные правила в PAM, чтобы допустить пользователей AD к использованию системы для входа и к sudo доступу. Когда вы меняете правила, запоминание их порядка и помечены ли они как required или как sufficient критически важно,если вы хотите,чтобы всё работало,как вы задумали.Вам не стоит отклоняться от этих правил,если только вы не знаете как писать правила для PAM

В случае со входом,PAM следует сначала запросить аккаунт AD и проверять локальные аккаунты только если аккаунту AD не соответствует локальный аккаунт.Поэтому, мы добавим записи,которые включат pam_winbindd.so в процесс аутентификации.

Главный процесс аутентификации в конфигурации PAM Arch Linux находится в /etc/pam.d/system-auth. Начав со стандартной конфигурации из pambase, измените её следующим образом:

system-auth

Раздел «auth»

Найдите строку:

auth required pam_unix.so ...

Удалите её, и замените следующим:

auth [success=1 default=ignore] pam_localuser.so
auth [success=2 default=die] pam_winbind.so
auth [success=1 default=die] pam_unix.so nullok
auth requisite pam_deny.so

Раздел «account»

Найдите строку:

account required pam_unix.so

Под ней допишите следующее:

account [success=1 default=ignore] pam_localuser.so
account required pam_winbind.so

Раздел «session»

Найдите строку:

session required pam_unix.so

Под ней допишите следующее:

session required pam_mkhomedir.so umask=0022 skel=/etc/skel
session [success=1 default=ignore] pam_localuser.so
session required pam_winbind.so

Раздел «password»

Найдите строку:

password required pam_unix.so ...

Удалите её и замените следующими:

password [success=1 default=ignore] pam_localuser.so
password [success=2 default=die] pam_winbind.so
password [success=1 default=die] pam_unix.so sha512 shadow
password requisite pam_deny.so

Проверка входа

Теперь запустите новую сессию/войдите через ssh и попробуйте войти,использую данные аккаунта AD. Имя домена опционально, так как это было задано в настройках Winbind как ‘default realm’. Заметьте,что в случае с ssh, вам нужно изменить /etc/ssh/sshd_config, чтобы он разрешал аутентификацию через kerberos: (KerberosAuthentication yes).

test.user
EXAMPLE+test.user

Оба должны работать. Стоит подметить,что /home/example/test.user будет создан автоматически.

Войдите в другую сессию использую аккаунт Linux. Удостоверьтесь,что всё ещё можете войти как root — запомните,что вы должны быть под аккаунтом root как минимум в одной сессии!

Настройка общих файлов

Ранее мы пропустили настройку общих файлов. Теперь,когда всё работает, вернитесь к /etc/smb.conf и добавьте эксопрт для хостов,которые вы желаете сделать доступными в Windows

/etc/smb.conf

[MyShare]
  comment = Example Share
  path = /srv/exports/myshare
  read only = no
  browseable = yes
  valid users = @NETWORK+"Domain Admins" NETWORK+test.user

В примере выше, ключевое слово NETWORK. Не путайте его с именем домена. Для добавления групп,добавьте символ ‘@’ к группе. Заметьте, Domain Admins заключается в «цитаты», чтобы Samba корректно считывала их,когда просматривает файл конфигурации.

Добавление файла keytab и включение беспарольного входа на машину через Kerber и ssh

Это объясняет,как сгенерировать keytab файл,который вам нужен,например,чтобы включить беспарольный вход на машину через Kerber и ssh с другой машины в том же домене. Допустим, что у вас много компьютеров в домене и вы только что добавили сервер/рабочую станцию использую описание выше в ваш домен, в котором пользователям нужен ssh для работы — например рабочаю станция GPU или вычислительный узел OpenMP и т.д. В этом случае вам, наверное, не захочется вводить пароль каждый раз при входе. С другой стороны аутентификация с помощью ключа используется множеством пользователей, в этом случае нужных полномочий для,например,монтирования общего NFSv4 с Kerberos. Так что это поможет включить беспарольные входы на машины используя «kerberos ticket forwarding».

Создание key tab файла

Запустите ‘net ads keytab create -U administrator’ как суперпользователь дабы создать keytab файл в ‘/etc/krb5.keytab’. Она напишет ваи,что необходимо включить аутентификацию с помощью keytab в файле конфигурации, чтобы мы могли совершить следующий шаг. Иногда возникают проблемы, если файл krb5.keytab уже существует,в таком случае нужно переименовать его и запустить команду ещё раз, это должно помочь.

# net ads keytab create -U administrator

Проверьте содержание файла следующим образом:

# klist -k /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM

Включение входа через keytab

Теперь вам нужно указать winbind,что он должен использовать keytab файлы,добавив следующий строки в /etc/samba/smb.conf:

/etc/samba/smb.conf

 kerberos method = system keytab
 dedicated keytab file = /etc/krb5.keytab

В итоге всё должно выглядеть примерно так:

/etc/samba/smb.conf

[Global]
  netbios name = MYARCHLINUX
  workgroup = EXAMPLE
  realm = EXAMPLE.COM
  server string = %h Arch Linux Host
  security = ads
  encrypt passwords = yes
  password server = pdc.example.com
  kerberos method = system keytab
  dedicated keytab file = /etc/krb5.keytab

  idmap config * : backend = tdb
  idmap config * : range = 10000-20000

  winbind use default domain = Yes
  winbind enum users = Yes
  winbind enum groups = Yes
  winbind nested groups = Yes
  winbind separator = +
  winbind refresh tickets = yes

  template shell = /bin/bash
  template homedir = /home/%D/%U
   
  preferred master = no
  dns proxy = no
  wins server = pdc.example.com
  wins proxy = no

  inherit acls = Yes
  map acl inherit = Yes
  acl group control = yes

  load printers = no
  debug level = 3
  use sendfile = no

Перезапустите winbind.service с помощью ‘systemctl restart winbind.service’ с привелегиями суперпользователя.

# systemctl restart winbind.service

Проверьте,всё ли работает,получив тикет для вашей системы и запустив

# kinit MYARCHLINUX$ -kt /etc/krb5.keytab

Эта команда не должна написать ничего в консоль,ондако ‘klist’ должен показать что-то вроде этого:

# klist

 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: MYARCHLINUX$@EXAMPLE.COM
 
 Valid starting    Expires           Service principal 
 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
         renew until 02/05/12 21:27:47

Некоторые частые ошибки : a)забывают поставить $ или b) игнорируют чувствительный регистр — он должен быть точно таким же,как записьв keytab

Подготовка sshd на сервере

Всё,что нам нужно сделать — это добавить некоторые опции в sshd_config и перезапустить sshd.service.

Измените ‘/etc/ssh/sshd_config’ чтобы он выглядел так в нужных местах:

# /etc/ssh/sshd_config

...

# Изсенить на no чтобы выключить s/key пароли
ChallengeResponseAuthentication no

# Опции Kerberos 
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
KerberosGetAFSToken yes

# Опции GSSAPI
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

...

Перезапустите sshd.service:

# systemctl restart sshd.service

Добавление опций, нужных для клиента

Для начала нам нужно убедиться в том, что тикеты доступны для клиента. Обычно всё работает, но, на всякий случай, используйте следующий параметр:

forwardable = true

Далее надо добавить опции:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

в наш файл .ssh/config, который говорит ssh использовать эту опцию, как альтернативу: можно использовать ‘ssh -o’ (смотрите страницу справочного руководства ssh(1)).

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

Клиент:

Убедитесь,что у вас правильный тикет, используя ‘kinit’. Затем подключитесь к своем машине через ssh

ssh myarchlinux.example.com

Вы должны подключится без просьбы ввести пароль

Если у вас также включна аутентификация ключем,нужно выполнить

ssh -v myarchlinux.example.com

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

Для дебага вы можете включить DEBUG3 на сервере и посмотреть лог через ‘journalctl’

Настройка для полной аутентификации Kerberos без пароля.

Если ваши клиенты не используют доменные аккаунты на их локальных машинах (по какой бы то не было причине),довольно сложно будет научить их использовать ‘kinit’ перед тем,как ssh подключится к рабочей станции.Так что есть классный способ это решить:

Генерирование keytab, которые будет принимать AD

Пользователь должен выполнить:

ktutil
addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC
- enter password for username -
wkt username.keytab
q

Теперь провертьте файл:

kinit -kt username.keytab

Оно не должно спросить пароль, теперь просто скопируйте это в ‘~/.bashrc’, это позволит не вводит пароль каждый раз.

Интересно знать

Файл ‘username.keytab’ не спецефичен для машины,и,следовательно,может быть скопирован на другие машины. Например,мы создали файл на Linux машине и скопировали на Mac клиента так как команды в неё другие…

Смотрите также

Wikipedia: Active Directory
Wikipedia: Samba
Wikipedia: Kerberos
Samba: Documentation
Samba Wiki: Samba & Active Directory^{[устаревшая ссылка 2020-08-02 ⓘ]}
Samba Man Page: smb.conf

Коммерческие решения

Centrify
Likewise

Источник

В данной инструкции мы установим Active Directory для офиса на Linux используя дистрибутив Zentual который основан на дистрибутиве Ubuntu Server. Дистрибутив Zentual 4 работает только на 64bit архитектуре.

Active Directory — LDAP-совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows. Active Directory позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики. Active Directory хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких десятков до нескольких миллионов объектов.

В дистрибутиве Zentual 4 используется четвертая версия Samba в которой существует полноценная реализация контроллера домена и сервиса Active Directory, совместимого с реализацией Windows 2000 и способного обслуживать все поддерживаемые Microsoft версии Windows-клиентов, в том числе Windows 8. Сервер Active Directory на базе Samba 4 может быть подсоединён к уже существующим доменам Microsoft Active Directory и наоборот, контроллеры доменов на базе продуктов Microsoft могут быть подсоединены к Active Directory серверу на базе Samba 4.

Скачиваем дистрибутив на сайте Zentual.org, либо скачиваем Zentual 4.2 по прямой ссылке

На момент написания статьи актуальная версия Zentual 4.0, Вы естественно проверьте и скачайте актуальную версию дистрибутива. На 24.03.2016г. новая версия имеет номер Zentual 4.2 и называется Zentyal Server (Development Edition) ссылку на скачку файла выше поправил на актуальную версию.

Открыв сайт zentual.org кликаем на кнопку Download Zentyal Server (Development Edition) :

В открывшемся окне кликаем под надписью GET your FREE copy of Zentual Linux Server! на кнопку Download Zentyal Server Community Edition:

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

Записываем скачанный дистрибутив Zentual на DVD диск, загружаемся с него:

Выбираем экспертную версию установки дистрибутива Install Zentual 4.0 (expert mode):

Выбираем страну, в нашем случае я выбираю Украина:

Отказываемся с автоматическим определением раскладки клавиатуры:

Выбираем страну раскладки клавиатуры:

Выбираем подходящую раскладку клавиатуры:

Выбираем способ переключения клавиатуры при нажатии на Ctrl+Shift:

Процесс установки дистрибутива Zentual:

Если у Вас несколько сетевых карт необходимо выбрать нужную сетевую карту:

По умолчанию сетевая карта постарается получить настройки автоматически от установленного DHCP сервера в сети, в нашем случае я желаю самостоятельно указать нужные параметры, для этого во время получения настроек по DHCP нажимаем Enter для активации кнопки Отмена, если Вы не успели и получили автоматически параметры нажмите кнопку Esc и в открывшемся окне выберите Настройка сети:

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

Выбираем пункт Настроить сеть вручную:

Указываем IP адрес 192.168.3.211 и нажимаем кнопку Продолжить:

Указываем маску сети 255.255.255.0 и нажимаем кнопку Продолжить:

Указываем IP адрес шлюза сети 192.168.3.1 и нажимаем кнопку Продолжить:

Указываем IP адрес DNS сервера 192.168.3.1 и нажимаем кнопку Продолжить:

Указываем имя компьютера office.ad.server.loc, где office это имя компьютера, а ad.server.loc это имя домена которое вы создаем в нашей сети, нажимаем Продолжить:

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

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

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

Так как я использую в данной установке слабый пароль, система спросит нужно ли использовать слабый пароль, я отвечаю Да, но в Вашем случае на боевом сервере советую использовать сложные пароли:

Подтверждаем выбранную временную зону нажав на кнопку Да, если необходимо измените временную зону нажав кнопку Нет:

Открывается окно разбивки винчестера, выбираем ручной метод Вручную и нажимаем Enter:

В окне зарметки дисков видим новый винчестер, кликаем на винт и нажимаем Enter:

В открывшемся окне соглашаемся для создания новой таблицы разделов на винчестере:

Создаем раздел /boot размером 512mb, для этого становимся на свободное место и нажимаем Enter:

Кликаем Создать новый раздел, нажимаем Enter:

Указываем размер раздела 512mb и нажимаем Продолжить:

Выбираем тип нового раздела Первичный и кликаем Enter:

Выбираем местоположение нового раздела: Начало и кликаем Enter:

Настраиваем раздел по примеру ниже:

Использовать как: Журналируемая файловая система Ext4
Точка монтирования: /boot
Метка ‘загрузочный’: вкл

Для сохранения и добавления раздела становимся на Настройка раздела закончена и нажимаем Enter:

Создаем раздел подкачки swap размером 2gb, для этого становимся на свободное место и кликаем Enter:

Выбираем Создать новый раздел, кликаем Enter:

Указываем размер раздела подкачки 2gb, кликаем на Продолжить:

Выбираем тип нового раздела Логический, кликаем Enter:

Выбираем местоположение нового раздела Начало, кликаем Enter:

Изменяем в разделе файловую систему с Ext4 на раздел подкачки, для этого становимся на Журналируемая файловая система Ext4 и нажимаем Enter:

В открывшемся окне инсталятора становимся на позицию раздел подкачки и нажимаем Enter:

Для сохранения изменений создаваемого раздела подкачки становимся на позицию Настройка раздела закончена и нажимаем Enter:

Создаем корневой раздел, для этого становимся на свободное место винчестера и кликаем Enter:

В появившемся окне выбираем Создать новый раздел и нажимаем Enter:

Указываем размер корневого раздела 12gb, становимся на кнопку продолжить и кликаем Enter:

Выбираем тип нового раздела Логический и кликаем Enter:

Выбираем местоположение нового раздела Начало:

Настраиваем корневой раздел по примеру ниже:

Использовать как: Журналируемая файловая система Ext4
Точка монтирования: /

Для сохранения и добавления раздела становимся на Настройка раздела закончена и нажимаем Enter:

Создаем домашний раздел /home, для этого становимся на свободное место винчестера и кликаем Enter:

В появившемся окне выбираем Создать новый раздел и нажимаем Enter:

Указываем размер домашнего раздела /home размера 71.4 GB, то есть все свободное место, становимся на кнопку Продолжить и кликаем Enter:

Выбираем тип нового раздела Логический и кликаем Enter:

Настраиваем домашний раздел по примеру ниже:

Использовать как: Журналируемая файловая система Ext4
Точка монтирования: /home

Для сохранения и добавления домашнего раздела становимся на Настройка раздела закончена и нажимаем Enter:

На скриншоте ниже Вы видите готовую разбивку винчестера, для продолжения установки становимся на Закончить разметку и записать изменения на диск и кликаем Enter:

Соглашаемся на уведомление системы о форматировании и кликаем Enter:

Процесс установки операционной системы:

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

Процесс установки операционной системы:

Если у Вас интернет в сети работает только через прокси сервер, тогда в следующем окне необходимо указать адрес прокси сервера по примеру как на скриншоте, если не используется, тогда ничего не пишем, становимся на Продолжить и кликаем Enter:

Соглашаемся с установкой загрузчика GRUB в главную загрузочную запись:

Выбираем, что часы не показываются в UTC:

Установка Zentual завершена, становимся на Продолжить и кликаем Enter, инсталятор выбросит установочный диск и перезагрузит сервер:

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

Нажимаем кнопку F2, откроется подробный вывод в консоли загрузки системы, как только появится запись с адресом для входа через браузер, перегружаем сервер кликнув на сочетание клавиш Ctrl+Alt+Del:

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

Авторизируемся на сервере введя логин adadmin, либо тот, что Вы указали во время установки и пароль, сам пароль во время установки не отображается:

Если Вам необходимо будет настраивать сервер, можно использовать для каждой команды sudo, я же для экономии просто авторизируюсь под пользователем root выполнив команду sudo su введя пароль и провожу настройку.

Проверяем наличие интернета на сервере выполнив пинг:

ping ya.ru

для прерывания пинга необходимо нажать сочетание клавиш Ctrl+c

Приступаем к продолжению установки системы через браузер, потому не рекомендую закрывать браузер либо прерывать процесс установки. Открываем в браузере подключение и так как используется шифрованное соединение по https, браузер Chrome будет ругатся, впрочем как и Firefox, необходимо нажать на Дополнительно:

И нажать на Перейти на сайт 192.168.3.211 (небезопасно):

Откроется окно веб интерфейса для авторизации и продолжения установки необходимых пакетов и настройки Active Directory, авторизируемся в систему введя логин adadmin и пароль который указали во время установки ранее и нажимаем кнопку Войти:

Откроется мастер установки, для продолжения установки нажимаем кнопку Continue:

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

Активируем пакеты:

Domain Controller and File Sharing
DNS Server
Antivirus
Printers

Для установки выбранных пакетов кликаем кнопку Установка:

Удостоверяемся, что выбраны все необходимые пакеты и кликаем кнопку Continue:

Видим процесс установки:

Открывается Мастер первичной настройки. Настраиваем сетевые интерфейсы, так как мы сетевой интерфейс настроили во время установки операционной системы настройку пропускаем, нажимаем Пропустить:

Пропускаем настройку сети в следующем окне кликнув на кнопку Пропустить:

Во время установки операционной системы мы указали имя домена office.ad.server.loc, где office это имя сервера, а ad.server.loc домен Active Directory и нажимаем для завершения кнопку Готово :

Процесс установки пакетов системы:

Установка сервера Active Directory на системе Zentual и переходим в веб интерфейс кликнув на кнопку GO TO THE DASHBOARD:

Рабочая панель настройки Active Directory в системе Zentual:

Переходим во вкладку Статус модуля, видим не активированные модули Сеть, DNS, Domain Controller and File Sharing, Принтеры, необходимо их активировать проставив галочку на чекбоксе:

Соглашаемся с активацией модуля Domain Controller and File Sharing кликнув кнопку Принять:

Соглашаемся с активацией модуля Принтеры кликнув кнопку Принять:

Применяем изменения кликнув на кнопку СОХРАНИТЬ ИЗМЕНЕНИЯ:

Соглашаемся с сохранением изменений кликнув на кнопку СОХРАНИТЬ:

Вход в веб интерфейс Zentual:

В данной инструкции мы установили дистрибутив Zentual Server, установили все необходимые модуля для работы Active Directory на сервере Linux. В следующей инструкции будет продолжение по добавлению пользователей, групп пользователей, общих папках, групповых политиках и администрированию нашего домена из Windows.

С Вами был Сергей Лазаренко.

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

Источник

Contents

Introduction
1. Background
2. Prerequisites
Installation
Kerberos
Pam
LDAP
1. TestQuery: Windows
Configure AD
1. TestQuery: Linux
libnss-ldap
Troubleshooting

Introduction

Active Directory from Microsoft is a directory service that uses some open protocols, like Kerberos, LDAP and SSL.

There are several ways to use AD for authentication, you can use Centrify Express, Likewise Open, pam_krb5, LDAP or winbind. For Centrify Express see [DirectControl]. Centrify Express can be used to integrate servers or desktops with Active Directory. Likewise Open is also a solution for Linux workstations to authenticate to an Active Directory domain. For Likewise Open see [LikewiseOpen] or Likewise Open. For Winbind see [ActiveDirectoryWinbindHowto].

The purpose of this document is to provide a guide to configuring Samba on Ubuntu to act as a file server in a Windows environment integrated into Active Directory. The goal is to create a file server that is as close to a one to one replacement for a Microsoft Windows file server as possible from the client’s perspective.

Background

It is important to keep in mind that the Samba developers have to play detective to try to basically reverse engineer the Microsoft implementation of the SMB protocol. The end result is that there are occasional issues that must be worked around if a bug fix does not exist. With the instructions below, expected behavior should be acceptable in most corporate environments.

Samba allows for a great deal of flexibility in how shares behave on a per-share basis. It is outside the scope of this document to cover each configuration setting and how they behave. It would be very beneficial to first read the smb.conf documentation found at the Samba web page. There are quite a few settings in the documentation, but getting a general feel of what they are and what they do will help in understanding this document and how you can take a step beyond by changing settings for your own tastes and environment.

Prerequisites

Security updates need to be enabled for not only the main repository, but for the universe repository as well (as now documented below). If this is not done, any security updates for the main (supported) packages create failed dependencies for the relevant universe packages.

Here is the list of prerequisites specific to this document:

Ubuntu Server Edition default installation.
Windows 2003 Native Domain (mixed-mode not tested, but may work)
Ample hard drive space to accommodate packages and shares.
Proper IP DNS settings configured so that internal names can be resolved.

Installation

Install the samba, acl, and attr packages if you wish to enable extended attributes which enable a greater level of control for file Access Control Lists. See InstallingSoftware for information regarding Package Managers and installing packages.

You can edit /etc/fstab similar to the following to enable extended attributes on boot:

<main file system> / ext3 defaults,acl,user_xattr,errors=remount-ro 0 1

Then remount the filesystem:

mount -o remount /

Kerberos

The first step in joining an Active Directory domain is to install and configure Kerberos. See Samba/Kerberos for details.

Pam

After Kerberos has been installed and configured, the authentication system (PAM) needs to be configured to use Active Directory. Edit /etc/pam.d/common-auth and add:

auth    sufficient      pam_krb5.so ccache=/tmp/krb5cc_%u
auth    sufficient      pam_unix.so likeauth nullok use_first_pass
auth    required        pam_deny.so

Then edit /etc/pam.d/common-session:

session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0077

kpasswd for password changing works, but note that AD by default disallows users from changing passwords more than once a day.

The users from AD have to exist in /etc/passwd on the Ubuntu workstation, you can also use libnss-ldap to get the account info from AD.

LDAP

TestQuery: Windows

Assuming you do not maintain the Active Directory you will want to determine the structure of AD before trying to connect to it from Linux. From a windows PC connected to AD you should perform a query using Microsoft’s Active Directory Application Mode (ADAM). ADAM is a package of tools that includes CSVDE, which we will be using to perform our queries.

NB ADAM is not supported on Windows 7, and has been replaced by AD LDS.

Type this into Google, the download page should be the second hit.

adam microsoft

Install. Open the command prompt. Start > RUN and type ‘cmd’ Navigate to the installation directory, default is c:windowsADAM

Example Queries: Query a user entry

CSVDE -f export.csv -r "(&(objectClass=user)(sn=lastname))"

wildcards work as well

CSVDE -f export.csv -r "(&(objectClass=user)(sn=last*))"

Query a computer entry

CSVDE -f export.csv -r "(&(objectClass=computer)(cn=computername))"

Return everything in the following AD folder

CSVDE -d "OU=Pathology,OU=Departmental OUs,OU=Medcenter,DC=Med,DC=University,DC=edu" -f export.csv

The output of these queries would be placed within export.csv inside c:windowsADAM. Which can then be viewed as a spreadsheet editor.

For more on querying with ADAM’s CSVDE [www.computerperformance.co.uk/Logon/Logon_CSVDE.htm]

Configure AD

In Windows Server versions prior to WS03 R2, it is necessary to extend the LDAP schema from AD with the UNIX attributes. Install «Windows Services for UNIX» from Microsoft (I used version 3.5). SFU: http://www.microsoft.com/windows/sfu/

Installing SFU 3.5 on Windows Server 2003 (non R2) does not appear to add the necessary LDAP schema extensions.

In order to extend the LDAP schema, it is necessary to install the «Server for NIS» component. The installation needs to be performed using an account that has Enterprise Admin privileges in order for the schema to be extended successfully (indeed, Enterprise Admin privileges are required even if the schema has already been extended). In Active Directory, schema extensions are non-reversible, so if the NIS Server is not required, it can be removed once the schema extension is complete. If the SFU Server for NIS is installed however, it will extend the Active Directory Users and Computers tool with a UNIX Attributes tab which allows GUI editing of the UNIX attributes for users, groups and computers.

In Windows Server 2003 R2, the Active Directory schema is already extended with an RFC2307-compliant schema. This differs from the schema extensions used in SFU3.5, requiring a different libnss-ldap configuration. It is still necessary to install Server for NIS to extend the Active Directory Users and Computers tool with the UNIX Attributes tab to allow GUI editing of UNIX attributes for users, groups and computers.

TestQuery: Linux

We will want to perform a testquery in Linux before we attempt to configure AD. It is much simpler to determine how to connect on the command line and then configure rather than reconfigure a file repeatedly.

We will need at least these two packages to perform test queries on Active Directory.

sudo apt-get install libnss-ldap ldap-utils

We perform queries with ‘ldapsearch’ We must specify these minimum parameters:

We need to specify the LDAP Server (Domain Controller)

ldapsearch -h medcenterdc01

and the authentication type: simple or SASL

If we have an active directory account and proper libraries installed, you can also authenticate using SASL-GSSAPI, and you will not need -D or -W options

sudo apt-get install libsasl2-modules-gssapi-mit
kinit ADuser
ldapwhoami -h medcenterdc01 -Y EXTERNAL

SASL authentication off, simple on

ldapsearch -h medcenterdc01 -x

and the folder we want to search in

ldapsearch -h medcenterdc01 -x -b "OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu"

and who to authenticate as

ldapsearch -h medcenterdc01 -x -b "OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu" -D "CN=last name\, firstname,OU=Users,OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu"

we’ll have it prompt for the password, instead of specifying it in the command

ldapsearch -h medcenterdc01 -x -b "OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu" -D "CN=last name\, firstname,OU=Users,OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu" -W

and lets search for sammy’s account

ldapsearch -h medcenterdc01 -x -b "OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu" -D "CN=last name\, firstname,OU=Users,OU=Pathology,OU=Departmental OUs,OU=medcenter,DC=mc,DC=university,DC=edu" -W "sAMAccountName=sammy"

One doesn’t need to worry about spaces, but to specify a comma as part of the path we need to prefix the comma with ‘\’

CN=last name\, firstname

libnss-ldap

You can install libnss-ldap and nscd from the Universe Repository.

Now you need to set up /etc/nsswitch.conf for ldap.

    passwd:         compat
    group:          compat
    shadow:         compat
    passwd_compat:  ldap
    group_compat:   ldap
    shadow_compat:  ldap

    hosts:       files dns
    networks:    files dns

    services:    db files
    protocols:   db files
    rpc:         db files
    ethers:      db files
    netmasks:    files
    netgroup:    files
    bootparams:  files

    automount:   files
    aliases:     files

If you have trouble when you attempt to ping and your network has a wins server you will want to append ‘wins’ to the hosts line of nsswitch.conf — you may only notice this only when you try to ping a static IP Linux PC from another Linux PC — I believe WINS is a part of the samba package and the IP addresses for WINS servers are stored in /etc/samba/dhcp.conf, the static IP machine also needs to specify its NetBIOS name within /etc/samba/smb.conf

When fiddling with /etc/nsswitch.conf, it is best to turn the Name Services Caching Daemon off — /etc/init.d/nscd stop or you will be confused by cached results. Turn it on afterwards.

Then you need to set up /etc/libnss-ldap.conf. AKA: /etc/ldap.conf

    # Replace windc.example.com with your Windows DC
    uri ldap://windc.example.com/

    base dc=example,dc=com
    ldap_version 3

    # Add a user to AD, that can read the container
    # with the users, that you want use.
    binddn cn=ldapreader,cn=Users,dc=example,dc=com
    bindpw cvfd123

    scope sub
    timelimit 30


    pam_filter objectclass=User

    pam_login_attribute sAMAccountName
    pam_lookup_policy yes

    # Modify cn=User,dc=e... to your container with your users.
    nss_base_passwd cn=User,dc=example,dc=com?sub
    nss_base_shadow cn=User,dc=example,dc=com?sub
    nss_base_group  cn=User,dc=example,dc=com?sub

    # For MSSFU:
    nss_map_objectclass posixAccount User
    nss_map_objectclass shadowAccount User
    nss_map_attribute uid sAMAccountName
    nss_map_attribute uniqueMember member
    nss_map_attribute uidNumber msSFU30UidNumber
    nss_map_attribute gidNumber msSFU30GidNumber
    nss_map_attribute userPassword msSFU30Password
    nss_map_attribute homeDirectory msSFU30HomeDirectory
    nss_map_attribute loginShell msSFU30LoginShell
    nss_map_attribute gecos name
    nss_map_attribute cn sAMAccountName

I think it only needs rootbinddn, no binddn, with the bindpw in /etc/libnss-ldap.secret, not here. I have also successfully combined /etc/ldap/ldap.conf, /etc/libnss-ldap.conf, and /etc/pam_ldap.conf, symlinking them all to /etc/ldap/ldap.conf — AndyRabagliati

Incorrect nss_map settings will prevent one from authenticating and reading AD in general. These settings are dependent on the column names within your AD database. In older systems the database (schema) needs to be extended as described in the ‘Configure AD’ section. Once these *NIX attributes are part of the schema they can be modified with the MMC snap-in Active Directory Users and Groups, as long as idmu.exe has been installed from the Windows Server 2003 R2 Administration Tools Pack. If *NIX group membership has been administered by modifying the list in the UNIX attributes tab of AD Users and Computers (which is REQUIRED in a NIS environment), then ‘uniqueMember’ should be mapped to ‘msSFU30PosixMember’ (or ‘posixMember’ for WS03R2) as ‘member’ only includes the membership listed in the Windows group. For Windows Server 2003 R2, the schema extensions are RFC2307 compliant — no longer prefixed ‘msSFU30’ and with the next letter in lower case (e.g. msSFU30UidNumber is now uidNumber).

If you are in a complex environment with multiple domains or multiple trees and want people from all your domains to login specify the Global Catalog port for your LDAP queries instead of the default port. If you do this is essential all LDAP servers specified in the ldap.conf be Global Catalogs. If you can create a DNS entry for your Global Catalogs of «ldap.company.com» then your URI becomes ldap://ldap.company.com:3268/. Using a DNS entry creates a dependancy on DNS but also allows you to add or remove Global Catalog servers with out having to edit the ldap.conf on each client. Taking this step also requires making all of the attributes you are using accessible via the Global Catalog LDAP service, many of the UNIX attributes are local to a specific domain. You can do this with the schema managment MMC. If you are using these attributes to authenticate your users (like UID) you may want to index them in Active Directory as well. Using the sAMAccountName gets around this since it’s already replicated to all Global Catalogs and indexed. If you have a large environment it’s very important to add proper filtering for your NSS lookups as shown below.

Further optimizations of the queries can be made for the nss_base properties:

nss_base_passwd         dc=mydomain,dc=com?sub?&(objectClass=user)(!(objectClass=computer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow         dc=mydomain,dc=com?sub?&(objectClass=user)(!(objectClass=computer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_group          dc=mydomain,dc=com?sub?&(objectClass=group)(gidNumber=*)

These filters may be required if not all of your AD users and groups have had their Unix Attributes (UID, GID, etc) configured. Specifiying uidNumber=* will exclude AD objects that have not had this attribute set from the search. . If running «id -Gn <user>» hangs (but getent passwd and getent group work correctly), then you should make these changes.The filters above will sort for users that are not computers (AD stores computers as User objects with a «$» at the end) and have a UID greater than or equal to 2000 and a Unix home directory specified. If you are not seeing what you expect work with out filters and using the default LDAP port and add complexity one step at a time.

The ampersand in the queries above merely specifies AND logic

AND (&(filter)(filter))
OR  (|(filter)(filter))
NOT (!(filter))

Troubleshooting

To debug LDAP queries one should make sure nscd is off and use the getent command

sudo /etc/init.d/nscd stop

getent passwd
getent shadow
getent group

To follow the actions of the command use strace

strace getent passwd

If thats not enough you can place a line in the configuration file for output:

debug 10

This can be a value anywhere from 1 to 10, 10 being the most verbose.

With this config is the LDAP Traffic unencrypted and someone can sniff it. To make it secure use SSL

Now you need to set up /etc/pam.d/common-auth and

    #
    # /etc/pam.d/common-auth - authentication settings common to all services
    #
    # This file is included from other service-specific PAM config files,
    # and should contain a list of the authentication modules that define
    # the central authentication scheme for use on the system
    # (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
    # traditional Unix authentication mechanisms.
    #
    auth    sufficient      pam_ldap.so
    auth    required        pam_unix.so nullok_secure use_first_pass

set up /etc/pam.d/common-account.

    #
    # /etc/pam.d/common-account - authorization settings common to all services
    #
    # This file is included from other service-specific PAM config files,
    # and should contain a list of the authorization modules that define
    # the central access policy for use on the system.  The default is to
    # only deny service to users whose accounts are expired in /etc/shadow.
    #
    account sufficient      pam_ldap.so
    account required        pam_unix.so

We are still using Kerberos for authentication, but now we are storing the information that would normally be stored in /etc/passwd using Active Directory.

Here are some other useful config files:

login.defs
nscd.conf
/var/log/auth.log

Here is an alternative configuration example: Patched pam_krb5 to include support for directory service users]

CategorySecurity

Источник

Как мне ввести в домен Ubuntu 20.04 | 18.04 к домену Windows? Могу ли я присоединить Debian 10 к домену Active Directory?

Эта статья была написана, чтобы показать вам, как использовать realmd для присоединения сервера или рабочего стола Ubuntu 20.04 | 18.04 / Debian 10 к домену Active Directory. Домен Active Directory является центральным узлом информации о пользователях в большинстве корпоративных сред.

Например, в инфраструктуре моей компании ключевым требованием является то, чтобы все пользователи прошли аутентификацию во всех системах Linux с учетными данными Active Directory. Это должно работать как для Debian, так и для дистрибутивов Linux на основе Red Hat.

В этом руководстве будет показано, как настроить SSSD для получения информации из доменов в одном лесу ресурсов Active Directory. Если вы работаете с несколькими лесами AD, это руководство может вам не подойти. Мы также пойдем дальше и настроим правила sudo для пользователей, которые входят в систему через AD. Вот схема, изображающая установку и как она работает.

Итак, выполните следующие действия, чтобы присоединиться к домену Ubuntu 20.04 | 18.04 / Debian 10 в Active Directory (AD).

Шаг 1. Обновите свой APT

Начните с обновления вашей системы Ubuntu / Debian Linux.

sudo apt -y update

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

Для Ubuntu 20.04 | 18.04 добавьте следующие репозитории в файл sources.list

sudo tee -a /etc/apt/sources.list <<EOF deb http://us.archive.ubuntu.com/ubuntu/ bionic universe deb http://us.archive.ubuntu.com/ubuntu/ bionic-updates universe EOF

Шаг 2. Задайте имя хоста сервера и DNS

Установите правильное имя хоста для вашего сервера с правильным доменным компонентом.

sudo hostnamectl set-hostname myubuntu.example.com

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

$ hostnamectl Static hostname: myubuntu.example.com Icon name: computer-vm Chassis: vm Machine ID: 5beb7ac3260c4f00bcfbe1088f48b8c7 Boot ID: b2a0d9abe43b455fb49484dbaa59dc41 Virtualization: vmware Operating System: Ubuntu 18.04.1 LTS Kernel: Linux 4.15.0-29-generic Architecture: x86-64
Убедитесь, что DNS настроен правильно:
$ cat /etc/resolv.conf

Ubuntu 20.04 | 18.04 поставляется с systemd-resolve, который вам нужно отключить, чтобы сервер мог напрямую обращаться к вашему сетевому DNS.

sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved
Если вы используете DHCP, вы можете обновить DNS-сервер вручную.
$ sudo unlink /etc/resolv.conf $ sudo vim /etc/resolv.conf

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

Для присоединения системы Ubuntu 20.04 | 18.04 / Debian 10 к домену Active Directory (AD) требуется ряд пакетов.

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

Только после успешной установки зависимостей вы можете приступить к обнаружению домена Active Directory в Debian 10 / Ubuntu 20.04 / 18.04.

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

$ sudo realm discover example.com example.com type: kerberos realm-name: EXAMPLE.COM domain-name: example.com 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

Замените example.com своим действующим доменом AD.

Шаг 5. Присоединитесь к Ubuntu 20.04 | 18.04 / Debian 10 к домену Active Directory (AD)

Учетная запись администратора AD требуется для интеграции вашего компьютера Linux с доменом Windows Active Directory. Проверьте и подтвердите учетную запись администратора AD и пароль.

Команда realm join настроит локальный компьютер для использования с указанным доменом, настроив как локальные системные службы, так и записи в домене идентификации. У команды есть несколько параметров, которые можно проверить с помощью:

$ realm join --help
Базовое выполнение команды:
$ sudo realm join -U Administrator example.com Password for Administrator:

Где:

Администратор – это имя учетной записи администратора, используемой для интеграции машины в AD.
example.com – это имя домена AD

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

Просмотр сведений о текущей области.

$ realm list example.com type: kerberos realm-name: EXAMPLE.COM domain-name: example.com 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@example.com login-policy: allow-realm-logins

В системах на основе RHEL домашний каталог пользователя будет создан автоматически. В Ubuntu / Debian вам необходимо включить эту функцию.

sudo bash -c "cat > /usr/share/pam-configs/mkhomedir" <<EOF Name: activate mkhomedir Default: yes Priority: 900 Session-Type: Additional Session: required pam_mkhomedir.so umask=0022 skel=/etc/skel EOF
Затем активируйте с помощью:
sudo pam-auth-update

Выберите <OK>

Убедитесь, что выбрано “activate mkhomedir” с помощью звездочки – [*]

Затем выберите <Ok>, чтобы сохранить изменения.

Ваш файл конфигурации sssd.conf находится в /etc/sssd/sssd.conf . При каждом изменении файла требуется перезагрузка.

Статус должен быть запущен.

$ systemctl status sssd

Если интеграция работает, должна быть возможность получить информацию о пользователе AD.
$ id jmutai@example.com uid=1783929917(jmutai@example.com) gid=1784800513(domain users@example.com) groups=1783870513(domain users@example.com)

Шаг 6. Контроль доступа – Ограничьте до пользователя / группы

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

Ограничение для пользователей

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

$ sudo realm permit user1@example.com $ sudo realm permit user2@example.com user3@example.com
Разрешить доступ к группе – Примеры
$ sudo ream permit -g sysadmins $ sudo realm permit -g 'Security Users' $ sudo realm permit 'Domain Users' 'admin users'

Это изменит файл sssd.conf .

Если вместо этого вы хотите разрешить доступ всем пользователям, запустите:

$ sudo realm permit --all
Чтобы запретить доступ всем пользователям домена, используйте:
$ sudo realm deny --all

Шаг 7. Настройте доступ через Sudo

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

Давайте сначала создадим файл разрешений sudo.

$ sudo vi /etc/sudoers.d/domain_admins
Добавить одного пользователя:
user1@example.com ALL=(ALL) ALL
Добавить еще одного пользователя:
user1@example.com ALL=(ALL) ALL user2@example.com ALL=(ALL) ALL
Добавить группу
%group1@example.com ALL=(ALL) ALL

Добавьте группу с пробелами.

%security users@example.com ALL=(ALL) ALL %system super admins@example.com ALL=(ALL) ALL

Шаг 8. Проверьте доступ по SSH

Получите доступ к серверу удаленно, поскольку пользователю AD разрешено входить в систему.

$ ssh user1@localhost The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is SHA256:wmWcLi/lijm4zWbQ/Uf6uLMYzM7g1AnBwxzooqpB5CU. ECDSA key fingerprint is MD5:10:0c:cb:22:fd:28:34:c6:3e:d7:68:15:02:f9:b4:e9. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.

Это подтверждение того, что наша конфигурация прошла успешно.

Посетите вики-страницы realmd и sssd, чтобы узнать больше.

Оригинал статьи на английском здесь.

Источник

Перейти к содержанию

На чтение 4 мин Опубликовано 13.09.2021

В этом руководстве мы обсудим, как интегрировать Linux-серверы (Centos/RHEL) с Windows Active Directory в целях аутентификации.

Выполните следующие шаги, чтобы интегрировать эти серверы с AD с помощью samba, winbind и Kerberos.

Содержание

Шаг 1: Установите пакеты samba-winbind и kerberos.
Шаг 2: Синхронизация времени.
Шаг 3: Отредактируйте файл /etc/hosts.
Шаг 4: Отредактируйте файл /etc/krb5.conf.
Шаг 6: Теперь настройте Samba и Winbind.
Шаг 7: Настройте файл /etc/nsswitch.conf для обработки аутентификации.

Шаг 1: Установите пакеты samba-winbind и kerberos.

# yum install samba-winbind samba-winbind-clients samba krb5-libs  krb5-workstation pam_krb5

Шаг 2: Синхронизация времени.

AD очень требователен к соответствию времени при аутентификации.

Поэтому время сервера linux и сервера AD должно быть синхронизировано с сервером ntp.

Используйте приведенную ниже команду для синхронизации времени сервера Linux с сервером ntp.

# ntpdate [ntp-server-ip-address/dns-name]

Чтобы сделать вышеуказанную конфигурацию постоянной, отредактируйте файл “/etc/ntp.conf” и просто замените то, что там есть, на один или несколько NTP-серверов в вашем домене, например:

# vi /etc/ntp.conf
server [ntp-server-ip-address/dns-name]

Запустите сервис:

# /etc/init.d/ntpd start
# chkconfig ntpd on

Шаг 3: Отредактируйте файл /etc/hosts.

# vi /etc/hosts
[ip-address]  adserver.yourdomain adserver

Шаг 4: Отредактируйте файл /etc/krb5.conf.

# vi /etc/krb5.conf
[domain_realm]
yourdomain = YOURDOMAIN
[libdefaults]
    ticket_lifetime = 24000
    default_realm = YOURDOMAIN
    dns_lookup_realm = true
    dns_lookup_kdc = false
    cache_type = 1
    forwardable = true
    proxiable = true
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
    permitted_enctypes = des3-hmac-sha1 des-cbc-crc
    allow_weak_crypto = no
[realms] 
    YOURDOMAIN = {
    kdc = [ip address of AD server:Port]
    admin_server = [ip address of AD server:Port]
    default_domain = yourdomain
  }

[appdefaults]
  pam = {
    debug = true
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
  }
[logging]
  default = FILE:/var/krb5/kdc.log
  kdc = FILE:/var/krb5/kdc.log
  admin_server = FILE:/var/log/kadmind.log

Шаг 5: Теперь протестируйте аутентификацию Kerberos.

# kinit [user-name]

Если он запросит пароль, введите пароль пользователя ad, если все в порядке, то мы получим приглашение, в противном случае перепроверьте файл krb5.conf.

Шаг 6: Теперь настройте Samba и Winbind.

Отредактируйте файл /etc/samba/smb.conf.

# vi /etc/samba/smb.conf
[global]
    workgroup = [Workgroup-Name]
    netbios name = site2       ## replace the site2 with hostname
    realm = 
    security = ADS
    template shell = /bin/bash
    idmap backend = tdb
    idmap uid = 1-100000000
    idmap gid = 1-100000000
    winbind use default domain = Yes
    winbind nested groups = Yes
    winbind enum users = Yes
    winbind enum groups = Yes
    template shell = /bin/bash
    template homedir = /home/%D/%U
    winbind separator = /
    winbind nss info = sfu
    winbind offline logon = true
    hosts allow = 127.0.0.1 0.0.0.0/0
    obey pam restrictions = yes
    socket options = TCP_NODELAY
    max log size = 150
    passdb backend = tdbsam
    printing = cups
    load printers = yes
    cups options = raw
    printcap name = cups
    disable spoolss = Yes
    show add printer wizard = No
    interfaces = eth0 lo
    bind interfaces only = yes
    winbind refresh tickets = true
    log file = /var/log/samba/log.%m
    max log size = 50
    log level = 3
    encrypt passwords = yes
    #map untrusted to domain = yes
    #auth methods = winbind guest sam
    map untrusted to domain = Yes
[printers]
    comment = All Printers
    path = /var/spool/samba
    browseable = yes
    public = yes
    guest ok = yes
    writable = no
    printable = yes

Шаг 7: Настройте файл /etc/nsswitch.conf для обработки аутентификации.

# vi /etc/nsswitch.conf
passwd:   compat winbind
shadow:   winbind
group:      compat winbind

Шаг 8: Теперь перезапустите службы winbind и Samba.

# /etc/init.d/smb restart
# /etc/init.d/winbind restart

Теперь присоединитесь к домену:

# net ads join -U [User Name]

Если вышеуказанная команда сообщает “Join is OK”, проверьте winbind:

Команда для составления списка всех пользователей AD:

Пожалуйста, не спамьте и никого не оскорбляйте.

Это поле для комментариев, а не спамбокс.

Рекламные ссылки не индексируются!

Источник

This tutorial will describe how you can join machines that run Linux Mint 17.1 OS to Windows 2012 Active Directory Domain Controller in order to authenticate remote accounts from AD back end identity provider to local Linux workstations with the help of SSSD service and Realmd system DBus service.

The System Security Services Daemon (SSSD) is a relative new service which provides cross-domain compatible methods for Active Directory users to authenticate to local machines using a combination of usernames and domain back end name to create the login identity, even if the Domain Controller goes offline (SSSD caches credentials).

REQUIREMENTS

Windows Server 2012 configured as an Active Directory Domain Controller
A Linux Mint 17.1 client machine which will be integrated to Windows PDC

Domain Settings:

Domain Name: caezsar.lan
Windows Server 2012 AD FQDN: server.caezsar.lan
Windows Server 2012 AD IP Address: 192.168.1.130
Linux Mint Hostname: mint-desktop
Linux Mint IP Address: automatically assigned by DHCP
Linux Mint first DNS IP Address: Manually assigned to point to AD PDC – 192.168.1.130

STEP ONE – Linux Mint Network Configuration

1. Before starting with installing the required services in order to integrate the local machine to the PDC Server, first we need to assure that Windows Domain Controller is reachable through DNS resolution on Linux Mint host by adding the DNS PDC IP Address on our Network Configuration. To achieve this goal, first open Network Settings, go to the Network Interface Card (in this case is the Wired Connection, but you can use a Wireless Connection also), open it for editing (hit the settings icon from bottom right) and add your PDC IP Address on IPv4 DNS filed (switch Automatic DNS to OFF) as illustrated in the following screenshots:

network settings

edit network interface settings

add DNS IP Address

If multiple Domain Controllers machines exists on your network then you can also add their IP Addresses on IPv4 DNS settings fields.

2. After you’re done, hit on Apply button and switch the edited Network Interface from ON to OFF and then back to ON in order to apply the new settings. After the network interface is started again, open a Terminal console and issue a ping command against your PDC domain name in order to verify if the settings are successfully applied and the domain name responds with the correct IP Address and FQDN of the PDC.

apply network settings

ping domain controller

If you want to avoid all this manual settings, then configure a DHCP server at your premises to automatically assign network settings, especially DNS entries, that will point to your Windows PDC IP Addresses needed for DNS resolution in order to reach the AD PDC.

STEP TWO – Install Required Software Packages

As presented at the beginning of this tutorial, in order to integrate a Linux Mint machine to an Active Directory Domain Controller you need to install the SSSD service along with the following software packages and dependency:

– SSSD service (responsible with back end realm authentication) with the following dependencies: sssd-tools (optional, but useful for sssd cache, user and groups manipulation), libpam-sss (PAM modules for local authentication) and libnss-sss (NSS modules for local DNS resolution)

– Realmd (system DBus service which manages domain integration and local resources permissions)

– The following Samba Modules: samba-common-bin and samba-libs (File sharing compatibility between Windows and Linux machines)

– Krb5-user (Client network authentication and communication with the PDC server)

– ADcli (Tools for joining domain and perform other actions on an AD)

– PackageKit (Linux cross-platform packages management for interoperabillity and user privileges for software installations)

3. Now, let’s start installing the above enumerated packages by opening a Terminal console on Linux Mint and issuing the following commands with sudo privileges:

First install Realmd and SSSD service:

sudo apt-get install realmd sssd sssd-tools libpam-sss libnss-sss

install realmd and sssd service

4. Next install Samba modules (by default this modules might be already installed on your system):

sudo apt-get install samba-libs samba-common-bin

install samba modules

5. Last, install the other remained packages: krb5-user, adcli and packagekit. On krb5-user package, the installer will prompt you to enter the realm that will be used for Kerberos authentication. Use the name of the domain configured for your PDC with UPPERCASE (in this case the domain is CAEZSAR.LAN), then hit Enter key to continue further with the installation packages.

sudo apt-get install krb5-user adcli packagekit

install kerberos, adcli and packagekit packages

Configure Kerberos realm

STEP THREE – Edit Configuration Files for SSSD, Realmd and PAM

6. Next step before starting joining Linux Mint to Windows Server AD PDC is to configure the local services for AD network authentication. By default the SSSD service has no configuration file defined on /etc/sssd/ path. In order to create a default configuration file for SSSD service, issue the following command to create and simultaneous edit the file:

sudo nano /etc/sssd/sssd.conf

SSSD configuration file excerpt:

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[sssd]
domains = CAEZSAR.LAN
config_file_version = 2
services = nss, pam

[domain/CAEZSAR.LAN]
ad_domain = CAEZSAR.LAN
krb5_realm = CAEZSAR.LAN
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
access_provider = ad

sssd configuration file

While editing the file make sure you replace domains, [domain/], ad_domain and krb5_realm parameters accordingly. Use the UPPERCASES as the above file excerpt suggests.

The fallback_homedir = /home/%d/%u parameter will cause the system to create home directories for all domain logged in users with the following path: /home/domain_name/domain_user, so practically all your domain users homes will be stored into a single directory named after your domain name on /home path. If you want to change this behavior so all domain users homes should be created as normal system users, /home/username, just remove %d variable and you’re done.

For other options and parameters concerning sssd.conf file run man sssd command.

After you finish editing the file, save it with CTRL+O , close it with CTRL+X and proceed further with the below instructions.

7. The next step is to create and edit a configuration file for Realmd in order to avoid some eventual package dependency problems by issuing the following command:

sudo nano /etc/realmd.conf

Use the following configurations for realmd file:

[service]

automatic-install = no

realmd conf file

After you add the above lines, save the file and close it.

8. The last file that you need to edit before joining the domain is the common-session PAM file. So, open this file for editing by running the below command and add the following line after the session optional pam_sss.so line in order for the system to automatically create home directories for the new authenticated AD users .

sudo nano /etc/pam.d/common-session

Add the following line as presented on the below screenshot:

session optional      pam_mkhomedir.so  skel = /etc/skel/  mask=0077

PAM common-session file

After you have edited the file, save it and close it, and proceed to the next step in order to make Linux Mint a part of the Windows Domain Controller.

STEP FOUR – Join Linux Mint to Windows Server 2012 Active Directory Domain Controller

9. Before joining the Linux Mint client to Windows PDC, first issue the discovery command against your domain name in order to view the complete realm configurations and a package list of software that must be installed on the client machine before you enroll it in the realm.

sudo realm discover  domain.tld

realm discover domain

10. If everything is correctly setup at the client side and the domain controller responds, issue the following command in order to integrate Linux Mint client machine to Windows Server 2012 AD PDC.

sudo realm join domain.tld -U domain_administrator --verbose

join AD domain

Use the -U option to specify an Active Directory administrative user with privileges to add machines on the server and the --verbose option to get debug output in case something goes wrong with the integration process.

Once the command returns successfully status and ads Linux Mint to AD you can use the sudo realm list command to view full details and the default configurations for your domain.

list realm

To manage sssd service use the following command switches (you don’t need to manually start the sssd service because it’s automatically started by the realmd when the machine is enrolled to realm):

sudo service sssd status|start|stop

11. To check if the machine appears on the Domain Controller, go to your Windows Server 2012, open Active Directory Users and Computers utility and search your Linux Mint hostname.

Active Directory Users and Computers

STEP FIVE – Log In on Linux Mint with Active Directory Accounts

12. To authenticate on Linux Mint with and an Active Directory user, first you need to add a permit rule on local policies in order to grant access for all realm users on local machine, by issuing the following command:

sudo realm permit --all

To grant access just for a specific AD user or group use the following command syntax:

sudo realm permit -u AD_username

sudo realm permit -g AD_group

To withdraw access for a user use the command with --x switch:

sudo realm permit domain --x domainAD_username

13. To perform Terminal console command line authentications on Linux Mint host with an Active Directory account, use double backslashes to escape the backslash which separates the domain string from user, as shown in the below syntax (you can append the dot domain or use just the domain string):

su - domain.tld\AD_username

su - domain\AD_username

AD user login

ad user login without dot domain

14. To log in with an AD account on Linux using Putty or to perform Linux Mint MDM GUI logins use the following syntax:

domainAD_username

domain.tldAD_username

AD user Putty login

Ad user GUI login

15. In case you have issues with AD users authentication on Linux Mint Logon Screen, log in with a local user account and change the Login Window Theme from an HTML theme to a GDM theme, log out, hit Escape key is case the last logged in user appears on username Login filed and continue the authentication process with a AD account as presented above.

Use GDM theme

GDM login screen

STEP SIX – Add Root Permissions to AD Domain Admins Users

16. In case you want to allow all Active Directory Domain Admins to have full administrative permissions in order to execute any command with root privileges on the Linux Mint machine, open the local sudoers file for editing and add the following line:

sudo nano /etc/sudoers

sudo visudo

Add this line after %sudo line:

%domain   admins@domain.tld  ALL=(ALL)      ALL

add domain admins root privileges

17. In case you don’t want your Linux Mint machine to be a part of the domain anymore, issue the following command to leave the domain:

sudo realm leave domain.tld -U AD_admin_user --verbose

leave AD PDC

That’s all! Now, the machine running Linux Mint 17.1 is integrated as a part of Windows Active Directory Domain Controller and can successfully replace your old Windows XP machine, for which Microsoft has stopped its support, but keep in mind that some features and, especially, a huge part of Active Directory Group Policy, don’t apply on Linux systems.

Источник

Думаю если вы попали на эту страницу, значит тем или иным путем пришли к выводу о том, что необходимо настроить систему централизованного управления учетными записями в локальной сети вашего предприятия, скорее всего это контроллер домена на Ubuntu или Windows. У вас как обычно 3 основных пути для реализации своего плана:

1. Выкинуть деньги на ветер
2. Сесть за пиратство
3. Использовать какое-либо решение на базе линукса

Если честно, есть еще 4-й вариант, и он очень даже неплох. Основывается он на Synology NAS, обладающих просто божественными возможностями даже в самых маленьких реализациях.

Но вернемся к нашим реалиям. Наш вариант номер 3. В деталях он выглядит примерно так:

У нас в сети нет ни одного серверного решения Microsoft
Мы не хотим появления в нашей сети пиратских серверных решений Microsoft
В большинстве своем наша сеть состоит из машин с ОС Ubuntu Desktop, но есть и пара ноутбуков с вендами.
У нас есть необходимость централизованного управления учётными записями
У нас есть одно или несколько сетевых хранилищ и мы хотим управлять доступом к хранимой на них информации, предоставляя его через протоколы NFS и CIFS(smb). Сетевые хранилища могут быть реализованы как на голых ubuntu server, так на различных решениях типа FreeNAS, NAS4Free и тд, так и на покупных решениях, типа QNAP, Synology и тд.

Реализовывать контроллер домена на Ubuntu мы будем на хосте ESXi с примерно следующими характеристиками:

CPU: 1 ядро на 2.2-2.8 GHz
RAM: 2 Gb
HDD: 1 hdd 32Gb
Network: 1 Сетевая карта
Имя сервера: ag-dc
Имя домена: adminguide.lan

Что касается физической машины, то подойдет любая не сильно мощная машина. Но если там хотя бы 4‑х ядерный CPU и 4+ гига оперативной памяти, я рекомендовал бы запилить на неё бесплатный гипервизор ESXi и уже с его помощью полностью утилизировать имеющиеся мощности.

Поправка к инструкции: Везде в тексте инструкции, имя тестового samba домена изменено с adminguide.local на adminguide.lan. зона .local может вызывать глюки в виндовых сетях. Если вы видите на скриншоте adminguide.local, на самом деле там должно быть adminguide.lan

Устанавливаем Ubuntu Server 18.04 LTS amd64
Изменяем имя сервера на ag-dc
1. После изменения имени сервера в соответствии с инструкцией, перезагружаем сервер следующей командой:
```
sudo reboot -h now
```
2. Проверяем имя сервера
  После загрузки сервера, авторизовываемся и смотрим результат команды
  hostnamectl
  . Должно быть следующее:
  
  Важно понимать, что после того, как вы настроите контроллер домена на Ubuntu, смена имени его сервера приведет к непредвиденным последствиям, поэтому не надо пытаться превратить свою тестовую попытку, в рабочее решение. После того как вы один или несколько раз инициализируете свой ad-dc и убедитесь в его работоспособности, удалите все свои достижения и уже только после этого выполняйте чистовую работу, полностью отдавая себе отчет в производимых действиях.
Настраиваем статический IP адрес
1. На данном этапе, пока у нас еще не стоит самба и не инициализирован домен, наши настройки будут следующими:
  IP адрес и маска сети сервера: 192.168.1.100/24
  Шлюз 192.168.1.1 (роутер в тестовой сети)
  dns сервер 192.168.1.1 (роутер в тестовой сети). Переходим по ссылке и выполняем все по инструкции приводя настройки сети к следующему виду:
```
            dhcp4: no
dhcp6: no
addresses: [192.168.1.100/24, ]
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.1, ]
```
  Вот как выглядит файл настроек на тестовом сервере:
  
  Главным ДНС сервером на данный момент должен быть указан локальный роутер, или любой другой днс сервер, например 8.8.8.8, способный выполнять эти функции.
Отключаем systemd-resolved
1. Останавливаем сервис systemd-resolved
```
sudo service systemd-resolved stop
```
2. Убираем systemd-resolved из автозапуска
```
sudo systemctl disable systemd-resolved.service
```
3. Удаляем ссылку /etc/resolv.conf
```
sudo rm /etc/resolv.conf
```
4. Открываем на редактирование файл /etc/resolv.conf
```
sudo nano /etc/resolv.conf
```
  По факту, на данный момент этого файла еще не существует, он будет создан при сохранении изменений.
5. Добавляем переадресацию на наш днс сервер и указываем search домен в resolv.conf .
```
nameserver 192.168.1.1
search adminguide.lan
```
  На данном этапе, nameserver должен указывать на тот же адрес, что и в пункте 3.1
  В search указывается имя нашего будущего домена Active Directory.
  Файл /etc/resolv.conf должен выглядеть следующим образом:
6. Сохраняем изменения нажав Ctrl+O
Настраиваем файл /etc/hosts
1. Одним из обязательных условий, является резолв имени нашего сервера, на его IP в локальной сети. Если сервер находится в сети 192.168.1.0/24 и его IP 192.168.1.100, то набирая на нем команду ping ag-dc или же ping ag-dc.adminguide.lan должен резолвиться адрес 192.168.1.100. Имя контроллера домена, не должно резолвиться на локальный адрес 127.0.0.1 или какой либо другой адрес, кроме того, что назначен сетевому интерфейсу который использует DC.
```
sudo nano /etc/hosts
```
2. Приводим файл hosts к следующему виду:
```
127.0.0.1       localhost.localdomain   localhost
192.168.1.100   ag-dc.adminguide.lan  ag-dc
```
3. Сохраняем с помощью команды
  Ctrl+O
Проверяем что не запущено никаких самвобых процессов

Для этого понадобится следующая команда:
```
ps ax | egrep "samba|smbd|nmbd|winbindd"
```
Если есть хоть один процесс и вы видите что-то типа этого:

таки возможно вы настраиваете AD-DC не на новом сервере или на сервере развернутом не из оригинального образа. Если вы решите на свой страх и риск продолжить установку, то вам необходимо убить все процессы с именами samba, smbd, nmbd, winbindd. Чтобы убить процесс, надо использовать команду sudo kill <id-процесса>:
```
sudo kill 3135
```
Устанавливаем Samba

На этом этапе так же важно знать, что после того как вы инициализируете контроллер домена на Ubuntu, вы не сможете изменить его название. Если вы называете свой домен ADMINGUIDE.LAN, он на веки вечные останется доменом ADMINGUIDE.LAN . Самба не поддерживает изменение имени домена. После его инициализации, чтобы изменить название, вам придется вывести из него все машины что вы успели зарегистрировать в нем, удалить старый домен, инициализировать новый и зарегистрировать машины повторно. Стоит ли говорить, что даже при 25 рабочих станциях — это уже проблема
1. Устанавливаем samba и все необходимые пакеты командой:
```
sudo apt -y install samba krb5-config winbind smbclient krb5-user
```
2. Область по умолчанию для Kerberos версии 5
  
  Указываем ADMINGUIDE.LAN
3. Серверы Kerberos для вашей области
  
  Указываем ag-dc.adminguide.lan
4. Управляющий сервер вашей области Kerberos
  
  Так же указываем ag-dc.adminguide.lan
5. Ожидаем окончание установки
Бэкапим стандартную конфигурацию Samba
```
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
```
Инициируем контроллер домена на Ubuntu 18.04
1. Запускаем инициализацию в интерактивном режиме
  
  Из своего домена, мы так же будем управлять пользователями и группами линуксовых машин. Поэтому нам нужно заранее включить поддержку NIS, с помощью команды —use-rfc2307
```
sudo samba-tool domain provision --use-rfc2307 --interactive
```
  Включение поддержки NIS, не имеет никаких противопоказаний к применению, даже если ваш домен никогда не будет обслуживать линуксовые машины. В то же время, если инициализировать домен без поддержки NIS, и когда-нибудь в него войдут линуксовые машины и захочется управлять их учётками, расширять схему Active Directory и добавлять поддержку NIS, придётся уже ручками на свой страх и риск.
2. Указываем параметры домена
  
  Если в процессе настройки не было допущено ошибок, все необходимые данные установщик поместит в квадратные скобки в виде стандартных значений:
```
Realm [ADMINGUIDE.LAN]:
Domain [ADMINGUIDE]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write 'none' to disable forwarding) [192.168.1.1]:
Administrator password:
Retype password:
```
  Когда установщик запросит пароль, рекомендую указать пароль понадежнее. Это будет пароль от учетной записи администратора домена.
  
  Если на этом этапе в квадратных скобках у вас указано не то значение которое вам бы хотелось, значит вероятнее всего в настройках ранее вы допустили серьезный косяк.
3. Смотрим результаты инициализации
  
  Следующие строки возвестят о том, что контроллер домена на Ubuntu успешно завершил инициализацию:
```
A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
Setting up fake yp server settings
Once the above files are installed, your Samba AD server will be ready to use
Server Role:           active directory domain controller
Hostname:              ag-dc
NetBIOS Domain:        ADMINGUIDE
DNS Domain:            adminguide.lan
DOMAIN SID:            S-1-5-21-4033150357-3109693390-3173112578
```
  Но радоваться еще слишком рано. Если вы видите нечто кардинально другое, значит вы допустили какую-то ошибку выше, либо прервали инициализацию запущенную ранее, либо инициализация вывалилась с ошибкой и сейчас вы пытаетесь инициализировать домен повторно. Если упереться рогом, можно вычистить все данные и записи сгенерированные в процессе инициализации и запустить её повторно. Это даже может привести к её успешному окончанию. НЕ ПЫТАЙТЕСЬ ЭТОГО ДЕЛАТЬ. Инициализируйте домен на новом чистом сервере. Если в процессе подготовки к инициализации, вы допустили косяк, и на момент запуска инициализации вы его не устранили и она завершилось ошибкой — просто удалите текущую инсталяцию сервера и начните сначала. Если вы настраиваете контроллер домена на виртуальной машине, сделайте снапшот выключенного сервера прежде чем приступать к пункту 7.1. В будущем в случае какого-то косяка на этапе инициализации, возвращайтесь к этому снапшоту и перепроверяйте всё исправляйте ошибки.
Настройка DC

Контроллер домена на Ubuntu, реализованный с помощью Samba сам автоматически запускает необходимые сервисы. Поэтому если они будут запущены не Samba DC, а например вручную пользователем, это может привести к необратимым последствиям и домен перестанет функционировать как должен. Поэтому на всякий случай, необходимо сделать эти сервисы недоступными для ручного запуска и отключить их автозапуск:
```
sudo systemctl stop smbd nmbd winbind
sudo systemctl disable smbd nmbd winbind
sudo systemctl mask smbd nmbd winbind
```
Делаем samba-ad-dc доступным для запуска, включаем сервис и включаем его автозапуск
```
sudo systemctl unmask samba-ad-dc
sudo systemctl start samba-ad-dc
sudo systemctl enable samba-ad-dc
```
Настройка DNS
1. Изменяем dns сервер в настройках сети на IP настраиваемого сервера. По факту он будет ссылаться на себя же как на днс сервер 192.168.1.100
  Приводим настройки параметров сети к следующему виду:
```
            dhcp4: no
dhcp6: no
addresses: [192.168.1.100/24, ]
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.100, ]
```
2. Изменяем dns сервер в resolv.conf, так же указывая там IP своего сервера, приводя его к следующему виду:
```
nameserver 192.168.1.100
search adminguide.lan
```
Настройка Kerberos

В процессе инициализации домена, создается файл krb5.conf, путь к нему указывается в последних строках отчета об успешной инициализации. Поэтому чтобы избежать ручной настройки файла /etc/krb5.conf, нам нужно заменить его только что сгенерированным.
```
sudo cp /var/lib/samba/private/krb5.conf /etc/
```
Проверяем результаты своей работы
1. Смотрим все шары файл сервера DC
```
smbclient -L localhost -U%
```
  Они создаются в процессе инициализации домена и должны присутствовать для его правильного функционирования.
  
  Контроллер домена на Ubuntu — Результат smbclient -L localhost -U%
2. Проверяем подключение к ним
  Подключаемся к папке netlogon от имени администратора домена
```
smbclient //localhost/netlogon -UAdministrator -c 'ls'
```
  Когда система запросит пароль, необходимо ввести пароль администратора домена, который мы указали при инициализации, в пункте 9.2
  
  Контроллер домена на Ubuntu — Результат smbclient //localhost/netlogon -UAdministrator -c ‘ls’
  
  В случае успешной авторизации, вы без ошибок подключитесь к папке
3. Проверяем правильность настройки DNS
  Без правильно функционирующей службы DNS, AD DC не сможет функционировать как запланировано. Главное, нам необходимо убедиться, что SAMBA_INTERNAL dns настроен правильно и работает. Для этого попытаемся извлечь из него необходимые записи
  1. Смотрим SRV запись _ldap
```
host -t SRV _ldap._tcp.adminguide.lan.
```
  2. Смотрим SRV запись _kerberos
```
host -t SRV _kerberos._udp.adminguide.lan.
```
  3. Проверяем A запись контроллера домена
```
host -t A ag-dc.adminguide.lan.
```
    Контроллер домена на Ubuntu — Результаты проверки DNS
4. Проверяем работоспособность Kerberos
```
kinit administrator
```
5. Смотрим кеш авторизационных тикетов Kerberos
```
klist
```
  Контроллер домена на Ubuntu — Результат kinit administrator и klist
Полезные ссылки:
- Best practices for sysvol maintenance
- Обновлённая версия статьи

Источник

На большом количестве разных интернет-ресурсов можно встретить описание процедуры присоединения серверов на базе ОС Linux к домену Active Directory, и практически везде в таких описаниях в виде неотъемлемой части присутствует установка Samba с последующим использованием Winbind. Мы тоже не стали в этом плане исключением. В этой заметке я хочу рассмотреть пример использования альтернативного средства расширения функционала аутентификации и авторизации в Linux – службы SSSD (System Security Services Daemon), которая будет автоматически настроена с помощью пакета realmd (Realm Discovery). В этом примере нами будет настроена аутентификация и авторизация на сервере Debian GNU/Linux 8.6 (Jessie) с подключением к домену Active Directory (на базе Windows Server 2012 R2).

Общую информацию о SSSD можно получить здесь — FedoraProject Wiki – SSSD и здесь — FedoraHosted Wiki – sssd. На русском языке небольшое описание есть в статье Датавед — Настройка SSSD и интересный комментарий есть в ветке форума Pro-LDAP.ru — Сводка систем аутентификации. Меня же SSSD заинтересовала после того, как я наткнулся на пару интересных статей в блоге Red Hat, где SSSD рассматривается как более продвинутая альтернатива Winbind —Overview of Direct Integration Options и SSSD vs Winbind. Даже не взирая на то, что SSSD имеет некоторые ограничения, такие как, например, отсутствие поддержки NTLM (зачем он нужен, если есть Kerberos), эта штука всё равно выглядит интересно.

Как сказано в документе Configuring_sssd_with_ad_server поддержка Active Directory (AD) появилась в SSSD начиная с версии 1.9.0. Проверим версию доступную нам в репозиториях только что установленной Debian Jessie:

# apt-cache show sssd

Package: sssd
Version: 1.11.7-3
Installed-Size: 42
Maintainer: Debian SSSD Team 
Architecture: amd64
Depends: python-sss (= 1.11.7-3), sssd-ad (= 1.11.7-3), sssd-common (= 1.11.7-3), sssd-ipa (= 1.11.7-3), sssd-krb5 (= 1.11.7-3), sssd-ldap (= 1.11.7-3), sssd-proxy (= 1.11.7-3)
Description-en: System Security Services Daemon -- metapackage
Provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. This package is a metapackage which installs the daemon and existing authentication back ends.
Multi-Arch: foreign
Homepage: https://fedorahosted.org/sssd/
Section: utils
Priority: extra
Filename: pool/main/s/sssd/sssd_1.11.7-3_amd64.deb
Size: 13248
...

Итак, имеющаяся в репозиториях Debian версия имеет поддержку AD, хотя и не является самой актуальной версией.

Предварительные требования

Прежде чем приступить к установке и настройке SSSD, убедимся в том, что на нашей Linux-системе корректно настроен DNS клиент, то есть, как минимум, в файле /etc/resolv.conf есть ссылки на DNS-серверы, которые отвечают за разрешение имён в домене Active Directory:

# cat /etc/resolv.conf

search ad.holding.com
nameserver 10.1.0.9
nameserver 10.6.1.8

Также, в силу того, что SSSD будет использовать Kerberos, нам нужно убедиться в том, что у нас корректно настроен NTP-клиент и время синхронизировано с контроллерами домена AD. Устанавливаем NTP-клиент и открываем на настраиваем его конфигурационный файл:

# apt-get install ntp
# nano /etc/ntp.conf

В файле меняем строчки указывающие на NTP-сервер. В качестве источника времени указываем контроллеры домена AD:

server 10.1.0.9 iburst
server 10.6.1.8 iburst

Перезапускаем службу ntp и проверяем статус синхронизации времени:

# service ntp restart
# ntpq -4 -p
# date -R

Синхронизация времени настроена и теперь можно приступать к настройке SSSD.

Установка realmd и присоединение к домену Active Directory

Для автоматизации создания конфигурации SSSD существует очень удобный инструмент – пакет realmd (Realm Discovery). Документацию об использовании этого инструмента можно найти по адресу freedesktop.org — realmd docs. Утилита realm, входящая в этот пакет способна автоматически обнаружить информацию о домене AD и поможет нам простым и удобным способом выполнить присоединение нашей Linux-системы к этому домену с автоматической настройкой системы аутентификации Linux (PAM/NSS) и её интеграцией с SSSD.

Установим пакет realmd:

# apt-get install realmd

Проверим как работает обнаружение домена, выполнив realm discover (подробности здесь)

# realm discover ad.holding.com --verbose

 * Resolving: _ldap._tcp.ad.holding.com
 * Performing LDAP DSE lookup on: 10.2.0.8
 * Performing LDAP DSE lookup on: 10.4.5.2
 * Performing LDAP DSE lookup on: 10.2.5.3
 * Successfully discovered: ad.holding.com
ad.holding.com
  type: kerberos
  realm-name: AD.HOLDING.COM
  domain-name: ad.holding.com
  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

Как видим, из службы DNS по служебным SRV-записям успешно получена информация о домене и определён набор пакетов, которые нужно установить и настроить в систему для успешного подключения к домену.

Перед запуском процедуры автоматической установки и настройки пакетов с последующим присоединением к домену, при желании (опционально) мы можем настроить дополнительные параметры для работы утилиты realm. Для этого можно создать и настроить конфигурационный файл realmd.conf:

# touch /etc/realmd.conf

Информацию о поддерживаемых опциях файла можно найти в онлайн-справке, либо в локальной справке man realmd.conf. Например, зададим произвольные имя и версию ОС, которые будут отправлены в качестве значений атрибутов operatingSystem и operatingSystemVersion при создании учётной записи компьютера в домене AD

[active-directory]
os-name = Debian GNU/Linux
os-version = 8.6 (Jessie)

Теперь перейдём к процедуре присоединения нашего Linux-компьютера к домену с помощью команды realm join. В ходе выполнения этой процедуры будет выполнено несколько действий:

Будет установлено ПО необходимое для присоединения и последующей авторизации в домене AD (пакеты adcli, libpam-sss, libnss-sss, sssd, sssd-tools);
Будет создана учётная запись компьютера в домене AD;
Будет сгенерирован keytab-файл /etc/krb5.keytab для поддержки Kerberos;
Будет сконфигурирована и запущена служба sssd
Будут настроены конфигурационные файлы PAM/NSS для поддержки доменной аутентификации

Пример выполнения команды:

# realm join --verbose --user=petya --user-principal="host/kom-app31.ad.holding.com@AD.HOLDING.COM" --computer-ou="OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com" kom-dc01.ad.holding.com

Все доступные к использованию опции можно посмотреть в онлайн-документации. В рассматриваемом нами примере Linux-компьютер с именем хоста KOM-APP31 будет присоединяться к домену AD.HOLDING.COM, а в процессе присоединения для создаваемой в домене учётной записи компьютера будет использоваться Organizational Unit (OU) Linux ServersKOMad.holding.com. Присоединение к домену будет выполняться с использованием подключения к ближайшему к нам контроллеру домена kom-dc01.ad.holding.com. Обратите внимание на то, что если в качестве последнего параметра явно указан контроллер домена, то он и будет в дальнейшем использоваться в качестве источника проверки учётных данных. Если же вместо имени конкретного контроллера домена указать имя домена, то для определения контроллеров домена используемых для аутентификации в дальнейшем будет использоваться механизм авто-обнаружения по SRV-записям в DNS, что не всегда является желательной конфигурацией, хотя и сводит к минимуму возможные дополнительные правки конфигурационных файлов после «джойна». Помимо этого при вызове команды нами используется ряд опций:

user – логин доменного пользователя с правами, достаточными для ввода компьютера в домен AD. От имени этого пользователя будет выполняться присоединение компьютера к домену и модификация атрибутов доменной учётной записи компьютера. В классической ситуации — это пользователь с правами администратора домена, так как именно администраторы домена по умолчанию в AD могут обновлять значение атрибута servicePrincipalName. Однако я не очень люблю для «попсовых» задач использовать привилегии такого уровня, поэтому здесь я использую рядового доменного пользователя, у которого есть права на создание и модификацию объектов типа Computer в OU указанном в опции computer-ou;
user-principal – строка регистрации принципала Kerberos, которая будет использоваться для генерации keytab-файла и регистрации значений атрибута userPrincipalName в свойствах учётной записи компьютера в домене AD.
Теперь о том, зачем мы здесь используем эту опцию.
Указывать в явном виде такое значение, как используется в нашем примере, вовсе не обязательно, так как по сути утилита adcli, которая используется в фоновом режиме в процессе «джойна» должна сама регистрировать значение вида host/serverfqdn@REALM. Однако в нашем случае из репозиториев Debian автоматически устанавливается устаревшая версия (0.7.5-1) этой утилиты, которая имеет проблему описанную в статье adcli creates wrong kerberos keytab entry with uppercase HOST, то есть при генерации keytab-файла записи типа host/* создаются в верхнем регистре, то есть HOST/*. А это, в свою очередь, может в дальнейшем привести к проблеме использования keytab-файла такими службами как, например, sshd. Судя по документу Red Hat Bugzilla — Bug 1267319 этот баг исправлен в adcli версии 0.8.0-1, но так как у нас нет этого обновления, мы используем обходное решение, то есть в явном виде задаём нужный нам формат записи в опции user-principal.;
computer-ou – имя OU, в котором мы хотим создать учётную запись компьютера в домене. Если учётная запись уже существует, то она будет обновлена.
verbose – понятное дело, подразумевает расширенный вывод информации о всех происходящих действиях.

Пример выполнения команды в моём конкретном случае:

 * Resolving: _ldap._tcp.kom-dc01.ad.holding.com
 * Resolving: kom-dc01.ad.holding.com
 * Performing LDAP DSE lookup on: 10.1.0.9
 * Successfully discovered: ad.holding.com
Password for petya:{здесь введём пароль пользователя}
 * Unconditionally checking packages
 * Resolving required packages
 * Installing necessary packages: adcli, libpam-sss, libnss-sss, sssd, sssd-tools
 * LANG=C /usr/sbin/adcli join --verbose --domain ad.holding.com --domain-realm AD.HOLDING.COM --domain-controller 10.1.0.9 --computer-ou OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com --login-type user --login-user petya --stdin-password
 * Using domain name: ad.holding.com
 * Calculated computer account name from fqdn: KOM-APP31
 * With user principal: host/kom-app31.ad.holding.com@AD.HOLDING.COM
 * Using domain realm: ad.holding.com
 * Sending netlogon pings to domain controller: ldap://10.1.0.9
 * Received NetLogon info from: KOM-DC01.ad.holding.com
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-hRFuGh/krb5.d/adcli-krb5-conf-5nYX3C
 * Authenticated as user: petya@AD.HOLDING.COM
 * Looked up short domain name: KOM
 * Using fully qualified name: KOM-APP31
 * Using domain name: ad.holding.com
 * Using computer account name: KOM-APP31
 * Using domain realm: ad.holding.com
 * Calculated computer account name from fqdn: KOM-APP31
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Using fully qualified name: KOM-APP31
 * Using domain name: ad.holding.com
 * Using computer account name: KOM-APP31
 * Using domain realm: ad.holding.com
 * Looked up short domain name: KOM
 * Computer account for KOM-APP31$ does not exist
 ! Couldn't find a computer container in the ou, creating computer account directly in: OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Calculated computer account: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Created computer account: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
 * Modifying computer account: dNSHostName
 * Modifying computer account: userAccountControl
 * Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack
 * Modifying computer account: userPrincipalName
 ! Couldn't set service principals on computer account CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com: 00002083: AtrErr: DSID-03151785, #1:
        0: 00002083: DSID-03151785, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)

 ! Couldn't authenticate with keytab while discovering which salt to use: KOM-APP31$@AD.HOLDING.COM: Client 'KOM-APP31$@AD.HOLDING.COM' not found in Kerberos database
 * Added the entries to the keytab: KOM-APP31$@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/kom-app31.ad.holding.com@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM: FILE:/etc/krb5.keytab
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

В моём примере видно, что процесс ввода в домен завершился успешно, однако с заполнением атрибута servicePrincipalName в свойствах учётной записи компьютера в домене возникла проблема, так как указанному в опции —user пользователю petya банально не хватило прав на это действие. Об этом я в общем-то и писал выше, то есть проблему эту я создал себе сам для большего контроля над процессом. Чтобы исправить это, я выполню данное действие в домене вручную с помощью утилиты setspn с любой доменной Windows-машины уже с правами доменного администратора:

C:> setspn -A HOST/kom-app31.ad.holding.com kom-app31

Проверка домена DC=ad,DC=holding,DC=com
Регистрация ServicePrincipalNames для CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com
        HOST/kom-app31.ad.holding.com
Обновленный объект

Проверяем результат:

C:> setspn -L kom-app31

Зарегистрирован ServicePrincipalNames для CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com:
        HOST/kom-app31.ad.holding.com

Теперь можем приступить к проверке результатов работы realm join, хотя по большому счёту делать это имеет смысл только в случае «траблшутинга» или необходимости внесения в конфигурационные файлы дополнительных правок, чтобы учесть собственную специфику, как в нашем случае.

Проверяем результат работы realm join

В ходе присоединения к домену утилита realm автоматически выполнила установку нужных пакетов — adcli, libpam-sss, libnss-sss, sssd, sssd-tools. При этом, наша Linux-система осталась свободной от монструозной Samba с её Winbind, и это, в некоторой степени, не может не радовать. Более того, в системе мы даже не обнаружим классически привычного для Kerberos пакета krb5-user. Поэтому если мы, по какой-то причине, всё-таки заходим заглянуть внутрь сгенерированного keytab-файла, то нам придётся таки установить соответствующий пакет (по крайней мере другого способа посмотреть keytab я не знаю):

# apt-get install krb5-user
# klist -e -k -t /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 KOM-APP31$@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 host/kom-app31.ad.holding.com@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 HOST/KOM-APP31@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (des-cbc-crc)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (des-cbc-md5)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (arcfour-hmac)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (aes128-cts-hmac-sha1-96)
   2 10/13/2016 10:52:10 RestrictedKrbHost/KOM-APP31@AD.HOLDING.COM (aes256-cts-hmac-sha1-96)

Как видим, в нашем keytab-файле присутствуют записи. которые мы ранее указывали в опции —user-principal.

***

Проверим наличие настроенного утилитой realm файла /etc/sssd/sssd.conf. При необходимости можно сразу подправить файл, чтобы разрешить аутентификацию по коротким именам, например petya, то есть, без указания доменного суффикса в формате petya@ad.holding.com. Для этого можно либо убрать параметр «use_fully_qualified_names = True» либо в глобальную секцию «[sssd]» добавить доменный суффикс по умолчанию. Я выбираю второй вариант. Помимо этого мы можем добавить нужные нам дополнительные серверы аутентификации — контроллеры домена, расширив значение параметра ad_server и добавив, при необходимости, параметр ad_backup_server (подробнее здесь). Указывать в явном виде конкретные контроллеры домена может быть полезно в случае, если в домене много контроллеров и автоматический механизм обнаружения по SRV-записям в DNS возвращает далеко расположенные контроллеры, что может вызвать дополнительные задержки в процессе аутентификации. В итоге файл примет следующий вид:

[sssd]
domains = ad.holding.com
config_file_version = 2
services = nss, pam
default_domain_suffix = ad.holding.com

[domain/ad.holding.com]
ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com
ad_backup_server = msk-dc01.ad.holding.com, msk-dc02.ad.holding.com
ad_domain = ad.holding.com
krb5_realm = AD.HOLDING.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad

Практика показала, что даже в случае явного указания контроллеров домена, в случае если в лесу AD несколько доменов, возможна ситуация, при которой поиск доменных пользователей не будет возвращать результатов. В таком случае в секцию [domain/ad.holding.com] можно попробовать добавить дополнительные параметры, ограничивающие поиск:

[domain/ad.holding.com]
...
subdomains_provider = none
ldap_idmap_default_domain_sid = S-1-5-21-xxx-xxx-xxx

Первый параметр отключает запросы к другим поддоменам внутри леса, а второй параметр определяет SID домена, в котором должен выполняться поиск. SID всех доменов в лесу AD можно легко получить на любом доменном Windows-компьютере с помощью PowerShell:

(Get-ADForest).Domains | %{Get-ADDomain -Server $_} | Select name, domainsid

***

Дополнительно пришлось столкнуться с ситуацией, когда при определении членства в группах безопасности для пользователя возвращался неполный перечень групп. Например команда id petya выводила только информацию об основной группе пользователя (например domain users). Обнаружилось и описание этой проблемы: sssd ticket 2667 — id_provider = ad requires ldap_use_tokengroups = False to see secondary groups. В качестве обходного решения этой проблемы предполагается отключение параметра ldap_use_tokengroups в секции домена:

[domain/ad.holding.com]
...
ldap_use_tokengroups = False
...

***

Ещё одна ситуация, с которой можно столкнуться в доменах Active Directory с большим количеством групп и пользователей – исчерпание пула idmap, используемого по умолчанию в SSSD. В таком случае команда типа getent group <имя группы> может не возвращать членство группы, а команда типа id <имя пользователя> может возвращать неполный список доменных групп пользователя. При этом, если запустить sssd интерактивно (службу предварительно нужно остановить) с расширенным дебагом…

# service sssd stop
# sssd -i --debug-level=3

…то в результате выполнения выше обозначенных команд можно обнаружить ошибку типа:

[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [SID пользователя/группы] to a UNIX ID

Для решения этой проблемы можно попробовать расширить используемый в SSSD по умолчанию размере пула idmap с 200000 до, например, 2000000. Делается это в секции описания домена в sssd.conf:

[domain/ad.holding.com]
...
ldap_idmap_range_size = 2000000
...

Подробнее об idmap и его границах в sssd можно почитать в man sssd-ad

***

Чтобы внесённые в sssd.conf изменения вступили в силу, перезапускаем службу sssd с очисткой кэшей sss:

# service sssd stop
# rm -f /var/lib/sss/db/*
# rm -f /var/lib/sss/mc/*
# service sssd start

Убедимся в том, что служба sssd успешно запущена и настроена на автоматический запуск:

# service sssd status

● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled)
   Active: active (running)  since Tue 2016-10-14 23:10:13 MSK; 4s ago
  Process: 10310 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 10311 (sssd)
   CGroup: /system.slice/sssd.service
           ├─10311 /usr/sbin/sssd -D -f
           ├─10312 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain ad.holding.com --debug-to-files
           ├─10313 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --debug-to-files
           └─10314 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --debug-to-files
...

***

Проверить то, что SSSD успешно прописан в качестве NSS/PAM провайдера можно, заглянув в ряд системных файлов — /etc/nsswitch.conf и /etc/pam.d/common-*. Файл nsswitch.conf привожу информативно без внесения в него каких-либо правок и убрав из вывода его комментарии, чтобы показать, что в нём появились вызовы sss:

passwd:         compat sss
group:          compat sss
shadow:         compat sss
gshadow:        files
hosts:          files dns
networks:       files
protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files
netgroup:       nis sss

Проверим файл /etc/pam.d/common-session. Внесём в этот файл дополнительную правку — в конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия. Таким образом, для вновь подключаемых к серверу доменных пользователей автоматически будут создаваться домашние каталоги по шаблону указанному в параметре fallback_homedir в конфигурации sssd.conf. Результирующий файл (без вывода комментариев) получится следующий:

session [default=1]     pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session required        pam_unix.so
session optional        pam_sss.so
session optional        pam_systemd.so
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

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

Файл /etc/pam.d/common-auth :

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Файл /etc/pam.d/common-account :

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
account requisite                       pam_deny.so
account required                        pam_permit.so
account sufficient                      pam_localuser.so
account [default=bad success=ok user_unknown=ignore]    pam_sss.so

Файл /etc/pam.d/common-password :

password        requisite                       pam_pwquality.so retry=3
password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password        sufficient                      pam_sss.so use_authtok
password        requisite                       pam_deny.so
password        required                        pam_permit.so

Проверяем доступ к пользователям и группам Active Directory

Теперь можно проверить возможность получения информации о пользователе из домена AD. При желании можно проверить разные форматы представления учётной записи (с NetBIOS-именем домена, с доменным суффиксом в виде UPN):

# getent passwd petya
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

# getent passwd KOM\petya
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

# getent passwd petya@ad.holding.com
petya@ad.holding.com:*:1668597447:1668100510:Петя Резинкин:/home/ad.holding.com/petya:/bin/bash

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

# getent group "KOM-SRV-Linux-Admins@ad.holding.com"

kom-srv-linux-admins@ad.holding.com:*:1668876454:petya@ad.holding.com,vovan@ad.holding.com

Как видим, всё в порядке. И при этом SSSD очень шустро и без граблей, с которыми мне ранее приходилось сталкиваться в Winbind, возвращает требуемые объекты каталога AD.

Ограничение доступа через доменные группы безопасности

Теперь нам нужно подумать о том, как ограничить доступ доменных пользователей для входа на наш Linux-сервер, так как в конфигурации по умолчанию все доменные пользователи, успешно прошедшие аутентификацию, смогут войти в нашу Linux-систему. Это подтвердит команда realm list, в которой нам нужно обратить внимание на строчку login-policy

# realm list

ad.holding.com
  type: kerberos
  realm-name: AD.HOLDING.COM
  domain-name: ad.holding.com
  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@ad.holding.com
  login-policy: allow-realm-logins

Разрешим вход только для конкретной доменной группы, например KOM-SRV-Linux-Admins, с помощью команды realm permit:

# realm permit --groups KOM-SRV-Linux-Admins@ad.holding.com

В результате этой команды в конфигурационный файл /etc/sssd/sssd.conf в секции, описывающей подключение к соответствующему домену, будет внесено изменение:

...
[domain/ad.holding.com]
...
access_provider = simple
simple_allow_groups = KOM-SRV-Linux-Admins@ad.holding.com

Проверим то, как изменился вывод realm list:

# realm list

ad.holding.com
...
  login-policy: allow-permitted-logins
  permitted-logins:
  permitted-groups: KOM-SRV-Linux-Admins@ad.holding.com

Как видим, политика login-policy изменилась, и теперь присутствует явное указание разрешённой доменной группы доступа.

***

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

Доступ к sudo

Для добавления возможности повышения привилегий с помощью команды sudo для доменных пользователей для простоты воспользуемся ранее упомянутой доменной группой безопасности KOM-SRV-Linux-Admins, хотя можно использовать и любую другую доменную группу, например с более узким составом членов.

Создадим файл, в котором будет описано разрешающее правило для sudo:

# touch /etc/sudoers.d/kom-srv-linux-admins

Обратите внимание на комментарии написанные в файле /etc/sudoers.d/README. Имя создаваемого файла не должно заканчиваться знаком «~» и иметь в своём составе точек. В файл добавим всего одну строку вида:

%KOM-SRV-Linux-Admins@ad.holding.com ALL=(ALL) ALL

Установим ограничивающие разрешения на созданный и настроенный файл:

# chmod 0440 /etc/sudoers.d/kom-srv-linux-admins

Проверяем результат. Войдя в систему от имени доменного пользователя, входящего в ранее разрешённую для sudo доменную группу KOM-SRV-Linux-Admins, пробуем выполнить любую команду с повышением привилегий через sudo:

petya@ad.holding.com@KOM-APP31:~$ sudo whoami
[sudo] password for petya@ad.holding.com: {вводим пароль пользователя petya}

root

Как видим, команда выполняется успешно с повышением привилегий.

В некоторых источниках, как например здесь приводится пример того, что для совместной работы sudo и sssd нужно устанавливать пакет libsss-sudo, хотя я такой пакет не устанавливал и sudo при этом работает, отталкиваясь от членства доменной группы безопасности. Поэтому надобность libsss-sudo для меня пока остаётся загадкой.

Удалённый доступ по протоколу SSH

Если говорить про SSH, то никакой специальной настройки sshd я не выполнял, так как по умолчанию ssh-сервер уже настроен на использование PAM, а тот в свою очередь был ранее автоматически настроен на использование доменной аутентификации с помощью утилиты realm.

Однако если вы захотите настроить Single sign-on (SSO) из Putty при подключении c Windows-машины по ранее описанной методике, то здесь без установки пакета kerb5-user, как я понял, опять же не обойтись.

# apt-get install krb5-user

В файле /etc/ssh/sshd_config достаточно раскомментировать и включить параметры GSSAPI:

...
# GSSAPI options 
GSSAPIAuthentication yes 
GSSAPICleanupCredentials yes
...

При этом AllowGroups можно не заполнять, так как будет использоваться членство групп описанное ранее в sssd с помощью realm permit. После правки перезапускаем службу ssh-сервера и проверяем работу SSO

# service ssh restart

p align=»center»>***

Резюмируя, можно сказать, что с помощью realmd и sssd настройка подключения Linux-машины к домену Active Directory несколько упрощается и становится более наглядной по сравнению с ранее описанным вариантом, а также не влечёт за собой необходимости использования Samba со «всеми вытекающими». Поэтому наверняка стоит задуматься об использовании данных инструментов для последующих «джойнов».

Дополнительные источники информации:

FedoraHosted.org — sssd Wiki — Configuring_sssd_with_ad_server
Red Hat Enterprise Linux Blog — SSSD-vs-Winbind
RHEL7 Documentation — System Level Authentication Guide — 7.3. SSSD and Identity Providers (Domains)
RHEL7 Documentation — System Level Authentication Guide — 7.2. SSSD and System Services
Андрей Маркелов — Обзор Red Hat Directory Server и RHEL IdM
jhrozek Blog — Anatomy of SSSD user lookup
Alan D Moore Blog — Joining Debian 8 to Active Directory
Датавед — Настройка SSSD
Форум проекта Pro-LDAP.ru — Сводка систем аутентификации
Сергей Яремчук — Подключаемся к Active Directory с помощью realmd

Источник

Терминология

Настройка

Настройка AD

Обновление GPO

Настройка Linux хоста

Установка

Обновление DNS

Настройка NTP

Kerberos

Создание ключа Kerberos

Подтверждение ключа

pam_winbind.conf

Samba

Запуск и проверка сервисов

Запуск Samba

Присоединение к Домену

Перезапуск Samba

Проверка Winbind

Проверка nsswitch

Проверка команд Samba

Настройка PAM

system-auth

Раздел «auth»

Раздел «account»

Раздел «session»

Раздел «password»

Проверка входа

Настройка общих файлов

Добавление файла keytab и включение беспарольного входа на машину через Kerber и ssh

Создание key tab файла

Включение входа через keytab

Подготовка sshd на сервере

Добавление опций, нужных для клиента

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

Настройка для полной аутентификации Kerberos без пароля.

Генерирование keytab, которые будет принимать AD

Интересно знать

Смотрите также

Коммерческие решения

Introduction

Background

Prerequisites

Installation

Kerberos

Pam

LDAP

TestQuery: Windows

Configure AD

TestQuery: Linux

libnss-ldap

Troubleshooting

Шаг 1. Обновите свой APT

Шаг 2. Задайте имя хоста сервера и DNS

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

Шаг 5. Присоединитесь к Ubuntu 20.04 | 18.04 / Debian 10 к домену Active Directory (AD)

Шаг 6. Контроль доступа – Ограничьте до пользователя / группы

Шаг 7. Настройте доступ через Sudo

Шаг 8. Проверьте доступ по SSH

Шаг 1: Установите пакеты samba-winbind и kerberos.

Шаг 2: Синхронизация времени.

Шаг 3: Отредактируйте файл /etc/hosts.

Шаг 4: Отредактируйте файл /etc/krb5.conf.

Шаг 6: Теперь настройте Samba и Winbind.

Шаг 7: Настройте файл /etc/nsswitch.conf для обработки аутентификации.

Устанавливаем Ubuntu Server 18.04 LTS amd64

Изменяем имя сервера на ag-dc

Настраиваем статический IP адрес

Отключаем systemd-resolved

Настраиваем файл /etc/hosts

Проверяем что не запущено никаких самвобых процессов

Устанавливаем Samba

Бэкапим стандартную конфигурацию Samba

Инициируем контроллер домена на Ubuntu 18.04

Запускаем инициализацию в интерактивном режиме

Указываем параметры домена

Смотрим результаты инициализации

Настройка DC

Настройка DNS

Настройка Kerberos

Проверяем результаты своей работы