Показаны сообщения с ярлыком Active directory. Показать все сообщения
Показаны сообщения с ярлыком Active directory. Показать все сообщения

вторник, 6 декабря 2011 г.

Особенности параметра–Filter

Сегодня в почту пришло письмо от многоуважаемого коллеги. К слову, как хорошо, когда задают вопросы. Это позволяет столкнуться с задачами и проблемами, с которыми раньше не сталкивался. Так вот:
Андрей, добрый день! У меня возник ещё один вопрос, т.к. я столкнулся с некорректной, на мой взгляд ,работой ключевого командлета Get-ADUser Задача состояла в том, чтоб выбрать членов указанной группы, для этого я написал простую, на мой взгляд, конструкцию:
Get-ADUser  –Properties * -Filter ‘memberof –like “*abc*”’ | ft name 
На выходе получаю пустой список Когда я немножко так сказать усложнил путь:
Get-ADUser –Properties * -Filter * | where {$_.memberof  –like “*abc*”} | ft name

То всё сработало чудесно.. Отсюда вопрос – почему так, и можно ли вообще доверять опции  -filter  данного командлета? Конечно, я могу пользоваться и вторым вариантом, однако это вызывает определённые неудобства связанные с работой в удаленных сессиях, т.к. объем выборки очень большой, и сессия обрывается..

И, мой ответ.
Здравствуйте!
Что тут стоит сказать. Прежде всего вот http://technet.microsoft.com/en-us/library/hh531527(WS.10).aspx. Обратите внимание на 11 пример. По сути получается примерно следующее. Атрибут memberof, это не совсем обычный атрибут. Это бэклинк (back-link) - вычисляемое значение. Мало того, согласно его описанию вот тут http://msdn.microsoft.com/en-us/library/ms677943.aspx, он может хранить не все группы, членом которых является пользователь, а только самую нижнюю в иерархии. Например, если пользователь является членом группы А и Б, а Б в свою очередь входит в С то группы С в списке не будет. По-этому с этим нужно работать совсем иначе. Для него требуется совсем другой синтаксис LDAP запроса, с указанием matching rule OID, который, при обработке запроса LDAP сервером вызовет рекурсивный обход всех вложенных объектов начиная от потомка в сторону предков.
Как-то так:
filter1
Указывая параметр filter, Вы задаете LDAP фильтр, который отрабатывает на сервере и возвращает уже отфильтрованный результат. А вот второй запрос
Get-ADUser –Properties * -Filter * | where {$_.memberof  –like “*abc*”} | ft name
работает немного иначе. Обратите внимание на вывод get-member. В нем атрибут memberof уже является обычной строкой. Поэтому этот oneliner работает без проблем, но количество объектов, которое он возвращает может быть очень большим.
Посему мне кажется, что значительно проще в этом плане использовать комадлет get-adgroupmember:filter2

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

понедельник, 21 июня 2010 г.

Установка софта через глобальные политики

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

installError1

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

installError2

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

воскресенье, 6 июня 2010 г.

Проблема с DNS зоной Active Directory

Давеча меня попросили разобраться с проблемой. При попытке добраться из одного домена в другой, через доверительные отношения, выдавалось сообщение: “Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть”. Я зашел через RDP на проблемный контроллер домена и попробовал. Сообщение действительно выдавалось :). Занятно, но при попытке зайти на общедоступные ресурсы с другой стороны успешно удавалось. Мало того, ситуация складывалась так, что домен, в ресурсы которого не удавалось зайти был совсем недавно создан и в него был мигрирован другой домен, NT4. Так вот в ресурсы этого NT4 заходило без вопросов и проблем. Собственно говоря вот так примерно это выглядело. Зеленые стрелки это удачные заходы на общие ресурсы, а красные – соответственно, неудачные. Внешние эллипсы это два физически удаленных географических места, соединенных wan соединением.

domains

Что ж, подумал я, вероятно где-то есть проблема с разрешением имен. И тут я сделал первую ошибку. Я просто бросил пинг из одного и из другого домена. Имена исправно разрешались и пинги исправно шли. Странно, подумалось мне, очень странно. Недолго думая я поставил снифферы на трех машинах. На контроллерах в обоих w2k3 доменах и на файловом сервере, доступиться к которому не удавалось. Хотел посмотреть, где и почему все застряет. И тут меня ждал обескураживающий результат. Все выглядело нормально на первый взгляд. То есть файловый сервер корректно шел на свой контроллер домена за разъяснениями, по поводу имени пользователя из другого домена. Тот, в свою очередь ходил в удаленный домен однако конечный контроллер почему-то упорно возвращал ошибку. И только в этот момент мне пришло в голову внимательно посмотреть в зону DNS домена-источника. Сделай я это раньше – сэкономил бы кучу времени. Оказалось,что его зона не содержит ни одной srv записи. То есть не было ни одной “подпапки” в оснастке DNS. Кроме того, были отключены автоматичесие обновления. Вот это да, подумалось мне. Положение спас файлик
%SystemRoot %\System32\Config\Netlogon.dns. В нем, как водится, находилась корректная структура зоны, нужные srv записи. Я просто скопировал нужные записи в текущий файл зоны и перезапустил DNS. Затем сбросил кеш всех серверов в обоих доменах и все. Проблема пропала. По сути дела можно было просто включить автоматические обновления и перегрузиться или перезапустить netlogon, который, если верить документации, должен был перерегистрировать записи из этого файла. Но, об этом я подумал только после того как скопировал записи и перезапустил DNS.

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

rem Экспорт зоны в файл.
rem ---------------------
dnscmd localhost /ZoneExport domain.lan exported.domain.lan.dns

rem Импорт зоны из файла.
rem ---------------------
dnscmd.exe localhost /ZoneDelete domain.lan
dnscmd.exe localhost /ZoneAdd domain.lan /Primary /file exported.domain.lan.dns /load dnscmd.exe localhost /ZoneResetType domain.lan /DsPrimary /OverWrite_Ds