Новость переведена плохо, видимо, человеком, который не знает зачем всё это нужно. Это "зайчатки" поддержки kerberos compound authentication.In particular Samba will issue Active Directory "Claims" in the PAC,
for member servers that support these, and honour in-directory
configuration for Authentication Policies and Authentication Silos.
The primary limitation is that while Samba can read and write claims
in the directory, and populate the PAC, Samba does not yet use them
for access control decisions.
В частности, Samba будет добавлять утверждения Active Directory (Claims) внутрь PAC (Privilege Account Certificate) для доменных серверов, которые это поддерживают и будет учитывать конфигурацию каталога для политик аутентификации и контейнеров политик (Authentication Policies and Authentication Silos).
Основное ограничение в том, что Samba может читать и записывать утверждения каталога и передавать их в PAC, но не способна принимать решения по авторизации относительно утверждений.
Пояснения:
PAC - это расширенный подписанный блок данных, который прилетает совместо с билетом (ticket) и используется для нужд авторизации (не аутентификации) на целевой сервер.
Современный Kerberos (реализации от 10 лет и моложе) поддерживает аутентификацию и авторизацию на основе утверждений (Claims-based identity). Если описывать в двух словах, то приложение может аутентифицировать и авторизовывать относительно дополнительных полей карточки каталога не синхронизируя каталог на себя. Вот у вас есть приложение у него есть своё понимание пользователя, например в БД, и тех столбцов, которые выступают в качестве полей-атрибутов. Есть 2 способа как интегрировать такое приложение со службой каталогов:
1) Интеграция здорового человека
- Создать учетную запись в каталоге и назначить ей SPN, разрешив ограниченное делегирование пользователей на сервисе приложения, чтобы радостно слать Kerberos-запросы на KDC и обрабатывать предъявленные билеты.
- Построить внутри приложения только те структуры данных (каталоги или таблицы БД), которые специфичны для приложения, а пользователей отдать в каталог, возможно расширив его схему, если полей каталога не хватает
- Получать значения атрибутов из каталога (PAC) совместно с билетом Kerberos, чтобы на этапе аутентификации получать значения атрибутов для дальнейшего использования внутри приложения. Если роли авторизации динамичны и ими управляет приложение, то тогда эти значения атрибутов из PAC можно использовать для нужд авторизации в том числе
- Если роли авторизации внутри приложения предопределены, то нужно создать объекты контейнеры (группы, сайты и прочее) на стороне каталога и произвести взаимно-однозначное соответствие. Зачастую получается так, что даже для динамически меняющихся приложений администратор приложения создаёт новую роль в приложении и привязывает её к контейнеру в каталоге
2) Интеграция курильщика
- Заводится пользовательская учётная запись в каталоге с огромными привилегиями
- Приложение не использует Kerberos, аутентифицируя своим способом ("на основе форм"), производя олицетворение (impersonation). Приложение приняло строки форм и пошло выписывать билеты на KDC от лица другого пользователя
- Повышенные привилегии нужны на чтение, а иногда и запись, почти на весь каталог, потому что приложение будет фильтравать LDAP и выкачивать к себе в базу интересующие атрибуты и объекты по расписанию.
- Такое приложение способно вынести роли авторизации на каталог, но оно будет ходить и каждый раз проверять само относительно каталога или кэша каталога в базе
Исторически поставщиком утверждений всегда был протокол SAML, он же реализует политики авторизации, он же их вменяет (вместо Kerberos Ticket у вас SAML Assertion). Каталог при этом может быть полностью интегрирован с политиками авторизации так, что Kerberos KDC отдаёт свои билеты во внутреннюю сеть, а SAML в веб-приложения при этом построены SAML PEP и SAML PDC полностью интегрированные с контнейнерами политик внутри службы каталогов.
Начиная с версии леса Windows Server 2012 Active Directory активно просовывает атрибуты в PAP и посылает вместе с билетами. Если раньше у вас Kerberos поддерживал только те данные, которые прислал KDC, то в свежих версиях можно просунуть еще и дополнительные атрибуты. Это значит, что вам не надо городить инфраструктуру SAML для формирования инфраструктуры в парадигме "политика безопасности, как бизнес-процесс", если там типовое получение и проверка атрибутов из каталога. Теперь у вас есть еще и Kerberos, который вам всё и так пришлёт. Это не только упрощает жизнь на крупных развертываниях, но еще и позволяет реализовать концепцию BYOD (bring your own device).
Все эти атрибуты в PAP чаще всего нужны как раз для BYOD и авторизации устройств и их местоположения. Например, корпоративный портал показывает только все функции и поля если вы зашли с корпоративного доменного компьютера, но даёт ограниченный функционал, если вы зашли со своего личного компьютера из дома или с офисного ноутбука. Или, например, портал показывает разные вещи на главной странице в зависимости от того из какого офиса вы вошли в систему. Пользователь при этом один и тот же.
Главное, что протокол SMB3 всё это умеет и может давать доступ к каталогу с учетом этих атрибутов, потому что ACL на фаловом сервере проверяет атрибуты из PAP.
Теперь к вопросу про то что наконец-то начала делать Samba. Она научилась с этим немножечко работать как DC, но как файловый сервер она этим пользоваться пока не способна.
Вообще для поддержки современных версий AD требуется еще и тонна объектов для BYOD по регистрации устройств, которые можно сделать доверенными, если есть действительный клиентский сертификат в хранилище на устройстве,.. но у меня есть сомнения, что Samba покусится на эти службы Active Directory, потому что это уже кусок Federation Services.
Если вы думаете, что всё это как-то шибко сложно и не нужно никому, то ни фига. Это просто в Linux с этим исторически всё плохо. Вообще, от современных разработчиков требуется поддержка протоколов децентрализированной аутентификации и авторзации не только для корпоративных функций, но также и для облачных сервисов. Облачно-ориентированные протоколы вроде OpenID Connect и OAuth2 требуют от разработчика того же самого: написать приложение с расчетом на то, что аутентификацию и, возможно, авторизацию держит сторонняя служба, а приложения получает подписанные сертификатами объекты от клиентского устройства пользователя, внутри которых находятся утверждения. Ну то есть claims-based приложение. В этом случае вместо билетов с PAP у вас JSON Web Token (JWT). Кстати, OAuth2 это отдельный фреиворк по авторизации, он всё что я описывал выше по связке Kerberos и SAML в разрезе авторизации он не умеет и не должен, он облачный, а не корпоративный. Он не умеет вменять политики авторизации для приложений и не формирует из приложений домены, но может быть интегрирован на бекенде с каталогами и базами для реализации схожих задач. Можно завести свои scope и просовывать туда утверждения из другого каталога или базы, где они радостно вычисляются на основании рядом стоящей корпоративной архитектуры. При желании можно использовать один и тот же каталог, просто расширив схему. Ну вот так вот оно и сделано в Active Directory для BYOD в версии схемы 2012R2+. Эта схема даёт стоковую интеграцию с устверждениями в OAuth2, даёт возможность регистрировать устройство как доверенное. Даёт возможность приложениям решить, что разрешено на таких доверенных, но удаленных устройствах.
P.S. Пока писал всё это аж ностальгия пробрала, будто очутился опять 2014-ом году. Ох уж эта реализация новинок десятилетней давности,.. но лучше поздно, чем никогда.
