Samba winbind: как аутентифицироваться из доверенного домена AD (одностороннее доверие)?

Вопрос или проблема

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

Пример

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

  1. Обновление Samba: Попробуйте обновить Samba до версии 4.8 или более поздней, так как эта версия включает в себя улучшенную поддержку однонаправленного доверия.

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

  3. Проверка конфигурации Kerberos (krb5.conf): Убедитесь, что у вас правильно прописаны KDC для обоих доменов, и что нет ошибок в конфигурации, которые могут препятствовать Kerberos в получении и обновлении билетов.

  4. Проверка подключения и диагностика:

    • Убедитесь, что сетевое подключение к контроллерам домена B доступно и что там нет брандмауэров, блокирующих необходимые порты.
    • Используйте команды wbinfo и kinit для диагностики. Например, команда wbinfo --online-status покажет статус доменов, которые может видеть машина.
  5. Просмотр журналов: Проверьте логи Samba и Kerberos на наличие ошибок, которые могут помочь диагностировать проблемы. Лог файлы можно найти в /var/log/samba.

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

Применение

Следуя приведенным рекомендациям, вы сможете диагностировать и устранить проблему с аутентификацией пользователей из доверенного домена. Внедрение изменений в конфигурацию и обновление ПО должны быть тщательно протестированы на тестовом сервере перед внедрением в рабочую среду. Это поможет избежать сбоев в аутентификации и обеспечит безопасность и стабильность работы вашей системы.

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

Оцените материал
Добавить комментарий

Капча загружается...