Комментарии к записи: Решаем проблему внезапной блокировки учетной записи

Автор: pmf

pmf — Tue, 01 Dec 2009 06:40:51 +0000

И все ж таки «несмотря» слитно пишется...

Автор: Сергей

Сергей — Tue, 01 Dec 2009 05:12:38 +0000

Отличная статья, но утилита не всегда срабатывает

И информация о заблокированной учетной записи идет с кодом

644

User Account Locked Out:

Target Account Name: vasiliy

Target Account ID: NNM\vasiliy

Caller Machine Name: Server1

Caller User Name: DC_1$

Caller Domain: NNM

Caller Logon ID: (0×0,0x3E7)

Тут сразу видно, с какой машины была блокировка.

Автор: mdanshin

mdanshin — Mon, 23 Nov 2009 18:31:08 +0000

Данияр, спасибо за комментарий. Лично мне мало приходится работать с ISA, но тем, кто с ним работает вплотную, уверен, будет интересно познакомиться с LockoutGuard.

Автор: Данияр

Данияр — Mon, 23 Nov 2009 16:42:10 +0000

Помимо внутренних факторов существуют еще и внешние, например безопасная публикация веб-ресурсов через ISA сервер (OWA, SharePoint, ActiveSync и т.д.). Также возможно блокировка учетной записи через VPN клиентов. В отличие от внутренних атак, внешние атаки отследить и предотвратить намного сложнее. Зачастую приходится пригибать к программам стороннего производителя. Например, LockoutGuard для ISA Server (www.isaserver.org/tutoria...ckout-Guard.html)

Автор: mdanshin

mdanshin — Fri, 20 Nov 2009 12:59:39 +0000

Коллеги, отличная идея — собрать как можно больше таких вариантов. Это очень полезно и сможет облегчить жизнь многим системным администраторам. Спасибо Вам!

Автор: Андрей

Андрей — Fri, 20 Nov 2009 12:51:36 +0000

А еще в ИЕ запоминает пароли к закрытым ресурсам — и если используют доменную аутентификацию — то аккаунт лочится

Автор: mdanshin

mdanshin — Fri, 20 Nov 2009 08:24:35 +0000

Борис, огромное Вам спасибо за комменетарий! Уверен, что тем кто будет решать данную проблему будет полезна Ваша информация!

Автор: Борис

Борис — Fri, 20 Nov 2009 07:29:56 +0000

Не могу не поделиться ещё парочкой вариантов возникновения Account Lock Out.

Предположим, что у вас стоит политика автоматической смены паролей (ну не раз в 40 дней по умолчанию, а хотя бы раз в полгода). На следующий день после смены пароля прямо с утра пользователь прибегает и жалуется на залоченный аккаунт. Совершенно не обязательно виновата дырявая память пользователя. Другие варианты:

1. Уже упомянутая запланированая задача.

2. Замапленые диски с кешированными паролями (не те, которые мапит ваш логон скрипт, а те что пользователь замапил руками).

3. Сервисы, работающие под аккаунтом пользователя.

и самое, пожалуй, неуловимое —

4. COM-объекты, запускающиеся от имени пользователя.

5. Виртуальные машины с любым из предыдущих пунктов, вытащенные из снапшота, клонированные, или просто давно не включавшиеся.

Ситуация 3 и 4 как правило связано с локальной установкой серверной части клиент-серверных приложений, и требует аккуратного исследования установок приложения и правильной его перенастройки после смены пароля.