Imagesforyou.ru

IMG FOR YOU — ИНТЕРЬЕРНАЯ ФОТОСТУДИЯ
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как управлять компьютерами в Active Directory. Часть 1: Создание и удаление учетных записей компьютеров

Как управлять компьютерами в Active Directory. Часть 1: Создание и удаление учетных записей компьютеров

Учетные записи компьютеров представляют собой устройства, подключенные к AD. Они хранятся в базе данных AD после того, как их подключат к домену. Это необходимо для применения к ним различных GPO и отслеживания их обновлений, если у вас установлен WSUS. И что еще более важно, это нужно для установки безопасной аутентификации для пользователей, входящих в Windows.

Чтобы управлять компьютерами, вам нужны права администратора домена, оператора учетной записи (Account Operators) или делегированные права на OU в котором хранятся компьютеры. Управлять можно с рабочей станции с установленными инструментами RSAT или на контроллере домена.

Содержание

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

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

Правой кнопкой мыши по иконке «Мой Компьютер» -> Управление -> Локальные пользователи и группы -> Пользователи. Переименуйте локального администратора в «root» выделив его учетную запись и нажав клавишу F2

Правой кнопкой по учетной записи root -> Задать пароль. Нажмите «Продолжить»

Задайте уникальный для учебного корпуса пароль, о котором проинформируйте отдел телекоммуникаций письмом

Установка Unreal Commander

В качетсве файлового менеджера рекомендуется использовать Unreal Commander из-за его методов работы с правами при копировании файлов и папок.

Unreal Commander можно скачать с официального сайта http://x-diesel.com или с университетского ftp-сервера ftp://ftp.rsu.edu.ru

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

Создание промежуточной папки

Создайте в разделе с достаточным количеством свободного места папку share. В нее надо скопировать Мои документы и Рабочий стол локальной учетной записи. Они расположены в Documents and Settings -> <имя локальной учетной записи>. При копировании данные унаследуют права доступа папки share. После завершения процесса копирования директорию локакльной учетной записи можно удалить целиком в целях экономии свободного дискового пространства.

Включение ПК в домен

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

Правой кнопкой мыши по иконке «Мой Компьютер» -> Свойства. Перейдите на закладку «Имя компьютера».

Windwos 7 вход в домен — только временный профиль

Зайдите в качестве локального администратора, запустите команду regedit в коммандной строке CMD и пройдите по ветке:

Читайте так же:
Влажность воздуха в серверной

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Далее необходимо найти профиль с окончанием .bak и переименновать его просто удалив это окончание вместе с точкой.
Или удалить вручную того пользователя чей профиль создается временным. В реестре надо удалить SSID ссылающийся на профиль.

А теперь то что предлагает делать Microsoft:

Способ 1. Исправьте профиль учетной записи пользователя

Для этого выполните указанные ниже действия.

    Нажмите кнопку Пуск

    Действия при наличии двух папок, имена которых начинаются с S-1-5 и содержат одинаковое длинное число, причем имя одной папки заканчивается на .bak. Измените папку .bak на обычную. Для этого выполните указанные ниже действия.

      Щелкните правой кнопкой папку, имя которой не содержит .bak и выберите команду «Переименовать». Затем добавьте .ba в конец имени папки.

Способ 2. Войдите в Windows и скопируйте свои данные в новую учетную запись.

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

Способ 3. Удалите ошибочный ИД безопасности и создайте новый профиль

    Удалите ошибочный ИД безопасности.
    Если для решения проблемы требуется помощь, перейдите к разделу » Получить помощь в решении проблемы «. Чтобы устранить проблему самостоятельно, перейдите к разделу Самостоятельное решение проблемы .

Помощь в решении проблемы

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

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

Заключение

По факту каких-то проблем из-за данной настройки я не получал. Отличий в настройке фаервола в зависимости от типа сети у меня нет, так что видимых проблем не было. На текущий момент там, где последний раз словил эту ошибку, настроил отложенный запуск службы сведений о подключенных сетях (Network Location Awareness Service). Ошибка больше не воспроизводится. Буду наблюдать дальше.

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

  • Блог
  • Обратная связь
  • gorbunov.ca (blog in English)

Сброс пароля учетной записи компьютера

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

Теория

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

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

Пароль учетной записи компьютера устанавливается автоматически и так же автоматически меняется по инициативе локального компьютера с периодичностью раз в 30 дней (в Windows NT раз в 7 дней). Периодичность определяется ключом реестра HKLMSYSTEMCurrentControlSetServicesNetlogonParameters REG_DWORD:MaximumPasswordAge по умолчанию равному 30.

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

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

Практика

Привычный (неправильный) набор действий:

image

  1. Запуск консоли Active Directory Users and Computers;
  2. Сброс учетной записи компьютера через контекстное меню (Reset Account).

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

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

