Вопрос или проблема
Привет, я новичок в Linux.
Чего я пытаюсь достичь: иметь возможность входить на машину Linux с учетными данными Active Directory из доверенного домена.
У меня следующая конфигурация:
+----------------+ +---------------+
+-----------+ | Forest B | | Forest A |
| User in | | | one-way trust | |
| domain B +----------+ Domain B +<--------------+ Domain A |
| | | b.net | | a.net |
+-----------+ | | | |
| | | |
+----------------+ +-------+-------+
|
|
|
|
|
+-------+-------+
| |
| Ubuntu 16.04 |
| samba 4.7.12 |
| |
| |
| |
+---------------+
Я успешно присоединил мой Ubuntu 16.04 к домену Active Directory A с помощью samba winbind, но не могу войти на машину с учетной записью пользователя, которая существует в домене B. Домен A и домен B являются доменами Active Directory, и между ними установлено однонаправленное доверие, так что домен A доверяет домену B, но домен B не доверяет домену A.
Вот мои smb.conf, krb5.conf и nsswitch.conf
/etc/samba/smb.conf
[global]
workgroup = A
security = ADS
realm = A.NET
encrypt passwords = yes
idmap config *:range = 16777216-33554431
allow trusted domains = yes
winbind trusted domains only = no
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
[printers]
comment = All Printers
browseable = no
path = /var/spool/samba
printable = yes
guest ok = no
read only = yes
create mask = 0700
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
browseable = yes
read only = yes
guest ok = no
/etc/krb5.conf
[libdefaults]
default_realm = A.NET
dns_lookup_kdc = false
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
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]
ATHENA.MIT.EDU = {
kdc = kerberos.mit.edu:88
kdc = kerberos-1.mit.edu:88
kdc = kerberos-2.mit.edu:88
admin_server = kerberos.mit.edu
default_domain = mit.edu
}
MEDIA-LAB.MIT.EDU = {
kdc = kerberos.media.mit.edu
admin_server = kerberos.media.mit.edu
}
ZONE.MIT.EDU = {
kdc = casio.mit.edu
kdc = seiko.mit.edu
admin_server = casio.mit.edu
}
MOOF.MIT.EDU = {
kdc = three-headed-dogcow.mit.edu:88
kdc = three-headed-dogcow-1.mit.edu:88
admin_server = three-headed-dogcow.mit.edu
}
CSAIL.MIT.EDU = {
kdc = kerberos-1.csail.mit.edu
kdc = kerberos-2.csail.mit.edu
admin_server = kerberos.csail.mit.edu
default_domain = csail.mit.edu
krb524_server = krb524.csail.mit.edu
}
IHTFP.ORG = {
kdc = kerberos.ihtfp.org
admin_server = kerberos.ihtfp.org
}
GNU.ORG = {
kdc = kerberos.gnu.org
kdc = kerberos-2.gnu.org
kdc = kerberos-3.gnu.org
admin_server = kerberos.gnu.org
}
1TS.ORG = {
kdc = kerberos.1ts.org
admin_server = kerberos.1ts.org
}
GRATUITOUS.ORG = {
kdc = kerberos.gratuitous.org
admin_server = kerberos.gratuitous.org
}
DOOMCOM.ORG = {
kdc = kerberos.doomcom.org
admin_server = kerberos.doomcom.org
}
ANDREW.CMU.EDU = {
kdc = kerberos.andrew.cmu.edu
kdc = kerberos2.andrew.cmu.edu
kdc = kerberos3.andrew.cmu.edu
admin_server = kerberos.andrew.cmu.edu
default_domain = andrew.cmu.edu
}
CS.CMU.EDU = {
kdc = kerberos.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}
DEMENTIA.ORG = {
kdc = kerberos.dementix.org
kdc = kerberos2.dementix.org
admin_server = kerberos.dementix.org
}
stanford.edu = {
kdc = krb5auth1.stanford.edu
kdc = krb5auth2.stanford.edu
kdc = krb5auth3.stanford.edu
master_kdc = krb5auth1.stanford.edu
admin_server = krb5-admin.stanford.edu
default_domain = stanford.edu
}
UTORONTO.CA = {
kdc = kerberos1.utoronto.ca
kdc = kerberos2.utoronto.ca
kdc = kerberos3.utoronto.ca
admin_server = kerberos1.utoronto.ca
default_domain = utoronto.ca
}
A.NET = {
admin_server = dc.a.net
kdc = dc.a.net
}
B.NET = {
admin_server = dc.b.net
kdc = dc.b.net
}
[domain_realm]
.mit.edu = ATHENA.MIT.EDU
mit.edu = ATHENA.MIT.EDU
.media.mit.edu = MEDIA-LAB.MIT.EDU
media.mit.edu = MEDIA-LAB.MIT.EDU
.csail.mit.edu = CSAIL.MIT.EDU
csail.mit.edu = CSAIL.MIT.EDU
.whoi.edu = ATHENA.MIT.EDU
whoi.edu = ATHENA.MIT.EDU
.stanford.edu = stanford.edu
.slac.stanford.edu = SLAC.STANFORD.EDU
.toronto.edu = UTORONTO.CA
.utoronto.ca = UTORONTO.CA
a.net = A.NET
.a.net = A.NET
b.net = B.NET
.b.net = .B.NET
[login]
krb4_convert = true
krb4_get_tickets = false
/etc/nsswitch.conf
passwd: compat winbind
group: compat winbind
shadow: compat
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Большинство изменений основано на этих инструкциях, хотя я добавил домен b в krb5.conf: https://docs.citrix.com/en-us/linux-virtual-delivery-agent/7-15-ltsr/installation-overview/ubuntu.html
Я попробовал следующие команды wbinfo:
wbinfo –online-status показывает домен A онлайн, но домен B оффлайн.
wbinfo -n B\administrator возвращает SID и wbinfo -s SID возвращает имя
wbinfo -m
BUILTIN
MYLINUX
A
B
wbinfo -K B\user%password возвращает следующее сообщение об ошибке:
wbcLogonUser(B\user): error code was NT_STATUS_NO_LOGON_SERVERS (0xc000005e)
error message was: No logon servers are currently available to service the logon request.
Could not authenticate user [B\user%password] with Kerberos (ccache: FILE)
Я был бы очень признателен, если бы кто-то помог мне решить эту проблему. Как я мог бы начать устранять эту проблему?
Только Samba 4.8.x+ поддерживает такое доверие.
Единственное, что я знаю, что нужно сделать, это настроить idmap
для доверенного домена в разделе [global]
вашего smb.conf
:
idmap config <trusted_domain> : backend = rid
idmap config <trusted_domain> : range = ?????- ?????
убедитесь, что диапазон не пересекается с диапазоном, который вы в настоящее время определили для (локального) домена.
Вы забыли добавить принципал Kerberos в smb.conf
. Без этого параметра пользователи с однонаправленным доверием не могут войти в систему.
Для принципалов Kerberos 5 через контроллер домена используйте
[global]
winbind use krb5 enterprise principals = Yes
Полные шаги описаны в моей статье в блоге на эту тему.
В этом решении я заметил простую проблему: система не может проверить членство в группах в Forest B.
Все пользователи из Forest B являются частью только группы “Domain Users”;
id B\\USERNAME
-> возвращает только uid(b\username) и gid(b\domain users)
однако после входа в систему через SSH членство в группах корректно обновляется.
Запись сохранена в кеш самлогина сети
с соответствующим SID и именем пользователя
Это ограничение создает проблему, если мы хотим ограничить доступ к SSH для определенных пользователей и групп. Сталкивались ли вы с этой проблемой или нашли её решение?
Ответ или решение
Чтобы предоставить решение для аутентификации пользователя из доверенного домена в Active Directory (AD) на машине с Ubuntu 16.04 и Samba, необходимо учесть несколько ключевых моментов, связанных с настройкой Samba и Winbind. Задача заключается в возможности входа пользователя из домена B на сервер, который находится в домене A, причем домен A доверяет домену B, но не наоборот.
Теория
Ваш сценарий включает использование Samba и Winbind для интеграции с доменами AD и аутентификацией с использованием учетных данных AD. В случае однонаправленного доверия между доменами A и B, важно правильно настроить маппинг идентификаторов (idmap) и Kerberos, чтобы учетные записи из домена B могли эффективно аутентифицироваться. Основная проблема, с которой вы столкнулись, связана с невозможностью аутентификации из-за некорректной конфигурации или отсутствия поддержки необходимых функций в используемой версии Samba.
Samba версии 4.7.12 может иметь ограниченную поддержку однонаправленных доверий, поэтому переход на более новую версию Samba (например, 4.8 и выше) может оказаться необходимым. Настройка схемы маппинга idmap для доверенного домена и использование Kerberos principal помогут решить проблему с аутентификацией и доступом к ресурсам.
Пример
Рассмотрим несколько важных изменений, которые могут помочь в решении этой проблемы:
-
Обновление Samba: Попробуйте обновить Samba до версии 4.8 или более поздней, так как эта версия включает в себя улучшенную поддержку однонаправленного доверия.
-
Настройка
smb.conf
: В файле конфигурации Samba вам необходимо добавить и изменить некоторые параметры:[global] workgroup = A security = ADS realm = A.NET encrypt passwords = yes idmap config *:backend = tdb idmap config *:range = 16777216-33554431 idmap config B:backend = rid idmap config B:range = 33554432-67108863 allow trusted domains = yes winbind trusted domains only = no kerberos method = secrets and keytab winbind refresh tickets = yes winbind use krb5 enterprise principals = Yes
Обратите внимание на добавление конфигурации для домена B и использование
winbind use krb5 enterprise principals
, что позволяет Kerberos использовать принципалы типа Kerberos 5. -
Проверка конфигурации Kerberos (krb5.conf): Убедитесь, что у вас правильно прописаны KDC для обоих доменов, и что нет ошибок в конфигурации, которые могут препятствовать Kerberos в получении и обновлении билетов.
-
Проверка подключения и диагностика:
- Убедитесь, что сетевое подключение к контроллерам домена B доступно и что там нет брандмауэров, блокирующих необходимые порты.
- Используйте команды
wbinfo
иkinit
для диагностики. Например, командаwbinfo --online-status
покажет статус доменов, которые может видеть машина.
-
Просмотр журналов: Проверьте логи Samba и Kerberos на наличие ошибок, которые могут помочь диагностировать проблемы. Лог файлы можно найти в /var/log/samba.
-
Учет временных ограничений и часового пояса: Убедитесь, что время на сервере и контроллерах домена синхронизировано, так как Kerberos чувствителен к отклонениям во времени.
Применение
Следуя приведенным рекомендациям, вы сможете диагностировать и устранить проблему с аутентификацией пользователей из доверенного домена. Внедрение изменений в конфигурацию и обновление ПО должны быть тщательно протестированы на тестовом сервере перед внедрением в рабочую среду. Это поможет избежать сбоев в аутентификации и обеспечит безопасность и стабильность работы вашей системы.
Также следует рассмотреть варианты настройки ограничения доступа и управления пользователями, чтобы минимизировать риски и управлять доступом пользователей из других доменов с учетом бизнес-требований и политики безопасности вашей организации.