Права администрирования доменов

Как мне сменить владельца домена (передать права на домен другому лицу)?

Домен зарегистрирован через регистратора РЕГ.РУ

Передача прав на домен RU, SU, РФ осуществляется на основании письма, поступившего в адрес ООО «Регистратор доменных имен РЕГ.РУ» от текущего Администратора (владельца домена — на кого он оформлен в данный момент). Т.е. текущему Администратору необходимо написать письмо о том, что он согласен передать права на домен

Это можно сделать одним из способов:
— Лично прийти в любой из офисов Регистратора с паспортом и написать письмо там (или написать его заранее и просто принести в офис) — Написать письмо, заверить его у нотариуса (заверить свою подпись на письме) и отправить обычной «бумажной» почтой в любой из офисов Регистратора.

Письмо от текущего Администратора о передаче прав на домен новому Администратору.

• Письмо от юридических лиц
• Письмо от физических лиц и ИП

Если текущий Администратор является физическим лицом, то есть 2 варианта доставки письма:
1. Письмо можно доставить в любой из офисов REG.RU (Москва, Санкт-Петербург, Киев, Самара, Екатеринбург и др. — адреса см. в самом низу) лично с паспортом для идентификации личности (заверять у нотариуса в таком случае не нужно);
2.

Можно отправить по обычной почте (адрес см. в самом низу) нотариально заверенное письмо (нужно заполнить письмо, распечатать его и заверить у нотариуса свою подпись на этом письме).

Если текущий Администратор является юридическим лицом, то письмо должно быть оформлено строго с правилами подготовки документов (см. ниже — «Правила оформления писем»).

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

лицом), в соответствии с Правилами регистрации Регистратор запрашивает данные документы для проведения идентификации. Без предоставления данных документов произведение операции будет невозможным.

Что писать в письме в поле «Номер договора»:

в поле «Номер договора (название аккаунта) нового администратора» нужно вписать номер договора с Рег.ру того, кому Вы передаете домен (см. ниже как его получить).

В поле «Номер договора (название аккаунта) партнера (с указанием профиля)» нужно вписать:
— если после переоформления домен будет обслуживаться у нас, т.е. останется на defin.

ru, то в этом поле нужно вписать номер 6440 от 13 октября 2015 года (аккаунт defin-domains).
— если после переоформления домен должен быть передан на аккаунт в Рег.

ру непосредственно, то это поле заполнять не нужно.

Действия нового Администратора, которому передается домен (обязательные!)

Необходимо зарегистрировать аккаунт на сайте Регистратора Рег.ру и обязательно заполнить базовую анкету данными, на которые должен быть переоформлен домен (войти в свой аккаунт на Рег.

ру, перейти в раздел «Личный кабинет» -> «Мои данные» -> «Базовая анкета для регистрации доменов и заключения письменного договора»). После заполнения анкеты своими данными, на которые будет переоформлен домен, нужно зайти в раздел «Личный кабинет» -> «Мои данные» и там будет указан номер Вашего договора.

Этот номер нужно сообщить тому, кто передает Вам домен, чтобы он вписал его в письме в поле «Номер договора (название аккаунта) нового администратора». Для успешного совершения операции в Личный кабинет на сайте Рег.ру должна быть загружена копия документа, подтверждающая идентификационные данные.

После смены Администратора, не забудьте передать сам домен новому Администратору на его аккаунт у нас (если домен остается у нас)! Сделать это можно из меню управления доменом выбрав «Передать управление другому пользователю»

Примечание. Смена Администратора не производится до истечения 30 (тридцати) календарных дней с момента получения Администратором прав администрирования на домен или после смены Регистратора.

Правила оформления писем

Если нужно передать права на домен в международных зонах (COM, NET, ORG и т.п.)

Передача прав на международные домены (com, net, org, и проч) внутри defin.ru осуществляется автоматически при участии бывшего и нового Администратора домена и производится за два этапа:

1. Передача домена на аккаунт нового Администратора

Это можно сделать при помощи автоматической системы переноса через панель управления доменами непосредственно (в меню управления доменом).

2. Смена данных владельца на нового Администратора

После переноса домена на аккаунт нового Администратора, необходимо поменять данные владельца на новые. Вам необходимо для этого сделать следующее:

1. Авторизуйтесь в панели управления и выберите пункт меню «Домены» -> «Список доменов». Найдите нужный домен и нажмите на него.
2. У Вас откроется меню управления доменом. Выберите там «Изменить контакты Администратора»
3. В открывшейся форме Вы можете полностью изменить владельца домена на нового Администратора.

Вопросы по теме:

