Feature request Доработать механизм проверки атрибута userWorkstations на ALT операционных системах 1) Создать пользователя с настройками по умолчанию. 2) ПКМ на пользователе -> Свойства -> Учетная запись 3) Нажать кнопку "Компьютеры для входа в систему" 4) Добавить имя компьютера из списка введенных в домен (компьютеры ALT-based). Пробовала варианты с полным именем домена (например DE3GOHTA.SAMBA.TESTDOMAIN) и только с DE3GOHTA 5) Применить изменения и попытаться войти пользователем с неразрешенного компьютера Результат: вход возможен с любого ALT-based компьютера Ожидаемый результат: вход возможен только с компьютера из списка 4) Дополнительно: вход невозможен с компьютера с Windows, введенного в домен (т.е. для Windows-клиента данная настройка отрабатывает корректно).
Выглядит, как клиентская настройка, а предлагается что-то на сервере поправить. Вы точно понимаете как это работает и какого поведения можно добиться. И, самое главное, какая задача решается. Что, в сущности, названо действием "возможен только с компьютера из списка"? Какой вход? Откуда, куда, по какому протоколу? > 5) Применить изменения и попытаться войти пользователем с неразрешенного компьютера На каком узле применить? И в чём заключается действие "войти пользователем с неразрешенного компьютера"? Какие протоколы предлагается контролировать?
Результат проверки актуальности Состояние: Описание не определяет узел назначения, PAM-службу и протокол аутентификации. Запрошенные сопровождающим уточнения не предоставлены. Рекомендация: оставить открытым до уточнения полного сценария.
Данная доработка касается ограничений логина. Ее нужно либо отдельным PAM-модулем обрабатывать, что сильно утяжеляет логин повторным подключением к серверу, либо путем правки sssd и winbind в паре. Вообще, на уровне MS AD данный атрибут признан устаревшим и реализация данной доработки выглядит сомнительно: https://learn.microsoft.com/ru-ru/windows/win32/adschema/a-userworkstations 'Этот атрибут пользователя больше не следует использовать. Чтобы управлять учетными записями, которые могут выполнять вход на какие рабочие станции, рекомендуется использовать команды "Разрешить локальный вход" и "Запретить локальный вход" или "Разрешить вход с помощью служб удаленных рабочих столов" и "Запретить вход в систему с помощью служб удаленных рабочих столов".' Почему MS от этого отказались? 1. Архитектурные ограничения по объему (Лимит в 64 машины) 2. Привязка к NetBIOS вместо DNS (противоречит исходному описанию, но legacy, в целом, понятное) 3. Плохая масштабируемость и децентрализация (группы не заложены) 4. Проблемы со сквозной аутентификацией (SSO) и сторонними сервисами ____ Учитывая этот статус, предлагаю отказаться от этой доработки и сформулировать проблему, которую мы решаем в деталях, а не доработки под наследие, которое считается устаревшим.
*** Bug 42333 has been marked as a duplicate of this bug. ***
На основании #42333 можно сказать, что данная доработка актуальна только для sssd, поскольку winbind обработка данного атрибута учитывается. Думаю, что это намеренное решение. При этом в sssd реализованы другие, более современные настройки ограничений.
