Системный Администратор Windows
3.15K subscribers
15 photos
2 videos
24 links
🖥️ Windows для системных администраторов: управление, оптимизация, безопасность. Полезные советы, лайфхаки, PowerShell-скрипты, автоматизация и практические решения для работы с серверами и рабочими станциями.

Авторский канал.
Download Telegram
👋 Привет, админы!

Продолжая тему SPN, сегодня расскажу, как отслеживать изменения SPN в AD. Был у меня кейс: один коллега удалил SPN у критического сервера (по ошибке, конечно 😅), и всё — WinRM лег, приложения не коннектятся. Алертов не было. Делать так — нельзя.

🔥 Вот скрипт, который можно повесить на задачу по расписанию. Он проверяет наличие SPN WSMAN/имя_компьютера и шлёт алерт, если он исчез:


$computers = Get-ADComputer -Filter * -Properties ServicePrincipalName
$missingSpn = @()

foreach ($comp in $computers) {
$expectedSpn = "WSMAN/$($comp.Name)"
if (-not ($comp.ServicePrincipalName -contains $expectedSpn)) {
$missingSpn += $comp.Name
}
}

if ($missingSpn.Count -gt 0) {
$body = "На следующих машинах отсутствует SPN WSMAN:`n" + ($missingSpn -join "`n")
Send-MailMessage -To "[email protected]" -From "[email protected]" `
-Subject " Отсутствует SPN WSMAN" -Body $body -SmtpServer "smtp.domain.local"
}


📌 Можно доработать — писать в лог, интегрировать с SIEM, триггерить webhook в Zabbix и т.д. Главное — не терять SPN из виду. Один сбой может стоить кучи нервов.

💬 А ты мониторишь SPN? Или больше полагаешься на ручной аудит/расследование постфактум? Поделись, как у тебя это организовано!

👉 @win_sysadmin
👍6
Media is too big
VIEW IN TELEGRAM
🚀 MEETUPxSPRINT OFFER для инженеров технической поддержки от YADRO

Хочешь узнать, как устроена техническая поддержка в одной из ведущих технологических компаний России? Приходи на онлайн-митап от YADRO! Расскажем, покажем, ответим на любые вопросы — и дадим возможность попасть в команду всего за 3 дня!

🔥 Программа митапа:

✔️ Сервисная служба YADRO: основные ресурсы и направления
Василий Бронников, Руководитель отдела техподдержки решений

✔️ Наши продукты: уникальные характеристики и возможности
Андрей Антоненко, Ведущий инженер техподдержки TATLIN

✔️ Реальные кейсы: как команды решают сложные задачи
Дмитрий Сафонов, Руководитель группы L1-поддержки TATLIN.UNIFIED

🔥 Что тебя ждёт:

Реальные кейсы и инсайты из практики техподдержки
Доклады от инженеров YADRO: продукты, процессы, особенности
Живое общение с командой и ответы на вопросы о работе и технологиях

👨‍💻 А если ты задумываешься о новой работе — у тебя есть возможность быстро попасть в команду YADRO и получить оффер за 3 дня. Для этого нужно пройти короткий тест. Сделать это можно уже сейчас, а также во время или после митапа — выбирай, как тебе удобно (но заявки принимаем до 6 июля).

📌 Тест можно пройти по ссылке.



🗓 26 июня, начало в 19:00 мск, четверг

🌐 ОНЛАЙН

Регистрация на мероприятие

Реклама. ООО "ЭВРОНЕ.РУ". ИНН 3663057399. erid: 2VtzqxHGr6J
Please open Telegram to view this post
VIEW IN TELEGRAM
👋 Привет, админы!

Помнишь, мы говорили про мониторинг SPN? Так вот — одно дело заметить пропажу, а другое — сразу восстановить, пока не прилетели тикеты от пользователей и не начался хаос.

🔥 Вот PowerShell-скрипт, который проверяет наличие SPN WSMAN/имя_компьютера и добавляет его обратно, если нужно:


Import-Module ActiveDirectory

$computers = Get-ADComputer -Filter * -Properties ServicePrincipalName

foreach ($comp in $computers) {
$spn = "WSMAN/$($comp.Name)"

if (-not ($comp.ServicePrincipalName -contains $spn)) {
try {
Write-Host "Восстанавливаю SPN для $($comp.Name)..." -ForegroundColor Yellow
setspn -S $spn $comp.Name
}
catch {
Write-Host " Ошибка для $($comp.Name): $_" -ForegroundColor Red
}
}
}


📌 Советую запускать это от имени учётки с правами на изменение SPN в AD. Можно повесить на планировщик или встроить в CI/CD пайплайн, если сервера поднимаются автоматически.

💡 Плюс: можно логировать в файл или отправлять уведомление при каждом восстановлении — для прозрачности.

💬 А у тебя бывали случаи, когда SPN пропадал и ломал всё? Как автоматизируешь восстановление? Делись кейсами в комментах 👇

👉 @win_sysadmin
🔥4👍21
👋 Привет, админы!

Сегодня разберём неочевидную, но важную тему: кто может изменять SPN в AD — и почему это может быть проблемой. Был у меня случай, когда обычный сервисный аккаунт внезапно “помог” и снёс SPN у пары серверов. Угадайте, сколько времени ушло на восстановление? 🙃

🔍 По умолчанию владельцем SPN является компьютер или учётка, которой принадлежит объект AD. Но если у пользователя есть права Write servicePrincipalName — он может спокойно его менять.

💡 Как проверить, кто может править SPN на конкретном объекте?


# Показываем ACL для объекта
$comp = Get-ADComputer -Identity "server01"
$acl = Get-ACL "AD:\$($comp.DistinguishedName)"
$acl.Access | Where-Object { $_.ActiveDirectoryRights -like "*WriteProperty*" -and $_.ObjectType -eq "bf9679c0-0de6-11d0-a285-00aa003049e2" }


📌 bf9679c0... — это GUID атрибута servicePrincipalName. Всё, что найдено — потенциальные редакторы SPN.

Чтобы ограничить доступ, можно:

* Убрать из ACL лишние делегирования (например, у сервисных аккаунтов).
* Создать отдельную группу SPN-админов, у которой будет право на редактирование, и только у неё.
* Мониторить изменения SPN через Security Event Log или Auditing в AD.

💬 А как ты контролируешь права на SPN? Сталкивался с ситуацией, когда “лишний” доступ ломал Kerberos или WinRM?

👉 @win_sysadmin
👍31👏1
👋 Привет, админы!

Поймал недавно одну неприятную ситуацию на проде — перестали запускаться скрипты PowerShell через Task Scheduler. Причём руками всё работает, а в планировщике — ноль реакции. Думаю, многим знакома такая картина.

🔍 В чём была проблема:
Оказалось, после обновления безопасности Windows один из серверов начал блокировать запуск скриптов из-за политики исполнения (ExecutionPolicy). А в задаче стояло просто powershell.exe -File ..., без указания параметров.

🛠️ Решение простое — всегда явно указывай политику исполнения при запуске из планировщика:


powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\Backup.ps1"


И не забудь, что путь к скрипту должен быть абсолютным, иначе Task Scheduler не найдёт файл, особенно если он запускается от SYSTEM или другого сервиса без профиля.

📌 если нужно логирование — добавь вывод в файл:


powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\Backup.ps1" >> C:\Logs\backup.log 2>&1


💬 А у тебя были случаи, когда планировщик Windows молчал как партизан? Как отлавливаешь такие баги?

👉 @win_sysadmin
👍121
👋 Привет, админы!

Недавно один из серверов начал ругаться на нехватку места на диске. Визуально — всё в порядке, но свободного осталось меньше 1 ГБ. Надо было срочно найти, кто пожрал диск. Делюсь простым, но мощным PowerShell-способом найти самые тяжёлые файлы:

📦 Поиск топ-10 самых больших файлов на диске:


Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue |
Where-Object { -not $_.PSIsContainer } |
Sort-Object Length -Descending |
Select-Object FullName, @{Name="SizeMB";Expression={"{0:N2}" -f ($_.Length / 1MB)}} -First 10


Что делает скрипт:

* Рекурсивно обходит все файлы (-Recurse)
* Отбрасывает каталоги (Where-Object { -not $_.PSIsContainer })
* Сортирует по размеру
* Показывает путь и размер в МБ

📍 Хочешь ограничить область поиска? Просто меняй -Path, например:


-Path "C:\Users", "D:\Temp"


Очень выручает, когда надо быстро понять, где «накапало» мусора — особенно в TEMP, профилях пользователей или логах каких-нибудь нестабильных приложений.


💬 А у тебя есть свой любимый способ находить крупные файлы в Windows? Используешь PowerShell, WinDirStat или что-то кастомное?

👉 @win_sysadmin
👍104🔥4🐳1
👋 Привет, админы!

Сегодня хочу поделиться полезным приёмом из практики hardening Windows — поиск старых и потенциально уязвимых локальных админов.

В некоторых организациях после внедрения GPO или изменений в AD остаются локальные админы, про которых все забыли. А это — отличная лазейка для lateral movement. Особенно если это старые учетные записи с паролями, установленными вручную.

📌 Вот PowerShell-однострочник, который покажет всех локальных админов на машине:


Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource


А если нужно проверить сразу несколько машин, удобно использовать Invoke-Command:


$servers = @("SRV1", "SRV2", "SRV3")
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource
}


📍 Особенно обратите внимание на пользователей с PrincipalSource = "Local". Если такие учетки не используются по делу — удаляйте или отключайте.

Регулярный аудит локальных групп — одна из простейших, но мощных мер для повышения безопасности.

💬 А вы чистите локальных админов вручную или автоматизировали? Может, делаете это через GPO или Ansible/Intune?

👉 @win_sysadmin
👍61
👋 Привет, админы!

Пару дней назад наткнулся на странную ситуацию: на одном из серверов пользователей начало выкидывать из сессий RDP. В логах — «The remote session was disconnected because there are no Remote Desktop License Servers available…». Хотя лицензии были, сервер активирован, всё по канонам.

📌 Причина оказалась банальной: служба Remote Desktop Licensing не стартовала автоматически после перезагрузки. А ведь настроена была как Automatic. Иногда и такое бывает — что-то тормозит при старте, и служба не успевает.

🛠 Решение? Завёл себе скрипт на PowerShell, который проверяет статус нужных RDS-служб и перезапускает их при необходимости:


$services = @(
"TermService", # Remote Desktop Services
"LicenseManager", # Remote Desktop Licensing
"SessionEnv", # Remote Desktop Configuration
"UmRdpService" # Remote Desktop Services UserMode Port Redirector
)

foreach ($service in $services) {
$svc = Get-Service -Name $service -ErrorAction SilentlyContinue
if ($svc.Status -ne 'Running') {
Write-Host "Перезапускаю службу: $($svc.DisplayName)"
Start-Service -Name $service
}
}


Можно засунуть в планировщик с триггером «при запуске системы» — и пусть подстраховывает.

💬 А у вас бывали проблемы с запуском RDS-компонентов? Или, может, делаете аудит служб другим способом? Делитесь опытом!

👉 @win_sysadmin
👍5
👋 Привет, админы!

Недавно на одном из серверов столкнулся с проблемой: служба Windows Update зависала в статусе "Ожидание другого установщика". Перезапуск сервиса не помогал, обновления не ставились, а WSUS-задание висело вечно.

💡 Решение оказалось простым, но неочевидным — кто-то (привет, SCCM или ручной запуск MSI) заблокировал установщик Windows Installer.

📌 Что делать:

1. Проверяем, нет ли зависших процессов установщика:


Get-Process -Name msiexec


2. Если что-то висит — снимаем задачу:


Stop-Process -Name msiexec -Force


3. Чистим временные каталоги обновлений:


net stop wuauserv
Remove-Item -Path "C:\Windows\SoftwareDistribution\Download\*" -Recurse -Force
net start wuauserv


4. И главное — проверяем, не заблокирована ли установка:


Get-WmiObject -Class Win32_Process | Where-Object { $_.Name -like "*msi*" }


Если ничего подозрительного нет — можно запускать установку обновлений повторно.

🧩 В моем случае зависший msiexec.exe не давал поставить ни одно обновление — после его убийства всё пошло как по маслу.

💬 А у вас бывали подобные подвисания с Windows Update? Как решаете — через PowerShell, скрипты или руками? Делитесь!

👉 @win_sysadmin
👍101
👋 Привет, админы!

Сегодня хочу напомнить об одной ветеранской уязвимостиSMBv1. Этот протокол давно пора отправить на пенсию, но до сих пор встречаются сервера и даже новые образы Windows, где он включен. А ведь через него гуляли такие "звезды", как WannaCry и NotPetya.

💡 Проверить, включён ли SMBv1, можно так:


Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol


А вот так его отключить:


Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart


🔥 И если надо автоматизировать проверку и отключение на парке машин — вот скрипт, который можно прикрутить к GPO, Intune или просто прокатить руками:


$computers = Get-Content ".\computers.txt"

foreach ($computer in $computers) {
Invoke-Command -ComputerName $computer -ScriptBlock {
$smb = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
if ($smb.State -eq 'Enabled') {
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Write-Output "$env:COMPUTERNAME: SMBv1 отключен"
} else {
Write-Output "$env:COMPUTERNAME: SMBv1 уже отключен"
}
}
}


📌 Главное — не забудьте про совместимость: если у вас вдруг остались старые принт-серверы или NAS'ы, которые ещё сидят на SMBv1 — сначала обновите их.

💬 А у вас ещё где-то живёт SMBv1? Или вы его давно похоронили? Делитесь в комментах, интересно узнать!

👉 @win_sysadmin
👍9
👋 Привет, админы!

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

🔍 Начал копать — и довольно быстро нашёл виновника: в автозагрузке сидела куча мусора, но особенно отличился один Group Policy скрипт, который пытался смонтировать сетевой ресурс, которого уже не существует.

📌 Чтобы быстро проверить, какие групповые политики срабатывают при входе, и сколько времени они занимают, запустил на клиенте:


Get-WinEvent -LogName Microsoft-Windows-GroupPolicy/Operational |
Where-Object { $_.Id -eq 4016 -or $_.Id -eq 5312 } |
Select-Object TimeCreated, Id, Message | Sort-Object TimeCreated -Descending


🕵️ ID 4016 — начало применения политики,
🕵️ ID 5312 — завершение.

Так можно выловить тормоза и даже понять, какой GPO затягивает загрузку. В моем случае один скрипт отрабатывал почти 90 секунд — удалил его, и всё полетело.

💬 А вы анализируете Group Policy лог? Или предпочитаете сторонние утилиты типа PolicyReporter, AGPM и т.п.? Делитесь своим опытом!

👉 @win_sysadmin
🔥12👍7
👋 Привет, админы!

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

🧩 Суть:
Есть скрипт .ps1, который делает бэкап и отправляет отчёт по почте. Запускаешь вручную — всё отлично. Но через Task Scheduler — тишина, никакой ошибки, ничего не происходит.

🔍 Что помогло выяснить причину:

1. В Action указывал не сам скрипт, а запуск powershell.exe с аргументами:


-ExecutionPolicy Bypass -File "C:\Scripts\Backup.ps1"


2. Обязательно указал "Start in" (рабочую папку), иначе относительные пути внутри скрипта не работали.

3. Заменил powershell.exe на powershell.exe -NoProfile, чтобы избежать подвисаний из-за пользовательского профиля.

4. В General поставил галочку "Run with highest privileges" — без этого не было доступа к сетевым путям и не выполнялись некоторые команды.

💡В итоге: Task Scheduler — штука капризная, особенно с PowerShell. Поэтому всегда логируйте выход скрипта в файл, добавляйте Start-Transcript и Stop-Transcript, и не забывайте про -NoProfile.

📌 Полный пример команды в задаче:


Program/script: powershell.exe
Add arguments: -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\Backup.ps1"
Start in: C:\Scripts


💬 А у вас бывали такие странности с планировщиком задач? Как отлаживаете такие случаи?

👉 @win_sysadmin
👍11🔥51👎1
👋 Привет, админы!

На днях словил интересный инцидент: пользователь жалуется, что не может зайти по RDP — “что-то не так с логином”. На месте оказалось, что учетка была заблокирована из-за перебора пароля. Классика. Но вот откуда попытки?

👀 Чтобы быстро выяснить, кто и откуда брутит учетку, пригодится такой PowerShell-скрипт:


Get-EventLog -LogName Security -InstanceId 4625 -Newest 1000 |
Where-Object { $_.Message -match "Имя учетной записи:\s+USERNAME" } |
Select-Object TimeGenerated, @{Name='IP';Expression={ ($_ .Message -split "Сетевой адрес:\s+")[1] -split "`n" | Select-Object -First 1 }} |
Sort-Object TimeGenerated -Descending


📌 Замените USERNAME на нужную учетку. Скрипт покажет последние неудачные попытки входа и IP-адреса источников. Очень удобно, чтобы отследить атаки или криво настроенные скрипты.

⚠️ И не забудьте — частые 4625 могут означать, что пора подумать о блокировке по IP, включении защиты по учеткам или внедрении fail2ban-аналогов под Windows (например, RdpGuard).

🧩 А вы как боретесь с перебором по RDP? Фаервол, GeoIP, кастомные решения?

👉 @win_sysadmin
👍91
👋 Привет, админы!

Если в домене внезапно начинают сыпаться жалобы вроде «не могу зайти, пароль верный» — один из первых шагов в расследовании: поиск заблокированных аккаунтов.

🔥 Вот простой PowerShell one-liner, который покажет всех заблокированных пользователей в Active Directory:


Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut, LastLogonDate


Эта команда выведет список пользователей, у которых стоит флаг LockedOut. Особенно удобно, если нужно быстро понять масштаб проблемы или найти конкретного "жертву GPO".

📌 А если хочешь сразу разблокировать всех (например, в тестовой среде):


Search-ADAccount -LockedOut | Unlock-ADAccount


⚠️ Но аккуратнее с этим — лучше сначала выяснить почему аккаунты блокируются. Часто причина — забытые пароли в автозапусках, мобильные устройства или сохранённые учётки на старых ПК.

💬 А как вы отслеживаете такие инциденты? Есть любимый способ логирования или используете сторонние решения типа ADAudit Plus?

👉 @win_sysadmin
👍103👎1
👋 Привет, админы!

Давеча пришлось накатить пачку обновлений на десяток серверов. Раньше делал это руками — заходишь, запускаешь sconfig, подтверждаешь... Короче, муторно.

🔥 Теперь использую вот такой PowerShell-скрипт, который делает всё сам:


Invoke-Command -ComputerName (Get-Content "servers.txt") -ScriptBlock {
Install-WindowsUpdate -AcceptAll -AutoReboot
} -Credential (Get-Credential)


Для этого нужен модуль PSWindowsUpdate (ставится через Install-Module PSWindowsUpdate). А список серверов просто сохраняю в servers.txt.

💡 Скрипт:

- скачивает и устанавливает обновления,
- автоматически перезагружает сервер (если нужно),
- работает параллельно по всем указанным хостам.

Теперь обновления ставлю за кофе-паузу, а не за полдня 🙂

💬 А вы как обновляете свои сервера? WSUS, Intune, руками? Поделитесь лайфхаками в комментах!

👉 @win_sysadmin
👍10
👋 Привет, админы!

На днях ловил интересную проблему с GPO. Пользователь жалуется: после перезагрузки пропадают закреплённые приложения на панели задач. Сначала подумал — баг профиля. Но нет, причина оказалась куда изощрённее: групповая политика переустанавливает taskbar layout при каждом входе.

🔍 Если используете XML-модификацию панели задач (через LayoutModification.xml), и она привязана в GPO, то при каждом входе пользователя этот layout применяется заново. В итоге все ручные закрепления — сносятся.

📌 Решение:

1. Если цель — задать стартовую конфигурацию и разрешить пользователям её менять, используйте параметр:


User Configuration → Administrative Templates → Start Menu and Taskbar → Do not use the taskbar layout configured in XML

Установите в Enabled.

2. Или вместо постоянного применения layout — разворачивайте XML один раз с помощью скрипта при создании профиля.

💡 Ещё вариант — вообще отказаться от XML и использовать PowerShell-скрипты для закрепления приложений. Например:


$apps = @(
"Microsoft.Edge",
"Microsoft.Windows.Explorer"
)

foreach ($app in $apps) {
$AUMID = (Get-StartApps | Where-Object { $_.Name -eq $app }).AppID
if ($AUMID) {
(New-Object -ComObject Shell.Application).NameSpace('shell:::{3080F90E-D7AD-11D9-BD98-0000947B0257}').ParseName($AUMID).InvokeVerb('pin to taskbar')
}
}


🧩 Такие нюансы часто всплывают, когда пытаешься автоматизировать «по красоте», а GPO делает всё по-своему.

💬 А вы как настраиваете панель задач в корпоративной среде? Через XML, скрипты или руками?

👉 @win_sysadmin
👍73
👋 Привет, админы!

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

🔥 Вот простой PowerShell для создания пользователей по CSV:


Import-Csv "C:\Scripts\users.csv" | ForEach-Object {
$name = "$($_.FirstName) $($_.LastName)"
$sam = $_.SamAccountName
$ou = "OU=Users,DC=contoso,DC=local"

New-ADUser -Name $name `
-GivenName $_.FirstName `
-Surname $_.LastName `
-SamAccountName $sam `
-UserPrincipalName "$[email protected]" `
-Path $ou `
-AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
-Enabled $true

Add-ADGroupMember -Identity "Domain Users" -Members $sam
}


CSV-шка выглядит так:


FirstName,LastName,SamAccountName
Ivan,Ivanov,i.ivanov
Petr,Petrov,p.petrov


🛡 Конечно, пароль временный — дальше юзер меняет при первом входе. Плюс можно докрутить добавление в разные группы, создание home-директории и т.д.

💬 А как вы автоматизируете ввод новых пользователей? Делаете через PowerShell, сторонние тулзы или вручную? Поделитесь своим способом!

👉 @win_sysadmin
👍191🥱1
👋 Привет, админы!

Сегодня словил интересную ситуацию с Windows Server, которая сначала выглядела как "магия", но в итоге — типичная особенность групповых политик.

🔥 Суть кейса: на нескольких новых машинах автоматически отключался экран через 1 минуту простоя, несмотря на выставленные GPO "никогда не выключать дисплей".

🤨 Что оказалось? Групповая политика исправно настраивала Computer Configuration > Policies > Administrative Templates > System > Power Management, но не трогала "Console lock display off timeout".

Эта настройка по умолчанию скрыта и не отображается в GUI! Но её можно включить в реестр или через GPO, а потом управлять через PowerShell:


powercfg /change monitor-timeout-ac 15


А вот как вывести текущие значения:


powercfg /query SCHEME_CURRENT SUB_VIDEO


💡 Если экран тухнет через минуту после блокировки — проверьте именно Console lock display off timeout. Это не то же самое, что просто "turn off display".

Решение: через GPO включил видимость параметра и задал нужное значение. Проблема ушла.

💬 А у вас бывали случаи, когда политика "применена", но система ведет себя по-своему? Какие грабли были с powercfg и энергосбережением?

👉 @win_sysadmin
👍122
👋 Привет, админы!

Недавно наткнулся на интересный момент при обновлении сертификатов на IIS — думаю, многим пригодится.

🛠 Когда меняешь сертификат вручную через GUI, всё просто. Но если нужно обновить десятки сайтов на одном сервере, то ручками — долго и больно. Решение? Конечно, PowerShell!

Вот скрипт, который автоматически находит и заменяет SSL-сертификат по thumbprint на всех сайтах в IIS:


Import-Module WebAdministration

$oldThumb = "111122223333444455556666777788889999AAAA"
$newThumb = "AAAA999988887777666655554444333322221111"

$sites = Get-ChildItem IIS:\Sites

foreach ($site in $sites) {
$bindings = Get-WebBinding -Name $site.Name | Where-Object { $_.protocol -eq "https" }

foreach ($binding in $bindings) {
$bindingInfo = $binding.bindingInformation
$cert = Get-Item "cert://LocalMachine/My/$oldThumb"

if ($cert) {
Write-Host "Обновляю сертификат на сайте $($site.Name)..."
# Удаляем старый биндинг
Remove-WebBinding -Name $site.Name -BindingInformation $bindingInfo -Protocol "https"
# Добавляем с новым thumbprint
New-WebBinding -Name $site.Name -Protocol "https" -Port 443 -IPAddress "*" -HostHeader $binding.Host
Push-Location IIS:\SslBindings
New-Item "0.0.0.0!443!$($binding.Host)" -Thumbprint $newThumb -SSLFlags 1
Pop-Location
}
}
}


🔥 Работает быстро и чётко. Особенно выручает в связке с автоматической выдачей сертификатов (например, через ACMESharp или Win-ACME).

💬 А вы как автоматизируете обновление сертификатов? Через PowerShell, Certbot, Group Policy или руками по старинке?

👉 @win_sysadmin
👍10
👋 Привет, админы!

Недавно столкнулся с интересной ситуацией: один из пользователей пожаловался, что антивирус ничего не находит, а система всё равно ведёт себя подозрительно. Решил копнуть — и не зря.

🕵️‍♂️ В итоге нашёл внедрение в процесс через WMI. Да-да, старый добрый WMI стал каналом для персистентности малвари. Чтобы выявить такие вещи, добавил себе в регулярный аудит вот такую проверку:


Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding |
Select-Object -Property Filter, Consumer


А дальше уже идёт разбор через:


Get-WmiObject -Namespace "root\subscription" -Class __EventFilter
Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer


⚠️ Если видите странные команды, непонятные пути, особенно с PowerShell или cmd.exe — повод для расследования.

Ну и напоследок

- Регулярно просматривайте WMI-события.
- Включите логирование WMI через Event ID 5861/5860 (Microsoft-Windows-WMI-Activity/Operational).
- Используйте Sysmon — он хорошо ловит подобные фокусы (Event ID 1 + родительские процессы).

💬 А вы мониторите WMI в своих инфраструктурах? Есть ли какие-то интересные кейсы? Поделитесь опытом!

👉 @win_sysadmin
👍10
👋 Привет, админы!

Бывает, нужно быстро понять, какие задачи по расписанию крутятся на сервере. Особенно когда сервер ведёт себя странно, а в логах — тишина. У меня был случай, когда скрипт сливал логи на сторону, а запускался через Task Scheduler под безобидным именем UpdateCheck.

🔥 Вот командлет, который мне помог всё быстро найти:


Get-ScheduledTask | Where-Object {$_.TaskPath -notlike '\Microsoft*'} |
Select-Object TaskName, TaskPath, State


А если хотите подробности (что запускается и от какого имени), то:


Get-ScheduledTask | ForEach-Object {
$info = $_
Get-ScheduledTaskInfo -TaskName $info.TaskName -TaskPath $info.TaskPath | Select-Object @{Name='Name';Expression={$info.TaskName}}, @{Name='User';Expression={$info.Principal.UserId}}, @{Name='LastRunTime';Expression={$_.LastRunTime}}, @{Name='NextRunTime';Expression={$_.NextRunTime}}, @{Name='Status';Expression={$_.LastTaskResult}}
}


📌 Советую раз в месяц гонять такой скрипт по всем серверам. Лучше найти лишнее самому, чем ждать сюрпризов от пользователей (или вредоносов).

💬 А вы как мониторите задания планировщика? Есть ли скрипты или автоматизация для этого?

👉 @win_sysadmin
👍9🔥31