Створення локальних користувачів та політик паролів через PowerShell

February 26, 2026 • February 26, 2026 • Читання: 4 хв • Views: 0

Було корисно?

Локальні облікові записи — це таргани корпоративної ідентифікації: навіть коли здається, що ви їх усунули,
вони з’являються в темних куточках «тимчасових» серверів, лабораторних машин, які підняли до продакшену, та пристроїв з
Windows під капотом.

Біль проявляється о 2-й ночі, коли сервісний обліковий запис спливає термін дії, інсталятор потай створив локального адміністратора,
або сканер безпеки питає, чому PasswordLastSet — «Never». PowerShell може це виправити — якщо використовувати його як оператор,
а не як особа, яка копіює й вставляє фрагменти в живий сервер з пітними руками.

Що ви насправді керуєте (і чому це постійно підводить)

«Локальний користувач» звучить просто: ім’я користувача і пароль, збережені на машині Windows. Але операційно
ви керуєте трьома перетинними системами:

Об’єкт облікового запису (включений/відключений, стан пароля, членство в групах, профіль, права).
Поверхня політики автентифікації (довжина пароля, складність, поріг блокування, термін дії).
Радіус ураження (де цей обліковий запис працює і що він може робити).

Локальні користувачі — загроза надійності, тому що вони «липкі». Вони переживають проєкти.
Вони переживають міграції. Вони не відображаються в центральній панелі IAM. І коли у вас більше кількох серверів,
«ми не забудемо змінити цей пароль» стає казкою перед аудиторами.

Завдання — не «створити користувача». Завдання: створити користувача, який є передбачуваним, виявлюваним, підконтрольним і відновлюваним.
Передбачуваність означає послідовні імена, послідовне членство в групах, послідовні правила паролів. Виявлюваність означає,
що ви можете провести інвентаризацію й пояснити, чому він існує. Підконтрольність означає, що політики застосовуються (або принаймні вимірюються).
Відновлюваність означає, що ви можете безпечно відключити обліковий запис без руйнувань сервера.

Якщо ви думаєте «це занадто багато для локальних користувачів», вітаю: ви ніколи не відповідали на розслідування латерального руху,
де улюбленими обліковими даними зловмисника був локальний пароль адміністратора, спільний на 700 машинах.

Факти та історичний контекст для аргументів

Інженери люблять факти, які можна використати на нарадах. Ось кілька корисних тез, коли в кімнаті починаються суперечки про «лише локальний акаунт».

Windows має локальні облікові записи з часів NT — і багато налаштувань безпеки були розроблені, коли мережі були менші й більш плоскі.
Спадщина досі формує поведінку.
MMC оснастка «Local Users and Groups» не завжди була доступна на всіх редакціях (особливо відсутня в деяких виданнях), тому
скрипти і net.exe стали лінгвофранкою автоматизації адміністрування.
За замовчуванням політика паролів не персональна. На автономних машинах це здебільшого політика на рівні машини; на комп’ютерах у домені
зазвичай перемагає політика домену, якщо не застосовані тонкі політики або локальні винятки.
Модуль LocalAccounts PowerShell (команди типу New-LocalUser) з’явився відносно пізно у порівнянні з ерою адміністрування Windows.
Старі скрипти використовують ADSI або net user, бо раніше не було вибору.
Політика блокування облікового запису — це важіль надійності, не лише безпеки. Надто сувора — ви самі собі DoS з-за сервісів із частими помилками;
надто м’яка — brute-force стає хобі.
«Пароль ніколи не спливає» — це не просто прапорець; це заява, що ви прийняли необмежений термін життя облікових даних.
Це потребує компенсувальних контролів (система ротації, LAPS, сховище з видачею, тощо).
Членство у групах — реальна модель дозволів для більшості адміністраторів. Об’єкт користувача нудний; вогонь — у групах.
Windows утримує кілька джерел істини для налаштувань безпеки (локальна політика безпеки, політика в реєстрі, політика домену, обробка GPO).
Ваш скрипт може «встановити» щось і все одно програти на наступному оновленні політик.
Вбудовані облікові записи поводяться інакше. «Administrator» і «Guest» мають спеціальну обробку і історичний багаж; перейменування не знімає ідентичність.

Основні інструменти: LocalAccounts, ADSI, net.exe, secedit

