Как добавить линукс в домен windows

В этой статье будет описан процесс добавления Linux-машины (Ubuntu 20.04) в домен Windows AD.

Шаг 1. Установка пакетов и подготовка

sudo apt updatesudo apt upgrade

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

Шаг 2. Настройка DNS

sudo nano /etc/netplan/*.yaml

network:ethernets:enp0s3:addresses:- 192.168.0.15/24gateway4: 192.168.0.10nameservers:addresses: [192.168.0.1, 192.168.0.2]search:- office.localoptional: trueversion: 2

• addresses — это IP, назначаемый сетевой карте;
• gateway4 — IP роутера;
• nameservers — DNS-сервера;
• search — целевой домен.

sudo netplan apply

Шаг 3. Обнаружение домена, присоединение к нему и проверка результата.

realm discover office.local

office.localtype: kerberosrealm-name: OFFICE.LOCALdomain-name: office.localconfigured: no...

realm join -U admin1 office.localPassword for admin1:

id user1@office.localuid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

Шаг 4. Последние настройки и авторизация.

sudo nano /etc/sssd/sssd.conf

sudo systemctl restart sssdid useruid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

sudo nano /etc/pam.d/common-session#add this line in the end of filesession optional pam_mkhomedir.so skel=/etc/skel umask=077

su – userPassword:Creating directory '/home/user1@office.local'.user1@ubuntu-server:~$

Это означает, что вы успешно вошли в систему как пользователь AD.

sudo realm deny –allsudo realm permit user0@office.local user1@office.localsudo realm permit -g 'Main Admins'

sudo nano /etc/sudoers.d/admins

user ALL=(ALL) ALL%Domain\ Admins ALL=(ALL) ALL

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

Введение

sudo aptitude update
sudo aptitude upgrade

sudo aptitude install krb5-user samba winbind 

sudo aptitude install libpam-krb5 libpam-winbind libnss-winbind

Настройка DNS

domain domain.com
search domain.com
nameserver 192.168.0.1
nameserver 192.168.0.2

supersede domain-name "domain.com";

prepend domain-name-servers 192.168.0.2;

/etc/init.d/networking restart

smbsrv01

# Имена этого компьютера
127.0.0.1	localhost
127.0.1.1	smbsrv01.domain.com	smbsrv01

ping dc
ping dc.domain.com

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

sudo net time set dc

ntpdate ntp.mobatime.ru

sudo aptitude install ntp

# You do need to talk to an NTP server or two (or three).
server dc.domain.com

sudo /etc/init.d/ntp restart

Настройка авторизации через Kerberos

[libdefaults]
	default_realm = DOMAIN.COM
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true

[realms]
	DOMAIN.COM = {
		kdc = dc
		kdc = dc2
		admin_server = dc
		default_domain = DOMAIN.COM
	}

[domain_realm]
	.domain.com = DOMAIN.COM
	domain.com = DOMAIN.COM
[login]
	krb4_convert = false
	krb4_get_tickets = false

kinit username@DOMAIN.COM

klist

kdestroy

Распространённые ошибки kinit

kinit(v5): Clock skew too great while getting initial credentials

kinit(v5): Preauthentication failed while getting initial credentials

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

DOMAIN.COM = {
# ...

kinit username@DOMAIN.COM

kinit(v5): Client not found in Kerberos database while getting initial credentials

Настройка Samba и вход в домен

[global]
   # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без
   # последней секции после точки, а realm - полное имя домена 
   workgroup = DOMAIN
   realm = DOMAIN.COM

   # Эти две опции отвечают как раз за авторизацию через AD
   security = ADS
   encrypt passwords = true
   # Просто важные 
   dns proxy = no 
   socket options = TCP_NODELAY

   # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе,
   # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде
   domain master = no
   local master = no
   preferred master = no
   os level = 0
   domain logons = no

   # Отключить поддержку принтеров
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

testparm

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

net ads join -U username -D DOMAIN

# net ads join -U username -D DOMAIN
Enter username's password:
Using short domain name -- DOMAIN
Joined 'SMBSRV01' to realm 'domain.com'

Используемые параметры команды net

net ads testjoin

#net ads testjoin
Join is OK

DNS update failed!

sudo aptitude install smbclient

smbclient -k -L workstation

Настройка Winbind

   # Опции сопоставления доменных пользователей и виртуальных пользователей в системе через Winbind.
   # Диапазоны идентификаторов для виртуальных пользователей и групп.
   idmap uid = 10000 - 40000
   idmap gid = 10000 - 40000
   # Эти опции не стоит выключать.
   winbind enum groups = yes
   winbind enum users = yes
   # Использовать домен по умолчанию для имён пользователей. Без этой опции имена пользователей и групп
   # будут использоваться с доменом, т.е. вместо username - DOMAINusername.
   # Возможно именно это вам и нужно, однако обычно проще этот параметр включить. 
   winbind use default domain = yes
   # Если вы хотите разрещить использовать командную строку для пользователей домена, то
   # добавьте следующую строку, иначе в качестве shell'а будет вызываться /bin/false
   template shell = /bin/bash
   # Для автоматического обновления билета Kerberos модулем pam_winbind.so нужно добавить строчку
   winbind refresh tickets = yes

sudo /etc/init.d/winbind stop
sudo smbd restart
sudo /etc/init.d/winbind start 

sudo testparm

ulimit -n 16384

# Добавить в конец файла строки:
*               -    nofile            16384
root            -    nofile            16384

# wbinfo -t
checking the trust secret for domain DCN via RPC calls succeeded

wbinfo -u
wbinfo -g

Добавление Winbind в качестве источника пользователей и групп

passwd:         compat
group:          compat

passwd:         compat winbind
group:          compat winbind

files:          dns mdns4_minimal[NotFoud=return] mdns4

getent passwd
getent group 

Авторизация в Ubuntu через пользователей домена

Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind.

Он-лайн авторизация

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

greeter-show-manual-login=true

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok try_first_pass
auth        sufficient    pam_winbind.so use_first_pass krb5_auth krb5_ccache_type=FILE
auth        required      pam_deny.so

account     sufficient    pam_winbind.so
account     required      pam_unix.so

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_ck_connector.so nox11
session     required      pam_limits.so
session     required      pam_env.so
session     required      pam_unix.so

password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_winbind.so
password    required      pam_deny.so

sudo bash -c "for i in 2 3 4 5; do mv /etc/rc$i.d/S20winbind /etc/rc$i.d/S99winbind; done"

mv /etc/rc4.d/S20winbind /etc/rc4.d/S99winbind

Офф-лайн авторизация

[global]
   # Возможность оффлайн-авторизации при недоступности доменконтроллера
   winbind offline logon = yes
   # Период кэширования учетных записей, по умолчанию равен 300 секунд
   winbind cache time = 300
   # Необязательная настройка, но избавляет от нудных пауз, указываем контроллер домена dc, 
   # можно указать и ip, но это является плохим тоном
   password server = dc

#
# pam_winbind configuration file
#
# /etc/security/pam_winbind.conf
#
[global]
  # turn on debugging
  debug = no
  # request a cached login if possible
  # (needs "winbind offline logon = yes" in smb.conf)
  cached_login = yes
  # authenticate using kerberos
  krb5_auth = yes
  # when using kerberos, request a "FILE" krb5 credential cache type
  # (leave empty to just do krb5 authentication but not have a ticket
  # afterwards)
  krb5_ccache_type = FILE
  # make successful authentication dependend on membership of one SID
  # (can also take a name)
  ;require_membership_of =
  silent = yes

auth    sufficient      pam_unix.so nullok_secure
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

auth    optional        pam_group.so
auth    sufficient      pam_unix.so nullok_secure  use_first_pass
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

Ссылки

Introduction

This Howto describes how to add an Ubuntu box in an Active Directory domain and to authenticate the users with AD.

Note: Centrify Express and Likewise Open are alternative solutions for Linux systems to authenticate to an Active Directory domain. For Centrify Express see DirectControl. For Likewise Open see LikewiseOpen.

Used terms

Kerberos

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

Join AD domain

Required software

You need to install the winbind and samba packages. The packages smbfs and smbclient are useful for mounting network shares and copying files.

Ubuntu 10.04 and later should also install the libnss-winbind and libpam-winbind packages.

The package smbfs is optional, but includes useful client utilities, including the smbmount command. Also useful is the smbclient package, which includes an FTP-like client for SMB shares.

Join

The first step in joining the Active Directory domain is to edit /etc/samba/smb.conf:

file:  /etc/samba/smb.conf 

[global]
        security = ads
        realm = LAB.EXAMPLE.COM
# If the system doesn't find the domain controller automatically, you may need the following line
#        password server = 10.0.0.1
# note that workgroup is the 'short' domain name
        workgroup = LAB
#       winbind separator = +
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        winbind enum users = yes
        winbind enum groups = yes
        template homedir = /home/%D/%U
        template shell = /bin/bash
        client use spnego = yes
        client ntlmv2 auth = yes
        encrypt passwords = yes
        winbind use default domain = yes
        restrict anonymous = 2

Adding valid users = @»Domain Users» to the [global] section will allow all Domain Users to see all of the shares avaliable without a password. This is the equivlient to allowing «Everyone» to read all shares. If you want to restrict reading a share then you will have to specify valid users for that share.

The «winbind use default domain» parameter is useful in single-domain enterprises and causes winbind to treat any username that isn’t qualified with a domain name as a username in the domain to which winbind is joined. Omit this parameter if you are concerned about confusion between local accounts on your systems and accounts in the default domain. The «winbind separator» directive is optional, and the default value is the usual backslash «» Domain and User separator. You can use «+» if you know of a specific reason «» will not work in your environment.

Be sure to restart the Samba and Winbind services after changing the /etc/samba/smb.conf file:

sudo /etc/init.d/winbind stop
sudo /etc/init.d/samba restart
sudo /etc/init.d/winbind start

Request a valid Kerberos TGT for an account using kinit, which is allowed to join a workstation into the AD domain. Now join to the domain, if the ticket was valid you should not need to supply a password — even if prompted you should be able to leave it blank.

This next step gave me the error:  kinit(v5): Cannot resolve network address for KDC in realm LAB.EXAMPLE.COM while getting initial credentials even though nslookup win2k3 and host 10.0.0.1 would both return the correct entries. To correct this problem, I had to edit my /etc/hosts file and add the following to it: 10.0.0.1   win2k3.lab.example.com

sudo kinit Administrator@EXAMPLE.COM
sudo net ads join
Using short domain name – LAB
Joined 'linuxwork' to realm 'LAB.EXAMPLE.COM'

If the Kerberos auth was valid, you should not get asked for a password. However, if you are not working as root and are instead using sudo to perform the necessary tasks, use the command sudo net ads join -U username and supply your password when prompted. Otherwise, you will be asked to authenticate as root@LAB.EXAMPLE.COM instead of a valid account name. You can also supply a password if you don’t want to get prompted. Just use net ads join -U <username>%<password> for this. Maybe it’s useful for unattended installations where you want to add machines to an AD automatically.

If your Active Directory server is not running DDNS as well (eg. if you’re running a separate DNS server) you may get the error:

sudo net ads join
Failed to join domain: failed to find DC for domain LAB.EXAMPLE.COM

To fix this, specify the AD server to the «net join» command:

sudo net ads join -S WIN2K3 -U <username>%<password>

You’ll get a warning about not being able to update DNS, but you will successfully join the AD!

Testing

Using a clean install of 10.04, I did not have to modify any PAM files to get authentication working. I had to edit common-session to get the home directories created, but that is it.

Setup Authentication

nsswitch

file: /etc/nsswitch.conf

passwd:         compat winbind
group:          compat winbind
shadow:         compat

I needed to add hosts:  files dns to /etc/nsswitch.conf to avoid the settings in /etc/hosts to be ignored.

Don´t forget to restart winbind again after editing /etc/nsswitch.conf!!!

Testing

You can check that the Domain has successfully been joined by:

wbinfo -u

You should get a list of the users of the domain.

I needed to make shadow:  compat winbind in /etc/nsswitch.conf to make wbinfo -u work.

And a list of the groups. Be patient these queries can take time.

wbinfo -g

Check Winbind nsswitch module with getent.

This step may or may not work. If you only see local users, try connecting with a Windows machine anyways. (Tested under Ubuntu 9.10 x64)

sudo getent passwd

root:x:0:0:root:/root:/bin/bash
...
LAB+administrator:x:10000:10000:Administrator:/home/LAB/administrator:/bin/bash
LAB+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash
...

Note that the domain name (here, «LAB+») is displayed by getent only if you have not set winbind use default domain = yes in smb.conf.

sudo getent group

root:x:0:
daemon:x:1:
bin:x:2:
...
LAB+organisations-admins:x:10005:administrator
LAB+domänen-admins:x:10006:manuel,administrator
LAB+domänen-benutzer:x:10000:
LAB+domänen-gäste:x:10001:
LAB+linux-admins:x:10004:manuel
...

PAM

With this configuration you can access the workstation with local accounts or with domain accounts. On the first login of a domain user a home directory will be created. This PAM configuration assumes that the system will be used primarily with domain accounts. If the opposite is true (i.e., the system will be used primarily with local accounts), the order of pam_winbind.so and pam_unix.so should be reversed. When used with local accounts, the configuration shown here will result in a failed authentication to the Windows/Samba DC for each login and sudo use. This can litter the DC’s event log. Likewise, if local accounts are checked first, the /var/log/auth.log will be littered with failed logon attempts each time a domain account is accessed.

Note: You can use pam-auth-update to add the necessary entries for winbind authentication. If you installed libpam-winbind above, this step is all you need to do to configure pam. You may want to add the line to automatically create the home directory.

sudo pam-auth-update

This PAM configuration does not acquire a Kerberos TGT at login. To acquire a ticket, use kinit after logging in, and consider using kdestroy in a logout script.

file: /etc/pam.d/common-account

account sufficient       pam_winbind.so
account required         pam_unix.so

file: /etc/pam.d/common-auth

auth sufficient pam_winbind.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required   pam_deny.so

On a Ubuntu 7.10 (Gutsy Gibbon) and 9.04 (Jaunty Jackalope) systems, these changes to pam.d/common-auth result in not being able to log in as a local user, for example by ssh. Your luck may be better, but test immediately just in case.

This one allows login for AD users and local users (tested with Ubuntu 9.10)

file: /etc/pam.d/common-auth

auth sufficient pam_unix.so nullok_secure
auth sufficient pam_winbind.so require_membership_of=domänen-admins use_first_pass
auth requisite  pam_deny.so
auth required   pam_permit.so
auth optional   pam_ecryptfs.so unwrap

ecryptfs does not work with AD users. Login is successful with local users and AD users which are members of AD group domänen-admins

file: /etc/pam.d/common-session

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

file: /etc/pam.d/sudo

auth sufficient pam_winbind.so
auth sufficient pam_unix.so use_first_pass
auth required   pam_deny.so

@include common-account

Final configuration

Each domain needs a directory in /home/.

sudo mkdir /home/LAB

One last thing

If you want to be able to use an active directory account to manage your Ubuntu box, you need to add it to the sudoers file. For that, you will need to edit the file /etc/group an add your username to the admin group and whatever other group you need(plugdev,audio,cdrom just to mention a few). it will be like:

.......
admin:x:117:olduser,ActiveDirectoryUser
.......

Where, olduser, is your current linux user and, ActiveDirectoryUser, is the new administrator. Another way to make a Domain Group a sudoer in your ubuntu is to edit the file /etc/sudoers (using the command ‘visudo’) and add the following line

%adgroup        ALL=(ALL) ALL

Where, adgroup, is a group from your active directory. Keep in mind that spaces in the group name are not allowed. You can use ‘%domain admins’, without quotes.

Usage

Logon with DOMAIN+USERNAME, unless you included «winbind use default domain» in your smb.conf, in which case you may log in using only USERNAME.

login: LAB+manuel
Password: *****
...
LAB+manuel@linuxwork:~$

Automatic Kerberos Ticket Refresh

To have pam_winbind automatically refresh the kerberos ticket

Add the  winbind refresh tickets  line to  smb.conf :

file:  /etc/samba/smb.conf 

#       winbind separator = +
        winbind refresh tickets = yes
        idmap uid = 10000-20000

And modify /etc/pam.d/common-auth:

file: /etc/pam.d/common-auth

auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required   pam_deny.so

Troubleshooting

If the Winbind PAM module in /var/log/auth.log says that the AD-user is not existing restart winbind. It might be best to restart the whole workstation.

sudo /etc/init.d/winbind restart

If when logging into the machine one gets a «no logon servers» error winbindsamba may not be starting properly. Try restarting them manually, and then logging in.

-If a manual restart works, then to fix this issue one needs to change scripts S20samba and S20winbind to S25samba and S25winbind in the /etc/rc2.d, rc3.d, rc4.d, rc5.d folders. The understanding is that this causes samba and winbind to startup later in the boot order for each runlevel. So that they start after S24avahi-daemon. If you then find that you must wait a bit before you can log in, you need to set «winbind enum users» and «winbind enum groups» in /etc/samba/smb.conf to ‘no’.

name service cache daemon

The name service cache daemon (nscd) can interfere with winbind, as winbind maintains its own cache. Remove it.

sudo apt-get remove nscd

Some names or groups are resolved with getent, but others are not

The range of your idmap parameter is not wide enough to encompass all the users or groups

idmap uid = 16777216-33554431
idmap gid = 16777216-33554431

Adding more than one Linux machine to a Windows network

The above procedure allows you to add as many Linux machines as you like. However, the UID assigned to a given user may not be the same across all the machines. It created file ownership & rights issues when files/folders are shared between these machines. See Question #21806 on https://answers.launchpad.net/ubuntu/ for details. Therefore it is advisable to specify the UID mapping method

idmap backend = rid:YOURDOMAIN=70000-1000000
idmap uid = 70000-1000000
idmap gid = 70000-1000000
winbind use default domain = yes
security = ADS

The newer syntax is (with old style you can get NT_STATUS_OBJECT_NAME_COLLISION in /var/log/samba/log.winbindd)

idmap domains = YOURDOMAIN
idmap config YOURDOMAIN:backend = rid
idmap config YOURDOMAIN:range = 70000-1000000
winbind use default domain = yes
security = ADS

Resources

• The Samba and Active Directory Wiki contains very detailed instructions.

Automated Methods

The SADMS package allows for automated joining to Active Directory through a GUI interface. http://sadms.sourceforge.net/

CategorySecurity

Перед администраторами иногда встают задачи интеграции Linux серверов и рабочих станций в среду домена Active Directory. Обычно требуется:
1. Предоставить доступ к сервисам на Linux сервере пользователям домена.
2. Пустить на Linux сервер администраторов под своими доменными учётными данными.
3. Настроить вход на Linux рабочую станцию для пользователей домена, причём желательно, чтобы они могли при этом вкусить все прелести SSO (Я, например, не очень люблю часто вводить свой длинный-предлинный пароль).

Обычно для предоставления Linux системе пользователей и групп из домена Active Directory используют winbind либо настраивают библиотеки nss для работы с контроллером домена Active Directory по LDAP протоколу. Но сегодня мы пойдём иным путём: будем использовать PowerBroker Identity Services (Продукт известен также под именем Likewise).

Установка.

Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.
Получить Open версию можно на сайте производителя, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.
Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Исходники (Open edition) доступны в git репозирории: git://source.pbis.beyondtrust.com/pbis.git
Я устанавливал PBIS на Debian Wheezy amd64:

wget http://download.beyondtrust.com/PBISO/7.1.0/1203/pbis-open-7.1.0.1203.linux.x86_64.deb.sh
./pbis-open-7.1.0.1203.linux.x86_64.deb.sh

Содержимое пакета устанавливается в /opt/pbis. Также в системе появляется новый runscript lwsmd, который собственно запускает агента PBIS.
В систему добавляется модуль PAM pap_lsass.so.
Утилиты (большей частью консольные), необходимые для функционирования PBIS, а также облегчающие жизнь администратору размещаются в /opt/pbis/bin

Ввод в домен.

Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)
Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.
Для ввода в домен потребуется указать: имя домена, логин и пароль доменного пользователя с правами для ввода ПК в домен, контейнер для размещения объекта компьютера в домене — всё то же самое, что и при вводе в домен windows ПК.

После ввода в домен потребуется перезагрузка.
Обратите внимание — PBIS умеет работать с сайтами Active Directory. Клиент PBIS будет работать с контроллерами того сайта, в котором он находится!

После перезагрузки.

После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ «^»).
В доменной DNS зоне появится запись с именем вашего ПК.
Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.

/opt/pbis/bin/config --list

[Eventlog]
        AllowDeleteTo
        AllowReadTo
        AllowWriteTo
        MaxDiskUsage
        MaxEventLifespan
        MaxNumEvents
[Lsass]
        DomainSeparator
        SpaceReplacement
        EnableEventlog
        LogInvalidPasswords
        Providers
[Lsass - PAM]
        DisplayMotd
        PAMLogLevel
        UserNotAllowedError
[Lsass - Active Directory provider]
        AssumeDefaultDomain
        CreateHomeDir
        CreateK5Login
        SyncSystemTime
        TrimUserMembership
        LdapSignAndSeal
        LogADNetworkConnectionEvents
        NssEnumerationEnabled
        NssGroupMembersQueryCacheOnly
        NssUserMembershipQueryCacheOnly
        RefreshUserCredentials
        CacheEntryExpiry
        DomainManagerCheckDomainOnlineInterval
        DomainManagerUnknownDomainCacheTimeout
        MachinePasswordLifespan
        MemoryCacheSizeCap
        HomeDirPrefix
        HomeDirTemplate
        RemoteHomeDirTemplate
        HomeDirUmask
        LoginShellTemplate
        SkeletonDirs
        UserDomainPrefix
        DomainManagerIgnoreAllTrusts
        DomainManagerIncludeTrustsList
        DomainManagerExcludeTrustsList
        RequireMembershipOf
        SmartcardEnabled
        SmartcardRequiredForLogin
[Lsass - Local provider]
        Local_AcceptNTLMv1
        Local_HomeDirTemplate
        Local_HomeDirUmask
        Local_LoginShellTemplate
        Local_SkeletonDirs
[User Monitor]
        UserMonitorCheckInterval
[System Initialization]
        LsassAutostart
        EventlogAutostart
        GpagentAutostart

Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.
Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.
Я также сразу задал «RequireMembershipOf» — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.
Описание каждого параметра можно получить, например так:

/opt/pbis/bin/config --detail RequireMembershipOf

Значение параметра устанавливается например так:

/opt/pbis/bin/config RequireMembershipOf "Администраторы^Linux"

Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.
loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.
uid формируется как хэш SID пользователя.
gid — как хэш SID primaryGroup пользователя.
Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.

Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin. Также Firefox (при настройке network.negotiate-auth.trusted-uris) позволяет использовать SSO при доступе к Web-порталам с доменной авторизацией (естественно если SSO настроена на сервере)

А как же SSO при доступе к ресурсам на Linux ПК?

Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.
Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)

GSSAPIAuthentication yes

И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)
UsePAM yes

(PBIS предоставляет модуль для PAM в том числе)
Также логично будет добавить директиву «AllowGroups» и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.

На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:

GSSAPIAuthentication yes

Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.

На клиентском Windows ПК (члене домена) при использовании Putty следует в свойствах SSH соединения установить флаг «Attempt GSSAPI authentification (SSH-2 only)» (В разных версиях этот пункт называется по-разному).

Также в секции Connection —> Data можно поставить переключатель в позицию «Use system username»

Если вы намереваетесь организовать таким образом ssh доступ администраторов к linux серверам — хорошей идеей будет запретить на них вход root по ssh и добавить linux-администраторов (а ещё лучше их доменную группу) в файл sudoers.

Это не единственные сценарии применения PBIS. если статья покажется Вам интересной — в следующей напишу как организовать samba файловый сервер в домене для доменных пользователей без winbind.

Дополнительную информацию по теме можно получить на форуме сообщества PowerBroker Identity Services: forum.beyondtrust.com

UPD. К преимуществам PowerBroker Identity Services я могу отнести:

1. Хорошую повторяемость (сравните последовательность действий этой статье с инструкцией по настройке winbind)
2. Кэширование данных из каталога (доменный пользователь может войти на ПК, когда домен не доступен, если его учётные данные в кэше)
3. Для PBIS не требуется формирование в каталоге AD дополнительных атрибутов пользователя
4. PBIS понимает сайты AD и работает с контроллерами своего сайта.
5. Большую безопасность (samba создаёт учётку компьютера с не истекающим паролем)
6. В платной версии (если возникнет такая необходимость) PBIS агент управляем через GPO (хотя это можно и вычеркнуть. если вы не намерены её покупать)

UPD 2 Пришла обратная связь от пользователя sdemon72. Возможно кому-то будет полезно.

Здравствуйте! Попробовал ваш рецепт на свежей linuxmint-18-mate-64bit, все получилось с некоторыми оговорками:
1. С получением программы через сайт у меня возникли сложности (не захотел писать реальный номер телефона, а бутафорский не прокатил — пришло письмо с сомнениями по его поводу), зато нашел репозиторий с наисвежайшими версиями: repo.pbis.beyondtrust.com/apt.html
2. При запуске программы выдает ошибки, чтобы их избежать, нужно перед запуском сделать следующее:
2.1. Установить ssh:
sudo apt-get install ssh
2.2. Поправить /etc/nsswitch.conf:
hosts: files dns mdns4_minimal [NOTFOUND=return]
(т.е. переносим dns с конца строки на вторую позицию)
2.3. Поправить /etc/NetworkManager/NetworkManager.conf:
#dns=dnsmasq
(т.е. комментируем эту строчку)
2.4. Перезапустить network-manager:
sudo service network-manager restart

После этого все сработало на ура! Буду очень благодарен, если внесете эти дополнения в статью, т.к. в поиске по сабжу она выпадает в первых строках. Оставлять комментарии я не могу (запрещает сайт), поэтому пишу вам лично.

Если интересно — история моих изысканий тут: linuxforum.ru/topic/40209

С уважением, Дмитрий

UPD 3: Почему бесплатную версию PBIS не получится применить в большой компании
В бесплатной версии работает только один алгоритм генерации UNIX iD (uid и gid) по SID доменного пользователя. Так вот он не обеспечивает уникальности
этих идентификаторов. Когда у вас очень старый домен или просто много пользователей очень высок риск, что два и более пользователя получат одинаковые идентификаторы в системе с OpenPBIS. В платной версии есть возможность выбора между алгоритмами генерации id, но она стоит значительно дороже аналогичного продукта от Quest Software ;(.

Для упрощения добавления Ubuntu или Debian в домен Active Directory вместо связки samba+winbind можно использовать пакет realmd (Realm Discovery), который позволяет автоматически настроить службу SSSD (System Security Services Daemon) в Linux. Эта статья применима для Ubuntu 20.04/22.04 и Debian 10/11.

Прежде всего обновите пакеты на вашем хосте Linux:

$ sudo apt -y update

Выведите текущее имя хоста:

$ hostnamectl

Если нужно, измените имя хоста:

$ sudo hostnamectl set-hostname ubnt22.vmblog.ru

Проверьте, что в Linux корректно настроен клиент DNS и он указывает на ваши контроллеры домена AD:

# cat /etc/resolv.conf

nameserver 192.168.42.10
nameserver 192.168.142.10
search vmblog.ru

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

$ sudo systemctl status systemd-timesyncd
$ sudo nano /etc/systemd/timesyncd.conf

NTP=192.168.42.10

$ sudo systemctl restart systemd-timesyncd

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

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

Проверьте, что ваш хост может обнаружить домен AD:

$ realm discover vmblog.ru --verbose

vmblog.ru
type: kerberos
realm-name: VMBLOG.RU
domain-name: vmblog.ru
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

Вы можете задать атрибуты вашего хоста Linux, которые нужно сохранить в учетной записи компьютера в Active Directory (атрибуты operatingSystem и operatingSystemVersion):

$ nano /etc/realmd.conf

[active-directory]
os-name = Ubuntu GNU/Linux
os-version = 22.04 (Jammy Jellyfish)

Для добавления Linux хоста в домен Active Directory вам понадобится учетная запись AD с правами администратора домена (или пользователь, которому делегированы права на добавление компьютеров в домен).

В самом простом случае для добавления хоста Ubuntu/Debian в домен достаточно выполнить команду:

$ sudo realm join -U apetrov vmblog.ru

Введите пароль доменного пользователя.

По умолчанию для вашего хоста Linux будет создана учетная запись компьютера AD в корневом OU (Organizational Unit) с именем Computers. Вы можете сразу поместить вам хост в нужную OU. Для этого используйте другую команду добавления в домен:

$ sudo realm join --verbose --user=apetrov --computer-ou="OU=Linux Servers,OU=HQ,DC=vmblog,DC=ru" vmblog.ru

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

$ sudo realm list

type: kerberos
realm-name: VMBLOG.RU
domain-name: vmblog.ru
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@vmblog.ru
login-policy: allow-realm-logins

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

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

Выберите пункт activate mkhomedir.

Проверьте конфигурацию sssd в файле:

$ cat /etc/sssd/sssd.conf

Чтобы применить изменения из файла sssd.conf, нужно перезапустить службу:

$ systemctl status sssd

Теперь вы может выполнить аутентификацию в Linux с помощью учетной записи Active Directory (указывается в формате UPN: user@vmblog.ru).

Проверьте, что вы можете получить информацию о пользователе AD:

$ id apetrov@vmblog.ru

Можно переключиться на пользователя:

su - apetrov@vmblog.ru

Creating directory '/home/apetrov@vmblog.ru'.
apetrov@vmblog.ru@ubnt22:~$

Чтобы разрешить доменным пользователям вход на хост Linux (консоль+SSH), выполните:

$ realm permit apetrov1@vmblog.ru ivanov2@vmblog.ru

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

$ ream permit -g LinuxAdmins@vmblog.ru

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

$ sudo realm permit --all
$ sudo realm deny --all

Вы можете разрешить определенным пользователям и группам повышать привилегии с помощью sudo. Создайте файл:

$ sudo nano /etc/sudoers.d/linux-admins

Добавьте в него пользователей и/или группы, которым разрешено sudo:

%LinuxAdminx@vmblog.ru ALL=(ALL) ALL
aivanov@vmblog.ru ALL=(ALL) ALL

Измените права на файл:

$ chmod 0440 /etc/sudoers.d/linux-admins

Теперь попробуйте аутентифицироваться на вашем Linux хосте с доменной учетной записью.

Процесс добавления rpm-based дистрибутивов (CentOS/Rocky Linux/RHEL/Fedora) в домен Active Directory немного отличается и описан в отдельной статье.

Как мне ввести в домен 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, чтобы узнать больше.

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

Microsoft’s Active Directory (AD) is the go-to directory service for many organizations. If you and your team are responsible for a mixed Windows and Linux environment, then you probably would like to centralize authentication for both platforms. I’ll cover how to add Linux computers to an Active Directory domain.

Active Directory and the need for centralized access management

Microsoft’s Active Directory, more popularly known as AD, has held the lion’s share of the market for enterprise access management for many years now. It is used by institutions and individuals the world over to centrally control access to resources belonging to the organization. It gives you the ability to manage users, passwords, resources such as computers, and  dictate who has access to what. For some of you reading this write-up, especially those who work in large institutions, you have interacted with AD before. Usually, the interaction is using one set of login credentials to log in to any workstation in the organization. That is just the tip of a large iceberg.

Imagine a collection of 40 computer systems and 70 users in a firm. Some employees run shifts while others work regular hours. Some have access to printing; others don’t. The traditional way of working is to create local user accounts on each computer a user needs to access. Imagine the workload on the end-user support team. When a user changes his password for any reason, that user has to change the password on all computers he previously had access to, to keep things in sync. In no time, there will be mayhem. Now, imagine two members of the staff resign. I do not need to tell you the monotonous work that has to be repeated any time there’s a change to the staffing or any workstations. For IT teams, this is a nightmare. Time that could be used for innovative tasks is now spent reinventing the wheel. I have not even spoken about managing access to the printers.

This is where a directory service such as Active Directory thrives. It can literally be a lifesaver. With Active Directory, each user is uniquely created as an object in a central database, with a single set of credentials. Each computer system is also created as an object. Automatically, every user can access every workstation with that same set of credentials. Any account changes that need to be made are made once at the central database. Members of staff can access the printers using the same set of credentials. The printers’ authentication mechanism can be coupled with AD to achieve that. Happy users, happy IT team.

Using groups and organizational units, access to various resources can be tailored and maintained. It gets even better. This directory can store staff phone numbers, email addresses, and can be extended to store other information. What if someone resigns? No problem. Just disable the user’s account. That person’s access to all resources is nullified on the spot. The bigger the organization, the greater the need for centralized management. It saves time; it saves emotions.

At its heart, a directory service is just an organized way of itemizing all the resources in an organization while facilitating easy access to those resources. Basically, AD is a kind of distributed database, which is accessed remotely via the Lightweight Directory Access Protocol (LDAP). LDAP is an open protocol for remotely accessing directory services over a connection-oriented medium such as TCP/IP.

AD is not the only directory service based on the x.500 standard, or that can be accessed using LDAP. Other directory services include OpenLDAP and FreeIPA. However, AD is a mature Windows-based service that comes incorporated with Windows Server systems. In other words, it’s going to be the automatic winner when your organization has many Windows systems. This is one of the reasons for its ubiquity. Directory services such as FreeIPA are Linux-based and provide an excellent service for a Linux stable. When the rubber hits the road, the choice boils down to which of the two you can set up quickly, given your current environment and your team’s skill set.

[ Learn how to manage your Linux environment for success by downloading this free eBook. ]

But what happens when you choose AD, and you have a few CentOS servers, and you do not want to maintain a separate set of credentials for your Linux users? That overhead is entirely avoidable. What you need to do is join the Linux servers to the AD domain, like you would a Windows server.

If that is what you need to do, then read on to find out just how to do it. It is possible to join a Windows system to a FreeIPA domain, but that is outside the scope of this article.

Prerequisites

This article presupposes that you have at least some introductory-level experience with Active Directory, especially around user and computer account management. Aside from that, the following obvious requirements need to be met:

• An account in AD that has the privileges necessary to join a system to the domain.
• A Linux server (a CentOS 7 server was used for this demonstration).
• A Domain Controller.
• Ensure your Linux server knows how to find the domain controller via DNS.

To make this article easier on everyone, here’s a list of key details. This is how the lab I used for this write up is set up, so you should modify accordingly.

• AD Domain Name: Hope.net
• User account for joining the domain: fkorea (Fullname — Fiifi Korea)
• Linux server hostname: centy2

Packages to install

For this configuration, the essential package to install is realmd. Aside from realmd, there are a host of packages that need to be installed to make this work.

# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Realmd provides a simplified way to discover and interact with Active Directory domains. It employs sssd to do the actual lookups required for remote authentication and other heavy work of interacting with the domain. In the interest of brevity, I won’t dwell on the other packages in the list.

However, for those interested in the details, a quick Google search should be of great help.

Realmd (interacting with the domain)

Now that all packages have been installed, the first thing to do is to join the CentOS system to the Active Directory domain. We use the realm application for that. The realm client is installed at the same time as realmd. It is used to join, remove, control access, and accomplish many other tasks. Here is the expected syntax for a simple domain join:

realm join --user=[domain user account] [domain name]

The space between the user account and the domain account is not a typo. By inserting the corresponding details, we get the following command:

# realm join --user=fkorea hope.net

Supply the password when the prompt appears and wait for the process to end.

Don’t let the short absence of output deceive you. There are a number of operations that go on as part of the process. You can tack on the -v switch for more verbose output. However, the best way to check if the computer is now a member of the domain is by running the realm list command. The command attempts to display the current state of the server with regard to the domain. It is a quick and dirty way to know which groups or users can access the server.

Have a look at its output:

It is also quite trivial to place the newly-created AD computer object in a specific Organizational Unit (OU) from the onset. I’ll leave that for further reading, but, as a tip, you can consult the man page. Using the realm client, you can grant or revoke access to domain users and groups. A deep dive on using realmd in a more fine-grained way is enough to make another article. However, I will not be out of order to pick out a few parameters for your attention, namely client-software and the server-software. By now, you should understand why we had to install so many packages.

To leave the domain altogether, you need two words: realm leave

Further configuration

So now that the Linux server is part of the AD domain, domain users can access the server with their usual credentials. We are done, right? Wrong. «What’s the problem?» I hear you say.

[ Free cheat sheet: Get a list of Linux utilities and commands for managing servers and networks. ]

Well, for starters, this is the barebones configuration to get you up and running. But the experience is clunky, to say the least. We need to configure the service further to give it a true AD feel. It should be just like logging on to a domain-joined Windows 10 workstation.

Secondly, there is the big elephant in the room for sysadmins called Dynamic DNS Updates (DynDNS). If it is not set up correctly, we create extra overhead by having to maintain DNS records manually. For an environment that relies heavily on DNS, that could be a problem. For Windows systems, joining a system to the domain means two entries are automatically managed and maintained on the DNS server. When IP addresses change, the change is automatically reflected in DNS. This means you can change the IPs of systems without incurring the cost of manual maintenance. This will only make sense to people who already take advantage of DNS in their environments. Aside from the noticeable productivity gains of automation, it helps to have both Windows and Linux environments working the same way.

The third issue is DNS Scavenging. In an Active Directory domain, DNS is usually provided by the Domain Controllers. Every system joined to the domain has an automatic DNS entry with a corresponding IP address. This is super convenient. Automatically, at a specified interval, stale DNS records are deleted to prevent misdirected packets and also take care of deleted computer objects. This is known as scavenging, and it is not turned on by default in AD. However, if it is turned on, we need to configure it. Typically, the scavenging interval is seven days. If, after that period, there has been no update to the record, it is deleted, unless it is a static record. For Windows systems, the Dynamic Updates feature is automatically set up. However, with Linux servers, a few modifications need to be made. Without doing that, we will have services going down after a while because their records are deleted from DNS, and no one knows how to reach their component parts.

Now that we know some of the potential issues we need to address, let’s take a look at some of the things we can tweak to deliver a more seamless experience to the end-user and the sysadmin.

SSSD (easier logins and dynamic updates)

sssd on a Linux system is responsible for enabling the system to access authentication services from a remote source such as Active Directory. In other words, it is the primary interface between the directory service and the module requesting authentication services, realmd. Its main configuration file is located at /etc/sssd/sssd.conf. As a matter of fact, this is the main configuration file we will modify.

Let’s have a look at its contents before configuration. Once you join the domain, it is immediately modified to contain the minimum information required for a successful logon. My file looked like this:

In order to solve all three of the problems I mentioned earlier, edit your file to look like the one below:

Most of the options are self-explanatory, and you can modify yours accordingly while we step through what some of the key options represent. More information on all the options can be obtained by checking the man page. I think it is well written. Just type man 5 sssd.conf at the command line. You can also view the man page for sssd_ad for further information.

First and foremost, the configuration file is separated into two sections. The global section, under [sssd] and the domain-specific options section, [domain/[domain name]].

The global section contains options that affect the general behavior of sssd, such as the version information and related services. One key parameter under this section is shown below:

• default_domain_suffix — Set this to the domain name if you do not want to have to type the full user account name when logging in. Instead of having to type fkorea@hope.net always, you can just type fkorea and the password. This helps a lot when you have a long domain name.

The domain-specific section contains parameters that are specific to the domain you have joined. Key parameters are:

• access_provider — Allows you to select a provider optimized and used for interacting with AD servers for authentication purposes. It should be set to ad. Other values that can be used here are ldap and ipa, assuming you use those directory services.

• id_provider — Allows you to select a provider optimized and used for interacting with AD servers for identification purposes. It should be set to ad.
• ad_hostname — This should be the fully qualified hostname of the server. It should be set if the system’s hostname is anything other than the fully qualified domain name. If this is not set and the sssd does not have access to the fully qualified hostname, dynamic updates will fail.
• ad_domain — This should be the full domain name (hope.net in this case).
• cache_credentials — This enables AD users to log in when the domain controller is offline. When this is set to true, credentials are cached for a period such that authentication does not fail when the back end is offline. The period of storage is also configurable.
• fallback_homedir — This helps you set a home directory for AD users who do not have a home directory attribute in AD. This is different from the override_home parameter that works when a home directory is set in AD for users.
• dyndns_update — This enables dynamic DNS updates and accepts either true or false as a value. When dynamic updates are enabled, updates occur primarily under three conditions:
  • When the Linux server restarts.
  • When the provider comes online.
  • When the refresh interval is due.
• dyndns_refresh_interval — This value is in seconds with a practical minimum of 60 seconds. It accepts integer values and has a default of 24 hours (86400s). In this example, we set it to 12 hours. If nothing else triggers an update, an update is regularly done between.
• dyndns_update_ptr — A boolean value that specifies whether the associated PTR record is to be updated in every update cycle. PTR records are used for reverse lookups, and unless there is a good reason, this should be set to true.
• dyndns_auth — Specifies whether the dynamic updates should be done securely or not. The setting depends on the mode accepted by AD. If AD is set to Accept Secure Updates Only, this value should be set to GSS-TSIG. If not, and you do not care for the security benefits of secure dynamic updates (despite the strong warning in AD), this value can be set to none.

Once the configuration is complete, restart sssd to apply settings immediately.

# systemctl restart sssd

At this point, we are set. We can now login like we would at a Windows workstation or server.

Visudo (granting admin privileges)

Users that are granted access have unprivileged access to the Linux server. For all intents and purposes, all Active Directory accounts are now accessible to the Linux system, in the same way natively-created local accounts are accessible to the system. You can now do the regular sysadmin tasks of adding them to groups, making them owners of resources, and configure other needed settings. If the user tries any activity that requires sudo access, the familiar error is presented. As can be seen in the inset, our user is not in the sudoers file.

In that light, we can edit the sudoers file directly to grant them superuser privileges. This is not an article on granting superuser privileges, but we can use the visudo tool to interact safely with the sudoers file.

Alternatively, we could have just added the user to the wheel group. The point is the user account is now available to be used by the system.

[ Network getting out of control? Check out Network automation for everyone, a free book from Red Hat. ] 

Wrap up

Try this out in your organization or lab environment. It is obvious I just scratched the surface on this topic but this will get you pretty far into the process. Check out the respective documentation if you want to explore options not covered in this article.

Joining a Linux system to an Active Directory domain allows you to get the best of both worlds. The process is very simple and can be scripted using Bash or automated using Ansible, especially during the system’s initial setup. If you are still managing a group of more than five systems without a directory service and a good reason, please do yourself a favor and get one set up. You can thank me later.

Привет, дорогой мой бложек. У меня для тебя новая заметка о том, как подключить Ubuntu (проверено на 18.04 и 20.04) к домену Active Directory.

Как всегда, ничего нового я не придумал. Всё и так есть в интернете, но теперь и здесь тоже будет. Зачем это надо я не буду рассказывать, т.к. если вы хотите это сделать, то скорее всего сами прекрастно знаете зачем вам это надо.

Подготовка

Для начала включаем universe пакеты. Если они еще не включены, то:

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

Теперь обновляем apt-индексы:

sudo apt -y update

Меняем имя хоста:

sudo hostnamectl set-hostname linux-utils.vitaliy.org

и проверяем — пишем hostnamectl и получаем результат:

    Static hostname: linux-utils.vitaliy.org
          Icon name: computer-vm
            Chassis: vm
         Machine ID: c6eccece18fa4459b843deae2cf5a2aa
            Boot ID: 545b62e60e0d4a72bfc86024bd2e2adc
     Virtualization: microsoft
   Operating System: Ubuntu 20.10
             Kernel: Linux 5.8.0-48-generic
       Architecture: x86-64

Проверяем что DNS у нас настроен корректно

Удаляем systemd-resolve и настраиваем /etc/resolv.conf сами.

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo unlink /etc/resolv.conf
sudo mcedit /etc/resolv.conf

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

search     vitaliy.org
nameserver 192.168.2.1
nameserver 192.168.2.2

Только укажите свои имя домена и DNS сервера.

Установка

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

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

Подключение к домену

Проверяем что мы «видим» наш домен:

$ sudo realm discover vitaliy.org
vitaliy.org
  type: kerberos
  realm-name: VITALIY.ORG
  domain-name: vitaliy.org
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-permitted-logins
  permitted-logins:
  permitted-groups: Domain Admins

Подключаемся у домену:

sudo realm join -U Administrator vitaliy.org

И тут же проверяем что всё хорошо:

$ realm  list
vitaliy.org
  type: kerberos
  realm-name: VITALIY.ORG
  domain-name: vitaliy.org
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-permitted-logins

Включаем возможность автоматического создания домашних папок пользоватея:

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

и активируем mkhomedir.

Затем перезагружаем sssd и проверяем что оно работает:

sudo systemctl restart sssd
systemctl status sssd

Настройка прав доступа

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

sudo realm permit user1@example.com
sudo realm permit -g 'Domain Users'

Можно разрешить всем:

sudo realm permit --all

или всем запретить:

sudo realm  deny --all

На этом всё.

Бесплатный бонус:

Пользователей группы Domain Admins можно добавить в sudoers. По умолчанию этого не произойдет.

Делается это так:

sudo mcedit /etc/sudoers.d/domain_admins

Пишем там следующее:

%domain admins        ALL=(ALL)     ALL

Вот теперь точно всё!