Я реализую ограничения безопасности для клиента, который хотел бы препятствовать тому, чтобы администраторские учетные записи вошли в рабочие станции.
Например, у каждого человека есть учетная запись пользователя и администраторская учетная запись, и только учетная запись пользователя должна иметь доступ. Администраторская учетная запись для поиска и устранения неисправностей целей и для возрастания полномочий решить вопросы.
Если я отклоняю Интерактивный Вход в систему для администраторских учетных записей, то способность использовать их для Выполненного, Как также удален. Я также смотрел на, "Позволяют Входу в систему локально" и определению только нормальных учетных записей, но это означает удалять Администраторов из, Позволяют Вход в систему локально, который вызывает дальнейшие проблемы.
Мое текущее обращение за помощью должно сделать сценарий входа в систему, который надеется видеть, является ли пользователь нормальной учетной записью или администраторской учетной записью, и при последнем обстоятельстве запускают процесс выхода из системы. Кто-либо может думать о лучшем способе сделать это? Мы просто пытаемся реализовать наименее привилегированный доступ и гарантировать, чтобы администраторы не входили в систему с их администраторскими учетными записями.
На самом деле это проблема персонала, а не ИТ. Если пользователи с административными привилегиями не могут соблюдать правила, они не должны иметь административных привилегий.
Даже если бы существовал простой способ предотвратить интерактивный вход в систему, нечего сказать, что они не могут его обойти - например, , они могли завершить работу explorer.exe и перезапустить его от имени администратора, что фактически предоставило им полноценную административную среду. Если вы дадите им возможность работать от имени, вы дадите им все.
К сожалению, но в прошлый раз, когда я рассмотрел ту же проблему, мне показалось, что «интерактивный вход в систему» и «запуск от имени» неразрывно связаны друг с другом, так что это решение невозможно.
Надеюсь. это в конечном итоге проблема XY для вас.
Решение для нас закончилось тем, что мы неправильно смотрели на проблему. Было необходимо, чтобы администраторы чего-то еще (например, администратор домена, администратор сервера) управляли этими ресурсами с рабочего стола, для которых им не нужны были права администратора. Поэтому мы создали отдельную учетную запись (например, John.Smith.admin) для управления этими ресурсами и предоставили ей возможность входа на рабочий стол, но без прав администратора на рабочем столе.
Другой вариант - передать задачи «запуск от имени» другому объекту, которому не требуются учетные данные, посредством интерактивного входа в систему. Управление сервером Windows может осуществляться с помощью нового центра администрирования, который представляет собой веб-страницу, управление Linux может выполняться с помощью SSH.
Если это вместо этого предназначено для остановки атак повышения привилегий, вам необходимо либо принудительно выполнить действия с помощью предполагаемых системы (например, RDP для этого сервера с этими учетными данными) или создать для этой цели выделенные рабочие станции администратора (например, рабочую станцию, которая может подключаться только к DC).
Обнаружилась «похожая» проблема:
Мы не хотели предоставлять нашим сервисным учетным записям привилегии интерактивного входа в систему (что я считаю стандартной практикой).
Однако различные приложения, работающие на серверах, были настроены с использованием учетных записей служб, и для их изменения требовалось запускать связанные инструменты / приложения с функцией «Запуск от имени»; что приведет к сбою, поскольку запуск от имени обрабатывается как интерактивный вход.
Итак, поскольку все серверы расположены в центре обработки данных, к которому контролируется физический доступ, мы удалили учетные записи служб у пользователей удаленных рабочих столов, а затем разрешили интерактивный вход.
Это должен быть достаточно хороший компенсаторный контроль.
Создайте или выберите Организационную единицу, которая будет содержать ваших пользователей с ограниченным входом-. Переместите пользователей в группу (, если необходимо). Создайте объект групповой политики и примените к OU Отредактируйте объект групповой политики. Перейдите к:Конфигурация пользователя > Политики > Административные шаблоны > Система и установите для политики с именем «Пользовательский интерфейс» значение «logoff.exe». Обратите внимание, что эта политика не будет применяться немедленно; вам нужно будет использовать «gpupdate» в ваших системах, если вы собираетесь сразу же протестировать.
Кредит принадлежит:https://www.authlite.com/kb/allow-runas-but-block-interactive-logon