Існує чотири практичні способи керувати локальними користувачами та політикою паролів у автоматизації Windows. Ви використовуватимете всі
залежно від версії ОС, обмежень віддаленого доступу та глибини необхідного втручання.

1) Модуль PowerShell LocalAccounts

Команди на кшталт Get-LocalUser, New-LocalUser, Add-LocalGroupMember читабельні та відносно безпечні.
Вони чудово підходять для сучасних збірок Windows Server і Windows 10/11. Також роблять помилки більш зрозумілими.

2) ADSI (провайдер WinNT)

Старий, але надійний. Працює, коли LocalAccounts недоступний. Також корисний для сумісності в змішаних парках.
Недолік: не такий дружний; один-рядковий трюк може зробити лихо, і ви помітите це лише коли продакшен почне кульгати.

3) net.exe (`net user`, `net localgroup`, `net accounts`)

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

4) secedit (експорт/імпорт локальної політики безпеки)

Коли потрібно переглянути або застосувати опції безпеки на рівні машини масово, secedit може експортувати політику у файл стилю INF.
Ви можете зберігати цей файл у системі контролю версій, дифувати його та застосовувати. Це не красиво, але чесно.

Одна перефразована ідея, яка керувала операціями десятиліттями: перефразована ідея «Hope is not a strategy» — Ed Yourdon.
Локальні облікові записи — це місце, куди надія йде на пенсію. Ставтеся до них як до будь-якої іншої робочої поверхні.

Принципи оператора: вирішіть спочатку, потім скриптуйте

Скрипти, які керують користувачами, виходять з ладу з банальних причин: обліковий запис уже існує, машина приєднана до домену, політика паролів
застосовується через GPO, WinRM напівналаштовано, або оператор не має локальних прав адміністратора. Тож не починайте з коду. Розпочніть з вирішення:

Намір: Для чого цей локальний акаунт існує? Аварійний доступ людини? Сервіс додатка? Підтримка вендора?
Обсяг: Які машини? Який OU? Які середовища?
Влада: Хто відповідає за життєвий цикл облікових даних? Сховище? Команда? Платформена служба?
Контроли: Закінчення терміну, блокування, аудит, обмеження членства, заборона інтерактивного входу де можливо.
Відновлюваність: Яка процедура відключення? Які сповіщення спрацьовують, якщо він зникне?

І так, ви можете автоматизувати все це. Пастка — автоматизувати неправильні припущення швидше.

Жарт №1: Якщо ваш «тимчасовий локальний адмін» старший за вашу кавоварку, він не тимчасовий — це викопний об’єкт із привілеями.

Практичні завдання (команди, виводи, рішення)

Найшвидший шлях стати хорошим у цьому — виконувати реальні, інспектовані операції та прив’язувати кожен вивід до рішення.
Нижче завдання, які ви справді виконуватимете в продакшені. Команди показані так, ніби виконуються в shell на хості.
Адаптуйте імена хостів і шляхи під своє середовище.

Завдання 1: Підтвердьте ОС і збірку (бо доступність командлетів важлива)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows Server 2022 Datacenter 21H2           20348

Що це означає: Ви на сучасній збірці сервера; модуль LocalAccounts зазвичай присутній.
Рішення: Віддавайте перевагу Get-LocalUser/New-LocalUser замість ADSI/net-парсингу.

Завдання 2: Перевірте наявність модуля LocalAccounts

cr0x@server:~$ powershell -NoProfile -Command "Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts | Select-Object Name, Version"
Name                               Version
----                               -------
Microsoft.PowerShell.LocalAccounts 1.0.0.0

Що це означає: Командлети доступні локально.
Рішення: Використовуйте їх для CRUD облікових записів; повертайтеся до ADSI лише у крайніх випадках.

Завдання 3: Інвентаризуйте існуючих локальних користувачів і їх прапори паролів

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordRequired, PasswordExpires, LastLogon | Format-Table -Auto"
Name               Enabled PasswordRequired PasswordExpires LastLogon
----               ------- ---------------- -------------- ---------
Administrator      False   True             False
DefaultAccount     False   False            False
Guest              False   False            False
svc_backup         True    True             True           1/21/2026 3:12:09 AM
vendor_support     True    True             False          12/11/2025 10:44:18 AM

Що це означає: У вас вже є принаймні два небудовані облікові записи; один не спливає.
Рішення: Вирішіть, чи vendor_support має бути обмежений у часі або відключеним, коли не використовується. «Never expires» потребує компенсувальних контролів.

