Моя учетная запись является локальным администратором на моей машине.
Если я попытаюсь перейти к несуществующей букве диска в моем собственном ящике, используя имя пути UNC:
\ mymachine \ x $
моя учетная запись будет заблокирована. Я также получил бы следующее предупреждение (идентификатор события 100, тип «Предупреждение») 5 раз в группе «Система» в средстве просмотра событий на моем ящике:
Серверу не удалось войти в учетную запись Windows NT «ourdomain \ myaccount» из-за следующей ошибки: Ошибка входа: неизвестное имя пользователя или неверный пароль.
Я бы также получил 3 раза следующее предупреждение:
Серверу не удалось войти в учетную запись Windows NT "ourdomain \ myaccount" из-за следующей ошибки: Указанная учетная запись в настоящее время заблокирована и не может быть подключена к ней.
На контроллере домена событие с кодом 680 типа «Аудит сбоев» будет появляться 4 раза в группе «Безопасность» в средстве просмотра событий:
Попытка входа:
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Учетная запись входа: myaccount
Затем следует событие с кодом 644:
Учетная запись пользователя заблокирована: Имя целевой учетной записи: myaccount Идентификатор целевой учетной записи: OURDOMAIN \ myaccount Имя вызывающего абонента: MYMACHINE Имя пользователя вызывающего абонента: STAN $ Домен вызывающего абонента: OURDOMAIN Идентификатор входа в систему вызывающего абонента: (0x0,0x3E7)
Далее следуют еще 4 ошибки с кодом события 680.
Как ни странно, каждый раз, когда я пытался перейти к пути UNC, мне предлагалось ввести имя пользователя и пароль, указанные выше ошибки записывались в журнал, и моя учетная запись блокировалась.
Когда я нажимаю «Отмена» в ответ на запрос имени пользователя и пароля, отображается следующее окно сообщения:
Windows не может найти \ mymachine \ x $. Проверьте орфографию и попробуйте еще раз или попробуйте найти элемент, нажав кнопку «Пуск», а затем «Поиск».
Я проверил с другими участниками группы, использующими XP, и они получили указанное выше окно сообщения только при переходе к «плохой» букве диска на их ящике. Ни у кого больше не запрашивали имя пользователя / пароль, а затем блокировали.
Итак, каждый раз, когда я пытался перейти к «плохой» букве диска, за кулисами XP пыталась войти в систему 8 раз, используя неверные учетные данные (или, по крайней мере, плохой пароль, поскольку логин был правильным), в результате чего моя учетная запись была заблокирована вышел с 4-й попытки. Интересно, что если бы я попытался найти «хороший» диск, такой как «c $», он бы работал нормально.
В качестве теста я попытался войти в свой ящик под другим именем и просмотреть «плохой» UNC-путь. Как ни странно, моя учетная запись «ourdomain \ myaccount» была заблокирована - не та, под которой я был авторизован! Я был полностью сбит с толку относительно того, почему передавались учетные данные для другого входа.
После долгого поиска в Google я нашел ссылку, относящуюся к некоторым настройкам IIS, с которыми я был смутно знаком по прошлому, но не мог понять, как они повлияют на эту проблему. Это было связано с настройкой безопасности каталога IIS «Анонимный доступ и контроль аутентификации», расположенной в:
Панель управления / Администрирование / Управление компьютером / Службы и приложения / Информационные службы Интернета / Веб-сайты / Веб-сайт по умолчанию / Свойства / Безопасность каталога / Анонимный доступ и контроль аутентификации / Редактировать / Пароль
При поиске в Интернете я не нашел никаких указаний на то, что это свойство связано с моей проблемой UNC. Но я заметил, что это свойство было установлено для моего имени пользователя домена и пароля. И мой пароль сделал в последнее время, но я не сбрасывал пароль для этого свойства. Конечно же, ввод нового пароля устранил проблему. Мне больше не предлагалось ввести имя пользователя и пароль при просмотре UNC-пути, и блокировка учетных записей прекратилась.
Теперь пара вопросов:
На самом деле я получаю несколько ошибок в пространстве IIS о моем подключенном диске.
http://server.domain.com.au/index.php?q=s$
Очевидно, он используется как: s $ Итак, он скрыт от обычных браузеров, но на самом деле запрос отправляется на веб-сервер, который перезаписывает запрос, как указано выше. (друпал я знаю)
Итак, если у вас есть аналогичная установка (IIS), вы должны видеть запросы на все, что не является фактическим общим ресурсом, и, вероятно, они тоже попадают в ваши файлы журнала IIS.
Удалите все кэшированные пароли на своей клиентской машине и попробуйте еще раз или поищите возможные следы Conficker :)
Поскольку у вас был подключен перенаправитель WebDAV - я забыл, как это выглядит для XP, но я подозреваю, что вы можете отвязать его из интерфейса Bindings для сетевого адаптера (возможно, в расширенном представлении).
Если вы возьмете сетевую трассировку того же клиента, подключающегося к другому диску на сервере с установленным IIS, вы увидите, что он делает две (или три - см. SMB) попытки подключения, более или менее одновременно:
Итак, когда вы подключились к своей локальной машине с помощью перенаправителя с поддержкой DAV, вы инициировали обнаружение экземпляра IIS, что, вероятно, привело к блокировке учетной записи (по причинам, которые вы указали). Ваши журналы IIS могут использоваться для подтверждения / опровержения этого.