none
Пустые пароли пользователей

    Question

  • Странная ситуация с паролями - установлены политики, запрещающие пароли до 8 символов, не использовать  5 предыдущих и т.д.
    Есть сервис (C#), кот автоматически создает пользователей из принятых на работу.
    Мало того, что сей сервис умудряется создать пользователей с пустым паролем, так еще у администратраторов есть возможность задавать пользователям пустые пароли. Причем , если пользователь создается через АД:Пользователи и компьютеры - задать ему пустой пароль администраторы не могут. А для пользователя созданного этим сервисом - могут. От GPO независит -  оба пользователя ( и созданный сервисом, и созданный в ручную через оснастку ADUC) находятся в одном OU.
    Мне надо запретить возможность задания пустого пароля. Подскажите плиз как где такое может задаваться

    Wednesday, August 26, 2009 2:18 PM

Answers

  • Спасибо. Нашел сам. В первые разы прозевал. В свойсвах юсера есть такой атрибут (см ADSIEDIT)
    userAccountControl - 0X220 = 544 - установленное сервисом  - означает  PASSWD_NOTREQD | NORMAL_ACCOUNT
    userAccountControl - 0x200 = 512 - верное значение - означает  NORMAL_ACCOUNT

    Решено. Всем сбросим в 544 и ок
    Thursday, August 27, 2009 7:48 AM

All replies

  • Т.е. у Вас в домене действует политика паролей (прям по рекомендациям разработчика), запрещающая пароли, длинной менее 8-ми символов, а сервис (кстати, он какой интерфейс использует, ADSI ?) успешно создает пользователей с пустым паролем!?


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
    Wednesday, August 26, 2009 2:22 PM
  • Да. Сервис самописный , на C#.
     Причем , как уже я говорил, и после этого данной учетке можно задать пустой пароль через ADUC. Т.е. региональные админы ставят юсерам пустые пароли.
    Thursday, August 27, 2009 5:35 AM
  • Бред какой-то. А сравните экземпляры объектов пользователей с действующей политикой паролей и проблемные. А схему Ваши программисты "допиливали" (?), хотя, модификацией схемы такого поведения врят ли можно добиться.


    Может, у Вас домен 2008 и действуют гранулированные политики паролей? :)


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
    Thursday, August 27, 2009 6:16 AM
  • Да, это возможно на уровне программирования. При смене пароля LSA обращается к функции PasswordFilter. Подробнее схему взаимодействия см. здесь:

    http://msdn.microsoft.com/en-us/library/ms721882(VS.85).aspx

    Если сервис подменяет эту функцию своей, то возможно все. :) Сервис, о котором идет речь, установлен на домен-контроллере?
    Thursday, August 27, 2009 6:39 AM
  • Osr, получается, что хук на Password Filter должен быть как минимум на PDC. Но почему тогда ADUC, со слов автора, следует политике паролей только для избранных пользователей, неужели сервис, видя обращения к созданным им учеткам, перехватив "PasswordChangeNotify" игнорирует "PasswordFilter"?..
    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
    Thursday, August 27, 2009 7:09 AM
  • неужели сервис, видя обращения к созданным им учеткам, перехватив "PasswordChangeNotify" игнорирует "PasswordFilter"?..
    Да, примерно это я имел ввиду. Здесь даже перехватывать PasswordChangeNotify не нужно, если подменена функция PasswordFilter. К сожалению, ничего определенного нельзя сказать, не зная, как работает этот сервис. Во всяком случае, существуют коммерческие решения для Windows Server 2003, дающие возможность использования нескольких политик пароля в домене, и они основаны на добавлении своих фильтров паролей.
    Thursday, August 27, 2009 7:18 AM
  • Сервис, о котором идет речь, установлен на домен-контроллере?  - нет.
    Мне сейчас бы найти какой атрибут пользователя за это отвечает
    Thursday, August 27, 2009 7:19 AM
  • Не на контроллере домена!? Контроллер домена должен быть тоже "подпилен"!

    Атрибут, который отвечает за что?
    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
    Thursday, August 27, 2009 7:37 AM
  • Спасибо. Нашел сам. В первые разы прозевал. В свойсвах юсера есть такой атрибут (см ADSIEDIT)
    userAccountControl - 0X220 = 544 - установленное сервисом  - означает  PASSWD_NOTREQD | NORMAL_ACCOUNT
    userAccountControl - 0x200 = 512 - верное значение - означает  NORMAL_ACCOUNT

    Решено. Всем сбросим в 544 и ок
    Thursday, August 27, 2009 7:48 AM
  • сорри сброшу в 512  :-) разволновался на радостях
    Thursday, August 27, 2009 7:49 AM
  • Да, вот и статья с описанием указанного атрибута

    http://support.microsoft.com/kb/305144/ru
    Thursday, August 27, 2009 7:55 AM