1. Як налагодити управління процесом реєстрації користувачів.
2. Глобальні політики
3. індивідуальні політики
4. «Підкруткою» реєстру

Як налагодити управління процесом реєстрації користувачів.

Рівні безпеки Windows NT можна порівняти з шкіркою цибулини: верхній шар - це численні перевірки, які виконує NT, перш ніж пустити користувача в систему. Якщо не допускати неавторизованої реєстрації користувачів, можна захистити мережу від багатьох потенційних небезпек. Політики реєстрації NT застосовуються в трьох областях.

• Глобальні політики в базі даних SAM. Ці політики охоплюють всіх користувачів бази даних SAM на будь-якому комп'ютері або в домені.
• Індивідуальні політики призначених для користувача облікових записів. Можна встановити свої політики для кожного користувача.
• Значення в реєстрі. Можна вплинути на процес реєстрації користувача за рахунок незначних змін в реєстрі.

Глобальні політики

Глобальні політики дозволяють задіяти парольні політики і блокувати облікові записи, коли NT виявляє спробу вгадати пароль. Ці політики називаються глобальними, оскільки вони зачіпають всі призначені для користувача облікові записи в SAM, до якої адміністратор підключається через User Manager for Domains. Залежно від того, яка база даних SAM редагується, політики можуть задаватися або для всіх користувачів домену, або для локальних облікових записів окремого комп'ютера. Кожна робоча станція NT і кожен автономної сервер NT мають локальну базу SAM, в якій визначаються локальні призначені для користувача облікові записи, дійсні тільки на даному комп'ютері.

Щоб виконати загальні налаштування в облікові записи користувачів, слід відкрити User Manager for Domains і вибрати в меню Policy, Account. На Екрані 1 зображено діалогове вікно Account Policy, яке при цьому з'являється.

У верхній частині вікна має стояти слово Computer - це означає, що робота ведеться з локальної SAM певного комп'ютера. Якщо нагорі стоїть Domain, значить, адміністратор працює з доменної SAM.

Налаштування параметрів Password Restrictions в діалоговому вікні Account Policy дозволить привчити користувачів до найбільш ефективних методів управління паролями. Налаштування пральних обмежень важлива тому, що користувачі, як правило, відносяться до паролів легковажно. Захист паролів здійснюється трьома способами: необхідно вимагати від користувачів створення важко вгадуються паролів, регулярної зміни паролів і налаштовувати політики блокування облікових записів.

Створення важко вгадуються паролів. Домогтися того, щоб користувачі вигадували важко паролі, що вгадуються, не так складно. Для цього потрібно встановити параметр Minimum Password Length (мінімальна довжина пароля).

У більшості випадків я рекомендую встановлювати мінімальну довжину - сім символів. Більше семи не рекомендується, внаслідок нез'ясованої помилки NT в хешування паролів, якщо тільки не встановлюються всі 14 символів. Якщо вдасться навчити користувачів застосовувати випадкові набори з семи літер, цифр і спеціальних символів, то розгадувати паролі буде нелегко. Однак установка мінімальної довжини пароля не гарантує, що придумані паролі будуть важко угадиваеми, оскільки користувачі можуть просто повторити одну і ту ж букву або цифру сім разів. Щоб паролі були дійсно надійними, потрібно використовувати парольний фільтр, наприклад утиліти Passfilt або Passprop з пакету Microsoft Windows NT Server 4.0 Resource Kit. Обидві програми вимагають, щоб користувачі створювали паролі, які включають комбінації букв верхнього та нижнього регістру, цифр і спеціальних символів.

Не слід обмежуватися тільки вимогою створення важко вгадуються паролів. Необхідно також супроводжувати його написанням політик, які демонструють забезпечення вимоги на рівні управління, проведенням сеансів навчання, під час яких користувачі дізнаються, як вибирати і запам'ятовувати складні паролі, і, нарешті, виконанням щомісячного або щоквартального аудиту паролів за допомогою якої-небудь утиліти, наприклад L0phtCrack 4.0 (LC4) компанії @stake. Щоб у користувачів не було спокуси записувати паролі, можна навіть вдатися до установки правил користування технікою. У цих правилах повинні бути задокументовані внутрішньокорпоративні вимоги до використання комп'ютерів. Такі правила також забезпечують законодавчо обґрунтований вихід з положення (звільнення, відшкодування збитків), якщо хтось їх порушує.