Завдання 4: Створіть новий локальний користувач без збереження пароля у відкритому вигляді

cr0x@server:~$ powershell -NoProfile -Command "$pw=Read-Host -AsSecureString 'Enter password'; New-LocalUser -Name 'svc_app' -Password $pw -Description 'App service account' -PasswordNeverExpires:$false -UserMayNotChangePassword:$true"
Enter password: ********

Що це означає: Обліковий запис створено; пароль збережено як SecureString.
Рішення: Негайно встановіть членство в групах і права; не лишайте сервісний обліковий запис без мінімальних дозволів.

Завдання 5: Перевірте властивості облікового запису, які вам важливі

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser -Name 'svc_app' | Select-Object Name, Enabled, UserMayChangePassword, PasswordExpires, PasswordLastSet | Format-List"
Name                  : svc_app
Enabled               : True
UserMayChangePassword : False
PasswordExpires       : True
PasswordLastSet       : 2/5/2026 1:03:27 PM

Що це означає: Цей обліковий запис не може змінювати свій пароль, і для нього увімкнено закінчення терміну дії.
Рішення: Покладіть ротацію паролів під контрольований механізм (сховище + запланована ротація, або кероване рішення), а не «хтось запам’ятає».

Завдання 6: Додайте обліковий запис до локальної групи (і перевірте)

cr0x@server:~$ powershell -NoProfile -Command "Add-LocalGroupMember -Group 'Users' -Member 'svc_app'; Get-LocalGroupMember -Group 'Users' | Select-Object Name | Sort-Object Name | Select-Object -First 10"
Name
----
BUILTIN\Administrator
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
SERVER01\svc_app

Що це означає: Обліковий запис — стандартний користувач, не адміністратор.
Рішення: Тримайте його таким, якщо тільки ви не можете довести, що додатку потрібні права адміністратора. «Потрібно admin» часто означає «ніхто не перевіряв дозволи».

Завдання 7: Аудит членства в локальній групі Administrators (група, яка зіпсує вам тиждень)

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Administrators' | Select-Object ObjectClass, Name, PrincipalSource | Format-Table -Auto"
ObjectClass Name                          PrincipalSource
----------- ----                          ---------------
User        SERVER01\Administrator         Local
Group       CONTOSO\Domain Admins          ActiveDirectory
User        SERVER01\vendor_support        Local

Що це означає: Локальний користувач вендора має права адміністратора. Це априорі високоризикові облікові дані.
Рішення: Якщо потрібен доступ вендора, перейдіть на доступ, обмежений у часі (увімкнення/відключення за вимогою), ротацію пароля після використання або видаліть із групи Administrators.

Завдання 8: Відключіть обліковий запис без видалення (відновлюваність — це фіча)

cr0x@server:~$ powershell -NoProfile -Command "Disable-LocalUser -Name 'vendor_support'; Get-LocalUser -Name 'vendor_support' | Select-Object Name, Enabled"
Name           Enabled
----           -------
vendor_support False

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

Завдання 9: Знайдіть, де посилаються на обліковий запис (заплановані завдання — часті порушники)

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object {$_.Principal.UserId -match 'svc_app|vendor_support'} | Select-Object TaskName, State, @{n='UserId';e={$_.Principal.UserId}} | Format-Table -Auto"
TaskName           State  UserId
--------           -----  ------
NightlyBackup      Ready  SERVER01\svc_app

Що це означає: svc_app використовується запланованим завданням; його відключення зламає цю роботу.
Рішення: Розглядайте обліковий запис як частину графа залежностей додатка. Ротуйте уважно; тестуйте виконання завдання після змін.

Завдання 10: Швидко перегляньте ефективну політику паролів і блокувань (net accounts)

cr0x@server:~$ powershell -NoProfile -Command "net accounts"
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          60
Minimum password length:                              14
Length of password history maintained:                24
Lockout threshold:                                    5
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15
Computer role:                                        WORKSTATION
The command completed successfully.

Що це означає: Ця машина очікує паролі 14 символів, термін дії 60 днів, блокування після 5 невдалих спроб.
Рішення: Сервісні облікові записи з ризиком інтерактивного входу слід обмежувати; якщо вони мають існувати, переконайтеся, що ви не спричините блокувань через застарілі збережені креденшіали.

