Power shell и его возможности в уходящем году

Планировщик Windows служит для запуска программ по расписанию или в ответ на какие-то события.Запускаться может практически все что угодно, но чаще всего запускают различные скрипты, например powershell.

Планировщик Windows находится в панели управления в разделе “Система и безопасность” — ”Администрирование” — ”Расписание выполнения задач”.

Создадим задание на запуск скрипта при каждом запуске компьютера. Для этого необходимо иметь файл скрипта для запуска. Воспользуемся кнопкой “Создать задачу” в меню “Действия” в правой части экрана.

На первой вкладке введем имя задачи. при желании также можно ввести ее развернутое описание. Укажем от какого пользователя она будет выполняться, должна ли выполняться только после входа в систему (выполнять для пользователей вошедших в систему) или вообще для всех пользователей. Обратите внимание что если запускаемые программы используют сетевые диски и папки, то необходимо указать пароль к учетной записи от которой будет запускаться задача. Выполнить с наивысшими правами означает “Запускать от имени администратора”. Также можно сделать чтобы задача вообще не отображалась при запуске – так называемая скрытая задача.

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

Обратим внимание что в меню “Начать задачу” есть различные типы запуска задачи: по расписанию, при простое, при входе в систему и т.д.

Также можно указать периодичность запуска задачи, отложить запуск, задать сроки действия задачи, и т.д.

На закладке действия указываем какая программа будет запускаться и при необходимости ее параметры. Также можно просто вывести сообщение на экран или отправить сообщение по электронной почте (меню действие).

На вкладке условия можно задать дополнительные условия работы задачи – например “Запускать только при питании от сети” – актуально для устройств которым нужна экономия питания – например ноутбуки – “разбудить компьютер для запуска задания” и т.д.

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

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

Также у планировщика есть и другие функции – например импорт/экспорт заданий, ведение журналов запуска, создание простый заданий (задаются только имя, описание, программа, пользователь и расписание) и так далее.

На этом демонстрация возможностей использования планировщика Windows окончена. Другие полезные статьи по настройке Windows Server вы найдете в нашей базе знаний, а заказать сервер на Windows можно здесь. 

Последнее обновление: 03.11.2023

Все привет! В уходящем году хочу оставить небольшой след про такой сильный язык программирования, как PowerShell. Вероятно, уже в следующем году, ввиду тенденции отказа от Windows систем в нашей стране, моя практика в этой области закончится, а за пару лет активности, так и не собрался с силами опубликовать что-то подобное. Кода тут не будет, для этого у меня есть отдельная работа с заметками, цель статьи, еще раз подчеркнуть реальные возможности данного языка, где я буду ссылаться на работы, которые я старался делать универсальными, а так же сделаю акцент на полезных модулях.

Буквально два года назад, имея базовые знания навигации в консоли Linux, написание несложных batch-файлов и небольшой опыт VBScript открыл для себя PowerShell, и после этого я уже в прямом смысле этого слова, не мог остановиться реализовывать свои идеи, правда, такое дело очень затягивает. В один момент решился завести канал на GitHub и там же по сей день виду работу с заметками, где за это время накопилось более 6 тысяч строк из описания работы cmdlet (PowerShell-команд) и утилит для Системного Администратора (AD, Exchange, VMWare, MSSQL и т.д.) с примерами, ведь далеко не все получалось найти в интернете, порой, только изучая на практике свойства и методы объектов, можно получить желаемый результат. Так же набралась небольшая коллекция модулей и тестовый стенд WinForms с примерами работы различных методов, на котором я в дальнейшем базировался для написания приложений с графическим интерфейсом. Все работы писал по большей части для себя с целью автоматизировать и разгрузить текущий рабочий процесс, иногда помочь коллегам, именно по этому мне хочется поделиться своими наработками, возможно кому-то это еще сможет пригодиться.