Правильный набор действий.

  1. Входим в локальный компьютер с использованием учетной записи локального администратора;
  2. Открываем командную строку (Start -> Run. -> cmd);
  3. Набираем команду
    netdom resetpwd /server:<имя_контроллера_домена>
    /userD:<имя_домена><имя_администратора_домена>
    /passwordD:<пароль_администратора_домена>
    Например,
    C:>netdom resetpwd /server:DC1 /userd:contosoadministrator
    /passwordd:P@ssw0rd
  4. Выходим из сессии локального администратора (logoff);
  5. Вуаля! Логинимся доменной учетной записью без всяких перезагрузок!

Полный синтаксис команды доступен по команде netdom resetpwd /?

Внимание! Ключ PasswordD пишется с ДВУМЯ буковками «D» на конце (что явно подчеркивает, что в команде имя пользователя и пароль указываются именно для ДОМЕННОГО администратора).

Почему нужен переход на другой домен?

Для изменения домена требуются большие основания. Если ресурс зарегистрирован не так давно, то есть вероятность, что он еще не индексируется поисковыми машинами и не находится в индексах Google или Yandex. В этом случае лучшим вариантом будет создание нового ресурса с другим доменом. Трафик не будет сохранен.

Перенос с сохранением трафика может быть нужен по нескольким причинам. Некоторые из них:

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

Переезд на новый домен Active Directory

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

Объективные причины

В каждом случае потребность переезда нужно решать индивидуально, основываясь на многих факторах, но что можно сказать относительно точно: необходимость переезда в связи с архитектурными особенностями вашего домена сильно преувеличена. Даже в случае с SLD сильно перегибают палку — такой домен поддерживается во многих продуктах последних версий (например Exchange 2016 поддерживает).

На мой взгляд обязательно нужно переезжать с доменов а-ля microsoft.com, то есть если вы умудрились взять для AD имя реально существующего домена, ещё и очень популярного. Во всех остальных случаях оставайтесь спокойно на существующих доменах.

А может оставить все как есть?

Действительно, а почему бы и нет? Но даже если у вас все в состоянии «работает — не трогай», то все равно находятся системные администраторы, которые скажут: «Надо переехать на новый домен, чтобы начать с чистого листа, чтобы все было сделано правильно.» И таких товарищей достаточно много (например одно из последних обсуждений на форуме Technet).

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

Именно об этом варианте я и собираюсь рассказать на примере доведения до ума старого домена, который был поднят ещё на Windows Server 2000.

Задачи

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

Начнем разбор с самого начала.

Резервное копирование

Первое, о чем вам нужно задуматься — как вы будете бэкапить КД. Если у вас уже настроено регулярное резервное копирование, это значительно упрощает ситуацию. В моем случае использовался DPM 2012 R2 с резервным копированием контроллеров домена целиком как виртуальных машин, а также их содержимого (например в случае, если понадобится провести полномочное восстановление, то состояние системы будет как нельзя кстати).

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

  • Выполняйте контрольное резервное копирование между важными изменениями в ядре инфраструктуры;
  • Сохраняйте резервные копии до тех пор, пока вы не убедитесь в нормальном функционировании всех КД;
  • Резервное копирование выполняйте поддерживаемыми средствами (например VSS);
  • Обязательно убедитесь, что вы имеете восстанавливаемые резервные копии! Да, забэкапить мало, надо ещё и проверить а восстанавливаются ли бэкапы нормально или нет.

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

Диагностика AD

Обязательно пройдитесь по всем КД и проверьте состояние их здоровья:

  • Проанализируйте ошибки AD DS, DNS и др. служб в просмотре осбытий;
  • Проверьте репликацию 2 и состояние КД командами repadmin и dcdiag;
  • Установите все обновления ОС.

Только при отсутствии проблем приступайте ко всем изменениям.

Имя домена

Некрасивое или «неправильное» по мнению сисадминов имя домена наиболее часто является главным аргументом для переезда на другой домен. С другой стороны, что такое «правильное» имя домена? Да такого нет в принципе! Есть рекомендации какие домены лучше не использовать (например те же SLD), но это всего лишь рекомендации, которые к исполнению не обязательны. Все зависит от вашего окружения и преследуемых целей.

Админы говорят: «У меня домен domain.local, а я хочу domain.ru как основной домен организации«. То есть они считают домен domain.ru правильным. Дак вот, я скажу, что нет, это неправильное имя домена. Как минимум потому что вам придется очень сильно запариться с разруливанием запросов DNS к реальному DNS-имени domain.ru.

Признаться честно, я и сам долго болел идеей переезда на новый домен (Пара слов про именование доменов Active Directory), но лень победила — перетаскивать эксчи с терабайтами баз, всех пользователей и кучу других сервисов грозило стать неподъемной задачей и я взялся наводить порядок на существующем домене.

