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