Завдання 11: Змініть налаштування політики паролів (де це дозволено) за допомогою net accounts

cr0x@server:~$ powershell -NoProfile -Command "net accounts /minpwlen:16 /maxpwage:45 /uniquepw:24 /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15"
The command completed successfully.

Що це означає: Локальна політика оновлена — якщо її не перевизначить доменний GPO.
Рішення: На машинах у домені розглядайте це як діагностичний інструмент, а не механізм забезпечення політики. Якщо GPO перезаписує, ваша «зміна» зникне.

Завдання 12: Перевірте стан приєднання до домену (джерело політики має значення)

cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance Win32_ComputerSystem).PartOfDomain"
True

Що це означає: Імовірно застосовуються політики домену.
Рішення: Не припускайте, що локальні команди політики паролів закріпляться; перевіряйте остаточну політику та пріоритет GPO.

Завдання 13: Експортуйте локальну політику безпеки у файл для дифу

cr0x@server:~$ powershell -NoProfile -Command "secedit /export /cfg C:\Windows\Temp\secpol.cfg /areas SECURITYPOLICY"
The task has completed successfully.
See log %windir%\security\logs\scesrv.log for detail information.

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

Завдання 14: Витягніть значення політики паролів з експортованого конфігу

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path C:\Windows\Temp\secpol.cfg -Pattern 'MinimumPasswordLength|MaximumPasswordAge|PasswordComplexity|LockoutBadCount' | ForEach-Object {$_.Line}"
MinimumPasswordLength = 14
MaximumPasswordAge = 60
PasswordComplexity = 1
LockoutBadCount = 5

Що це означає: Увімкнено складність (1), мінімальна довжина 14, макс. вік 60, блокування при 5.
Рішення: Якщо сканери нарікають, ви можете довести, що саме налаштовано. Якщо конфігурації відрізняються між вузлами в кластері, спочатку виправте узгодженість.

Завдання 15: Встановіть «Password never expires» для конкретного локального користувача (зімні причини, не байдуже)

cr0x@server:~$ powershell -NoProfile -Command "Set-LocalUser -Name 'svc_backup' -PasswordNeverExpires $true; Get-LocalUser -Name 'svc_backup' | Select-Object Name, PasswordExpires"
Name       PasswordExpires
----       --------------
svc_backup False

Що це означає: Обліковий запис більше не спливає.
Рішення: Роби це лише коли маєте надійну ротацію в іншому місці (керована сховищем, запланована оновлення + план перезапуску сервісів, або кероване рішення). Інакше ви міняєте прості збої на витік доступу.

Завдання 16: Знайдіть застарілі локальні облікові записи (остання активність старша за N днів)

cr0x@server:~$ powershell -NoProfile -Command "$cutoff=(Get-Date).AddDays(-90); Get-LocalUser | Where-Object {$_.Enabled -and $_.LastLogon -and $_.LastLogon -lt $cutoff} | Select-Object Name, LastLogon | Sort-Object LastLogon"
Name           LastLogon
----           ---------
svc_legacy     10/2/2025 11:18:44 AM
vendor_support 11/3/2025 8:20:01 AM

Що це означає: Увімкнені облікові записи не входили 90 днів.
Рішення: Кандидати на відключення, але спочатку перевірте заплановані завдання, служби та конфігурації «run as». Застарілий не завжди означає невикористовуваний — але часто так.

Завдання 17: Перевірте служби Windows на залежності «Log On As»

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Service | Where-Object {$_.StartName -match 'svc_app|svc_backup'} | Select-Object Name, State, StartName | Format-Table -Auto"
Name           State   StartName
----           -----   ---------
AppWorker      Running .\svc_app
BackupAgent    Running .\svc_backup

Що це означає: Ці облікові записи прив’язані до запущених служб.
Рішення: Будь-яка зміна пароля вимагає скоординованого оновлення облікових даних служби (і, бажано, вікна перезапуску). Інакше — інцидент власноруч.

Завдання 18: Експортуйте інвентар локальних користувачів у CSV для централізованого перегляду

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordExpires, PasswordLastSet, LastLogon, Description | Export-Csv -NoTypeInformation C:\Windows\Temp\local-users.csv; Get-Item C:\Windows\Temp\local-users.csv | Select-Object Name, Length"
Name            Length
----            ------
local-users.csv 924