Как передать международный домен другому человеку? →

Как поменять ФИО / паспортные данные / почтовый адрес / дату рождения в данных домена? →

Как мне изменить email, телефон и адрес во Whois данных домена? →

Как перенести домен с одного аккаунта на другой? →

назад в категорию «Управление доменами»

Администратор домена: правовой статус и ответственность

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

Даже после принятия «Антипиратского закона» вопрос о том, кто же все-таки должен нести ответственность, не всегда решается судами однозначно.

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

Правовой статус. Соотношение с фигурой владельца сайта

Для того, чтобы дать определение, целесообразно обратиться к Правилам регистрации доменных имен в домене .RU (утв. от 05.10.2011 г.). Это важный акт, который определяет процедуру регистрации сайтов в Интернете на доменах .RU.

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

https://www.youtube.com/watch?v=jG1KBdCf_zc

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

Здесь также очень важно различать другую фигуру — владельца сайта. Владелец сайта в сети «Интернет» – лицо, которое самостоятельно и по своему усмотрению определяет порядок использования сайта, в том числе порядок размещения информации на нем (см. п. 17 ст. 2 Федерального закона «Об информации, информационных технология и защите информации»).

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

Функции

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

Что же касается сдачи домена в аренду, то это в принципе возможно, хотя в законе на это указания по-прежнему нет, и это при том, что в доктрине уже давно говорят о целесообразности такой гражданско-правовой конструкции.

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

Ответственность

Что же касается ответственности, то тут все не так однозначно. Важно вспомнить известное Постановление Суда по интеллектуальным правам от 11 декабря 2014 г. № С01-1204/2014 по делу № А56-59132/2013.

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

Мотивирует суд это тем, что именно эта фигура определяет порядок наполнения сайта, без его участия в какой-либо степени не происходит размещение контента на Интернет-ресурсе.

Постановление СИП не носит обязательного характера, однако арбитражным судам вменено в обязанность не нарушать единообразие практики (ст. 304 АПК РФ). Поэтому можно сделать вывод, что по сути СИП утвердил направление судебной практики.

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

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

С владельцем сайта сложнее, так просто его ФИО или наименование получить не удастся, никаких реестров владельцев сайтов в России нет.

Итоги

Таким образом, администратор домена все-таки будет нести ответственность за незаконно размещенный контент.

В то же время есть судебные дела, когда привлекались конкретные пользователи Интернета: чаще всего это было в тех случаях, когда пользователя можно было полностью идентифицировать (узнать его ФИО, адрес и т. д.).

Если предъявлен иск к администратору, но фактически управляло сайтом другое лицо (владелец сайта), можно предъявить к последнему регрессный иск.

ИБ: Автоматизация получения прав администратора домена в Active Directory

bga68
С момента появления фреймворка Empire и приложения BloodHound пентесты систем на базе Active Directory становятся все проще и прямолинейнее для 95% сред.21.09.2017

byt3bl33d3r

С момента появления фреймворка Empire и приложения BloodHound пентесты систем на базе Active Directory становятся все проще и прямолинейнее для 95% сред.

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

Мне кажется, что скрипт, работающий по принципу «запустил и забыл», который автоматически получает права администратора домена, является мечтой для каждого специалиста по безопасности.

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

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

Нужно сосредоточиться на пост-эксплуатации в целом и получении персональной конфиденциальной информации, документов и так далее. То есть все, что можно продемонстрировать «менеджменту» как влияющее на деятельность организации в случае, если произойдет реальное компрометирование.

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

Цели проекта и практическая реализация

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

Хотя в BloodHound , насколько мне известно, не предусмотрено использование возможностей, которые можно получить при помощи эскалации привилегий домена, например, GPP-пароли в хранилище SYSVOL (лично я считаю, что эта тема встречается практически повсюду).

Таким образом, я хотел реализовать более «деятельную» версию BloodHound, которая функционировала бы наподобие червя. Следует отметить, что в Empire есть большая часть базовых функций из BloodHound, раскиданных по разным модулям, и любой метод, выполняемый BloodHound, на который еще нет модуля в Empire, можно легко реализовать (например, схему ACL attack path update, на которую, между прочим, стоит обратить вниманием).В итоге я остановился на фреймворке Empire и решил делать автоматизацию при помощи RESTful API, что давало бы мне свободу при парсинге результатов работы модулей и больший контроль над общей логикой и пользовательской обратной связью.

Алгоритм работы

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

Рисунок 1: Общая схема автоматизированного получения прав администратора домена

