none
Призрак CN в лесу AD RRS feed

  • Вопрос

  • Есть лес AD

    DC=subdom1,DC=dom,DC=local

    Давно(год-два) существовал в subdom1 контроллер домена с именем subdom1-dc2

    Он был удален/понижен в роли, или умер, и вычищен из AD. История этого уже не сохранила.

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

    dsquery computer forestroot -name subdom1-dc*

    приходит ответ о существовании объекта

    "CN=SUBDOM1-DC2\0ACNF:49685e7d-0849-40bf-a110-10a2ad77ece9,CN=Computers,DC=subdom1,DC=dom,DC=local"

    Но при изучении контейнера computers через ADSIEdit такого объекта нет.

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

    Как избавится от этого призрака? Обращаю внимание на наличие неэкранированного "/" в итоговом имени CN объекта.

    29 августа 2014 г. 9:56

Ответы

  • В запросах LDAP вместо "\" следует указать экранированный вариант "\\". Для того, чтобы проявить этот объект, можно попробовать сделать запрос LDAP (через ADUC или ADSIEdit) с фильтром типа (CN=*\\0ACNF:*) и попытаться удалить из результатов запроса.

    Еще один вариант: попытаться удалить с помощью ldifde.exe:

    ldifde -i имя_файла

    где содержимое файла должно быть таким:

    DN: CN=SUBDOM1-DC2\\0ACNF:49685e7d-0849-40bf-a110-10a2ad77ece9,CN=Computers,DC=subdom1,DC=dom,DC=local
    changetype: delete
    

    вариант - просто сменить имя компьютера:

    DN: CN=SUBDOM1-DC2\\0ACNF:49685e7d-0849-40bf-a110-10a2ad77ece9,CN=Computers,DC=subdom1,DC=dom,DC=local
    changetype: modify
    sAMAccountName=что-то-другое
    PS Если данный объект не ищется в домене даже с экранированным обратным слэшем на КД этого домена, и если доменов в лесу несколько, то, возможно, он застрял в глобальном каталоге на КД другого домена. В таком случае стоит поискать его в разделе домена на КД другого домена в глобальном каталоге (подключаясь ADSIEdit'ом через порт 3268). В случае обнаружения удалить его можно с помощью repadmin /removelingeringobjects


    Слава России!

    29 августа 2014 г. 10:24

Все ответы

  • В запросах LDAP вместо "\" следует указать экранированный вариант "\\". Для того, чтобы проявить этот объект, можно попробовать сделать запрос LDAP (через ADUC или ADSIEdit) с фильтром типа (CN=*\\0ACNF:*) и попытаться удалить из результатов запроса.

    Еще один вариант: попытаться удалить с помощью ldifde.exe:

    ldifde -i имя_файла

    где содержимое файла должно быть таким:

    DN: CN=SUBDOM1-DC2\\0ACNF:49685e7d-0849-40bf-a110-10a2ad77ece9,CN=Computers,DC=subdom1,DC=dom,DC=local
    changetype: delete
    

    вариант - просто сменить имя компьютера:

    DN: CN=SUBDOM1-DC2\\0ACNF:49685e7d-0849-40bf-a110-10a2ad77ece9,CN=Computers,DC=subdom1,DC=dom,DC=local
    changetype: modify
    sAMAccountName=что-то-другое
    PS Если данный объект не ищется в домене даже с экранированным обратным слэшем на КД этого домена, и если доменов в лесу несколько, то, возможно, он застрял в глобальном каталоге на КД другого домена. В таком случае стоит поискать его в разделе домена на КД другого домена в глобальном каталоге (подключаясь ADSIEdit'ом через порт 3268). В случае обнаружения удалить его можно с помощью repadmin /removelingeringobjects


    Слава России!

    29 августа 2014 г. 10:24
  • Объект действительно застрял в глобальном каталоге.

    repadmin /removelingeringobjects

    Рапортует о исправлении 0 объектов.

    Хотя при просмотре через ADSIEdit' :3268 в

    DC=dom,DC=local

                DC=subdom1

                            CN=Computers

    Объект есть.

    Можете подсказать как пересоздать ветку subdom1  в глобальном каталоге с сервера subdom1-dc1.subdom1.dom.local

    При структуре

    GC = dc1.dom.local,dc2.dom.local

    DC = subdom1-dc1.subdom1.dom.local

    3 сентября 2014 г. 5:04
  • Наверное, в вашем случае проще всего, действительно, заново пересоздать раздел глобального каталога на каждом из КД командами (для примера - команды для dc1, для dc2 - аналогично, только замените dc1 на dc2)

    repadmin /unhost dc1.dom.local DC=subdom1,DC=dom,DC=local

    и

    repadmin /rehost dc1.dom.local DC=subdom1,DC=dom,DC=localsubdom1-dc1.subdom1.dom.local

    (подробнее см., например, http://blogs.msdn.com/b/canberrapfe/archive/2012/04/14/un-hosting-amp-re-hosting-active-directory-partitions.aspx ).

    Впрочем, вариант с удалением только "застрявших" записей с помощью repadmin /removelingeringobjects тоже возможен, хотя и более трудоемок. Описание процедуры см., например, в Technet Library, раздел "Solution" вплоть до подраздела "Enable strict replication consistency". Также в этом случае полезно прочитать тект по ссылке http://technet.microsoft.com/en-us/library/cc785298(v=WS.10).aspx и по ссылкам в этом тексте.


    Слава России!

    3 сентября 2014 г. 9:58
  • Спасибо. Вариант трудоемкого repadmin /removelingeringobjects с TechNet не прошел. А вариант с полным (как я понял) убиением всех GC при помощи repadmin /unhost я опасаюсь делать. Неуверен как к отсутствию GC отнесется Exchange и комплект SystemCenter
    3 сентября 2014 г. 14:14
  • repadmin /unhost GC не убивает - он всего лишь удаляет реплику раздела соответствующего (другого) домена. Но вот Exchange, если он задействует данный GC, действительно не сможет найти пользователей этого домена - как и любая другая программа. Ну и, вполне возможно, что сервер на время отсутсвия раздела перестанет объявлять себя глобальным каталогом через DNS. Так что я бы тоже поостерегся делать rehost во время активной работы с GC.

    Слава России!

    3 сентября 2014 г. 14:27