none
Странные проблемы с одной из учётных записей RRS feed

  • Общие обсуждения

  • Одна из учётных записей не может получить доступ к шарам \\domain\netlogon и \\domain\sysvol и к dfs с сообщением об ошибке "нет доступа" со всеми вытекающими последствиями. При этом ко всем остальным шарам на всех остальных серверах доступ есть в соответствии с членством в группах. Так же без проблем работают Outlook@Exchange и Lynk, да и всё остальное.
    Помимо этого, при попытке обратиться к любому контроллеру домена в любом домене леса по UNC \\dc.domain, выдаётся запрос на ввод логина и пароля. Однако, если зайти на \\domain, выдаётся список шар Netlogon, Sysvol и dfs. доступа к ним, как я уже упомянул, нет.

    Из нюансов: эта учетная запись была мигрирована из корневого домена леса в другой родительский домен того же леса посредством командлета Powershell Move-ADObject. Однако, это не первая мигрированная учетка, до нее было мигрировано около сотни без каких-либо проблем.

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

    16 декабря 2016 г. 15:47

Все ответы

  • Я бы начал с самого простого. Раз все симптомы у вас указывают на то, что эта учётка не может получить доступ к контроллеру домена, то я бы включил аудит неудачных попыток входа для контроллеров домена (если он ещё не включен) и посмотрел бы, что пишется в журнале событий Безопасность по поводу попыток входа под этой учётной записью.

    А дальше бы действовал на основе полученной дополнительной информации.


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


    • Изменено M.V.V. _ 16 декабря 2016 г. 16:27
    16 декабря 2016 г. 16:27
  • Аудит включил, в журнал ничего не пишется.
    Чтобы убедиться, что аудит работает, делал попытку доступа на шару \\dc.domain\c$ из-под нормальной учётки. В журнале фиксировались события Audit Failure в категории File Share.
    При попытке доступа к этой и к другим шарам на DC из-под проблемной учётки никаких записей в журнал аудита не производится.
    Вот такая дополнительная информация.
    17 декабря 2016 г. 10:16
  • Вдогонку.
    Что любопытно, если из-под проблемной учётки дать команду gpupdate, сообщений об ошибках нет.
    Более того, в журнале появляется запись об успешном обновлении пользовательской политики.
    17 декабря 2016 г. 10:21
  • Еще подробности.
    Если из-под проблемной учётки подключаться к шарам по UNC на основе IP-адресов контроллеров, шары sysvol и netlogon открываются.
    Если пытаться получить доступ к шаре \\x.x.x.x\c$ контроллера, где x.x.x.x - его IP-адрес, в журнал пишутся события Audit Failure в категории File Share.

    Упреждая вопросы, с разрешением имён всё в порядке.

     
    17 декабря 2016 г. 12:26
  • Аудит включил, в журнал ничего не пишется.
    Чтобы убедиться, что аудит работает, делал попытку доступа на шару \\dc.domain\c$ из-под нормальной учётки. В журнале фиксировались события Audit Failure в категории File Share.
    При попытке доступа к этой и к другим шарам на DC из-под проблемной учётки никаких записей в журнал аудита не производится.
    Вот такая дополнительная информация.

    Вы немного не то проверяете. Нужно включить аудит именно попыток входа - Audit logon event ("Аудит входа в систему" в русской версии), а не доступа к общим папкам. А проверить, что аудит работает, можно командой

    net use \\dc.domain\SYSVOL /user:domain\user password

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

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

    PS Групповые политики ныне (начиная с обновления для MS16-072) считываются с SYSVOL от имени учётной записи компьютера, так что ничего удивительного, что они читаются.


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

    17 декабря 2016 г. 13:06
  • Аудит неудачных попыток входа был включен по умолчанию, никаких событий при неудачных попытках из-под проблемной учётной записи не фиксировалось изначально, это я проверил первым делом еще до того, как сюда писать.

    Сейчас проверил, что net use \\dc.domain\SYSVOL с неправильными учётными данными приводит к появлению в журнале аудита соответствующих записей, т.е. аудит работает.

    Проблемная учетка ведёт себя неправильно на нескольких ПК, так что версия с сохранением реквизитов доступа к контроллерам (ко всем?) неправильная. Или что вы имеете в виду?

    За PS спасибо, не знал.

    17 декабря 2016 г. 13:26