Регулярна зміна паролів. Введення важко вгадуються паролів - тільки один із способів їх захисту. Можна зобов'язати користувачів міняти паролі регулярно, цей захід безпеки важлива, оскільки з плином часу паролі можуть бути розгадані, збігтися або виявитися записаними на папері. Буває також, що співробітники, які користуються однією і тією ж обліковим записом, змінюють роботу всередині компанії або звільняються. Я рекомендую, щоб користувачі змінювали свої паролі кожні 90 днів. Коли встановлено параметр Maximum Password Age в діалоговому вікні Account Policy, система NT перевіряє тривалість використання кожного пароля при кожному вході в систему. У міру наближення до встановленої дати NT починає попереджати користувачів про необхідність міняти паролі. За замовчуванням NT виводить на екран повідомлення про час дії пароля за 14 днів до закінчення терміну його дії, а також в подальшому при кожній реєстрації, і так до тих пір, поки користувач не змінить пароль. Можна за допомогою реєстру поміняти проміжок часу до закінчення терміну дії пароля, коли NT починає видавати попередження, але про це пізніше. Однак, навіть якщо встановлений максимальний термін дії пароля, користувачі можуть брати в якості нового пароля старий, ігноруючи, таким чином, політику адміністратора. Уникнути подібної проблеми можна, встановивши параметр Password Uniqueness в діалоговому вікні Account Policy. Коли така політика встановлена, NT пам'ятає попередні паролі користувачів і не допускає повторного введення. Я рекомендую встановлювати максимальне значення даного параметра - пам'ятати 24 пароля. Буває, що користувачі роблять швидку зміну 24 паролів, щоб NT «забула» їх улюблені паролі, і можна було б використовувати ці паролі знову. Щоб захистити систему від такої поведінки, слід встановити параметр Minimum Password Age, після чого користувачі не зможуть змінювати свої паролі протягом зазначеного числа днів. Наприклад, якщо встановити параметр Password Uniqueness в значення «пам'ятати 24 пароля», а Minimum Password Age в значення «дозволити зміну через два дні», то користувачам буде потрібно 48 днів, щоб повернутися до своїх улюблених паролів.

Накладення вищезазначених обмежень - непопулярний захід, вона може змусити деяких користувачів записувати свої паролі. Тому я підкреслюю важливість застосування документованих правил і навчання персоналу.

Якщо необхідно змінити регламент використання паролів в домені, який вже містить багато користувачів, потрібно пам'ятати одне застереження: NT бере до уваги параметри «максимальний термін дії пароля» і «мінімальна довжина пароля», тільки коли адміністратор змінює пароль. Так що ці дві політики не мають зворотної дії на паролі, які в даний час задіяні користувачами домену. Наприклад, припустимо, що в даний момент в мережі є 100 користувачів, і адміністратор змінює параметр «максимальний термін дії пароля» з Password Never Expires ( «Термін дії не обмежений») на Expires In 90 Days ( «Термін дії 90 днів») і чекає один рік. Жоден пароль цих користувачів не вичерпає терміну дії протягом зазначеного часу, за винятком тих користувачів, які поміняють пароль за власною ініціативою або чий пароль буде переустановлений адміністратором. Після того як адміністратор встановить політики Maximum Password Age і Minimum Password Length або скористається утилітами Passprop і Passfilt, користувачі також повинні поміняти свої паролі, щоб ці політики і утиліти вступили в дію. У розділі «Індивідуальні політики» я поясню, як ввести в дію парольні зміни.

Установка політик блокування облікових записів. Третій спосіб захистити паролі під час процедури реєстрації - встановити параметр Account lockout в діалоговому вікні Account Policy. NT блокує призначену для користувача обліковий запис, якщо протягом 24 год відбуваються три поспіль спроби реєстрації в системі з неправильним паролем. Саме три поспіль, оскільки, якщо після двох невдалих спроб проникнення стороннього в системі успішно реєструється справжній власник облікового запису, NT скидає лічильник невдалих спроб. Можна налаштувати систему так, що обліковий запис залишиться заблокованою до тих пір, поки член групи Administrators або Account Operators не розблокує її вручну. Або ж можна зробити так, щоб NT автоматично розблокувала обліковий запис після великого проміжку часу.

Звертаю увагу читачів на два прапорці в нижній частині Екрану 1. Прапорець Forcibly disconnect remote users from server when logon hours expire ( «Примусово припиняти сеанс віддалених користувачів сервера після закінчення робочого часу») визначає, що робити з тими користувачами, які залишаються в системі, після того як сплив відведений їм для роботи час протягом дня. Цей параметр на Екрані 1 відключений, тому що User Manager for Domains звертається до бази даних SAM автономного сервера замість доменної SAM. Бази даних SAM робочих станцій і автономних серверів не підтримують погодинних обмежень, так що в даному випадку наведена функція недоступна.

Параметр Users must log on in order to change password ( «Користувачі повинні зареєструватися в системі, для того щоб поміняти пароль») - дещо незвичний тип політики реєстрації: він визначає, як NT звертається з паролями, у яких закінчився термін дії. За замовчуванням цей параметр відключений; це означає, що, коли користувач реєструється з простроченим паролем, NT вимагає змінити пароль, а потім продовжує процедуру реєстрації. Оцінка ступеня ризику такої установки за замовчуванням залежить від того, наскільки безпечними адміністратор вважає прострочені паролі, оскільки користувачі можуть отримувати доступ до системи ще довго після того, як закінчився термін дії пароля. Якщо встановити прапорець Users must log on in order to change password, NT не дозволить користувачам входити в систему після того, як закінчився термін дії пароля. Проте не слід відразу робити висновок, що потрібно обов'язково включати цей параметр. Використання даного параметра може конфліктувати з іншої популярної політикою реєстрації: параметром User Must Change Password at Next Logon ( «Користувач зобов'язаний змінити пароль при наступній реєстрації») у властивостях користувальницької облікового запису. Припустимо, що адміністратор встановив параметр Users must log on in order to change password в діалоговому вікні Account Policy. Потім користувач просить перевстановити пароль, оскільки він забув його. Коли адміністратор змінює пароль, він включає параметр User Must Change Password at Next Logon у властивостях користувальницької облікового запису, щоб користувач міг вибрати новий пароль. Але коли користувач намагається зареєструватися в системі, щоб поміняти свій пароль, NT блокує доступ, заявляючи, що пароль прострочений. Таким чином, обидва параметри встановлювати не можна.

Потрібно пам'ятати, що парольні обмеження і політики блокування на Екрані 1 - глобальні, т. Е. Все користувачі в домені є суб'єктами одних і тих же політик. Не можна, наприклад, ввести більш складні паролі тільки для адміністраторів, не створюючи нового домену. Щоб вирішувати такі завдання, можна застосовувати індивідуальні політики.

індивідуальні політики

Індивідуальні політики «пересилюють» глобальні політики для даної користувальницької облікового запису. Кожна призначена для користувача обліковий запис має кілька параметрів, які впливають на здатність користувача реєструватися в системі. Адміністратори і оператори облікових записів можуть редагувати ці параметри, виконавши подвійне клацання по облікового запису користувача в User Manager for Domains. На Екрані 2 показано діалогове вікно New User, яке при цьому з'являється.

У діалоговому вікні New User можна змінити пароль користувача, вводячи новий пароль в полях Password і Confirm Password. Можна вказати, що користувач повинен змінити свій пароль при наступній реєстрації, вибравши прапорець User Must Change Password at Next Logon. Як я вже сказав, адміністратори часто встановлюють цю політику, коли перевстановлюють паролі в разі, якщо користувач забув пароль. Такий підхід гарантує, що адміністратори не мають доступу до призначених для користувача облікових записів протягом досить тривалого часу. Однак будь-який бажаючий, маючи права адміністратора, за допомогою програми LC4 може розкривати паролі. Тому краще не встановлювати параметр User Must Change Password at Next Logon, а довіряти адміністраторам і спробувати обмежити число співробітників з таким рівнем повноважень.

Якщо потрібно зберегти контроль над деякими обліковими записами: наприклад, обліковими записами для спільного використання або обліковими записами тих користувачів, які відмовилися вибрати важко вгадуваний пароль, потрібно встановити параметр User Can not Change Password ( «Користувач не може змінювати пароль»). Для тих призначених для користувача облікових записів, які небажано обмежувати максимальним терміном дії пароля на рівні домену, можна встановити параметр Password Never Expires ( «Термін дії пароля не обмежений»). Цей параметр можна також встановити для облікових записів серверних додатків (таких, як Microsoft SQL Server) - це дозволить уникнути досить поширеною ситуації, коли одного разу при перезавантаженні сервера з'ясовується, що ні одна з важливих служб не запускається, оскільки термін дії пароля облікових записів серверних додатків закінчився. На жаль, деякі адміністратори встановлюють параметр Password Never Expires, щоб зробити виняток для окремих впливових користувачів, які не бажають регулярно міняти свої паролі.

Параметр Account Disabled ( «Рахунок заблокована») може застосовуватися для тимчасового захисту облікових записів співробітників, які перебувають у відпустці або відсутніх з інших причин. Якщо адміністратор блокує обліковий запис, NT не дозволяє користувачеві увійти в систему, навіть якщо той знає пароль. Коли користувач залишає компанію, можна не видаляти його обліковий запис негайно, а просто заблокувати її. Збереження облікового запису приблизно на 30 днів дозволяє відтворити об'єкти, до яких мав доступ даний співробітник. Заблоковану обліковий запис в разі повернення співробітника легко відновити.

Можна встановити обмеження по днях тижня і годинах протягом дня, коли користувачеві дозволяється реєструватися в системі. Однак подібну політику не можна назвати дуже практичною. Проте, якщо в компанії є користувачі, які працюють строго певні години (наприклад, касир в банку), можна клацнути Hours і відкрити діалогове вікно Logon Hours. У ньому потрібно просто вибрати часовий проміжок, потім клацнути Allow ( «Дозволити») або Disallow ( «Не дозволяти»). Якщо користувачі намагаються увійти в систему в невстановлений час, NT не дає доступу. Якщо користувачі реєструються під час дозволеного проміжку і залишаються в системі в ті години, коли працювати їм явно не дозволено, за замовчуванням NT дозволяє продовжити сеанс. Для зміни цієї установки за замовчуванням можна скористатися глобальної політикою. У діалоговому вікні Account Policy слід встановити прапорець Forcibly disconnect remote users from server when logon hours expire. Необхідно врахувати, що вибір цього параметра завершує сеанс роботи користувачів з сервером, але не сеанс на їх робочих станціях. Нехай, наприклад, адміністратор дозволив користувачу А входити в систему з 8.00 ранку до 18.00 вечора і встановив параметр Forcibly disconnect remote users from server when logon hours expire. О 9.00 ранку користувач А реєструється на своїй робочій станції і з'єднується з декількома серверами для виконання робіт з файлами і принтерами. Він залишається в системі після 18.00. О 18.00 сервери завершують сеанс даного користувача, але він залишається зареєстрованим на своїй робочій станції. Зауважимо, що після закінчення відведеного проміжку часу сервери відключають тільки неактивних користувачів. Якщо користувачі взаємодіють з серверами (наприклад, мають відкриті файли, звертаються до папок кожні кілька хвилин), то сервери не будуть завершувати сеанси користувачів, незважаючи на тимчасові обмеження.

За замовчуванням NT дозволяє реєстрацію з будь-якої робочої станції. При бажанні можна обмежити число комп'ютерів, з яких користувачі можуть підключатися. Слід клацнути Logon To в діалоговому вікні New User, щоб вивести вікно Logon Workstations, наведене на Екрані 3. Можна вказати до восьми робочих станцій.

