ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Windows Server 2016: создаем пользователя и даем RDP права
Стало недостаточно просто локального админа и нужно создать новую учетку на Windows Server 2016? А еще и снабдить УЗ правами на RDP (Remote Desktop Protocol)? Легко – займет 3 минуты твоего времени. Переходим к делу.
Что у вас должно быть
Шаг 1. Создаем пользователя
Нажмите правой кнопкой мыши на стартовое меню и найдите Computer Management. Кликните на него:
В меню навигации раскройте список Local Users and Groups и нажмите на Users:
Нажмите правой кнопкой мыши и выберите New User. Осталось только заполнить данные о новом пользователе: юзернейм, полное имя, описание и пароль. Особое внимание к галочкам User must change password at next logon (смена пароля после первого входа) и Password never expires (пароль никогда не устаревает – его не нужно менять регулярно):
По окончанию настройки нажмите Create. Готово!
Шаг 2. Даем права на RDP
Дважды кликните на Remote Desktop Users и нажмите кнопку Add:
В поле Enter the object names to select начните вводить имя созданного ранее пользователя и нажмите Check Names:
Имя пользователя заполнится автоматически до нужного формата. Нажмите OK в двух местах чтобы завершить настройку:
Шаг 3. Проверяем пользователя
Отключитесь от учетной записи администратора и подключитесь под новым пользователем. Работает!
Как разрешить обычным пользователям RDP доступ к контроллеру домена?
По умолчанию удаленный RDP-доступ к рабочему столу контроллеров домена Active Directory разрешен только членам группы администраторов домена (Domain Admins). В этой статье мы покажем, как предоставить RDP доступ к контроллерам домена обычным пользователям без предоставления административных полномочий.
Многие могут вполне обоснованно возразить, зачем, собственно, рядовым пользователям нужен удаленный доступ к рабочему столу DC. Действительно, в small и middle-size инфраструктурах, когда всю инфраструктуру обслуживают несколько администраторов, обладающих правами администратора домена, такая необходимость вряд ли понадобится. Обычно хватает возможностей делегирования пользователям административных полномочия в Active Directory или предоставления прав с помощью PowerShell Just Enough Administration (JEA).
Однако в больших корпоративных сетях, обслуживаемых большим количеством персонала, нередко возникает необходимость предоставления RDP доступа к DC (как правило к филиальным DC или RODC) различным группам администраторов серверов, команде мониторинга, дежурным администраторам и прочим техническим специалистам. Также бывают ситуации, когда на DC разворачивают сторонние службы, управляемые не доменными администраторами, которое также необходимо как-то обслуживать.
Чтобы войти в систему удаленно, вам нужно право на вход через службы удаленных рабочих столов
После повышения роли сервера до контроллера домена в оснастке управления компьютером пропадает возможность управления локальными пользователями и группами. При попытке открыть консоль Local Users and Groups (lusrmgr.msc). появляется ошибка:
Как вы видите, на контроллере домена отсутствуют локальные группы. Вместо локальной группы Remote Desktop Users, на DC используется встроенная доменная группа Remote Desktop Users (находятся контейнере Builtin). Управлять данной группой можно из консоли ADUC или из командной строки на DC.
Чтобы вывести состав локальной группы Remote Desktop Users на контроллере домена, выполните команду:
net localgroup «Remote Desktop Users»
Как вы видите, она пустая. Попробуем добавить в нее доменного пользователя itpro (в нашем примере itpro—обычный пользователь домена без административных привилегий).
net localgroup «Remote Desktop Users» /add corp\itpro
Убедитесь, что пользователь был добавлен в группу:
net localgroup «Remote Desktop Users»
Однако и после этого пользователь не может подключиться к DC через Remote Desktop с ошибкой:
Политика “Разрешить вход в систему через службу удаленных рабочих столов”
Чтобы разрешить доменному пользователю или группе удаленное RDP подключение к Windows, необходимо предоставить ему право SeRemoteInteractiveLogonRight. Вы можете предоставить это полномочие с помощью политики Allow log on through Remote Desktop Services (Разрешить вход в систему через службу удаленных рабочих столов).
Чтобы разрешить RDP подключение членам группы Remote Desktop Users, нужно изменить настройку этой политики на контроллере домена:
Обратите внимание, что группа, которые вы добавили в политику Allow log on through Remote Desktop Services, не должны присутствовать в политике “Deny log on through Remote Desktop Services”, т.к. она имеет приоритет (см статью Ограничение сетевого доступа в домене под локальными учетками). Также, если вы ограничиваете список компьютеров, на которые могут логиниться пользователи, нужно добавить имя сервера в свойствах учетной записи в AD (поле Log on to, атрибут LogonWorkstations).
Лучше всего создать в домене новую группу безопасности, например, AllowDCLogin. Затем нужно добавить в нее учетные записи пользователей, которым нужно разрешить удаленный доступ к DC. Если нужно разрешить доступ сразу на все контроллеры домена AD, вместо редактирования локальной политики на каждом DC, лучше через консоль управления доменными политиками ( GPMC.msc ) добавить группу пользователей в доменную политику Default Domain Controllers Policy (политика Allow log on through Remote Desktop Services находится в разделе Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment).
Теперь пользователи, которых вы добавили в политику, смогут подключаться к рабочему столу контроллеру домена по RDP.
Доступ к требуемому сеансу RDP отклонен
В нескорых случаях при подключении по RDP к контроллеру домена, вы можете получить ошибку:
Если вы подключаетесь к DC под неадминистративной учетной записью, это может быть связано с двумя проблемами:
Создание нового пользователя с правом удаленного доступа по RDP
2115 просмотров 3 2020-11-11 2021-11-11
Если у Вас возникла необходимость работать на сервере вдвоем(или сколь угодно больше человек) одновременно, то не обойтись без создания новых локальных пользователей. Данное руководство как раз призвано помочь с этой задачей.
Наглядные примеры будут показаны на основе Windows Server 2019, но добавление пользователя происходит аналогичным образом на остальных версиях ОС, которые представлены у нас.
Итак, первым делом на сервере кликните ПКМ по значку Пуск, чтобы открылось контекстное меню.
По-другому его можно вызвать с помощью сочетания клавиш Win + X.
В нем нужно перейти в раздел Управление компьютером(в англ. редакции “Computer Management”.
В нем в разделе “Локальные пользователи” есть два подраздела: “Пользователи” и “Группы”. Пока нас интересует только “Пользователи”, на котором(либо, перейдя в него, на пустом месте) нужно кликнуть ПКМ и выбрать “Новый пользователь”.
Откроется форма с полями для ввода данных нового пользователя.
В форме также присутствуют чекбоксы, в которых можно по желанию потребовать изменение пароля при первом входе пользователя в систему, либо, наоборот, запретить пользователю изменять пароль и/или сделать его бессрочным.
“Отключить учетную запись”(по крайней мере в рамках этого руководства) выбирать не стоит, поскольку мы хотим создать пользователя, чтобы сразу же использовать его в работе.
Обязательными полями является только “Пользователь”, которое в сущности является логином учетной записи, и “Пароль”, которое является паролем соответственно. Причем пароль должен отвечать требованиям политики безопасности по умолчанию.
Справка самих Microsoft содержит в себе информацию об этих требованиях политики безопасности(в дальнейшем ее можно будет изменить/отключить по своему желанию в соответствующей оснастке).
Итак, выбрав подходящий пароль и создав пользователя, двойный щелчком(или ПКМ по нему => Свойства) откройте его свойства. Далее перейдите в раздел “Членство в группах”.
Далее, кликнув по кнопке “Добавить”, переходим в раздел добавления групп, в которых будет состоять созданный пользователь.
Впишите в текстовое поле “Пользователи удаленного рабочего стола” и кликните на кнопку “Проверить имена”.
Система автоматически подберет соответствующую одноименную группу. Остается лишь кликнуть “ОК”…
…и “Применить” в оставшемся окне. Абсолютно аналогичным образом можно добавить созданного пользователя в группу “Администраторы”, если у Вас есть необходимость работать с правами администратора.
Готово. Пользователь создан и имеет права удаленного доступа к серверу.
Если ранее на сервере уже происходила авторизация под другой учетной записью(например, Administrator), окне подключения кликните на “изменить”, затем “Больше вариантов”, затем “Использовать другую учетную запись”, в поля введите данные созданного пользователя.
Убедиться в корректности осуществленных манипуляций можно в Панели управления, либо зайдя в командную строку(директория в ней по умолчанию будет соответствовать домашней директории нового пользователя.
Управление пользователями в коллекции RDS
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
Как администратор, вы можете напрямую управлять тем, какие пользователи имеют доступ к определенным коллекциям. Таким образом, вы можете создать одну коллекцию со стандартными приложениями для информационных работников, а затем создать отдельную коллекцию приложений с интенсивным использованием графики моделирования для инженеров. Существует два основных этапа управления доступом пользователей в развертывании служб удаленных рабочих столов (RDS):
Создание пользователей и групп в Active Directory
В развернутом состоянии службы удаленных рабочих столов и доменные службы Active Directory (AD DS) являются источником всех пользователей, групп и других объектов в домене. Вы можете управлять Active Directory непосредственно с помощью PowerShell, или использовать встроенные средства пользовательского интерфейса, которые добавляют в процесс простоты и гибкости. Выполнение следующих условий позволит установить эти средства (если они все еще не установлены) и затем использовать эти инструменты для управления пользователями и группами.
Установите средства AD DS
Выполнение следующих условий позволит установить средства AD DS на сервер, на котором уже запущены AD DS. После установки можно создавать пользователей или группы.
Создание группы
Вы можете использовать группы AD DS для предоставления доступа группе пользователей, которым необходимо использовать одни и те же удаленные ресурсы.
Создайте пользователя и добавьте его в группу
Назначение пользователей и групп в коллекции
Теперь, когда вы создали пользователей и группы в Active Directory, вы можете уточнить, кто будет иметь доступ к коллекциям удаленных рабочих столов в вашей среде.
Подключитесь к серверу, на котором выполняется роль посредника подключений к удаленному рабочему столу (посредник подключений к удаленному рабочему столу), выполнив действия, описанные ранее.
Добавьте другие серверы удаленного рабочего стола в пул управляемых серверов посредников подключений к удаленному рабочему столу.
Изменение коллекции для предоставления доступа к конкретным пользователям или группам описано ниже.
Окно групп пользователей не может быть пустым. Чтобы сузить круг пользователей, имеющих доступ к коллекции, необходимо сначала добавить определенных пользователей или группы, а затем удалить остальные группы.
Делегируем управление RDP-сеансами
В организации, где я работаю, удаленка запрещена в принципе. Была. До прошлой недели. Теперь пришлось в срочном порядке внедрять решение. От бизнеса — адаптация процессов к новому формату работы, от нас — PKI с пин-кодами и токенами, VPN, детальное логирование и много чего ещё.
Помимо всего прочего, я занимался настройкой инфраструктуры удаленных рабочих столов aka службы терминалов. У нас несколько RDS-развертываний в разных ЦОДах. Одной из задач было дать возможность коллегам из смежных подразделений ИТ подключаться к пользовательским сеансам в интерактивном режиме. Как известно, для этого есть штатный механизм RDS Shadow и самый простой способ его делегировать — дать права локального администратора на RDS-серверах.
Я уважаю и ценю своих коллег, но очень жадный до раздачи админских прав. 
Тех, кто со мной солидарен, прошу под кат.
Что ж, задача ясна, теперь — к делу.
Шаг 1
Создадим в Active Directory группу безопасности RDP_Operators и включим в нее учётные записи тех пользователей, которым хотим делегировать права:
Если у вас несколько AD-сайтов, то перед тем, как перейти к следующему шагу, нужно подождать, пока она будет реплицирована на все контроллеры домена. Обычно это занимает не более 15 минут.
Шаг 2
Дадим группе права на управление терминальными сессиями на каждом из RDSH-серверов:
Шаг 3
Добавим группу в локальную группу Пользователи удаленного рабочего стола на каждом из RDSH-серверов. Если у вас серверы объединены в коллекции сеансов, то делаем это на уровне коллекции:
Для одиночных серверов задействуем групповую политику, дождавшись, пока она применится на серверах. Те, кому лень ждать, могут форсировать процесс с помощью старого доброго gpupdate, желательно централизованно.
Шаг 4
Подготовим для «управленцев» такой PS-скрипт:
Чтобы PS-скрипт было удобно запускать, сделаем для него оболочку в виде cmd-файла с таким же именем, как у PS-скрипта:
Кладем оба файла в папку, которая будет доступна «управленцам» и просим их перелогиниться. Теперь, запустив cmd-файл, они смогут подключаться к сессиям других пользователей в режиме RDS Shadow и принудительно их разлогинивать (бывает полезно, когда пользователь не может самостоятельно завершить «зависшую» сессию).
Выглядит это примерно так:
Несколько замечаний напоследок
Нюанс 1. Если сеанс пользователя, к которому пытаемся получить управление, был запущен до того, как на сервере отработал скрипт Set-RDSPermissions.ps1, то «управленец» получит ошибку доступа. Решение здесь очевидно: подождать, пока управляемый пользователь перелогинится.
Нюанс 2. После нескольких дней работы с RDP Shadow заметили интересный то ли баг, то ли фичу: после завершения теневого сеанса у пользователя, к которому подключались, пропадает языковая панель в трее и чтобы ее вернуть, пользователю нужно перелогиниться. Как оказалось, мы не одиноки: раз, два, три.
На этом всё. Желаю здоровья вам и вашим серверам. Как всегда, жду обратной связи в комментариях и прошу пройти небольшой опрос ниже.