Пользователи и компьютеры active directory не открывается

Каталог статей

На данном сайте есть статья просвещения установки Active Directory интегрированная с DNS. Посмотреть как это делается вы можете здесь.

Чуть отклоняюсь от проверки установки Active Directory и напоминаю что служба DNS в нашей сети может работать и без Active Directory, а вот Active Directory без службы DNS — не может. Поэтому прочтите внимательно статью про установке службы DNS интегрированный с службой каталога Active Directory по указанной сноске выше.

Так вот допустим мы установили Active Directory совместно с DNS как было описано здесь, и теперь нам необходимо хотя бы минимально проверится правильно ли мы все сделали.

Для проверки конфигурации домена после установки Active Directory в меню «Администрирование», нашего сервера появляются много чего нового. Но в данном случае нас интересует инструмент или вернее оснастка — «Active Directory — пользователи и компьютеры» что бы проверить работает правильно ли Active Directory и правильно ли размещен контроллер домена, смотрите рисунок 1.

Заходим в Пуск/Администрирование/Active Directory — пользователи и компьютеры, и открываем оснастку(смотри рисунок 1). В открывшемся окне смотрим на название нашего домена и проверяем правильно ли его название. В нашем случае это единственный домен rk.com (кто читал последовательно все про Active Directory или рассылку знает с чем связано данное название, а кто не читал и не получает рассылку — напомню что это домен нашей конторы «Рога и Копыта»). То есть главное что в данной операции мы делаем это проверяем правильность имени нашего домена, смотрите рисунок 2, и как видно на рисунке 2 у нас домен стал с правильном именем а именно тот который ему назначили при установке.

Дважды щелкаем на название нашего домена или на знак + что бы открыть контейнер нашего домена rk.com. В открывшемся контейнере (смотрите рисунок 3), выбираем пункт контроллеры домена — Domain Controllers.

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

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

Открывается окно показанное на рисунке 5 с вкладками. Смотрим данные на всех вкладках и контролируем если они правильные. Мы еще вернемся к данным вкладкам поэтому на этом проверку конфигурации домена на этом закончим.

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

Так как мы установили Active Directory интегрированную с DNS с помощью «Мастера установки Active Directory», то как бы сам мастер автоматически сконфигурировал наш DNS (что рекомендуется). То есть он создал все необходимые записи и прописал их в DNS-е, и как мы знаем посредством этих записей DNS позволяет найти необходимые узлы и службы. О ресурсных записях DNS смотрите здесь.

1. Открыть оснастку DNS. Для этого необходимо зайти в — Пуск/Программы/Администрирование/DNS, смотрите рисунок 6.

В окне оснастки DNS дважды щелкнем по имени DNS сервера и раскрываем все дерево консоли а так же — Зоны прямого просмотра и если сами прописали — Зону обратного просмотра, так как мастер установки зону обратного просмотра не создает сам. На рисунке 7 то что нужно раскрыть отмечено красным.

Так же для просмотра стандартных записей ресурсов раскройте папки _msdcs, _saites, _tcp, и _udp. Что занчит эти записи мы с вами уже обсуждали и вы можете просмотреть это здесь.

Чем сложнее наша сеть, тем многочисленнее будут записи в службе DNS. К примеру из того что показано на рисунке 8 мы делаем вывод что —

прописались необходимые записи для глобального каталога (кто не знает что такое глобальный каталог и что он делает смотри здесь), а именно записи типа SVR (напомню что посредством такого типа записей клиенты Active Directory находят контролер домена или хосты предоставляющие необходимый сервис). Как ведите из рисунка 8 записи имеют тип SVR но каждая запись так же предоставляет свой отдельный сервис. Что такое LDAP вы если читали внимательно материалы на сайте должны уже знать, что касается Kerberos и Krasswd (служба изменения пароля Kerberos) мы к ним еще вернемся в отдельной теме, что бы не заморочить вас окончательно. да и тема довольно большая и вы хотелось бы что бы привыкли к настройкам DNS и Active Directory что бы усвоить эту информацию легче.

Помимо всего что у нас есть в службе DNS, служба Netlogon создает файл журнала в котором указываются все служебные записи ресурсов. Данный файл созданный службой Netlogon находится в %Systemroot%System32ConfigNetlogon.dns. Пример содержимого этого файла смотрите на рисунке 9.

Если в сети есть другие реализации DNS которые не поддерживают динамическое обновление то все эти записи придется вести в ваш DNS сервер — «ручками», то есть вручную. Увы.

Мы по умолчанию когда устанавливали Active Directory решили так же посредством «мастера установки Active Directory» автоматически установить и службу DNS без который Active Directory — мертва или скажем более миролюбиво — не работает. В этом случае сам «мастер» должен создать интегрированную с Active Directory зону прямого поиска с именем соответствующей имени домена. Так вот при установки Active Directory с интегрированным DNS меняется местоположение данных зоны которое переносится из файла зоны DNS в каталог Active Directory на нашем сервере.

2. В оснастки DNS открываем дерево «Зона прямого просмотра«, правой кнопкой мыши становимся на зону нашего домена. В нашем случае это будет корневая зона rk.com и правой кнопкой мыши открываем контекстное меню. В появившимся меню выбираем «Свойства«. Откроется окно показанное на рисунке 10.

3. Смотрим на вкладке «Общие» (рисунок 10). Напротив надписи «Тип» (отмечено красным на рисунке 10) при интегрированной установки обязательно должно быть надпись — «Интегрированная в Active Directoey«. Чуть ниже на этой же вкладке смотрим надпись «Динамическое обновление» и ту должно стоять запись как на рисунке 10, то есть — «Небезопасные и безопасные». Если не стоит это запись то все равно выберите ее. Еще надо отметить что при интегрированной установки Active Directory совместно с DNS в свойствах зоны появляется новая вкладка безопасность (подчеркнута на рисунке 10 синим цветом). Предназначена она для задания настроек безопасности при обновлениях.

Ту же самое проделываем с зоной _msdcs.rk.com. Узнать больше что это за зоны, зачем они нужны и что они делают можно здесь.

Так же на вкладке «Общие» множите проверить тип репликации и при необходимости выбрать нужный тип. О репликации читайте на сайте.

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

На данной вкладке проверяемся что возле надписи «Загружать зону при старте» в поле выбора стоит — «Из Active Directory и реестра«. Не рисунке 11 отмечено красным цветом.

В процессе установки «Мастер установки Active Directory» создает на нашем сервере системный том с именем Sysvol. Зачем нужен Sysvol? А нужен он в основном для того что в нем хранятся общедоступные файлы, реплицируемые среди других контроллеров домена. В этих файлах, к примеру содержатся сценарии регистрации, некоторые объекты групповой политики. Напоминаю что — общий системный том должен размещается только на файловой системе NTFS. Размещается данный файл если ничего не трогать при установки в папке %Systemroot%Sysvol. Но мы в праве разместит данный системный том и в другом месте по нашему усмотрению. График репликации общего системного тома Sysvol совпадает с графиком репликации службы каталога Active Directory. Это надо помнить так как из-за этого результат репликации файлов в только что установленном системном томе или из него до истечения двух периодов репликации (который равняется в среднем около 10минутам) не дают о себе знать.

Примечание: Только не путаете Sysvol с файлом базы данных Active Directory — Ntds.dit, который можно размещать и на файловой системе с FAT (но не очень желательно).

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

• Общая папка Sysvol ;
• Общая папка Netlogon;
• Системные политики Windows 95, Windows 98, Windows Milenium, Windows NT 4;
• Настройки групповой политики Windows 2000 и Windows Server 2003;
• Сценарии входа и выхода пользователей.

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

2. Найти место расположение данной папки которое вы задали или оставили по умолчанию. Если в оставили все по умолчанию, то данная папка находится в %Systemroot%Sysvol. Смотрите рисунок 12.

4. Убедитесь в том что расшаренная или общедоступная папка sysvol содержит папку с названием вашего домена. В моем случае это папка rk.com.

Такая опция как «Режим восстановления службы каталога» на простых или рядовых серверах отсутствует. Что бы проверить работает данный режим нужно проделать следующее.

2. В появившемся меню — «Меню дополнительных вариантов загрузки» или «Windows Advanced Options» выберите с помощью клавиш со стрелками пункт — «Восстановление службы каталога» (Directory Services Restore Mode), после чего нажмите клавишу «Ввод»

3. На экране вновь откроется меню Загрузка (Boot), но в нижней части появится цветная надпись — Восстановление службы каталогов (Directory Services Restore Mode). Выбрав нужную установку операционной системы, нажмите на Enter. Теперь после перезагрузки система запустится в режиме восстановления службы каталога. Необходимо чуть подождать. а может и не чуть.

4. После появления экрана приветствия нажмите сочетания клавиш Ctrl + Alt + Delete. При регистрации на локальном компьютере укажите имя администратора сервера (имя учетной записи и пароль администратора должны быть определены в процессе настройки сервера) а так же специальный пароль который мы указали при установки службы каталога. Далее нажмите на кнопку ОК.

Пароль администратора который мы пользовались и прописан в Active Directory сейчас не действует по причине того что сама Active Directory «сломаласЯЯЯ», поэтому мы и используем пароль который мы указали при установке Active Directory.

5. Для того что бы запустить контроллер домена в безопасном режиме, при появлении окна «Windows работает в безопасном режиме» ( Windows Is Running In Safe Mode) нажмите на кнопку ОК.

Пользователи и компьютеры active directory не открывается

Ну логичнее всего было бы определить на каком из DC расположен глобальный каталог и доступен ли он (DC). Если он доступен, то надо смотреть зону DNS на предмет правильности srv записи о глобальном каталоге. Ну и конечно такой вариант как посмотреть настройки DNS клиента на машине, выдающей ошибку доступа к GC, и живость DNS сервера, держащего зону.

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

то есть «упасть» он теоретически не может.
Что за бред?
Расказать как ДНС сервера АД-шные валятся?
Смотри зону и логи. И если сюда все это хозяйство запостишь, то вообще все круто будет.

Что за бред?
Расказать как ДНС сервера АД-шные валятся?

елементарно. я тож оч удивился про «нероняемый ДНС» — «Вы просто не умеете их готовить!»

Good. «DNS серверу не удалось открыть зону в AD. . Проверьте правильность функционирования AD и перегрузите зону» —-так сказал мне DNS. То что AD не работает это я и так знаю а перегрузка зоны не помогла.

mm2 Итак. Имеем замкнутый круг.
1. AD не воркает без ДНС
2. ДНС не воркает без АД, так как в данном случае АД используется как хранилище зоны
3. Демоут домен контроллера невозможен без доступа к глобальному каталогу, который не доступен по причине недоступной зоны ДНС.

Я вижу один выход
1. Удаление старой ДНС зоны (скорее всего через оснастку ДНС будешь послан со словами нетути у меня доступа к АД поэтому зону удалять не буду) — ковыряй реестр (оно и там настройки зоны ныкает) и %SystemRoot%system32dnsbackup (оно и здесь ее ныкает)
2. Поднятие новой ДНС зоны (уже простой текстовой)
3. Рестарт сервиса netlogon на домен контроллере
4. Демоут сервера

Системная утилита quser.exe

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

Quser так же может работать удаленно используя следующий синтаксис:

Первая проблема этого способа — это то, что quser работает через RPC. Если вы выполняете команду удаленно, а порты не открыты, вы получите ошибки:

• Error 0x000006BA enumerating sessionnames
• Error [1722]:The RPC server is unavailable.

Для примера, следующие команды исправят эти проблемы на одном компьютере, но скорее всего вы будете менять настройки через политики. Так же обратите внимание, что правило устанавливается на «Any», а не только «Domain»:

Вторая проблема — если вы будете выполнять команду через Invoke-Command, то могут быть проблемы с кодировками:

И третья проблема — у нас возвращается строка, а не объект. Что бы мы могли все эти данные, в дальнейшем, экспортировать (например в CSV), мы должны ее парсить. Это можно сделать так:

Далее нам нужно преобразовать все в специальный массив — PSCustomObject, т.к. только он может быть экспортирован в CSV и представляет собой более удобный вывод:

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

Такой скрипт мы можем объединить в один командлет, который сможет работать локально и удаленно:

В функцию добавлено несколько деталей:

1. Функция имеет атрибут «ComputerName» в которую можно передать имя компьютера. Т.к. эта переменная является строкой мы не можем использовать одновременно несколько (конвейер передает по одному);
2. По умолчанию «ComputerName» выполняет $env:computername, что возвращает имя текущего компьютера;
3. Часть команды «quser /server:$ComputerName 2>Null » будет исключать некоторые ошибки, которые связаны с выключенными компьютерами. Иначе — будут выводиться красные сообщения мешающие выводу;
4. Добавлено несколько условий, которые различают логические ошибки (например фаервол), физические (компьютер выключен) и условие в случае если все хорошо;

Мы можем вызывать скрипт несколькими приемами:

Отмечу, что в случаях выключенных компьютеров запросы идут очень долго (около 2-3 секунд на компьютер). Способа снизить конкретно таймаут — я не знаю. Один из вариантов ускорить работу — фильтровать вывод с Get-ADComputer исключая отключенные учетные записи компьютеров. Так же можно попробовать использовать параллелизм.

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

Сам файл будет выглядеть так:

Отмечу следующие моменты:

1. Можно увидеть разницу во времени и датах. У меня одна ОС с американской локализацией, а другая с русской. В принципе у вас таких проблем быть не должно, но можно исправить через Get-Date (парсингом даты);
2. Из-за предыдущего пункта у меня бывали проблемы с кодировками, но они самоустранились быстрее, чем я смог предпринять действия.

Определения кто из пользователей за каким компьютером работает. AD.

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

Сразу оговорюсь, что в качестве исходных данных имею Windows среду и домен Active Directory, причем ОС преимущественно WindowsXP — Server2003. Ну и обслуживаемые компании были в основном некрупными (от 30 до 500 пользователей).

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