Так сложилось, что многие с кем я общался, недолюбливают данный язык, порой, не воспринимают за язык вовсе, на рынке и правда для написания скриптов есть более функциональные конкуренты, но когда ты являешься администратором Windows систем, то это однозначно лучший, а порой незаменимый инструмент под рукой. Во-первых, язык является объектно-ориентированным, что сильно упрощает работу, и хотя в последнее время активно пишу на Bash, где преимущества в работе с текстом очевидны, но в силу привычки, мне очень не хватает данной модели, прибегая к сторонним инструментам, например jq и xmllint, которые нужно изучать отдельно, формировать массивы используя свой синтаксис. В PowerShell весь процесс автоматизирован и привычен. Во-вторых, язык на прямую интегрирован с платформой .NET, что дает возможности, как создание графических форм, используя WinForms и WPF, сетевые сокеты (например, можно написать свой syslog сервер), использовать различные библиотеки (изначально написанные на, или для C#), вплоть до создания и манипуляциями с графикой (создание или редактирование изображений).

Думаю очевидно, что для системного администратора графический интерфейс дает много возможностей, например, можно оптимизировать работу консольной команды или целого ряда cmdlet, не запоминая все ключи, имея возможность менять параметры наглядно в формах интерфейса. Автоматизировать процесс создания учетных записей в Active Directory, или формирование динамических табличный отчет состояния инфраструктуры VMWare (помимо набора модулей из PowerCLI присутствует целый ряд встроенных командлетов для Hyper-V) или Exchange (EMShell), где с помощью нескольких кликов можно узнать состояние всех баз данных и групп доступности в удобном формате, просмотреть message tracking log и выгрузить PST (возможность, которая отсутствует в консоли управления). Все это позволяет автоматизировать рутину, а главное, оптимизировать работу инструментов под себя. Естественно, никто не мешает выбрать другой интерфейс взаимодействия, например написать своего собственного бота Telegram или использовать Pipeline в Jenkins, где вся логика будет на PowerShell, и вероятно, для многих решения на базе скриптов могут казаться костыльными, тем не менее, это работает, а порой очень хорошо и других вариантов попросту может и не быть. Но в конечно итоге можно создать свою службу (используя бесконечный цикл и NSSM) или даже конвертировать скрипт в исполняемый exe-файл используя модуль ps2exe.

Фоновые задания (Jobs). Здесь смотря с кем сравнивать, например в Bash для управления jobs слишком мало функционала, они есть и работают неплохо, но по факту сами задания непредсказуемы и нуждаются в дополнительном логирование. По времени выполнения, тут все не очень хорошо, но наглядно, т.к. задания выполняются упорядочено (в отличие от Thread в Python). Для сравнения на ping 256 машин занимает примерно 2 минуты используя встроенный модуль, если воспользоваться модулем ThreadJob, время сокращается в среднем до 26 секунд, а вот задания через PoshRSJob уже 13 секунд.

А вот в Python это занимает всего 5 секунд уже с resolve именем хоста, где можно так же создать отдельный поток для графического интерфейса (в примере, TKInter).

Но эту проблему можно исправить, используя классы .NET, например, System.Net.Sockets.TcpClient для проверки портов, где можно определить timeout ожидания ответа в 100мс и ситуация становится более наглядной, и демонстрирует разницу, при проверки одного порта на всех 254 хостах, создание заданий с использования ThreadJob занимает в среднем на 30-40% меньше времени, чем пауза (Start-Sleep) в 100 миллисекунд.

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

Далее мне хотелось увеличить возможности удаленного администрирования без прямого взаимодействия с удаленным пользователем и добавить инструментов, за время работы у меня выработался определенный алгоритм, который я выполняю при анализе проблем в работоспособности операционной системы – это оценка нагрузки процессов, состояние служб, проверка uptime, последних обновлений и установленных приложений, состояние синхронизации компьютерных часов (ntp) и лицензий (kms), анализ сетевых настроен, подключений и конечно логов. Всем этим и не только возможно управлять удаленно, и у меня это получилось поместить в один интерфейс.

Работа с REST API. Есть одна ключевая особенность, PowerShell способен на прямую конвертировать вывод JSON и XML в объект (в обоих направлениях), что сильно оптимизирует работу для написания своих собственных скриптов взаимодействия с различными сервисами, для меня это остается самым удобно читаемым форматом, на фоне альтернатив, например, модулей для IDE. В остальном, преимуществ у Invoke-RestMethod или Invoke-WebRequest над curl особых нет. А вот для создания собственного REST API сервера вариантов наберется даже несколько. Имеется полноценный кроссплатформенный Web Framework Pode для создания REST API, веб-сайтов и серверов TCP/SMTP. Можно воспользоваться встроенным классом .NET HttpListener, на базе которого можно обработать все условия кодов возврата и использоваться базовую авторизация (Base64), и допустим создать возможность управления Windows системой на платформе Linux без необходимости конфигурирования WinRM – WinAPI, пример такой реализации.

В копилку кроссплатформенности, PowerShell Core очень неплохо работает в системе Linux, пусть и реализовано малая часть функционала, тем не менее можно комбинировать с другим языком, например Bash, и создать тот же простенький REST сервер.

Благодаря прямому взаимодействию PowerShell с ОС Windows и COM-объектами, вы можете создавать собственные кликеры на WScript для автоматизации любым простых действий (порой незаменимый подход по сей день, особенно, если это старые desktop Windows приложения), управлять продуктами MS Office (например, автоматическое создание подписи в Outlook с получением информации о пользователи из LDAP), создание и парсинг Excel-отчетов или автоматизация действий в браузере через Internet Explorer (альтернатива Selenium). Для примера у меня была задача, читать из smb каталога Excel-файл и смотреть на даты окончания срока доступа, по итогу такого совпадения делать рассылку на почту (указанную в столбце с Email и информацией в теле письма, о чем идет речь из столбца с описанием). Или, с указанным интервалом получать метрики измерений скорости интернета, используя Okkla Speedtest с выгрузкой их в InfluxDB и отрисовской в Grafana. Так же мне было удобно читать отчеты на почте состояния заданий и репозиториев Veeam, пока я нахожусь в дороге на работу, а позднее, написал модуль получения данных через REST API, который в дальнейшем развил до автоматизации добавления виртуальных машин в систему резервного копирования.

.NET Framework/Core. Модули есть практически для всего, можно даже создать собственный сервер мониторинга через WMI/CIM (фактически метрики дублируют Performance Counter), или библиотеку SNMP. Есть ряд библиотек для различных баз данных, таких как MS SQL (имеет 3 варианта взаимодействия, в том числе встроенный класс System.Data.SqlClient), MySQL Connector, SQLite, для других же присутствует стандартизированный программный интерфейс взаимодействия ODBC (присутствуют драйверы для PostgreSQL, Firebird, Elastic и т.д.). Примеры для работы с различными модулями можно посмотреть тут. У меня как-то была задача, реализовать рассылку оповещений об окончании срока действия лицензий из ITInvent (данная программа мне очень нравится своим удобством удобной, т.к. работал с ней в разных компаниях, но к сожалению данный функционал отсутствовал), где база крутилась в MS SQL Express на Oracle Linux, разобравшись во взаимосвязях между таблицами эту задачу получилось выполнить за 3 дня и на выходе всего 70 строк кода.

Selenium. Очень удобный и простой инструмент в первую очередь для функционального тестирования, но так же может быть полезен при автоматизации тех действий, для которых не предусмотрено API. Ключевой проблемой в PowerShell является отсутствие актуального готового решения подготовки всех зависимостей для работы с данным инструментом. Данный процесс подготовки у меня получилось автоматизировать, и как мне кажется, требует отдельного внимания, по этому планирую написать отдельную статью.

На этом пожалуй все. Осознаю, что многие решения нужно было описывать в свое время отдельной статьей, все работы это только энтузиазм, не являюсь разработчиком, весь опыт исключительно на практике. В освоение большинства тем очень помогали статьи различных источников, в т.ч. Habr и большая база знаний Microsoft, где так же присутствует браузер модулей PowerShell и .NET API.

10 октября 2023

В 2018 г. появилось программное обеспечение PowerShell Core 6.0 как кроссплатформенный инструмент автоматизации для операционных систем Windows, Linux и MacOS. PowerShell Core имеет открытый исходный код и работает на платформе .NET Core 2.x, в отличии от предыдущих версий, работающих на .NET Framework.
В статье представлен обзор, как изменилось использование PowerShell с версии 6 до последнего обновления 7.x. 

Вступление

Переход на PowerShell Core требовался для обеспечения кроссплатформенности продукта, но при этом привел к снижению функциональности, стабильности и надежности. Кроме того, пользователи столкнулись с проблемами совместимости с существующими модулями Windows PowerShell.

• Не поддерживаются уже привычные решения:
• Возможность параллельного выполнения команд с помощью workflows.
• Нет поддержки WMI v1 и соответственно не работают командлеты Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent и т.д.
• Исчезли командлеты связанные с графическим отображением такие, как Out-GridView, Show-Command и параметр -ShowWindow
• Не работают модули ActiveDirectory и DnsClient.

0

 В начале 2020 г. компания Microsoft выпустила PowerShell 7.0. В этом программном обеспечении удалось решить большую часть проблем 6-ой версии. 7-ая версия основана на .NET Core 3.x, где поддерживается множество API .NET Framework, обеспечивая обратную совместимость с более 90% существующих модулей Windows PowerShell. Теперь поддерживаются модули ActiveDirectory, DnsClient, DnsServer, BitLocker, BranchCache, Defender, Hyper-V и многие другие, полный список которых приводится на сайте Microsoft. 
Вернулись командлеты требующие графическую функциональность, такие как Out-GridView и Show-Command. Повысилась стабильность и производительность.

В PowerShell 7.0 появились новые функции, в том числе:

• параллелизация конвейера с помощью ForEach-Object -Parallel;
• новые операторы:

• упрощенное динамическое представление ошибок и командлет Get-Error для более легкого анализа ошибок;
• автоматические уведомления о новых версиях;
• возможность вызывать ресурсы DSC непосредственно из PowerShell 7.

 Жизненый цикл  PowerShell 7.0 теперь соответствует политике жизненного цикла поддержки .NET Core и включает выпуски Long Term Service и non-Long Term Service.

1

Осенью 2020 г. вышла общедоступная версия PowerShell 7.1, основанная на  .NET 5.0.
В этой версии появился ряд новых функций и обновлений:

• PSReadLine 2.1.0 с прогнозной технологией IntelliSense
• Версия PowerShell 7.1 опубликована в Microsoft Store.
• Пакеты установщика обновлены для новых версий ОС с поддержкой ARM64.
• 2 экспериментальные функции PSNullConditionalOperators и PSUnixFileStat стали основными.
• Добавлены 4 экспериментальные функции Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace, PSNativePSPathResolution,  PSCultureInvariantReplaceOperator и PSSubsystemPluginModel.

2

PowerShell 7.2 — это следующий выпуск Long Term Servicing (LTS) на основе .NET 6.0.
Новые возможности, обновления и критические изменения:

• Добавлены новые универсальные пакеты установщика для большинства поддерживаемых дистрибутивов Linux.
• Включена поддержка Центра обновления Майкрософт в Windows.
• Добавлены две новые экспериментальные возможности.

– Улучшена поддержка передачи аргументов собственных команд.
– Включена поддержка цвета в ANSI для FileInfo.

• Улучшены варианты заполнения нажатием клавиши TAB.
• Семь экспериментальных функций стали основными, одна удалена.
• Платформа DSC отделена от PowerShell 7, чтобы обеспечить возможность внесения будущих улучшений.
• Несколько критических изменений для повышения удобства использования.

3

В начале 2023 г. появилась версия PowerShell 7.3, основанная на  .NET 7.0.

Некоторые критические изменения в новой версии:

• PowerShell 7.3 не работает в Windows 7. 
• PowerShell Direct для Hyper-V поддерживается только в Windows 10, версия 1809 и более поздних версиях.
• Test-Connection не работает из-за намеренного критического изменения в .NET 7 
• Перемещение определения данных типа System.Security.AccessControl.ObjectSecurity в модуль Microsoft.PowerShell.Security. 
• Дополнительные улучшения заполнения нажатием клавиши TAB.
• Улучшена обработка ошибок.
• Улучшены сеансы и удаленное взаимодействие.
• Обновлены ряд командлетов.
• Добавлены новые экспериментальные функции.

УЦ АйТи Клауд по направлению системное администрирование, сетевые технологии, безопасность сетей

Курсы к статье

Будьте в курсе всех событий

Затрудняетесь
с выбором курса?

Оставьте заявку на консультацию

Хотите преподавать в АйТи Клауд?

Если вы имеете компетенции и хотите работать тренером курсов в АйТи Клауд – оставьте ваши данные, мы свяжемся с вами!

Скрипты Powershell в большинстве случаев используются для автоматизации выполнения определенных задач, и зачастую для их выполнения необходимо указывать определенные учетные данные, часто с повышенными правами. Для интерактивных сценариев это не проблема, поскольку при необходимости они могут предложить администратору ввести пароль, а вот для автоматизированных сценариев, требующих учетных данных, это становится более сложной задачей.

Да, бесчисленные руководства по кибербезопасности не устают повторять, что скрипты, требующие повышенных разрешений, должны запускаться только в защищенных системах, из каталогов, в которые имеют доступы только администраторы. Однако, при пентестах сетей Windows постоянно приходится сталкиваться со скриптами, содержащими жестко зашитые ученые данные. Причем очень часто это данные от привилегированных учеток. Очень часто так получается, что со временем уровень защищенности скриптов ослабевает. Бесчисленные копии, бекапы, старые версии – доступ к ним уже не так сильно ограничивается, в результате чего посторонним проще получить к ним доступ.

Поэтому администраторам важно помнить, что жестко вводить пароль в скрипт – плохая идея. Хотя можно зашифровать пароль в файл, как показано на рисунке, такие файлы лишь ненамного лучше, чем зашифрованный пароль с открытым текстом.

Это связано с тем, что любой, у кого есть доступ к файлу, может использовать его для аутентификации, не зная фактического пароля. Кстати, по похожему принципу построена атака pass the hash, когда злоумышленник вместо пароля использует его хэш, и этого бывает достаточно для аутентификации в системе.

Поэтому нужен более безопасный способ предоставления учетных данных автоматизированным сценариям PowerShell. В доменной инфраструктуре Active Directory мы можем использовать Windows Credential Manager для получения разрешений.

Хотя Windows Credential Manager существует в автономных системах, иногда его поведение может быть довольно странным. Например, если автономная система настроена без пароля (вообще без аутентификации), кэшированные учетные данные в диспетчере учетных данных часто не предоставляют доступ к подключенным сетевым дискам, даже если сохраненные учетные данные верны.

Специальные учетки

Первым шагом в этом процессе усиления защиты скриптов создание учетной записи специально для данного сценария PowerShell, которой и будут назначены необходимые разрешения. Хотя в некоторых организациях создается специальная учетная запись, которую могут использовать все сценарии PowerShell, такая практика может ослабить безопасность. Причина этого заключается в том, что использование универсальной “учетной записи PowerShell” нарушает принцип минимальных привилегий.

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

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

Поэтому лучше создать отдельные учетные записи Active Directory для каждого сценария PowerShell. Вы всегда можете сохранить эти учетные записи в специальной папке Active Directory, чтобы не загромождать папку пользователей. Просто убедитесь, что имя и описание каждой учетной записи четко указывают на ее назначение.

Настройка Windows Credential Manager

На скриншоте PowerShell показано, что модуль Credential Manager успешно установлен

После установки модуля вы можете добавить сохраненные учетные данные в Windows Credential Manager. Это уже можно делать в окне PowerShell без привилегированных прав доступа, используя учетную запись обычного пользователя. В переменной $Password мы сохраняем пароль.

$Username = PowerShellDemo@poseylab.com

$Password = ConvertTo-SecureString “P@ssw0rd” -AsPlainText -Force

$Credential = New-Object -TypeName PSCredential -ArgumentList $UserName, $Password

New-StoredCredential -Target PowerShell -Credential $Credential -Type Generic -Persist LocalMachine 

Стоит отметить, что параметр Target, используемый в последней команде, по сути, присваивает понятное имя учетным данным (PowerShell). В принципе, вы можете назвать целевой объект как угодно. Однако важно запомнить присвоенное целевое имя, поскольку вам нужно будет ссылаться на него всякий раз, когда вы будете использовать сохраненные учетные данные.

На скриншоте ниже показано, что учетные данные были записаны в диспетчер учетных данных Windows.

Соответственно, для получения сохраненных учетных данных достаточно просто использовать эту команду:

Get-StoredCredential -Target <Target Name>

$Cred = Get-StoredCredential -Target PowerShell

 New-ADUser -Credential $Cred -Name “TestUser” -SamAccountName “TestUser” -UserPrincipalName TestUser@poseylab.com -AccountPassword (ConvertTo-SecureString “P@ssw0rd” -AsPlainText -Force) -Enabled $True

После создания новой учетной записи подтвердаем успешность операции с помощью этой команды:

 Вот что мы получили в итоге:

Заключение

Используя Windows Credential Manager, мы можем использовать в скриптах Powershell привилегированные учетные записи Active Directory, не снижая при этом общий уровень защищенности инфраструктуры.

18 июня для системных администраторов пройдет открытый урок, посвященный GPO: «Групповые политики как средство автоматизации». Записаться бесплатно можно на странице курса «Администратор Windows».

Похожее:

Power shell и его возможности в уходящем году Как обновить power shell Windows 10 — Wikipedia Republished // WIKI 2 Утилита WMIC, часть 2 – методы и ключи |