Чтобы система работала корректно, необходимо установить мой форк, пока не будет интегрирован этот pull-запрос (и соответствующие изменения) в текущее хранилище. Мой форк содержит API и исправления функциях, связанных с работой с базами данных, для скриптов, взаимодействующих с RESTful API.

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

python empire —rest —username username —password password

Запустится консоль Empire и сервер RESTful API.Для загрузки и запуска системы автоматизации DeathStar (кодовое название моего творчества) необходимо выполнить следующую последовательность команд.

git clone https://github.com/byt3bl33d3r/DeathStar# Death Star is written in Python 3pip3 install -r requirements.txt# Supply the username and password you started Empire's RESTful API with

./DeathStar.

py -u username -p password

Если все прошло успешно, будет создан http-слушатель, и вы увидите статус 'Polling for Agents', который означает, чтобы вы авторизированы в RESTful API и DeathStar находится в ожидании первого агента.

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

Схема в действии

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

На первом видео привилегии повышаются при помощи уязвимости, связанной с GPP-паролями в хранилище SYSVOL.

Вначале распространение начинается с машин, где в групповых политиках прописано использование незашифрованых учетных записей. Затем дело доходит до системы, где авторизирован администратор домена. Далее происходит поиск запущенных процессов и инъекция (по умолчанию в explorer.exe) в процесс, запущенный от имени учетной записи администратора домена.

Таким образом, мы получаем агента, запущенного в этом контексте безопасности:

Во втором видео демонстрируется получение учетной записи администратора домена при помощи Mimikatz и злоупотребления взаимосвязями в контексте локального администратора:Следует упомянуть, что на видео выше используются учетные записи тем или иным образом. Хотя утилита DeathStar пригодна для получения прав администратора домена при помощи взаимосвязей локального администратора и PSInject без использования самих учетных записей.

Добавочный функционал

Кроме того, можно внедрить дополнительные уловки в пост-эксплуатацию, первичное имя сервиса (SPN) и т. д.

Более того, как только на базе фреймворка Empire будет реализована схема, связанная с именованными каналами в SMB (SMB Named Pipe pivoting), то тогда мир увидит нового червя.

Заключение

На примере утилиты DeathStar мы видим, что автоматизация получения прав администратора домена возможна даже с использование общедоступных инструментов.

Надеюсь, что вскоре появится много новых схожих утилит (лично я знаю двух людей, которые работают над решением этой задачи).Напоследок хотел бы сказать, что на все про все у меня ушло 3-4 дня.

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

Благодарности

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

Хотел бы поблагодарить нижеуказанных ребят за постоянную поддержку и советы:

• harmj0y
• wald0
• mattifestation
• rvrsh3ll
• xorrior
• CptJesus
• subTee

bga68Mac на службе у хакера.

Создание образа шифрованного диска

Создание администратора домена — Parallel Data Warehouse

• 04/17/2018
• Время чтения: 2 мин

Для некоторых операций требуются права администратора домена системной платформы аналитики.

Some operations require Analytics Platform System domain administrator privileges. В этом разделе объясняется, как создать дополнительных администраторов домена устройств.

This explains how to create additional appliance domain administrators.

Создание администратора доменаCreate a Domain Administrator

Чтобы иметь достаточные разрешения для настройки всех узлов AP, пользователь, запускающий Configuration Manager ТД (dwconfig.exe), должен быть членом группы «Администраторы домена «.

To have sufficient permissions to configure all APS nodes, the user running the APS Configuration Manager (dwconfig.exe) must be a member of the Domain Admins group. Для запуска и завершения служб APS пользователь должен быть членом группы пдвконтролнодеакцесс .

To start and stop the APS services, the user must be a member of the PdwControlNodeAccess group.

Добавление пользователя в группу «Администраторы домена»To add a user to the Domain Admins group

1. Войдите в активный узел AD (устройство_Domain-AD01 или ** устройство_Domain-AD02**), используя существующую учетную запись администратора домена устройства.Log into the active AD node (appliance_domain-AD01 or appliance_domain-AD02) using an existing appliance domain administrator account.

2. В меню Пуск выберите команду Выполнить.On the Start menu, click Run. В поле Открыть введите DSA. msc.In the Open box, type dsa.msc. Нажмите кнопку ОК.Click OK.

3. В программе Active Directory пользователи и компьютеры щелкните правой кнопкой мыши элемент Пользователи, наведите указатель на пункт создатьи выберите пункт пользователь.In the Active Directory Users and Computers program, right-click Users, point to New, and then click User.

4. В диалоговом окне новый объект — пользователь введите описание нового пользователя и нажмите кнопку Далее.In the New Object — User dialog box, complete the description of the new user, and then click Next.

   Заполните диалоговое окно пароль и нажмите кнопку Далее.Complete the password dialog box, and then click Next.

   Предупреждение

   SQL Server PDW не поддерживает знак доллара ($) в паролях администратора домена или локального администратора.SQL Server PDW does not support the dollar sign character ($) in the domain administrator or local administrator passwords.

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

   A password containing a dollar sign will valid and be usable but can block upgrade and maintenance activities

   Подтвердите новое описание пользователя и нажмите кнопку Готово.Confirm the new user description, and then click Finish.

5. В списке пользователей дважды щелкните нового пользователя, чтобы открыть диалоговое окно Свойства пользователя.In the list of users, double-click the new user to open the user properties dialog box.

6. На вкладке Входит в состав нажмите кнопку Добавить.On the Member Of tab, click Add.

   Введите Администраторы домена. Пдвконтролнодеакцесс и нажмите кнопку Проверить имена.Type Domain Admins; PdwControlNodeAccess and then click Check Names. Нажмите кнопку ОК.Click OK.

   Это добавит нового пользователя в группу «Администраторы домена » и группу пдвконтролнодеакцесс .This adds the new user to the Domain Admins group and the PdwControlNodeAccess group. Нажмите кнопку ОК.Click OK.

См. такжеSee Also

Запустите систему Configuration Manager (Analytics Platform)Launch the Configuration Manager (Analytics Platform System)

Что нужно знать администратору домена об ответственности за пиратский контент — мнение юриста — Офтоп на vc.ru

Директор юридической компании Legal Jazz Роман Фадеев и младший юрист Константин Юферов написали для vc.ru колонку о том, должен ли администратор домена нести ответственность за пиратский контент и как снизить риски привлечения к ответственности.

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

Как это происходит

Например, компания без разрешения скопировалафотографии правообладателя и разместила на своем сайте как фото своей продукции.Правообладатель обратился в суд за защитой авторских прав. Одновременнотребования были предъявлены и к администратору доменного имени, который был не фактическим владельцем сайта, а просто сотрудником компании-нарушителя.

Администратор домена пытается доказать, чтоон по просьбе руководителя зарегистрировалдомен, но не наполнял сайт контентом. Согласно практике Суда поинтеллектуальным правам, администратор в итоге все же понесет ответственность.Оговоримся, что речь идет о спорах, связанных с ведением предпринимательскойдеятельности, рассматриваемых в арбитраже.

Заиспользование чужих фото на сайте ждет штраф по ст. 1301 Гражданскогокодекса РФ в размере от 10 тыс руб до 5 млн руб за каждыйфакт нарушения. Выходит,100 чужих фото обойдутся минимум в 1 млн руб.

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

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

Судебная практика: за что отвечает администратор и почему

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

Суд по интеллектуальным правам (СИП) — судтретьей, кассационной инстанции, — полагает, что существование сайта невозможнобез доменного имени, а администратор может:

• Определять порядок использования домена — возможность наполнения контентом).
• Создавать техническиеусловия для посетителей своего интернет-ресурса.
• Контролировать использование интернет-ресурса. Например, обеспечивать функционирование сервера, на котором располагается сайт,поддерживать сайт в работоспособном состоянии и обеспечивать его доступностьдля пользователей.

Именно наличие такихвозможностей у администратора является основанием его ответственности засодержание сайта.

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

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

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

С точки зрения правообладателей, привлечениеименно администратора домена, пусть и вместе с фактическим владельцем сайта — суровая необходимость.

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

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

Именно поэтому для правообладателя стольважно привлечь к ответственности администратора доменного имени, личностькоторого можно установить наверняка. Администратор доменного имени, скореевсего, выдаст фактического владельца сайта.

Администратор как информационный посредник

Администраторы домена часто полагают, что ониявляются информационными посредниками (ст.1253.1 ГК РФ), что освобождает их от ответственности. 

К категории информационных посредников относятся:поисковые системы, сервисы хостинга видео, хостинг-провайдеры и те, ктопредоставляет возможность доступа к контенту в сети.

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

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

Как снизить риски привлечения к ответственности

Сейчас кроме перевода правадминистрирования на фактического владельца сайта, администратор никак не можетзащититься от рисков привлечения к ответственности по иску правообладателя. Чтож, пора посмотреть в своем аккаунте у регистратора, что там за вами числится.

Как снизить размер ответственности

Конституционный суд РФ в Постановлении от13.12.2016 N 28-П признал возможным снижать размер ответственности за нарушениениже пределов, установленных законом (нижний предел — 10 тыс руб закаждое нарушение) при наличии определенных критериев. Например, нарушениедопущено впервые и не носило грубый характер.

Если в вашем деле есть такие критерии — говоритеоб этом  суду и просите снизить размер компенсации.

Заключение

• ​ Администратор доменногоимени несет ответственность за контент на сайте, доменное имя которогозарегистрировано на него.
• Лучше не становиться администраторомдоменного имени, если вы не можете фактически контролировать размещение контента.
• Если вы не можете снятьс себя администрирование доменного имени, стоит хотя бы заключить договораренды доменного имени с фактическим владельцем сайта. Это позволит предъявитьрегрессное требование к нему, если правообладатель взыщет с вас деньги.
• Если вы администратор и вас привлекли каксоответчика в процесс по иску правообладателя, ссылайтесь на критерии изПостановления КС РФ от 13.12.2016 N 28-П, чтобы суд снизил размерответственности.

#Колонка #юридические_вопросы #советы_юриста

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать

[конспект админа] Меньше администраторов всем

Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.

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

Ограниченные группы

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

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

Active directory не очень любит путешественников во времени, и контроллер домена благополучно отправился в «захоронение» (tombstone).

Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.

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

Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.

Первый способ: через Группы с ограниченным доступом (Restricted groups), расположенные в групповых политиках по адресу Конфигурация компьютера – Политики – Параметры безопасности.

Расположение политик Restricted groups.

Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:

Добавляем группу «Администраторы», в которую добавляем группу helpdesk.

И получаем локальную группу «Администраторы» без Domain admins.

При такой настройке локальная группа «Администраторы» не будет зачищена.

Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.

Настройка группы безопасности через GPP.

Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.

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

Использование встроенных групп безопасности

Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.

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

Под спойлером предлагаю ознакомится с набором основных групп безопасности.

Познакомиться со всеми группами и более полным описанием можно в официальной документации.

Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети.

Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности – secpol.

msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.

Настройка прав доступа через групповые политики.

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

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

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

Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 10\2016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.

Достаточно администрирования

Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.

1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации.

Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.

Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.

Проверка версии и разрешение удаленных подключений при помощи PS.

Создадим группу безопасности и специального пользователя:

$VMOperatorGroup = New-ADGroup -Name «VM-operators» -GroupScope DomainLocal -PassThru$OperatorUser = New-ADUser -Name «VMOperator» -AccountPassword (ConvertTo-SecureString 'P@ssword1' -AsPlainText -Force) -PassThruEnable-ADAccount -Identity $OperatorUserAdd-ADGroupMember -Identity $VMOperatorGroup -Members $OperatorUser

Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:

New-Item -Path «C:\Program Files\WindowsPowerShell\Modules\Demo_Module» -ItemType DirectoryNew-ModuleManifest -Path «C:\Program Files\WindowsPowerShell\Modules\Demo_Module\Demo_Module.psd1″New-Item -Path «C:\Program Files\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities» -ItemType Directory

А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:

$VMRoleCapabilityParams = @{ Author = 'Сервер Молл' Description = 'VM Role Capability File' CompanyName = 'ServerMall'VisibleCmdlets= 'Get-VM', @{ Name='Start-VM'; Parameters=@{ Name='Name'; ValidateSet='win' } }, @{ Name = 'Stop-VM'; Parameters = @{ Name = 'Name'; ValidateSet = 'win'}}New-PSRoleCapabilityFile -Path «$ENV:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\VMRoleCapability.psrc» @VMRoleCapabilityParams

Теперь необходимо подготовить файл сессии PowerShell:

$NonAdministrator = «DOMAIN\VM-win-Operators» $ConfParams = @{ SessionType = 'RestrictedRemoteServer' RunAsVirtualAccount = $true RoleDefinitions = @{ $NonAdministrator = @{ RoleCapabilities = 'VMRoleCapability'} } TranscriptDirectory = «$env:ProgramData\JEAConfiguration\Transcripts»} New-Item -Path «$env:ProgramData\JEAConfiguration» -ItemType Directory$SessionName = 'VM_OperatorSession'New-PSSessionConfigurationFile -Path «$env:ProgramData\JEAConfiguration\VM.pssc» @ConfParams

Зарегистрируем файл сессии:

Register-PSSessionConfiguration -Name 'VM_OperatorSession' -Path «$env:ProgramData\JEAConfiguration\VM.pssc»

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

Enter-PSSession -ComputerName SERVERNAME -ConfigurationName VM_OperatorSession -Credential (Get-Credential)

Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.

Доступ к серверу ограничен управлением одной виртуальной машиной.

Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.

Интерфейс JEA Toolkit Helper.

При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.

Журнал выполнения PowerShell.

Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.

Файловый журнал JEA.