Для решения этой задачи были перепробованы разные методики:
•именование машин по именам пользователей (нудно. Через пару месяцев начинаешь забывать переименовать компьютер, и система катится в хаос)
•строгий учет кому куда можно ходить где нибудь в отдельном Excel и установка прав на логон только на конкретную машину и т.д. (чистой воды паранойя, была у одного из клиентов. ОЧЕНЬ нудно и муторно)
•Использование сторонних утилит от bginfo и psloggedon от Sysinternals, до всевозможных Hyena и Ideal Administrator (большая часть стоит денег, не всегда корректно работают, или слишком открытые, например в случае с BgInfo на рабочем столе становится видна информация, которую не хотелось бы чтобы видели абсолютно все. Возможно это паранойя – но не хочется чтобы толпы неизвестных людей в отделе продаж или на ресепшне узнали внутреннее имя компьютера, пользователя, IP и т.п. просто взглянув на экран.

В результате, мы «построили свой лунапарк с VBS и пользователями», и написали 2 небольших логон-логоф скрипта, которые запускаются групповой политикой на уровне всего домена при входе пользователя в систему, и при выходе из нее соответственно.

Dim adsinfo, ThisComp, oUser

‘ Определяем объекты
Set adsinfo = CreateObject(«adsysteminfo»)
Set ThisComp = GetObject(«LDAP://» & adsinfo.ComputerName)
Set oUser = GetObject(«LDAP://» & adsinfo.UserName)

‘ Заносим данные в AD
‘ В поле Department компьютера пишем имя пользователя, и время входа
Thiscomp.put «Department», «Logged on: » + oUser.cn + » » + CStr(Now)
ThisComp.Setinfo

‘В поле Department учетки пользователя пишем имя компьютера и время входа
oUser.put «Department», «Logged on: » + ThisComp.cn + » » + CStr(Now)
oUser.Setinfo
wscript.quit

Dim adsinfo, ThisComp, oUser

‘ Определяем объекты
Set adsinfo = CreateObject(«adsysteminfo»)
Set ThisComp = GetObject(«LDAP://» & adsinfo.ComputerName)
Set oUser = GetObject(«LDAP://» & adsinfo.UserName)

‘ Заносим данные в AD
‘ В поле Department компьютера пишем имя пользователя, и время входа
Thiscomp.put «Department», «Logged off: » + oUser.cn + » » + CStr(Now)
ThisComp.Setinfo

‘В поле Department пользователя пишем имя компьютера и время входа
oUser.put «Department», «Logged off: » + ThisComp.cn + » » + CStr(Now)
oUser.Setinfo
wscript.quit
Пояснения по коду наверное не нужны, скрипт элементарен, расскажу лишь про плюсы скрипта которые в моей ситуации значительно перевесили минусы (о которых тоже расскажу).

•при таком скрипте достаточно настроить в оснастке AD отображение одного дополнительного столбца (в нашем случае department) и можно будет четко видеть где кто работает в данный момент, когда он туда залогинился, либо если на компьютере никто не работает – то кто на нем работал последним, и когда вышел из системы
•Не привлекается никакого стороннего ПО, нагрузка на систему (время входа пользователя) увеличивается очень незначительно
•Легко и наглядно отслеживается наличие старых объектов компьютеров-пользователей в AD (по дате последнего логина)
•Данные централизованно хранятся в AD и не нужно никакого дополнительного хранилища (файла, папки, БД и т.п.). Данные дублируются в объектах Пользователь и Компьютер, т.е. можно отследить ситуацию «дважды под одним и тем же вошел на разных компьютерах».
•Выбраны наименее используемые (у нас и у всех тех организаций, с которыми я работал) ОБЩИЕ для объектов пользователь и компьютер поля AD. Это плюс, потому что если бы поля были разными – то пришлось бы добавлять отображение лишних столбцов в оснастке AD
•Легко корректировать скрипт по своему усмотрению (выбирать другие поля для хранения данных, писать дополнительно в текстовый файл, исключать из обработки отдельных пользователей или компьютеры (например терминальные сервера), и т.д.)

•НЕ ХРАНИТСЯ история входов, т.е. записано только текущее состояние. Если история входов нужна, то временно можно добавив несколько строк кода писать информацию еще и в сетевой файл, а если нужна постоянно – то лучше подумать о другом методе учета.
•Требуется выдать дополнительное разрешение WriteModify на поле Department объектов Компьютер и Пользователь в AD для всех доменных пользователей. Минус в моей ситуации сомнительный, но и отрицать его не буду – он есть.

Продолжение следует (если, конечно, вам интересно читать такие «опытные мелочи»)