Теперь суть вопроса: чтобы пользоваться красивыми именами и логиниться во все доменные сервисы по адресу электронной почты достаточно создать дополнительный UPN-суффикс и назначить его всем нужным учеткам. При этом неважно какое у вас имя домена. Для переезда в облако доп. суффиксов достаточно (если у кого сомнения, читайте Локальная инфраструктура и Azure AD)

Перенос DNS-зоны _msdcs.ForestName

Это первое, с чего я начал. Почему? Нужно привести DNS в нормальное состояние, ведь от этого сервиса зависит здоровье AD в целом.

Для доменов, созданных на Windows Server 2000, зона _msdcs.ForestName располагается на уровне домена и желательно её перетащить на уровень леса, как это по умолчанию сделано на новых доменах AD на Windows Server 2003 и старше:

Сам процесс подробно расписан в официальной документации и на моем блоге в статье DNS-зона _msdcs.ForestName отсутствует.

Изменения вполне можно проводить в рабочее время, но все же обкатайте все на лабе.

Настройка защищенных динамических обновлений DNS

Вероятнее всего большинство разрешают незащищенные обновления DNS 3 . Тем не менее, согласно лучшим практикам рекомендуется разрешать динамические обновления только для авторизованных клиентов 4 .

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

Не забывайте, что вы можете настроить обновление клиентских DNS-записей на стороне DHCP-сервера, если он развернут на Windows Server. Изменения можно проводить в рабочее время (я бы даже сказал рекомендуется проводить в рабочее время), будет возможность оперативно отлавливать проблемы пользователей.

Настройка зон обратного просмотра

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

Изменения можно проводить в рабочее время.

Обновление уровней леса и домена

Нет никаких причин сидеть на старых уровнях леса и домена 5 и лишь ограничивать себя в функциональности AD. Например пользуйтесь корзиной AD 6 , повысив уровень леса до 2008 R2 и активировав соответствующую функцию.

Повысьте до максимально возможных значений уровни леса и домена (зависит от того на каких версиях ОС у вас работают КД) 7 . Задача относительно безболезненная, можно выполнять её в рабочее время.

Переезд с FRS на DFS-R

Уже с Windows Server 2008 FRS не считается надежной и устарела, а на дворе 2017 год. Смело переезжайте на DFS-R, к тому же последние на сегодняшний момент версии ОС уже перестали поддерживать FRS вообще (то есть даже новые КД на Windows Server 2016 в домен вам не запилить).

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

Процесс миграции вполне возможно проводить в рабочее время.

Настройка межсайтовой топологии (если актуально)

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

Сайты AD 8 созданы для того, чтобы «рассказать» Active Directory о реальной физической топологии сети, на основе которой AD построит топологию репликации оптимальным образом. По идее разбивать инфраструктуру на сайты нужно сразу как только один любой КД появляется в удаленном расположении (то есть вне локальной сети). Но и тут не все так просто, о чем мягко намекает объем гайда (см. статью Active Directory Design Guide) по планированию AD, в котором много внимания уделено именно сайтам.

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

Best practice

Если вы прошли путь, который я расписал выше и который проходил сам и хотите сделать ещё лучше, то предлагаю посмотреть в сторону лучших практик администрирования AD DS. Читайте дальше.

Удаление лишних ролей

Одна из основных идей AD — абсолютная идентичность и равнозаменяемость всех контроллеров домена. И это не корыстный интерес Microsoft, чтобы вы покупали как можно больше лицензий на ОС, это действительно важный аспект.

Идея в том, чтобы построить ядро инфраструктуры из абсолютно идентичных друг другу контроллеров домена (кроме ip и ролей fsmo разумеется). В случае утери любого из них не надо заморачиваться с его восстановлением, просто вычистите его остатки из AD и заведите новый с нуля.

Все поворачивается к вам совсем другим местом, если у потерянного КД имелись какие-то важные данных (многие организации держат и файловые помойки, и терминальные серверы и многое другое на одиночных КД). Таким образом вы лишаете себя той гибкости, которая изначально была заложена в архитектуру AD DS.

Вот пример списка установленных ролей и компонентов с полностью чистого контроллера домена:

По возможности держите на КД только роли AD DS и DNS (в зависимостях подтянутся File Services с DFS). Как минимум не размещайте на КД новые роли, а в идеале снимайте существующие «левые» сервисы (и DHCP тоже), если таковые имеются.

Одна и та же версия ОС

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

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

Рекомендации по best practice

Если соберетесь перелопатить инфраструктуру ради приведения ядра к идеальному виду, то вам непременно придется выводить старые КД из работы и вводить новые. Когда будете выводить старые КД, не забудьте:

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector