Статья

Разрешаем сохранение учетных данных при подключении по RDP

При подключении к удаленному рабочему столу по RDP есть возможность сохранить учетные данные, чтобы не вводить их каждый раз. Но есть одна тонкость. Так если подключаться с компьютера, находящегося в домене, к компьютеру в рабочей группе, то использовать сохраненные данные не удастся, а будет выдано сообщение примерно такого содержания:

«Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»

Дело в том, что сохранение учетных данных при подключении к удаленному компьютеру запрещено доменными политиками по умолчанию. Однако такое положение вещей можно изменить.

На компьютере, с которого осуществляется подключение, нажимаем Win+R и вводим команду gpedit.msc, затем жмем OK. Дополнительно может потребоваться ввод пароля администратора или его подтверждения, в зависимости от политики UAC.

В открывшемся окне редактора локальной групповой политики идем в раздел Административные шаблоны -> Система -> Передача учетных данных. Нас интересует политика Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера ″только NTLM″ (в англ. варианте Allow Delegating Saved Credentials with NTLM-only Server Authentication).

Включаем политику, затем жмем на кнопку Показать, чтобы добавить в список серверы, к которым собираемся подключаться.

Заполнять список можно несколькими способами. Например:

• TERMSRV/удаленный_пк — разрешаем сохранять учетные данные для одного конкретного компьютера;
• TERMSRV/*.contoso.com — разрешаем сохранять данные для всех компьютеров в домене contoso.com;
• TERMSRV/* — разрешаем сохранять данные для всех компьютеров без исключения.

Внимание: используйте в TERMSRV заглавные буквы, как в примере. Если указан конкретный компьютер, то значение удаленный_пк должно полностью совпадать с именем, введенным в поле «Компьютер» удаленного рабочего стола.

Заполнив список жмем OK и закрываем редактор групповых политик. Открываем командную консоль и обновляем политики командой gpupdate /force. Все, можно подключаться.

И еще. Используя локальные групповые политики мы разрешаем сохранять учетные данные только на одном конкретном компьютере. Для нескольких компьютеров будет лучше создать в домене отдельное OU и привязать к нему соответствующую доменную политику.

Статья

Разрешаем сохранение учетных данных при подключении по RDP

При подключении к удаленному рабочему столу по RDP есть возможность сохранить учетные данные, чтобы не вводить их каждый раз. Но есть одна тонкость. Так если подключаться с компьютера, находящегося в домене, к компьютеру в рабочей группе, то использовать сохраненные данные не удастся, а будет выдано сообщение примерно такого содержания:

«Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»

Дело в том, что сохранение учетных данных при подключении к удаленному компьютеру запрещено доменными политиками по умолчанию. Однако такое положение вещей можно изменить.

На компьютере, с которого осуществляется подключение, нажимаем Win+R и вводим команду gpedit.msc, затем жмем OK. Дополнительно может потребоваться ввод пароля администратора или его подтверждения, в зависимости от политики UAC.

В открывшемся окне редактора локальной групповой политики идем в раздел Административные шаблоны -> Система -> Передача учетных данных. Нас интересует политика Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера ″только NTLM″ (в англ. варианте Allow Delegating Saved Credentials with NTLM-only Server Authentication).

Включаем политику, затем жмем на кнопку Показать, чтобы добавить в список серверы, к которым собираемся подключаться.

Заполнять список можно несколькими способами. Например:

• TERMSRV/удаленный_пк — разрешаем сохранять учетные данные для одного конкретного компьютера;
• TERMSRV/*.contoso.com — разрешаем сохранять данные для всех компьютеров в домене contoso.com;
• TERMSRV/* — разрешаем сохранять данные для всех компьютеров без исключения.

Внимание: используйте в TERMSRV заглавные буквы, как в примере. Если указан конкретный компьютер, то значение удаленный_пк должно полностью совпадать с именем, введенным в поле «Компьютер» удаленного рабочего стола.

Заполнив список жмем OK и закрываем редактор групповых политик. Открываем командную консоль и обновляем политики командой gpupdate /force. Все, можно подключаться.

И еще. Используя локальные групповые политики мы разрешаем сохранять учетные данные только на одном конкретном компьютере. Для нескольких компьютеров будет лучше создать в домене отдельное OU и привязать к нему соответствующую доменную политику.

Защита RDP. Принудительный ввод пароля

Защита RDP. Принудительный ввод пароля

Настройка политики удаленного рабочего стола для защиты от сохраненных паролей. В данном видео мы рассмотрим настройку безопасности RDP подключения к серверу Windows Server 2016. А в частности запретим пользователям подключаться к удаленному рабочему столу через сохраненный ранее пароль

Хотите получать свежие новости через ВК? Не вопрос, жми по ссылке: IT-Skills | Запишись в ИТ качалку

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

Но, тут есть и свои недостатки, а в частности возможность получить доступ к конфиденциальной информации через сохраненный пользователем пароль.

В чем суть, когда мы подключаемся в удаленному рабочему столу, вместе с вводом логина и пароля предлагается запомнить указанные данные, чтобы далее подключение выполнялось в автоматическом режиме.

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

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

Собственно, этим мы и займемся в данном видеоуроке.

Защита от автоматического входа любого компьютера

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

Вообще впервые с данной задачей я столкнулся еще несколько лет назад, когда были подозрения утечки конфиденциальной информации от сотрудников. На тот момент, в компании работало несколько сисадминов и в ходе обсуждения одной из причин утечки было как раз сохраненные пароли для RDP сеанса. Другие сисадмины хором сказали, что сделать так, чтобы пользователь всегда вводил пароль возможности нет. Однако я начал более подробно раскапывать эту тему и оказалось что возможность есть! Причем это стандартный функционал любой операционной системы не ниже Windows ХР и 2003 сервера.

Если у вас вопрос связан с защитой конкретного сервера или компьютера, который не входит в домен и на него не распространяется групповая политика, то тут потребуется отредактировать локальную групповую политику сервера или клиентской машины, к которой вы хотите подключаться (Win+R \ gpedit.msc \ Политики \ Административные шаблоны \ Компоненты Windows \ Службы удаленных рабочих столов \ Узел сеансов удаленных рабочих столов \ Безопасность \ Всегда запрашивать пароль при подключении \ Включить)

Чтобы быстренько применить эти изменения введем команду Win+R \ cmd \ gpupdate

Проверим, подключаемся к данному серверу с сохраненными данными и получаем следующее сообщение:

Недопустимые учетные данные: Политика проверки подлинности на сервере не допускает запросы на подключение с использованием сохраненных учетных данных. Введите новые учетные данные.

Убрать возможность сохранить пароль на клиентском компьютере

Если вы хотите убрать возможность сохранять любые пароли на клиентском компьютере через RDP, то можно выполнить следующую настройку.

Win+R \ gpedit.msc \ Политики \ Административные шаблоны \ Компоненты Windows \ Службы удаленных рабочих столов \ Клиент подключения к удаленному рабочему столу \ Запретить сохранение паролей \ Включить

Там же можно выполнить на своем компьютере, чтобы лишний раз не возникало желание сохранить пароль.

Применяем запрет через групповую политику домена GPO

Если вы хотите раздать данные настройки сразу нескольким компьютерам, то тут можно воспользоваться групповой политикой, но стоит учитывать, что для этого компьютеры должны находиться в домене.

(Пуск \ Диспетчер серверов \ Средства \ Управление групповой политикой \ Выбираем групповую политику, в зависимости от того, на какие компьютеры мы хотим её применить \ Либо можно создать отдельную политику и вручную указать компьютеры, к которым будут применяться данные настройки \ Default Domain Policy \ ПКМ \ Изменить \ Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Службы удаленных рабочих столов) Можно одновременно применить и запрет на сохранение пароля и требования вводить пароль если подключаются к этому компьютеру.

Проверим сработает ли данная система если мы добавим наш сервер в менеджер подключение Remote Desktop Connection Manager. Так же запрашивается пароль, так как данная программа использует для работы стандартный инструмент подключения к рабочему столу.

Как говорят, что эта защита срабатывает не всегда если человек подключается с какой-то стороннего RDP клиента, а не стандартного.

Но, в любом случае, самый распространенный источник работы это все же стандартный, так что берем данный метод на заметку.

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

Системный администратор запретил использовать сохранённые учётные данные. Разрешаем сохранение учетных данных при подключении по RDP

При подключении к удаленному рабочему столу по RDP есть возможность сохранить учетные данные, чтобы не вводить их каждый раз. Но есть одна тонкость. Так если подключаться с компьютера, находящегося в домене, к компьютеру в рабочей группе, то использовать сохраненные данные не удастся, а будет выдано сообщение примерно такого содержания:

«Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»

Дело в том, что сохранение учетных данных при подключении к удаленному компьютеру запрещено доменными политиками по умолчанию. Однако такое положение вещей можно изменить.

На компьютере, с которого осуществляется подключение, нажимаем Win+R и вводим команду gpedit.msc , затем жмем OK. Дополнительно может потребоваться ввод пароля администратора или его подтверждения, в зависимости от .

В открывшемся окне редактора локальной групповой политики идем в раздел Административные шаблоны -> Система -> Передача учетных данных. Нас интересует политика Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера ″только NTLM″ (в англ. варианте Allow Delegating Saved Credentials with NTLM-only Server Authentication).

Включаем политику, затем жмем на кнопку Показать, чтобы добавить в список серверы, к которым собираемся подключаться.

Заполнять список можно несколькими способами. Например:

TERMSRV/удаленный_пк — разрешаем сохранять учетные данные для одного конкретного компьютера;
TERMSRV/*.contoso.com — разрешаем сохранять данные для всех компьютеров в домене contoso.com;
TERMSRV/* — разрешаем сохранять данные для всех компьютеров без исключения.

Внимание: используйте в TERMSRV заглавные буквы, как в примере. Если указан конкретный компьютер, то значение удаленный_пк должно полностью совпадать с именем, введенным в поле «Компьютер» удаленного рабочего стола.

Заполнив список жмем OK и закрываем редактор групповых политик. Открываем командную консоль и обновляем политики командой gpupdate /force . Все, можно подключаться.

И еще. Используя локальные групповые политики мы разрешаем сохранять учетные данные только на одном конкретном компьютере. Для нескольких компьютеров будет лучше создать в домене отдельное OU и привязать к нему соответствующую доменную политику.

На сегодняшний день в сети существует сотни, а возможно, даже тысячи учетных записей администратора. Имеете ли вы контроль над всеми этим учетными записями, и знаете ли вы, что они могут делать?

Для чего необходимо контролировать учетные записи администраторов?

Если вы являетесь администратором сети Windows, а таких большинство, то ваше пристальное внимание должно быть направлено на корпоративный Active Directory enterprise. Со всеми этими заботами относительно безопасности контроллеров домена, серверов, служб, приложений и подключением к Internet, остается совсем мало времени на то, чтобы убедиться, что ваши учетные записи администраторов контролируются правильно.

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

Сколько у вас учетных записей администратора?

Чтобы ответить на этот вопрос, необходимо сделать некоторые вычисление (как сказал бы Jethro Bodine). Т.к. каждый компьютер с операционной системой Windows имеет учетную запись локального администратора, то мы начнем отсюда. Эти компьютеры включают Windows NT, 2000, XP и Vista. Убедитесь, что вы включили все компьютеры клиентов, которые используются администраторами, разработчиками, сотрудниками и даже находятся в серверной комнате или на прикладных устройствах. Если у вас есть киоски, тестовые компьютеры, централизованные рабочие станции и т.п., то всех также необходимо включить в наш расчет. Не нужно пока считать учетные записи пользователей, т.к. количество устройств, может не соответствовать количеству пользователей.

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

И наконец, вы должны рассмотреть контроллеры домена. Здесь у вас есть очень важная учетная запись администратора – это учетная запись, которая контролирует Active Directory. Эта учетная запись администратора не только контролирует Active Directory, но также управляет корневым доменом, также как и учетная запись корпоративного администратора. Если у вас более одного домена, то у вас должна быть одна учетная запись администратора для каждого домена. Соответствующая учетная запись администратора имеет силу лишь в том домене, в котором она размещается, но все равно это очень важная учетная запись.

Ограничение прав на вход

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

Ограничение доступа к учетной записи локального администратора

Вне зависимости от того, разрешаете ли вы обычным пользователям иметь доступ к их рабочей станции или нет, вы должны ограничить их доступ к учетной записи локального администратора. Два простых способа для этого заключаются в изменении имени учетной записи локального администратора и частого изменения пароля для нее. Существует объекты политики группы для каждого из этих параметров. Первый параметр находится в Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options, как показано на рисунке 1. Политика, которую необходимо настроить называется Accounts: Rename Administrator Account.

Рисунок 1: Политика для изменения имения учетной записи локального администратора

Вторая политика, которую вам необходимо настроить, является частью нового комплекта настроек политик (suite of policy settings), который появится в 2007. Эта политика является часть комплекта под названием PolicyMaker suite, и располагается в Computer Configuration|Windows Settings|Control Panel|Local Users and Groups, как показано на рисунке 2.

Рисунок 2: Политика для сброса пароля для учетной записи локального администратора Administrator accounts

Примечание: Эта политика не запрещает обычному пользователю от постоянного контроля на этой учетной записью, т.к. единственный способ сделать это, заключается в удалении обычного пользователя из группы администраторов.

Ограничение доступа к сети

Как все знают (но не все помнят), учетная запись администратора не должна использоваться на повседневной основе. По этой причине, нет необходимости настраивать сеть так, чтобы разрешать доступ в сеть под этой учетной записью. Один хороший способ по ограничению прав для этой учетной записи заключается в том, чтобы запретить учетной записи администратора доступ к серверам и контроллерам домена в сети. Это легко можно сделать с помощью настройки GPO. Эта настройка GPO находится Computer Configuration|Windows Settings|Security Settings|Local Policies|User Rights Assignment, как показано на рисунке 3. Политика, которую вы должны настроить называется Deny Access to this Computer from the Network (запретить доступ к этому компьютеру из сети).

Рисунок 3: Политика для запрета администратору доступа к компьютеру из сети

Другие настройки

Вы также можете ограничить доступ для учетной записи администратора внутри корпорации. Другие примеры, где вы можете ограничить доступ:

• Не использовать учетную запись администратора в качестве служебной учетной записи
• Запретить доступ к терминальным службам на серверах и контроллерах домена
• Запретить администраторам Administrator возможность входа в качестве службы на серверах и контроллерах домена
• Запретить учетной записи администратора входить в качестве batch job

Эти настройки лишь ограничат область влияния учетной записи администратора над компьютерами в сети. Эти настройки не запрещают пользователю с правами администратора настраивать этот доступ. В этом случае вы должны настроить аудит для конфигурации учетной записи администратора, а также проверять, когда эта учетная запись использовалась для входа и использовании пользовательских прав. И снова эти настройки можно выполнить с помощью GPO. Вы можете найти эти настройки в Computer Configuration|Windows Settings|Security Settings|Local Policies|Audit Policy, как показано на рисунке 4.

Рисунок 4: Политика для настройки аудита по управлению и использованию учетной записи

Резюме

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

В предыдущих статьях, посвященных локальным политикам безопасности, вы узнали о принципах работы политик учетных записей и политик аудита. Владея приобретенными знаниями, вы можете значительно обезопасить учетные данные ваших пользователей и отслеживать попытки несанкционированного доступа. Стоит учесть, что пользователи не владеют достаточной базой знаний по обеспечению безопасности и даже у обычного пользователя может быть достаточно привилегий для нанесения ущерба своей системе и даже компьютерам в вашей интрасети. Избежать подобных проблем помогают локальные политики безопасности назначения прав пользователя, о чем, собственно, и пойдет речь в данной статье. При помощи политик назначения прав пользователя вы можете сами определить, для каких пользователей или групп пользователей будут предоставлены различные права и привилегии. Оперируя данными политиками, вы можете не волноваться за то, что пользователи будут выполнять действия, которые им делать не положено. Для назначения прав доступны 44 политики безопасности, о применении которых далее пойдет речь.

Политики назначения прав пользователей

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

1. Архивация файлов и каталогов . При помощи данной политики вы можете указать пользователей или группы, предназначенные для выполнения операций резервного копирования файлов, каталогов, разделов реестра и других объектов, которые подлежат архивации. Данная политика предоставляет доступ для следующих разрешений:
   • Обзор папок/Выполнение файлов
   • Содержимое папки/Чтение данных
   • Чтение атрибутов
   • Чтение расширенных атрибутов
   • Чтение разрешений

На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» и «Операторы архивации» , а на контроллерах домена – «Операторы архивации» и «Операторы сервера» .

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

Восстановление файлов и каталогов . Эта политика позволяет вам указывать пользователей и группы, которые могут выполнять восстановление файлов и каталогов, в обход блокировке файлов, каталогов, разделов реестра и прочих объектов, расположенных в архивных версиях файлов.На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» и «Операторы архивации» , а на контроллерах домена – «Операторы архивации» и «Операторы сервера» .

Вход в качестве пакетного задания . При создании задания, используя планировщик заданий, операционная система регистрирует пользователя в системе как пользователя с пакетным входом. Данная политика разрешает группе или определенному пользователю входить в систему при помощи такого метода.По умолчанию, как на рабочих станциях, так и на контроллерах домена, данные привилегии предоставляются группам «Администраторы» и «Операторы архивации» .

Вход в качестве службы . Некоторые системные службы осуществляют вход в операционную систему под разными учетными записями. Например, служба «Windows Audio» запускается под учетной записью «Локальная служба» , служба «Телефония» использует учетную запись «Сетевая служба» . Данная политика безопасности определяет, какие учетные записи служб могут зарегистрировать процесс в качестве службы.По умолчанию, как на рабочих станциях, так и на серверах, ни у одной группы нет на это разрешений.

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

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

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

Доступ к компьютеру из сети . Данная политика безопасности отвечает за разрешение подключения к компьютеру по сети указанным пользователям или группам.На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» и «Операторы архивации» , «Пользователи» и «Все» . На контроллерах домена – «Администраторы» , «Проверенные пользователи» , «Контроллеры домена предприятия» и «Все» .

Завершение работы системы . Используя этот параметр политики, вы можете составить список пользователей, которые имеют право на использование команды «Завершение работы» после удачного входа в систему.На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» , «Операторы архивации» и «Пользователи» (только на рабочих станциях), а на контроллерах домена – «Администраторы» , «Операторы архивации» , «Операторы сервера» и «Операторы печати» .

Загрузка и выгрузка драйверов устройств . При помощи текущей политики вы можете указать пользователей, которым будут предоставлены права на динамическую загрузку и выгрузку драйверов устройств в режиме ядра, причем эта политика не распространяется на PnP-устройства.На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» , а на контроллерах домена – «Администраторы» и «Операторы печати» .

Замена маркера уровня процесса . Используя данную политику безопасности, вы можете ограничить пользователей или группу от использования API-функции CreateProcessAsUser для того, чтобы одна служба могла запускать другую функцию, процесс или службу. Стоит обратить внимание на то, что такое приложение как «Планировщик заданий» для своей работы использует данные привилегии.По умолчанию, как на рабочих станциях, так и на контроллерах домена, данные привилегии предоставляются учетным записям «Сетевая служба» и «Локальная служба» .

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

Запретить локальный вход . Данная политика запрещает отдельным пользователям или группам выполнять вход в систему.По умолчанию всем пользователям разрешен вход в систему.

Изменение метки объектов . Благодаря данной политике назначения прав, вы можете предоставить возможность указанным пользователям или группам изменять метки целостности объектов других пользователей, таких как файлы, разделы реестра или процессы.По умолчанию никому не разрешено изменять метки объектов.

Изменение параметров среды изготовителя . Используя эту политику безопасности, вы можете указать пользователей или группы, которым будет доступна возможность чтения переменных аппаратной среды. Переменные аппаратной среды — это параметры, сохраняемые в энергонезависимой памяти компьютеров, архитектура которых отлична от x86.На рабочих станциях и контроллерах домена, по умолчанию данные привилегии предоставляются группам «Администраторы» .

Изменение системного времени . Эта политика отвечает за изменение системного времени. Предоставив данное право пользователям или группам, вы тем самым кроме разрешения изменения даты и времени внутренних часов позволите им изменять соответствующее время отслеживаемых событий в оснастке «Просмотр событий» .На рабочих станциях и серверах данные привилегии предоставляются группам «Администраторы» и «Локальная служба» , а на контроллерах домена – «Администраторы» , «Операторы сервера» и «Локальная служба» .

Изменение часового пояса . При помощи текущей политики безопасности, вы можете указать пользователей или группы, которым разрешено изменять часовой пояс своего компьютера для отображения местного времени, которое представляет собой сумму системного времени компьютера и смещения часового пояса.На рабочих станциях и контроллерах домена по умолчанию данные привилегии предоставляются группам «Администраторы» и «Пользователи» .

Применение политик назначение прав пользователей

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

Заключение

В данной статье мы продолжили изучение политик безопасности, а именно, узнали о политиках назначения прав пользователей. При помощи политик назначения прав пользователя вы можете сами определить, для каких пользователей или групп пользователей будут предоставлены различные права и привилегии. Подробно описаны 18 из 44 политик безопасности. На приведенном в статье примере вы также узнали о том, как можно применить данные политики в организации. В следующей статье вы узнаете политиках, управляющих журналами событий.