Остання політика, что стосується реєстрації и застосовується относительно окремий Користувачів, пов'язана з Датою Закінчення терміну Дії облікового запису. За замовчуванню срок Дії призначення для користувача обліковіх запісів НЕ обмеження. Можна Встановити дату Закінчення терміну Дії облікового запису, клацнувші Account в діалоговому вікні New User и вказано дату у вікні Account Information (див. Екран 4). Встановлення терміну дії облікового запису виправдано для співробітників, що працюють за тимчасовим контрактом, або коли заздалегідь відомо, що користувач покине компанію. Адміністратор просто заздалегідь встановлює певну дату, після чого NT бере турботу про цей обліковий запис на себе. Я знаю адміністраторів, які використовували цю функцію, маючи хронічні проблеми, пов'язані з тим, що їх не попереджали про час відходу співробітників з компанії. Відповідальні адміністратори встановлювали межу в 30 днів для кожного користувача і вимагали від відділу кадрів щомісячного звіту зі списком дійсно працюючих співробітників. На основі поданих списків адміністратори продовжували термін дії облікових записів. В результаті, якщо хтось звільняється, а адміністратора не ставлять до відома про це, NT автоматично закриває обліковий запис через 30 днів.

User Manager for Domains дозволяє змінювати політики реєстрації окремих користувачів для багатьох облікових записів за один крок. Потрібно утримувати клавішу Ctrl, клацаючи по облікових записів користувачів, які потрібно змінити. Потім слід вибрати User, Properties і внести зміни. Ця можливість виявляється до речі, коли необхідно встановити параметр User Must Change Password at Next Logon, щоб ввести в дію нові доменні парольні обмеження.

Переглядаючи локальну базу даних автономного сервера або робочої станції, ви не знайдете політик для окремих користувачів, які я тільки що описав. Функції Logon To, Hours і Account Disabled відсутні. Дана установка доступна лише для доменних облікових записів.

«Підкруткою» реєстру

Крім глобальних і індивідуальних політик для управління процесом реєстрації можна внести зміни в налаштування реєстру в підрозділі HKEY_LOCAL_ MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon. Зокрема, за допомогою налаштувань в реєстрі можна отримувати сповіщення в процесі реєстрації, приховувати імена користувачів в діалоговому вікні реєстрації в системі, а також скорочувати і продовжувати термін дії пароля.

З юридичної точки зору відображення повідомлення в процесі реєстрації дуже важливо. Це повідомлення означає, що користувачі входять в дану систему, і закріплює за адміністратором право стежити за їхніми діями. Ви бажаєте бачити дане попередження до того, як користувачі вводять свої облікові дані. Воно створюється додаванням двох значень типу REG_SZ в підрозділі Winlogon. У записі LegalNoticeCaption необхідно додати коротку рядок, яку NT буде відображати в заголовку вікна попередження. У записі LegalNoticeText потрібно додати повний текст, який слід отримати в юридичному відділі. Коли ці значення задані, NT відображає повідомлення при кожному натисканні користувачем Ctrl + Alt + Del під час входу. Користувач повинен виконати клацання мишею, перш ніж NT дозволить ввести ім'я та пароль.

Під час реєстрації NT автоматично заповнює поле Username в діалоговому вікні ім'ям останнього зареєстрованого користувача. Якщо ця настройка за замовчуванням ризикована в конкретному середовищі, можна зробити так, щоб поле було порожнім, змінюючи значення параметра DontDisplayLastUserName типу REG_SZ на 1.

Як вже зазначалося вище, NT починає виводити повідомлення про закінчення терміну дії пароля за 14 днів до цієї дати. Якщо потрібно скоротити або збільшити час перед закінченням терміну дії пароля, коли NT починає попереджати користувачів, можна змінити значення параметра PasswordExpiryWarning типу REG_DWORD з 14 на бажане число днів.

Необхідно виконати описані настройки реєстру на комп'ютері кожного користувача. Якщо машин багато, для цієї мети можна скористатися редактором системних політик System Policy Editor (SPE). SPE дозволяє поширити зміни в реєстрі на кожен комп'ютер домену з центральної бази даних. SPE також можна використовувати для застосування обмежень, які захищають робочі станції після того, як користувач зареєструвався в системі. Наприклад, адміністратор може розгорнути на настільних комп'ютерах користувачів хранитель екрану з паролем і заборонити його відключення.

Щоб захистити свою мережу від безлічі ризиків, потрібно, перш за все, не допускати несанкціонованого доступу користувачів. Застосування глобальних, індивідуальних і реєстрових політик дозволяє надійно охороняти вхід в домен.

Ренді Франклін Сміт - редактор Windows & .NET Magazine і президент компанії Monterey Technology Group, яка займається навчанням і консалтингом в області захисту Windows NT. Зв'язатися з ним можна за адресою: [email protected] .