Глава 3. Идентификация и функциональная совместимость

SSSD: поддержка смарт-карт

SSSD поддерживает локальную аутентификацию с использованием смарт-карт: пользователь сможет авторизоваться в системе, открыть текстовую или графическую консоль, а также получить доступ к локальным службам, в том числе sudo. Для этого необходимо поместить карту в специальный считыватель и предоставить имя пользователя и PIN. После подтверждения ее сертификата пользователь будет аутентифицирован.
В настоящее время SSSD не поддерживает возможность получения билета Kerberos по смарт-карте — для этого по-прежнему придется использовать традиционный kinit.
Для того чтобы включить интегрированную поддержку смарт-карт в Red Hat Enterprise Linux 6, необходимо изменить настройки аутентификации и разрешить SSSD запрашивать пароль пользователя, одноразовый пароль (OTP) или PIN-код карты. Для этого надо изменить директивы auth в файлах /etc/pam.d/password-auth и /etc/pam.d/system-auth. Подробную информацию можно найти в документации: http://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#idm-smart-cards

Аутентификация в кэше SSSD

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

Оптимизация быстродействия за счет отключения «ou=sudoers,$DC» на сервере IdM

Клиент IdM (Identinty Management) теперь ищет правила ограничения доступа для sudo в структуре cn=sudorules,cn=sudo,$DC дерева каталога LDAP на сервере IdM вместо поиска в дереве совместимости ou=sudoers,$DC, которое генерируется дополнительным модулем slapi-nis для Directory Server.
В окружениях, где в дереве совместимости нет прямой необходимости (например, для поддержки работы с устаревшими клиентами), ou=sudoers,$DC можно просто отключить. Так как процесс генерации такого дерева с помощью slapi-nis является довольно ресурсоемким — особенно в окружениях с интенсивной обработкой большого числа операций аутентификации — его отключение поможет заметно улучшить производительность.

SSSD: поддержка различных UID и GID на разных клиентах

SSSD дает возможность присвоить пользователям различные идентификаторы UID и GID на разных клиентах Red Hat Enterprise Linux, что помогает решить проблемы, вызванные дублированием UID и GID. Эта функциональность реализуется на стороне клиента с помощью sss_override.
Так как переопределения хранятся в кэше SSSD, то при очистке кэша они тоже будут удалены. За подробной информацией обратитесь к справочной странице sss_override(8).

Кэширование операций initgroups

SSSD поддерживает кэширование операций initgroups, что заметно увеличивает скорость их обработки и повышает быстродействие некоторых приложений, в том числе GlusterFS и slapi-nis.

Новые пакеты: adcli

Новый инструмент adcli предназначен для управления объектами Active Directory (AD) в Red Hat Enterprise Linux 6: компьютерами, пользователями и группами. Наиболее распространенным примером применения adcli является добавление узла в домен AD и обновление его идентификационных данных.
adcli способен определить текущую структуру сайта, поэтому компьютер сможет присоединиться к домену AD без какой-либо дополнительной настройки. Также adcli позволяет периодически обновлять идентификационные данные клиентов, на которых работает SSSD.

SSSD: автоматическое обновление идентификационных данных клиентов Linux в Active Directory

Некоторые инструменты Windows исключают узлы из Active Directory, если их пароль не обновлялся на протяжении длительного периода времени, принимая это за признак того, что клиент больше не активен.
Эту проблему удалось решить периодическим обновлением пароля узла Linux, что помогает подтвердить его активное состояние.

SSSD: подбор диапазонов ID в окружениях с большими значениями RID

Алгоритм автоматического присвоения идентификаторов в SSSD был доработан и теперь поддерживает объединение диапазонов доменов. Раньше, если идентификатор RID (Relative ID) превышал 200 000, администратору приходилось вручную подгонять автоматически выбранный диапазон, так как по умолчанию SSSD ограничивал максимальное значение в диапазоне числом 200 000.
Теперь SSSD автоматически корректирует диапазон для клиентов AD, что отменяет необходимость вмешательства со стороны администратора и упрощает процедуру присвоения идентификаторов — особенно в крупномасштабных окружениях AD.

SSSD: поддержка GPO разных контроллеров доменов

SSSD допускает применение объектов групповой политики (GPO, Group Policy Object), предоставленных разными контроллерами доменов.