Що це означає: У вас тепер є невеликий артефакт, який можна імпортувати в пайплайн інвентаризації.
Рішення: Нормалізуйте «відомо хороше» та сповіщайте про зміни. Дрейф облікових записів — це сигнал, а не фоновий шум.

Реальність політики паролів у Windows (локально vs домен)

Політика паролів — це місце, куди добрі наміри тихо зникають. Ключова деталь: на автономній хості
«політика паролів» — це здебільшого одна політика на рівні машини, застосована до локальних облікових записів. На хості, приєднаному до домену,
зазвичай контролює те, що застосовує домен, і локальні налаштування можуть не мати значення.

Що ви можете надійно контролювати локально

Існування та стан локального користувача: створення, відключення, перейменування (обережно), опис, прапори.
Членство в локальних групах: хто в Administrators, Remote Desktop Users тощо.
Деякі машинні налаштування пароля/блокувань на автономних машинах або там, де GPO дозволяє.
Прапор закінчення терміну для конкретного користувача (PasswordNeverExpires) для локальних облікових записів.

Що вас здивує, якщо ви не протестуєте

Перезапис доменним GPO: ви встановили мінімальну довжину 16 локально, GPO каже 14, і після оновлення політики ви повертаєтесь до 14.
Ваш скрипт «працював», але програв у питанні керування.
Різне застосування для різних типів облікових даних: сервісні входи, заплановані завдання, RDP-входи та доступ по SMB можуть завершуватися різними помилками.
Обліковий запис існує, але контекст автентифікації змінює режим помилки.
Блокування через кешовані старі паролі: ви ротуєте пароль, але сервіс продовжує намагатися з старим паролем кожну хвилину й блокує обліковий запис.

Жарт №2: Політики паролів як парасолі — усі погоджуються, що вони потрібні, поки не попросять їх носити під дощем.

Сильна думка: перестаньте «ручне керування» локальними паролями адміністраторів

Якщо ваше середовище достатньо велике, щоб виправдовувати скрипт, воно достатньо велике, щоб виправдовувати централізоване управління.
Для локальних адмінів ви хочете унікальні паролі на хост і автоматичну ротацію. Люди непослідовні,
а нападники люблять послідовність.

Якщо вам потрібні локальні адміни для аварійного доступу, використовуйте операційний рунабук: контрольоване оформлення, коротка дія,
ротація після використання та моніторинг змін членства. Мета не «ідеально». Мета — «не соромно».

Три корпоративні міні-історії з практики

Інцидент, спричинений хибним припущенням: «локальна політика застосовується всюди»

Платформна команда запустила PowerShell-завдання, щоб «зміцнити» автономні Windows-машини для виробничої лінії.
Скрипт встановив мінімальну довжину пароля та поріг блокування через net accounts. Він пройшов без помилок. Усі заспокоїлися.

Через місяць інша команда приєднала половину цих хостів до домену, щоб увімкнути централізоване патчування та інвентаризацію.
Платформній команді ніхто про це не сказав, бо приєднання було «просто невелике покращення».

Потім лінія почала падати по-іншому: сервісний обліковий запис, який роками працював стабільно, почав блокуватися.
Сервіс використовував локальний користувач, пароль якого людина оновлювала вручну на одній машині й розповсюджувала «для зручності».
На щойно приєднаних вузлах спрацювала суворіша доменна політика блокування. Сервіс повторно намагався з застарілим паролем, заблокувався,
і лінія зупинилася.

Постмортем мав одне важливе речення: вони припустили, що локальна політика є авторитетною.
Виправлення також було в одному реченні: визначати статус приєднання до домену, вимірювати фактичну політику і трактувати ротацію паролів як систему, а не ритуал.

Оптимізація, яка відкинула назад: «Давайте ротуємо все щодня»

Ініціатива безпеки вимагала частої ротації паролів. Команда, яка це робила, захотіла допомогти і зробила нічну задачу ротації.
Вона оновлювала паролі локальних сервісних облікових записів і намагалася «полагодити» вплив на служби, встановлюючи нові облікові дані й перезапускаючи їх.

Тиждень це виглядало блискуче. Графіки віку паролів впали. Панелі відповідності підросли. Команду почали запрошувати на більше нарад,
що ніколи не винагорода, але часто сприймається як така.

Потім прийшов Patch Tuesday. Декілька серверів перезавантажувалися повільніше, і робота ротації перекривалася зі стартом служб.
Частина служб отримала оновлені облікові дані під час ініціалізації, потім перезапустилася ще раз. Деякі служби не люблять перезапусків під час ініціалізації.
Декілька перейшли в стан помилки й там залишилися. Моніторинг засвітився як святкова ілюмінація.

Проблема була не в самій ротації; вона була у зв’язуванні: зміни паролів і перезапуски відбувалися в нестабільний вікно запуску,
без перевірок стану додатків.
Виправили це, додавши вікна обслуговування, валідацію, специфічну для сервісів, і ротацію рідше, але безпечніше.
Відповідність погодилася на компроміс, бо простій — теж проблема безпеки.

Нудна, але правильна практика, яка врятувала ситуацію: «спочатку інвентар, потім зміни»

Інша команда мала звичку, яка здавалася болісно повільною: перед будь-якою зміною локальних облікових записів вони запускали скрипт інвентаризації, який експортував:
локальних користувачів, членство в групах, ідентифікатори входу служб і принципали запланованих завдань. Кожен запит на зміну містив диф.

Коли вендор попросив локального адміна «для налагодження», команда створила виділений обліковий запис, за замовчуванням відключений, і задокументувала
його потрібне членство й поведінку терміну дії. Вони вмикали його лише під час сесій вендора.

Місяці потому внутрішній скан відповіді на інциденти помітив цей обліковий запис як «присутній адмін». Швидка реакція іншої команди була видалити його миттєво.
Дифф інвентаря їх врятував: він показав, що обліковий запис відключений і не входив від останньої сесії вендора.
Також були перераховані три заплановані завдання, які посилалися на цей username — але ці завдання теж були відключені і прив’язані до старого ангажементу.

Команда відключила заплановані завдання назавжди, видалила обліковий запис із Administrators і тримала його відключеним як маркер ідентичності до завершення контракту.
Ніяких збоїв, ніякої драми, ніяких несподіваних відмов у найгірший час. Нудна практика перемогла.

Швидка методика діагностики

Коли «локальні користувачі/політика паролів» ламаються, це зазвичай відбувається в одному з трьох місць: стан ідентичності, застосування політики або використання залежностей.
Ось як швидко знайти вузьке місце без танців у Event Viewer.

По-перше: підтвердіть, з чим маєте справу (автономна vs доменна, доступні командлети)

Перевірте приєднання до домену: (Get-CimInstance Win32_ComputerSystem).PartOfDomain
Перевірте збірку ОС: Get-ComputerInfo
Перевірте модуль LocalAccounts: Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts

Чому: Це визначає, чи локальні зміни політики справді матимуть ефект і який шлях автоматизації надійний.

По-друге: інспектуйте стан об’єкта облікового запису

Чи увімкнений він? Get-LocalUser -Name X | Select Enabled
Прапори пароля: PasswordExpires, PasswordLastSet, UserMayChangePassword
Членство в групах: Get-LocalGroupMember -Group Administrators

Чому: «Login failed» часто означає «обліковий запис відключено» або «немає потрібної групи», а не «неправильний пароль».

По-третє: ідентифікуйте, що використовує ці креденшіали

Служби: Get-CimInstance Win32_Service | Where StartName -match X
Заплановані завдання: Get-ScheduledTask | Where Principal.UserId -match X

Чому: Змінити пароль легко; змінити всіх споживачів — там народжуються відмови.

По-четверте: валідуйте застосування політики (що фактично діє)

net accounts для поточного локального вигляду
secedit /export щоб зафіксувати стан політики і порівняти між хостами

Чому: Якщо GPO перезаписує зміни, потрібно правити джерело істини, а не симптом.

Типові помилки: симптом → корінь → виправлення

1) «Мій скрипт встановив мінімальну довжину пароля, але це не змінилося»

Симптоми: net accounts показує старі значення через деякий час; сканер безпеки все ще повідомляє про попередні налаштування.
Корінь: Домашній GPO перевизначає локальну політику; або коробка керована базовими налаштуваннями безпеки.
Виправлення: Підтвердіть статус приєднання до домену, потім внесіть зміни в шар, який керує політикою. Локально — вважайте зміни ефемерними, якщо ви не контролюєте GPO.

2) «Обліковий запис успішно створено, але вхід не вдається»

Симптоми: Користувач існує, увімкнений, але не може ввійти через RDP/SMB/інтерактивно.
Корінь: Відсутні права (наприклад, не в Remote Desktop Users), локальна політика безпеки забороняє вхід,
або обліковий запис примушено змінити пароль при першому вході і цього не можна зробити в даному контексті.
Виправлення: Перевірте членство в групах і локальні призначення прав; для сервісних облікових записів уникайте інтерактивного входу.

3) «Сервіс почав падати після ротації пароля»

Симптоми: Служба не стартує; журнали подій показують помилку входу; заплановане завдання повертає 0x52e (помилковий пароль).
Корінь: Пароль змінено, але не оновлено для споживача (служба/завдання); або перезапуск не відбувся.
Виправлення: Знайдіть усіх споживачів (служби + завдання), оновіть облікові дані, потім перезапустіть у контрольованому вікні. Перевірте стан після.

4) «Обліковий запис постійно блокується»

Симптоми: Події блокування; повторні невдалі автентифікації; обліковий запис розблоковується і знову блокується швидко.
Корінь: Якийсь процес досі використовує старі креденшіали (служба, завдання, змонтований диск, закешований логін).
Виправлення: Ідентифікуйте всіх споживачів, оновіть їх, потім скиньте блокування. Якщо не знайдете — тимчасово відключіть обліковий запис і дивіться, що зламається.

5) «Get-LocalUser каже, що LastLogon порожній, тому я не можу визначити використання»

Симптоми: LastLogon порожній для деяких облікових записів хоча ви підозрюєте активність.
Корінь: LastLogon не завжди заповнюється для всіх типів автентифікації, і це не повний аудит.
Виправлення: Для визначення використання використовуйте журнали подій/налаштування аудиту, а інвентаризація залежностей (служби/завдання) — надійніший сигнал.

6) «Ми перейменували Administrator; нападники все одно його знаходять»

Симптоми: Засоби безпеки все ще ідентифікують вбудованого адміна; аудити все ще посилаються на нього.
Корінь: Вбудований обліковий запис ідентифікується за SID (RID 500), а не лише за іменем.
Виправлення: Перейменуйте, якщо політика вимагає, але також відключайте, де можливо, використовуйте LAPS/унікальні паролі та моніторте активність RID 500.

7) «Наша автоматизація виконана, але деякі сервери не змінилися»

Симптоми: Флот має непослідовні локальні користувачі/політики; на деяких вузлах додаткові адміністи.
Корінь: Збої віддаленого доступу, проблеми з правами або скрипти, які не перевіряють результат (вони припускають успіх).
Виправлення: Робіть скрипти ідемпотентними і перевіряйте стан після кожної дії; експортуйте інвентар і робіть диф; припиняйте прогін, якщо дрейф лишається.

Чеклісти / покроковий план

План A: Створити локальний сервісний обліковий запис із розумними налаштуваннями

Інвентар перед зміною: експортуйте поточних локальних користувачів і членство в Administrators.
Створіть обліковий запис з безпечним методом введення пароля (запит SecureString або введення зі сховища).
Встановіть прапори свідомо: поведінка терміну дії, чи може користувач змінювати пароль, увімкнений/відключений.
Надайте мінімальне членство в групах: почніть з Users; уникайте Administrators.
Прив’яжіть залежності: налаштуйте службу/завдання на використання облікового запису.
Валідація: запустіть службу, виконайте завдання, перевірте журнали, підтвердіть відсутність блокувань.
Документування: поле опису у користувача; додайте власника і призначення; зафіксуйте в інвентарі.

План B: Застосувати політику паролів і блокувань на автономних серверах

Перевірте, чи хост приєднаний до домену. Якщо так — зупиніться і керуйте політикою через GPO.
Використайте net accounts для зчитування поточних налаштувань; експортуйте через secedit для артефакту дифу.
Застосуйте політику через net accounts (або послідовний підхід зі шаблонами безпеки).
Заново прочитайте налаштування і підтвердіть, що вони закріпилися.
Протестуйте створення облікового запису і зміну пароля під новими правилами (не дізнавайтеся про застосування політик під час інциденту).

План C: Безпечний робочий процес відключення/видалення локальних облікових записів

Ідентифікуйте залежності (служби, завдання, «run as»), перш ніж торкатися облікового запису.
Спочатку відключіть обліковий запис; моніторте на предмет збоїв.
Якщо немає збоїв, негайно видаліть з привілейованих груп (Administrators, Remote Desktop Users).
Після періоду спостереження розгляньте видалення — але зберігайте докази того, що було видалено.
Оновіть інвентар і базову конфігурацію, щоб воно не «виросло назад» непоміченим.

План D: Гігієна флоту (те, чого люди уникають)

Стандартизувати конвенції іменування (наприклад, svc_* для сервісів, bg_* для аварійного доступу).
Централізувати інвентар: збирати локальних користувачів, локальних адміністраторів і прапори паролів регулярно.
Сповіщати про зміни членства в Administrators і про створення нових увімкнених локальних користувачів.
Ротувати привілейовані креденшіали через керовану систему; не створювати спільні паролі між хостами.
Проводити щоквартальні огляди «застарілих облікових записів» з доказами залежностей, а не на відчуттях.

Питання та відповіді

1) Чим користуватися: `New-LocalUser` чи `net user`?

Використовуйте New-LocalUser, коли він доступний; це зрозуміліше, і об’єкти легше перевіряти. Зберігайте net user для сумісності і швидкої діагностики.

2) Чи можу я встановити складність пароля для окремого локального користувача?

Не так, як зазвичай мають на увазі. Складність — це частина політики машини/домену, а не поворотний перемикач на рівні користувача.
Ви можете встановити поведінку терміну дії для окремого користувача (наприклад, «ніколи не спливає»), але складність застосовується на рівні політики.

3) Чому моя зміна політики паролів повертається назад?

Тому що щось з вищим пріоритетом володіє нею — зазвичай групова політика домену. Локальні зміни не «провалилися»; вони програли боротьбу за керування.

4) Який найбезпечніший спосіб поводження з локальними акаунтами адміністраторів?

Унікальний пароль для кожного хоста, автоматична ротація і аудит членства. Якщо ви досі копіюєте один пароль між машинами — припиніть.
Це вже не «операції», це «предмет колекції інцидентів».

5) Чи повинні сервісні облікові записи мати термін дії пароля?

Якщо ви можете безпечно ротувати і оновлювати всіх споживачів автоматично — так, термін дії підходить. Якщо ні, вимушене закінчення терміну спричинить відмови.
У такому випадку ставте «ніколи не спливає» лише за умови реальної механіки ротації та моніторингу.

6) Чому відключення локального користувача іноді не фіксує доступ?

Бо доступ може приходити від іншого принципалу (групи домену, іншого локального облікового запису, кешованого токена) або реальна проблема — в авторизації (членство в групі), а не в автентифікації. Перевірте, хто саме входить і звідки.

7) Як довести, яка політика паролів діє на хості?

Використовуйте net accounts для швидкого перегляду і secedit /export для файлу, який можна додати до заявки і дифувати між машинами.
Докази краще за суперечки.

8) Чи можна видаляти локальні облікові записи після демонтажу додатка?

Зазвичай так, але спочатку відключіть і перевірте залежності. Видалення може залишити сиротливі ACL і зламати завдання, про які ніхто не пам’ятав.
Якщо потрібне чисте середовище, зробіть знімок інвентаря перед видаленням.

9) Яка найпоширеніша причина блокувань локального облікового запису після зміни пароля?

Заплановане завдання або служба досі налаштовані з старим паролем. Повторні спроби спричиняють блокування.
Оновіть споживачів або змініть пароль і споживач у одному контрольованому вікні.

Висновок: практичні наступні кроки

Локальні користувачі не є априорі злими. Вони просто зазвичай не керовані за замовчуванням, а «за замовчуванням» — це місце, де надійність отримує удари.
Якщо хочете короткий операційний шлях: інвентар, стандартизація, автоматизація, перевірка і план відкату.

Наступні кроки, які ви можете зробити цього тижня:

Запустіть інвентар Get-LocalUser і членство локальних Administrators по вашому парку серверів; зберіть результати централізовано.
Визначте політику щодо локальних акаунтів: які дозволені, як вони іменуються, як спливають і хто ними володіє.
Реалізуйте сповіщення про зміни членства в локальних Administrators і про створення нових увімкнених локальних користувачів.
Для будь-яких привілейованих локальних акаунтів перейдіть на унікальні паролі на хості та ротацію з аудиторією.
Напишіть рунабук для ротації паролів, який включає: виявлення залежностей, кроки оновлення, перезапуски служб і перевірки працездатності.

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