Назад | Перейти на главную страницу

Как исследовать блокировки сети Windows, связанные с проверкой подлинности Outlook Exchange Server?

Я конечный пользователь, а не ИТ-специалист. К сожалению, мои корпоративные ресурсы не могут решить эту проблему. Я ищу совета, чтобы дать им.

Я блокировал аккаунт в нашей корпоративной сети в среднем 2-3 раза в день в течение последних четырех месяцев. Я прожил несколько дней без проблем и был заблокирован 7 раз за один день. За предыдущие 8 лет я дважды был заблокирован.

Каждая блокировка требует звонка в нашу корпоративную службу поддержки, чтобы разблокировать мою учетную запись. Блокировки происходят из-за того, что наша система безопасности «думает», что я неоднократно пытаюсь пройти аутентификацию с неверными учетными данными (неправильный пароль).

Полная информация о чрезвычайно утомительном процессе отладки на сегодняшний день находится в моем сообщении в блоге: http://tech.kateva.org/2009/05/debugging-network-account-lockouts.html.

Около недели назад я взломал Outlook 2007, и мои локауты исчезли. Стоимость заключалась в том, что мне приходилось вручную аутентифицировать (домен / имя пользователя и пароль) первый раз каждый «день», когда мой клиент Outlook подключался к серверу Exchange. Раздражает, но я могу с этим жить.

С тех пор, как я начал этот процесс, мой ноутбук обновился. У меня есть новое оборудование с безупречным корпоративным стандартным образом диска, и я вернулся к Outlook 2003. Я снова оказался заблокированным!

Так что я не думаю, что проблема в моем ноутбуке.

При дальнейшем исследовании я обнаружил, что если я отправлял Outlook 2003, чтобы всегда запрашивать учетные данные, я НЕ был заблокирован.

Поэтому мне нужно понять, чем отличается процесс аутентификации, когда я

а. Outlook подключается к Exchange и автоматически аутентифицируется (стандартное поведение) с использованием учетных данных, связанных с моей учетной записью (сетевой домен NTLM / un и pw).

б. Outlook подключается к Exchange, и мне нужно вручную ввести свои сетевые un и pw.

Как-то "Ъ" работает правильно. Однако я думаю, что с процессом «a» сервер Exchange (наш Outlook?) Отправляет неправильные учетные данные в Active Directory, что приводит к блокировке меня.

Я подозреваю неправильную настройку моей учетной записи Active Directory и / или почтового ящика Exchange Server.

Мне нужно предоставить нашей службе поддержки и службе безопасности хороший список вещей, которые они могут исследовать в Active Directory или Exchange Server. Если я не могу этого сделать, мне нужно будет получить новый корпоративный идентификатор и отказаться от существующего идентификатора пользователя.

Я думаю, что если я смогу указать им в правильном направлении и дать им довольно точные указания, они смогут решить эту проблему.

Любой совет поможет. Возможно, мне просто придется исследовать, как аутентификация NTLM (AD) работает с запросами Exchange Server.

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

Я (как член ИТ-организации) создал сценарий, который размещался на PDC (теперь эмулятор PDC). Каждый раз, когда учетная запись заблокирована, этот контроллер домена регистрирует идентификатор события # 644 (4740 в Windows Server 2008) в журнале безопасности. Событие также включает имя клиентского компьютера, который последний раз пытался войти в систему с неправильным паролем. Итак, мой сценарий опрашивал журнал безопасности каждые 5 минут и размещал эти данные на веб-странице, доступной для службы поддержки.

Как только у нас это было, было тривиальным делом изменить рабочий процесс службы поддержки, чтобы проверять эту страницу всякий раз, когда у них возникала проблема с блокировкой учетной записи, а затем помогать пользователю обнаружить, что именно на этой машине вызвало блокировку. Как вы отмечаете в своей статье в блоге, виновником обычно является какая-то вторая машина, на которой пользователь забыл, что они вошли в систему, когда они изменили свой пароль со своей основной машины. Обычно на этой второй машине будет запущен Outlook или диск будет подключен с помощью учетных данных пользователя (теперь устаревших).

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

Если есть интерес к этому сценарию, я мог бы выкопать его, стереть пыль и разместить здесь.

Я отвечу на свой вопрос. Я не был заблокирован более недели, даже после включения повторного включения сквозной аутентификации Outlook, поэтому, хотя не было окончательного решения, я могу сообщить, где я оставил вещи.

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

Последние две вещи, которые я сделал:

  1. Я обнаружил, что новый корпоративный имидж включает в себя два сопоставления дисков. Вздох. (Звук удара головой о стену.) Я давно снял их со своего старого ноутбука, но они вернулись. Я удалил их снова. Это была не единственная проблема корпоративного имиджа.
  2. Я экспериментировал с переключением аутентификации Outlook 2003 между "автоматической" (по умолчанию), только Kerberos (современной) и только NTLM (устаревшей). Переход на Kerberos, казалось, решил проблемы, но я думаю, что это отвлекающий маневр. Возврат к значениям по умолчанию не устранил проблему блокировки.
  3. Я использую Retrospect Professional для Windows для резервного копирования моей рабочей станции на внешний диск. (Корпоративное резервное копирование неплохо, но восстановление занимает около недели.) Это программное обеспечение имеет функцию автозапуска. Я бы установил его на автоматический запуск с использованием учетных данных для входа в систему, а не с помощью коварной функции предоставления учетных данных. Интересно, хотя насчет пересечения между подключенными дисками и автозапуском. Я отключил автоматический запуск Retrospect Pro на данный момент.

Я очень ценю ссылку, которую Neobyte предоставил на обновленную страницу устранения неполадок Microsoft:

http://technet.microsoft.com/en-us/library/cc773155%28WS.10).aspx

У меня остались психические шрамы. Учитывая поразительное разнообразие проблем, связанных со службами аутентификации Microsoft и их кучей унаследованных взломов, а также пересечение с распределенной аутентификацией и функциями post-hoc безопасности, такими как блокировки аутентификации, я теперь глубоко консервативен в отношении использования любой новой или новой корпоративной сети. или «облачные» инициативы. Они должны быть построены на гораздо более надежной инфраструктуре, чем то, что предоставляет Microsoft, и для их реализации требуется как финансирование ИТ, так и реорганизация ИТ.

Я предполагаю, что имя пользователя, пароль и домен, которые вы используете для Exchange, идентичны учетным данным, с которыми вы входите на свой компьютер.

Если проблема возникла повторно после переустановки корпоративного SOE, и это происходит только с вами ... у вас есть перемещаемый профиль или ваши настройки каким-либо другим способом перенесены в сетевое расположение? Если да, то это объясняет, почему проблема возникла после обновления рабочей станции. В вашем сообщении в блоге говорится, что вы «восстановили данные» на своем новом SOE. Вы уверены, что не восстановили проблемное приложение?

Удалите все плагины, которые вы, возможно, добавили в Outlook 2003, и любые другие нестандартные (например, не то, что ваш ИТ-отдел устанавливает для вас) настройки, которые вы добавили в новый SOE с момента его получения.

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

ОБНОВИТЬ

Эта ссылка от Microsoft может помочь вам и / или вашей ИТ-группе в решении проблемы.

[Устранение неполадок с блокировкой учетной записи] (http://technet.microsoft.com/en-us/library/cc773155(WS.10).aspx «Microsoft Technet»)

Другой ответ, опять же с точки зрения ИТ, - это переосмысление политики блокировки учетных записей.

Нередко можно увидеть, что политика блокировки настроена так, что 10 неудачных попыток входа в систему в течение 10 минут вызывают полную блокировку. пока администратор не сбросит учетную запись. Мало того, такой низкий лимит делает вас уязвимыми для простой атаки типа «отказ в обслуживании» (DoS): BadGuy (TM) должен использовать только 10 неверных паролей, и теперь он заблокировал учетную запись. Представьте, что это происходит с 500 аккаунтами! Я видел: это неинтересно. Хуже того, представьте, что это делается для всех ваших учетных записей администратора!

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

Для взлома пароля грубой силой, даже если пароль минимально сложный, требуются тысячи или миллионы попыток, прежде чем у него появится хоть сколько-нибудь приличный шанс на успех. Так почему бы не подумать о политике паролей, которая допускает 50 попыток входа в систему за 5 минут, а затем автоматически сбрасывается через 5 минут? При такой скорости (50 попыток каждые 5 минут) большинство скриптов грубой силы просто откажутся, но большинство беглых попыток DoS не достигнут предела. Скрипты брутфорса, которые сделал поймите, что учетная запись разблокируется через 5 минут, допуская еще 50 попыток, будет ограничено 7200 попытками в день. Вы, конечно, можете менять границы всего, что вам нравится.

Одна вещь, которая меня беспокоит, - это возможность проблемы с синхронизацией времени на контроллерах домена и, возможно, на вашей рабочей станции, которая мешает Kerberos. Плохое время может привести к неудачному входу в систему, что считается блокировкой. Команда «w32tm» может помочь вам диагностировать, отклоняется ли время вашей рабочей станции от контроллеров домена или серверов Exchange (или друг от друга). Я считаю, что вам не нужны специальные привилегии для проверки этой команды.

Это мое угадать что ручной вход в Outlook запускает совершенно новый сеанс входа в систему, а не пытается повторно использовать токен, который вы получили при входе в сеанс рабочего стола. По какой-то причине он не устаревает, как вход в систему на рабочем столе.

Следующее, что я буду искать, это подозрительные записи журнала событий, но я полагаю, что это уже было сделано. К сожалению, я не могу описать, как могло бы выглядеть «подозрительное». Я бы сравнил обычный сквозной вход в систему Exchange с неудачным входом в систему и начал бы искать в Google различия, если это не было очевидно. :}

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

Стоит хотя бы проверить.