Vadims Podans's blog - PowerShell

Программная обработка запросов сертификатов в папке Pending Requests

Camelot — Sat, 03 Jul 2010 19:48:17 GMT

Как известно, когда запрос попадает в папку Pending Requests, администратор CA должен что-то с ним явно сделать — или одобрить или отклонить. Это можно сделать при помощи оснастки CetSrv.msc или при помощи PowerShell. Ещё можно через certutil, но речь сегодня не о нём. Если вспомнить предыдущие посты посвящённые CryptoAPI и PowerShell, можно вспомнить какие-то основные принципы. Как обычно, мы будем использовать интерфейс ICertAdmin2. Для аппрува соответствующих запросов необходимо воспользоваться методом ResubmitRequest(). Как вы видите, метод принимает 2 аргумента:

HRESULT ResubmitRequest( [in] const BSTR strConfig, [in] LONG RequestId, [out, retval] LONG *pDisposition );

это конфигурационная строка CA вида: CAComputerName\CAName и номер запроса. И в ответ метод возвращает результат выполнения операции. Вот как это можно аккуратно сделать в PowerShell:

function Issue-PendingRequest {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFomPipeline = $true)]
        [string]$CAConfig,
        [Parameter(Mandatory = $true)]
        [int]$RequestID
    )
    try {$CertAdmin = New-Object -ComObject CertificateAuthority.Admin}
    catch {Write-Warning "Unable to instantiate ICertAdmin2 object!"; return}
    try {
        $status = switch ($CertAdmin.ResubmitRequest($CAConfig,$RequestID)) {
            0 {"The request was not completed."}
            1 {"The request failed."}
            2 {"The request was denied"}
            3 {"The certificate was issued."}
            4 {"The certificate was issued separately."}
            5 {"The request was taken under submission."}
            6 {"The certificate is revoked."}
        }
    }
    catch {$_; return}
    Write-Host "Operation status for the request '$RequestID': $ststus"
}

Для отклонения запроса, следует воспользоваться методом DenyRequest(). Как и метод ResubmitRequest тоже принимает всего 2 аргумента, но кроме ошибок ничего не возвращает:

HRESULT DenyRequest( [in] const BSTR strConfig, [in] Long RequestId );

И код будет очень похож на предыдущий:

function Deny-PendingRequest {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFomPipeline = $true)]
        [string]$CAConfig,
        [Parameter(Mandatory = $true)]
        [int]$RequestID
    )
    try {$CertAdmin = New-Object -ComObject CertificateAuthority.Admin}
    catch {Write-Warning "Unable to instantiate ICertAdmin2 object!"; return}
    try {$CertAdmin.DenyRequest($CAConfig,$RequestID)}
    catch {$_; return}
    Write-Host "Successfully denied request '$RequestID'"
}

вот так легко можно программным способом управлять реквестами из папки Pending Requests без графических оснасток или certutil. Что касается certutil, я не уверен, что он сможет заапрувить или отклонить реквест на удалённом CA. У него есть параметр –config, но я не уверен, что он работает в данном случае. Плюс, когда я выложу в общий доступ свой PS модуль для PKI, эта операция будет ещё проще. Вам не придётся вручную набивать конфигурационную строку, а просто воспользоваться командой Get-CertificationAuthority.

PowerShell Powered - http://www.sysadmins.lv

Преобразование десятичного числа в IP адрес

Camelot — Sun, 30 May 2010 10:52:39 GMT

Недавно в мессенджер упал интересный вопрос:

в Active Directory у пользователя есть атрибут msRADIUSFramedIPAddress в котором храниться статический IP адрес, который назначается на вкладке Dual In в свойствах пользователя. Если смотреть через LDAP то значение мало похоже на введённый IP адрес. Хотелось бы на выходе получить работающий скрипт пишущий в файл соответсвие пользователь - IP адрес. Как я понял проблему, идёт двойная конвертация.

Действительно, если смотреть на это свойство через провайдер ADSI (не путать с adsiedit.msc), мы увидим число мало похожее на IP адрес. Например, 168846386. Для приведения данного числа в формат IP адреса нужно преобразовать его в двоичный формат, а после — разбить на октеты по 8 бит и каждый октет преобразовать обратно в десятичную форму. В .NET есть целый класс конверторов System.Convert, который позволяет конвертировать между собой множество форматов. Мы воспользуемся вот таким методом: Convert::ToString Method (Int32, Int32), в котором первый аргумент отвечает за исходное число, а второй — выходной формат. Поскольку нам нужно получить двоичное представение, указываем формат 2:

[↓] [vPodans] [convert]::ToString(168846386,2)
1010000100000110010000110010

Строка содержит неполные 32 бита. Чтобы их дополнить мы должны добавить слева недостающие нули:

[↓] [vPodans] $bin = [convert]::ToString(168846386,2)
[↓] [vPodans] $bin
1010000100000110010000110010
[↓] [vPodans] $bin.length
28
[↓] [vPodans] $fullBin = "0" * (32 - $bin.length) + $bin
[↓] [vPodans] $fullbin
00001010000100000110010000110010

Мы знаем, что 4 октета это 32 бита, следовательно вычитаем из 32 длину актуальной строки и получаем количество добавочных нулей. И эти нули добавляем в начало строки. Теперь эту строку надо разбить на 4 октета по 8 бит или по 1 байту:

[↓] [vPodans] 0,8,16,24 | %{$fullbin.substring($_,8)}
00001010
00010000
01100100
00110010

Я воспользовался методом String::Substring Method (Int32, Int32). Первый аргумент указывает стартовый символ, откуда начинать вырезать, а второй аргумент указывает количество символов, которые нужно вырезать. Вот и получили 4 байта. Преобразовать обратно в десятичный формат их так же просто, но с использованием Convert::ToInt32 Method (String, Int32):

[↓] [vPodans] 0,8,16,24 | %{[convert]::ToInt32($fullbin.Substring($_,8),2)}
10
16
100
50

Теперь это осталось собрать в строку и расставить точки между октетами. Для этого мы вопспользуемся статическим методом Join() класса System.String:

[↓] [vPodans] [string]::Join(".",$(0,8,16,24 | %{[convert]::ToInt32($fullbin.substring($_,8),2)}))
10.16.100.50

вот мы и получили наш заветный IP-адрес. И вот весь код:

$bin = [Convert]::ToString(168846386,2)
$fullBin = "0" * (32 - $bin.Length) + $bin
[string]::Join(".", $(0,8,16,24 | %{[Convert]::ToInt32($fullBin.Substring($_,8),2)}))

Надеюсь, поможет ещё кому-нибудь

PowerShell Powered - http://www.sysadmins.lv

Best Practices Analyzer (BPA) и PowerShell

Camelot — Mon, 03 May 2010 14:48:04 GMT

Что делать, что делать, одна продажная роботиха за 300 долларов или 300 продажных роботих по доллару?

Да, вот такой непростой выбор. А точнее чему отдать преимущество: этому BPA или PowerShell'у? Как известно, Best Practices Analyzer (BPA) в Windows Server 2008 R2 основан на скриптах PowerShell. Я не знаю, как оно там внутри происходит, но есть мнение, что как-то оно происходит. С этой проблемой сталкиваются все те, кто управляет политикой исполнения (ExecutionPolicy) через групповые политики. И вот как это выглядит, если в групповой политике задано значение AllSigned или RemoteSigned и вы пытаетесь просканировать какую-то роль:

Т.е. как я понимаю, этот BPA тянет скрипты с серверов Microsoft'а, либо одно из двух. При этом, он запускает консоль с изменением текущей политики исполнения. Однако тут есть одна хитрость. Если вы не управляете политикой исполнения скриптов из политик, а вручную набираете команду:

Set-ExecutionPolicy RemoteSigned

то BPA ВНЕЗАПНО начинает работать. Т.е. по сути всё равно RemoteSigned будь то вручную, будь то через политику, будут иметь одинаковый эффект. Но в первом случае BPA работает, во втором — нет. Единственная разница здесь в том, что если политика исполнения скриптов задана командлетом Set-ExecutionPolicy (не через групповые политики) её можно спокойно переопределить для конкретного сеанса. Вот как это делается (только PowerShell V2):

PS C:\> Get-ExecutionPolicy
AllSigned
PS C:\> powershell -executionpolicy remotesigned
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\> Get-ExecutionPolicy
RemoteSigned
PS C:\>
PS C:\> Exit
PS C:\> Get-ExecutionPolicy
AllSigned

Запустили пошик с нужным ключиком и для текущей сессии получили нужную политику исполнения. Вышли из сессии и снова вернулись в AllSigned. Если же политика исполнения управляется через групповые политики, то такой финт ушами уже не пройдёт:

PS C:\> Get-ExecutionPolicy
AllSigned
PS C:\> powershell -executionpolicy remotesigned
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\> Get-ExecutionPolicy
AllSigned
PS C:\>

Как AllSigned был, так и остался.

Собственно и вопрос: как сделать так, чтобы работал BPA и политика исполнения скриптов назначалась через групповые политики?

PowerShell Powered - http://www.sysadmins.lv

Осторожно, баг!

Camelot — Sat, 01 May 2010 22:46:05 GMT

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

А дело в том, что одна моя задумка с треском проваливалась из-за непонятного и тупого бага в интерфейсе ICertEncodeAltName. Это CryptoAPI интерфейс, который позволяет кодировать строковые значения для расширения Subject Alternative Name в ASN.1 DER encoded строку. На возню с ним я потратил почти неделю (чуть меньше, наверное) и только сегодня я смог найти все ответы. Хотя я это должен был сделать много раньше, но дико тупил на ровном месте. Итак, давайте посмотрим, что из себя представляет этот баг.

Для начала я покажу как собирается этот интерфейс:

$san = New-Object -ComObject CertificateAuthority.EncodeAltName

Далее, его надо инициализировать методом Reset() и в качестве аргумента метода указать размер объекта. Т.е. количество элементов, которые должны содержаться в расширении Subject Alternative Name. Если только один элемент, то и указываете число 1:

$san.Reset(1)

и теперь можно в него заряжать данные методом SetNameEntry():

$san.SetNameEntry(0,0x3,"Custom-Name")

Где 0 — индекс массива, в который надо записать строку, 0x3 — тип строки. В данном случае это DNS и последний аргумент указывает само значение строки. Полный список типов можно получить вот здесь: http://msdn.microsoft.com/en-us/library/aa374981(VS.85).aspx. Только учтите, что реально типы начинаются не с нуля (как по ссылке), а с единицы. т.е. 0x3 в нашем случае это DNS (2+1).

После того как мы загнали туда данные, их можно кодировать:

$san.Encode()

И давайте посмотрим, что у нас получилось:

[↓] [vPodans] $san = New-Object -ComObject CertificateAuthority.EncodeAltName
[↓] [vPodans] $san.Reset(1)
[↓] [vPodans] $san.SetNameEntry(0,0x3,"Custom-Name")
[↓] [vPodans] $str = $san.Encode()
[↓] [vPodans] $str
???????

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

[↓] [vPodans] $str.ToCharArray() | %{[int][char]$_}
3376
2946
30019
29811
28015
20013
28001

Чтобы убедиться, что в каждом символе по 2 байта, мы преобразуем эти числа в их шестнадцатиричное (hex) представление:

[↓] [vPodans] $str.ToCharArray() | %{"{0:X4}" -f [int][char]$_}
0D30
0B82
7543
7473
6D6F
4E2D
6D61

видите, в каждом символе по 2 байта и все они записаны в little-endian последовательности. Т.е. первый байт находится справа, а не слева, как обычно. Давайте соберём эти байты в последовательную строку, переставив байты местами в каждой строке:

30 0D 82 0B 43 75 73 74 6F 6D 2D 4E 61 6D

И что же означают эти циферки-букавки? А означают они следующее:

30 (48) — тип кодировки. 30 или 48 (в десятичном представлении) означает Constructed encoding.
0D (13) — длину строки начиная со следующего байта. Остаточная длина должна быть 13 байт. Но моя математика говорит, что дальше не 13, а только 12 байт.
82 (130) — тип закодированной строки. 130 означает DNS. 80 (128) — OtherName, 81 (129) — RFC822Name и т.д.
0B (11) — размер строки начиная со следующего байта. Остаточная длина должна быть 11 байт. Но моя математика говорит, что их там не 11, а только 10 байт.
Остальные байты — сама строка, только в hex'е.

Куда-то пропал один очень важный байт, из-за чего сервер CA начинал доставлять шлакоблоки при виде такой строки. В принципе, мы можем посмотреть, что у нас потерялось по дороге:

[↓] [vPodans] $str1 = "43 75 73 74 6F 6D 2D 4E 61 6D".split(" ")
[↓] [vPodans] $str1 | %{$a += invoke-expression [char]0x$_}
[↓] [vPodans] $a
Custom-Nam

Последний символ куда-то провалился. Нет его больше. Т.е. размер вычислен правильно, просто не хватает одного байта. Причём, если попробовать что-то другое, попроще, интерфейс возвращает правильный размер и все байты. Я не знаю точно, в каких условиях этот баг проявляется, но уже очевидно, что если в строке присутствует дефис, уже начинается бяка.

Что можно сделать? Вариантов куча. Как вы видите ASN.1 DER кодировка достаточно простая, её можно сделать самому. Либо использовать православные интерфейсы CertEnroll — IX509ExtensionAlternativeNames. На первый взгляд там багов не обнаружено . Примеры использования данных интерфейсов можно посмотреть (а заодно и почитать) в моём буржуйском бложике: How to add FQDN to HP iLO request.

На сегодня всё. Спокночи.

PowerShell Powered - http://www.sysadmins.lv

Делаем скриншоты средствами PowerShell

Camelot — Thu, 22 Apr 2010 20:43:41 GMT

Сегодня пришло письмо, где человек спрашивал о том, можно ли сделать скриншот средствами PowerShell. Я вообще не очень понял зачем это, но это уже не моё дело. Если я пишу этот пост, значит можно

Для этого существует класс Drawing.Graphics у которого есть замечательный метод CopyFromScreen(). Данный метод принимает в качестве аргументов различные параметры, которые определяют координаты области, которую нужно сфоткать. В принципе можно забивать фиксированные значения (см. конструкторы с Int, как этот — CopyFromScreen(Int32, Int32, Int32, Int32, Size)), а можно эти размеры выставлять динамически, в зависимости от размеров экрана. Для этого лучше воспользоваться самым первым методом: CopyFromScreen(Point, Point, Size).

Как получить размеры экрана? Очень просто, достаточно воспользоваться статическим свойством VirtualScreen класса Windows.Forms.SystemInformation:

[Windows.Forms.SystemInformation]::VirtualScreen

[↓] [vPodans] [Windows.Forms.SystemInformation]::VirtualScreen


Location : {X=0,Y=0}
Size     : {Width=1280, Height=800}
X        : 0
Y        : 0
Width    : 1280
Height   : 800
Left     : 0
Top      : 0
Right    : 1280
Bottom   : 800
IsEmpty  : False



[↓] [vPodans]

Вот размеры экрана на моём нотебуке. Готично. Теперь нужно создать объект Drawing.Graphics. Однако, этот объект нельзя создать через New-Object, поскольку для этого нет ни одного конструктора. Следовательно объект нужно создавать используя статические методы. Статические методы можно посмотреть на странице Drawing.Graphics Members. И там мы можем найти красивый метод — FromImage. В качестве аргумента этого метода нужно указать картинку — http://msdn.microsoft.com/en-us/library/system.drawing.image.aspx. Это может быть файл или объект класса Drawing.Bitmap. Давайте создадим объект класса Drawing.Bitmap с использованием следующего конструктора — Bitmap Constructor (Int32, Int32):

[↓] [vPodans] [void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
[↓] [vPodans] $size = [Windows.Forms.SystemInformation]::VirtualScreen
[↓] [vPodans] $bitmap = new-object Drawing.Bitmap $size.width, $size.height
[↓] [vPodans] $bitmap


Tag                  :
PhysicalDimension    : {Width=1280, Height=800}
Size                 : {Width=1280, Height=800}
Width                : 1280
Height               : 800
HorizontalResolution : 96
VerticalResolution   : 96
Flags                : 2
RawFormat            : [ImageFormat: b96b3caa-0728-11d3-9d7b-0000f81ef32e]
PixelFormat          : Format32bppArgb
Palette              : System.Drawing.Imaging.ColorPalette
FrameDimensionsList  : {7462dc86-6180-4c7e-8e3f-ee7333a7a483}
PropertyIdList       : {}
PropertyItems        : {}



[↓] [vPodans]

Примечание: WinForms по умолчанию не загружаются вместе с PowerShell, поэтому мы их подгружаем в консоль в ходе работы. Мы создали Bitmap и теперь его можем использовать для создания объекта Drawing.Graphics:

$graphics = [Drawing.Graphics]::FromImage($bitmap)

А дальше уже вызывать метод CopyFromScreen(). При этом указываем первым аргументом начало координат (верхний левый угол или 0,0) и в аргумент правый нижний угол. Т.е. максимум точек по ширине и высоте. Их мы можем получить из свойств Width и Height класса Windows.Forms.SystemInformation. Средний аргумент опускаем и делаем его пустым:

[↓] [vPodans] $graphics = [Drawing.Graphics]::FromImage($bitmap)
[↓] [vPodans] $graphics.CopyFromScreen($size.Location,[Drawing.Point]::Empty, $size.size)

Всё, мы сфоткали наш экран и загнали картинку обратно в Bitmap. Теперь нужно выгрузить картинку куда-то в файл. Для этого у Bitmap есть метод Save(), в котором достаточно указать путь к файлу:

[↓] [vPodans] $bitmap.save(".\screenshot.jpg")
[↓] [vPodans] gi .\screenshot.jpg


    Directory: C:\Users\vPodans


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        22.04.2010     22:37     286319 screenshot.jpg


[↓] [vPodans]

Всё

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

И код:

[void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$size = [Windows.Forms.SystemInformation]::VirtualScreen
$bitmap = new-object Drawing.Bitmap $size.width, $size.height
$graphics = [Drawing.Graphics]::FromImage($bitmap)
$graphics.CopyFromScreen($size.location,[Drawing.Point]::Empty, $size.size)
$graphics.Dispose()
$bitmap.Save(".\screenshot.jpg")
$bitmap.Dispose()

PowerShell Powered - http://www.sysadmins.lv

Создание самоподписанного сертификата средствами PowerShell

Camelot — Sun, 18 Apr 2010 09:46:11 GMT

Самоподписанные сертификаты — это зло, за исключением сертификатов корневых CA. Я об этом говорил, говорю и буду говорить. Но в данном случае мы не преследуем цель создания самоподписанного сертификата. Нас по сути будет интересовать немного другое — рассмотрение принципа, который заложен во многих популярных тулзах как MakeCert или OpenSSL. Лично я не фанат ни первого, ни второго по своим сугубо личным причинам. Но, кроме этих двоих есть ещё утилита CertReq.exe, которая достаточно православная и вряд ли ей грозит вымирание (а жаль). Вобщем, сегодня предлагаю ещё раз поковырять CryptoAPI.

Как мы уже знаем, CryptoAPI обладает большим количеством всяческих COM интерфейсов, при помощи которых мы можем работать практически с любыми аспектами цифровых сертификатов. Некоторые из них бажные, а некоторые — не очень , но функционал у них впечатляющий. В настоящее время существует 2 основных набора API, которые реализуют клиентскую часть энроллмента — XEnroll и CertEnroll. Первый доступен только в системах начиная с Windows 2000 и до Windows Server 2003 включительно. В более новых версиях XEnroll был вырезан вместе с CAPICOM'ом полностью (куски CAPICOM'а ещё можно найти в висте) за ненадобностью. Семейство интерфейсов CertEnroll было значительно переработано и расширено, что делает его крайне гибким. Я не буду рассказывать про XEnroll, потому что это неинтересно и трупов пинать нехорошо.

Многие считают, что CryptoAPI — это очень сложно. Я могу возразить им. Я не программист совсем, но могу достаточно свободно их использовать. Нашей отправной точкой будет MSDN по адресу: Certificate Enrollment API Reference. Эта секция содержит всё самое необходимое — описание интерфейсов и перечисления. И самый первый интерфейс, который мы видим — IX509Enrollment. Этот интерфейс реализует нечто промежуточное между клиентом и сервером. Мы можем по описанию найти то, что нам нужно, а именно первую секцию — Out-of-band-enrollment. И мы видим, что для него надо сначала вызвать метод CreateRequest(). Но прежде чем вызывать метод, нам надо создать форму сертификата, на основе которой будет создан запрос. Как я уже упоминал, мы будем делать самоподписанный сертификат, поэтому следующий интерфейс подойдёт нам как нельзя кстати — IX509CertificateRequestCertificate2. Вот давайте с него и начнём.

Все указанные здесь и далее интерфейсы являются COM интерфейсами семейства X509Enrollment и эти объекты создаются следующим образом:

$Cert = New-Object -ComObject X509Enrollment.CX509CertificateRequestCertificate.1

Примечание: как строятся такие команды? Поскольку это COM интерфейс, первую букву I в названии интерфейса меняем на букву C. Далее, если мы видим цифру 2 в конце названия интерфейса, в команде мы ставим точку и пишем число на единцу меньшее. Вот такие нехитрые правила.

Прежде чем его начать использовать, нам надо инициализировать его. К сожалению документация на MSDN далеко не полная, поэтому будем искать нужные методы через PowerShell и командлет Get-Member:

[↓] [vPodans] $cert | gm -MemberType methods


   TypeName: System.__ComObject#{728ab35a-217d-11da-b2a4-000e7bbb2b09}

Name                             MemberType Definition
----                             ---------- ----------
CheckPublicKeySignature          Method     void CheckPublicKeySignature (IX509PublicKey)
CheckSignature                   Method     void CheckSignature (Pkcs10AllowedSignatureTypes)
Encode                           Method     void Encode ()
GetCspStatuses                   Method     ICspStatuses GetCspStatuses (X509KeySpec)
GetInnerRequest                  Method     IX509CertificateRequest GetInnerRequest (InnerRequestLevel)
Initialize                       Method     void Initialize (X509CertificateEnrollmentContext)
InitializeDecode                 Method     void InitializeDecode (string, EncodingType)
InitializeFromCertificate        Method     void InitializeFromCertificate (X509CertificateEnrollmentContext, string...
InitializeFromPrivateKey         Method     void InitializeFromPrivateKey (X509CertificateEnrollmentContext, IX509Pr...
InitializeFromPrivateKeyTemplate Method     void InitializeFromPrivateKeyTemplate (X509CertificateEnrollmentContext,...
InitializeFromPublicKey          Method     void InitializeFromPublicKey (X509CertificateEnrollmentContext, IX509Pub...
InitializeFromTemplate           Method     void InitializeFromTemplate (X509CertificateEnrollmentContext, IX509Enro...
InitializeFromTemplateName       Method     void InitializeFromTemplateName (X509CertificateEnrollmentContext, string)
IsSmartCard                      Method     bool IsSmartCard ()
ResetForEncode                   Method     void ResetForEncode ()


[↓] [vPodans]

Из всех методов нам по сути доступен только InitializeFromPrivateKey(), поскольку остальные методы инициализации требуют наличие доступа к Certification Authority. Посмотрим что требуется для этого метода:

[↓] [vPodans] $cert | gm -MemberType methods | ?{$_.name -eq "InitializeFromPrivateKey"} | select definition

Definition
----------
void InitializeFromPrivateKey (X509CertificateEnrollmentContext, IX509PrivateKey, string)


[↓] [vPodans]

В качестве аргументов метода нам надо указать контекст энроллмента и объект закрытого ключа. Значения контекста находятся здесь: X509CertificateEnrollmentContext (просто включаете поиск на MSDN по названию перечисления). В качестве контекста мы можем выбрать контекст текущего пользователя или компьютера (остальное нас сейчас не волнует совсем). Контекст пользователя имеет значение 0x1. Так и запишем. Но этого мало. Надо ещё создать объект закрытого ключа:

$PrivateKey = New-Object -ComObject X509Enrollment.CX509PrivateKey

Этот интерфейс позволяет задавать различные параметры закрытого ключа, но мы обойдёмся лишь самым необходимым:

# во-первых надо указать CSP. Выберем самый простой криптопровайдер
$PrivateKey.ProviderName = "Microsoft Base Cryptographic Provider v1.0"
# закрытый ключ будет использоваться для подписи (Digital Signature)
# http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx
$PrivateKey.KeySpec = 0x2
# длина вполне стандартная
$PrivateKey.Length = 1024
# ключ будем хранить в пользовательском хранилище
$PrivateKey.MachineContext = 0x0
# и генерируем ключ
$PrivateKey.Create()

Ура! Мы сгенерировали ключ. Теперь вернёмся к предыдущему интерфейсу и инициализируем его из закрытого ключа:

$Cert.InitializeFromPrivateKey(0x1,$PrivateKey,"")

Мы указываем контекст текущего пользователя и объект закрытого ключа. Там есть ещё один аргумент, который называется String. Я не знаю, что они этим хотели сказать, поэтому оставляем пустую строку. А теперь вернёмся к интерфейсу IX509CertificateRequestCertificate2 и посмотрим, что мы можем сделать сейчас. Например, используя свойства NotBefore и NotAfter мы зададим срок действия сертификата. Например, 1 год с сегодняшнего дня:

$Cert.NotBefore = [datetime]::Now
$Cert.NotAfter = $Cert.NotBefore.AddDays(365)

Теперь нам надо добавить следующие свойства: EncancedKeyUsage (т.е. для каких целей вообще будет использоваться сертификат), Subject (на кого будет выписан сертификат) и Issuer (кто выдал этот сертификат). Поскольку у нас самоподписанный сертификат, поле Subject и Issuer будут одинаковые. На MSDN'е не хватает документации по свойствам Issuer и Subject, но у нас есть поиск, который нас приведёт сюда: IX500DistinguishedName. Поля Subject и Issuer должны заполняться в формате Distinguished Name и доступные префиксы для DN достаточно понятно расписаны в таблице. Нам нужно как-то активировать этот объект. Методов для инициализации здесь нет, поэтому будем использовать метод Encode().

Лирическое отступление: в подавляющем большинстве случаев вы не можете присваивать значения свойствам объектов после создания самих объектов. Предварительно их надо «активировать» одним из двух способов. Если у объекта есть метод Initialize или производное от него, необходимо сначала воспользоваться одним из доступных методов инициализации. Если объект не содержит явных методов инициализации, нужно воспользоваться методом Encode, который кодирует объект или строку в ASN.1 DER строку и инициализирует объект. Единственным исключением из этого правила являются коллекции объектов. Они как правило используют метод Add() для добавления уже инициализированных объектов.

Уже с главной страницы IX500DistinguishedName видно, что Encode кодирует строку, которая записана в DN формате. Поэтому вызываем этот метод:

$SubjectDN.Encode("CN=Some Subject,DC=lucernepublishing,DC=COM", 0x0)

После строки нужно ещё указать флаг, в котором указана строка DN. Ставим дефолтный флаг. Теперь у нас готово поле Subject и Issuer (как мы договаривались, они будут одинаковые). Давайте их прицепим к нашему шаблону сертификата:

$Cert.Subject = $SubjectDN
$Cert.Issuer = $Cert.Subject

Что нам осталось сделать? Нам надо создать расширение Enchanced Key Usage. Для этого нам надо использовать следующий интерфейс: IX509ExtensionEnhancedKeyUsage:

$EKU = New-Object -ComObject X509Enrollment.CX509ExtensionEnhancedKeyUsage

Данный объект инициализируется из коллекции объектов IObjectIds. Давайте создадим эту коллекцию:

$OIDs = New-Object -ComObject X509Enrollment.CObjectIDs

В эту коллекцию с использованием метода Add() надо добавить один или несколько объектов IObjectId, каждый из которых представляет конкретное предназначение сертификата. Например, Server Authentication, Client Authentication, Smart Card Logon, Secure e-mail и т.д. Но мы сделаем сертификат для Code Signing. OID этого EKU = 1.3.6.1.5.5.7.3.3. Вот и сделаем его:

# создаём объект IObjectID
$OID = New-Object -ComObject X509Enrollment.CObjectID
# инициализируем его с использованием Code Signing
$OID.InitializeFromValue("1.3.6.1.5.5.7.3.3")
# добавляем наш OID в коллекцию OID'ов
$OIDs.Add($OID)
# добавляем коллекцию в объект IX509ExtensionEnhancedKeyUsage
$EKU.InitializeEncode($OIDs)

объект EKU у нас готов, теперь его надо добавить в наш шаблон сертификата. Поскольку это не стандартное поле сертификата, а расширение, добавляем этот объект в свойство X509Extensions, которое является аналогом интерфейса IX509Extensions и, который в свою очередь, является коллекцией расширений. Поэтому добавляем наше расширение методом Add():

$Cert.X509Extensions.Add($EKU)

Всё, мы собрали все минимально необходимые поля и расширения:

[↓] [vPodans] $cert


Type                        : 4
EnrollmentContext           : 1
Silent                      : False
ParentWindow                :
UIContextMessage            :
SuppressDefaults            : False
ClientId                    :
CspInformations             : System.__ComObject
HashAlgorithm               : System.__ComObject
AlternateSignatureAlgorithm : False
TemplateObjectId            :
PublicKey                   : System.__ComObject
PrivateKey                  : System.__ComObject
NullSigned                  : False
ReuseKey                    : False
Subject                     : System.__ComObject
CspStatuses                 : System.__ComObject
SmimeCapabilities           : False
SignatureInformation        : System.__ComObject
KeyContainerNamePrefix      : lp
CryptAttributes             :
X509Extensions              : System.__ComObject
CriticalExtensions          : System.__ComObject
SuppressOids                : System.__ComObject
Issuer                      : System.__ComObject
NotBefore                   : 16.04.2010 18:25:22
NotAfter                    : 16.04.2011 18:25:22
SignerCertificate           :
PolicyServer                :
Template                    :



[↓] [vPodans]

Теперь мы можем превращать наш шаблон сертификата в настоящй сертификат.

Лирическое отступление: а что такое запрос в техническом смысле? На самом деле запрос ничем не отличается от сертификата. Когда вы запрашиваете сертификат у CA, клиент использует эти же интерфейсы для генерации запроса. При этом получается самый настоящий самоподписанный сертификат, где Subject и Issuer одинаковые и равны имени текущего пользователя или компьютера, а так же содержит все необходимые расширения. Сам запрос подписывается закрытым ключом, который мы сгенерировали. По большому счёту, его уже можно использовать как настоящий самоподписанный сертификат. Если его отправить на сервер CA, то последний просто подменяет значения необходимых полей (как Issuer, в котором он ставит себя) и расширений, удаляет старую подпись и подписывает сертификат новой подписью. Вы можете убедиться в этом очень просто. Сгенерируйте запрос для сертификата, откройте оснастку Certificates и разверните секцию Certificate Enrollment Requests. Там будет этот самый запрос в виде уже готового сертификата. Просто там он ждёт, пока какой-нибудь CA не подпишет его.

Давайте вернёмся в самое начало текущего поста и вспомним про «исходный предмет» — IX509Enrollment. Вот этот интерфейс нам сконвертирует шаблон сертификата в настоящий сертификат с использованием метода CreateRequest(). Но прежде чем использовать метод, нам надо инициализировать объект:

$Request = New-Object -ComObject X509Enrollment.CX509enrollment
$Request.InitializeFromRequest($Cert)

И генерируем файл запроса, который ничем не отличается от самоподписанного сертификата:

$endCert = $Request.CreateRequest(0x0)

В аргументах метода указываем кодировку согласно этой страничке: EncodingType Enumeration. Мы выбираем Base64 с заголовками. $endCert будет содержать сам сертификат (открытую его часть). Фактически запрос хранится в контейнере Certificate Enrollment Requests. Поскольку этот интерфейс не был задуман специально для самоподписанных сертификатов мы проходим стандартную процедуру установки сертификата. Мы просто берём открытую часть нашего же сертификата и устанавливаем её. Вот, кстати, как он выглядит:

[↓] [vPodans] $endcert
-----BEGIN CERTIFICATE-----
MIICaTCCAdKgAwIBAgIQEzCS/mFIxLBAiGjz7+n0dDANBgkqhkiG9w0BAQUFADBP
MRMwEQYKCZImiZPyLGQBGRYDQ09NMSEwHwYKCZImiZPyLGQBGRYRbHVjZXJuZXB1
Ymxpc2hpbmcxFTATBgNVBAMMDFNvbWUgU3ViamVjdDAeFw0xMDA0MTgxMTI5MDla
Fw0xMTA0MTgxMTI5MDlaME8xEzARBgoJkiaJk/IsZAEZFgNDT00xITAfBgoJkiaJ
k/IsZAEZFhFsdWNlcm5lcHVibGlzaGluZzEVMBMGA1UEAwwMU29tZSBTdWJqZWN0
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBGa+PnrhnOFO5+76c5zX5/+xh
Kb2hUYl/pRuIKzYcqrmkvqjpPK/McusibT1h70emUkED0TSZsAlSivdIFK6WSxn6
HsTCaGIHhyOSKAvzQkBsZ74BPEydGT5LiX0+MOTyxwFAHhb+bqfbkdkXqUSkJAHK
Z6p+fgX8uaJkKjL/kwIDAQABo0YwRDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNV
HQ4EFgQUzIFwoRTY6KjUiqmjWjSjlkxbNncwDgYDVR0PAQH/BAQDAgeAMA0GCSqG
SIb3DQEBBQUAA4GBACizodCpl/cF3OGLUx8HVag0yhr1e1P8+CLPc31FmCPAY1CO
T0yxyJPoafkbXKRjclevNJdvxE3ys9fyYigFUhgswh3oWmjanDaatPKa0kE4147k
SQHvN8JP20KeDDCJBk/FbS3xCn3jTix90ddzTa1uFoqBbBNbKOaDHIrqypTY
-----END CERTIFICATE-----

[↓] [vPodans]

Система приклеит этот сертификат к шаблону сертификата и переложит его уже в контейнер Personal:

$Request.InstallResponse(0x2,$endCert,0x0,"")

Всё, теперь мы увидим этот сертификат в нашем хранилище и который готов к использованию. Я немного переработал код и обернул его в красивую функцию, которая будет делать следующее:

Генерировать тестовый самоподписанный сертификат для подписи скриптов PowerShell
Устанавливать сертификат с закрытым ключом в контейнер Personal
Устанавливать открытую часть сертификата в Trusted Root CAs для обеспечения доверия этому сертификату
Устанавливать открытую часть сертификата в Trusted Publishers для задания явного доверия цифровым подписям, сделанные этим сертификатом.

#####################################################################
# Create PowerShell cert.ps1
# Version 1.0
#
# Creates self-signed signing certificate and install it to certificate store
#
# Note: Requires at least Windows Vista. Windows XP/Windows Server 2003
# are not supported.
#
# Vadims Podans (c) 2010
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

function New-SigningCert {
<#
.Synopsis
    Creates self-signed signing certificate and install it to certificate store
.Description
    This function generates self-signed certificate with some pre-defined and
    user-definable settings. User may elect to perform complete certificate
    installation, by installing generated certificate to Trusted Root Certification
    Authorities and Trusted Publishers containers in *current user* store.
    
.Parameter Subject
    Specifies subject for certificate. This parameter must be entered in X500
    Distinguished Name format. Default is: CN=PowerShell User, OU=Test Signing Cert.

.Parameter KeyLength
    Specifies private key length. Due of performance and security reasons, only
    1024 and 2048 bit are supported. by default 1024 bit key length is used.

.Parameter NotBefore
    Sets the date in local time on which a certificate becomes valid. By default
    current date and time is used.

.Parameter NotAfter
    Sets the date in local time after which a certificate is no longer valid. By
    default certificate is valid for 365 days.

.Parameter Force
    If Force switch is asserted, script will prepare certificate for use by adding
    it to Trusted Root Certification Authorities and Trusted Publishers containers
    in current user certificate store. During certificate installation you will be
    prompted to confirm if you want to add self-signed certificate to Trusted Root
    Certification Authorities container.
#>
[CmdletBinding()]
    param (
        [string]$Subject = "CN=PowerShell User, OU=Test Signing Cert",
        [int][ValidateSet("1024", "2048")]$KeyLength = 1024,
        [datetime]$NotBefore = [DateTime]::Now,
        [datetime]$NotAfter = $NotBefore.AddDays(365),
        [switch]$Force
    )
    
    $OS = (Get-WmiObject Win32_OperatingSystem).Version
    if ($OS[0] -lt 6) {
        Write-Warning "Windows XP, Windows Server 2003 and Windows Server 2003 R2 are not supported!"
        return
    }
    # while all certificate fields MUST be encoded in ASN.1 DER format
    # we will use CryptoAPI COM interfaces to generate and encode all necessary
    # extensions.
    
    # create Subject field in X.500 format using the following interface:
    # http://msdn.microsoft.com/en-us/library/aa377051(VS.85).aspx
    $SubjectDN = New-Object -ComObject X509Enrollment.CX500DistinguishedName
    $SubjectDN.Encode($Subject, 0x0)
    
    # define CodeSigning enhanced key usage (actual OID = 1.3.6.1.5.5.7.3.3) from OID
    # http://msdn.microsoft.com/en-us/library/aa376784(VS.85).aspx
    $OID = New-Object -ComObject X509Enrollment.CObjectID
    $OID.InitializeFromValue("1.3.6.1.5.5.7.3.3")
    # while IX509ExtensionEnhancedKeyUsage accept only IObjectID collection
    # (to support multiple EKUs) we need to create IObjectIDs object and add our
    # IObjectID object to the collection:
    # http://msdn.microsoft.com/en-us/library/aa376785(VS.85).aspx
    $OIDs = New-Object -ComObject X509Enrollment.CObjectIDs
    $OIDs.Add($OID)
    
    # now we create Enhanced Key Usage extension, add our OID and encode extension value
    # http://msdn.microsoft.com/en-us/library/aa378132(VS.85).aspx
    $EKU = New-Object -ComObject X509Enrollment.CX509ExtensionEnhancedKeyUsage
    $EKU.InitializeEncode($OIDs)
    
    # generate Private key as follows:
    # http://msdn.microsoft.com/en-us/library/aa378921(VS.85).aspx
    $PrivateKey = New-Object -ComObject X509Enrollment.CX509PrivateKey
    $PrivateKey.ProviderName = "Microsoft Base Cryptographic Provider v1.0"
    # private key is supposed for signature: http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx
    $PrivateKey.KeySpec = 0x2
    $PrivateKey.Length = $KeyLength
    # key will be stored in current user certificate store
    $PrivateKey.MachineContext = 0x0
    $PrivateKey.Create()
    
    # now we need to create certificate request template using the following interface:
    # http://msdn.microsoft.com/en-us/library/aa377124(VS.85).aspx
    $Cert = New-Object -ComObject X509Enrollment.CX509CertificateRequestCertificate
    $Cert.InitializeFromPrivateKey(0x1,$PrivateKey,"")
    $Cert.Subject = $SubjectDN
    $Cert.Issuer = $Cert.Subject
    $Cert.NotBefore = $NotBefore
    $Cert.NotAfter = $NotAfter
    $Cert.X509Extensions.Add($EKU)
    # completing certificate request template building
    $Cert.Encode()
    
    # now we need to process request and build end certificate using the following
    # interface: http://msdn.microsoft.com/en-us/library/aa377809(VS.85).aspx
    
    $Request = New-Object -ComObject X509Enrollment.CX509enrollment
    # process request
    $Request.InitializeFromRequest($Cert)
    # retrievecertificate encoded in Base64.
    $endCert = $Request.CreateRequest(0x1)
    # install certificate to user store
    $Request.InstallResponse(0x2,$endCert,0x1,"")
    
    if ($Force) {
        # convert Bas64 string to a byte array
         [Byte[]]$bytes = [System.Convert]::FromBase64String($endCert)
        foreach ($Container in "Root", "TrustedPublisher") {
            # open Trusted Root CAs and TrustedPublishers containers and add
            # certificate
            $x509store = New-Object Security.Cryptography.X509Certificates.X509Store $Container, "CurrentUser"
            $x509store.Open([Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
            $x509store.Add([Security.Cryptography.X509Certificates.X509Certificate2]$bytes)
            # close store when operation is completed
            $x509store.Close()
        }
    }
}

С виду кажется сложно, но на самом деле тут ничего сложного нет совсем. Просто представьте себе сертификат как большую матрёшку, в которую вы вкладываете другие маленькие матрёшки, которые представляют собой поля и расширения сертификатов. Начинаете собирать самые маленькие матрёшки, вкладываете в более большие и в конечном итоге собираете настоящий сертификат. Хоть документация на MSDN не очень полная, используя командлет Get-Member вы можете восполнить этот пробел.

1 PS1 file
13,1 KB New-SigningCert.ps1

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell (часть 3)

Camelot — Mon, 14 Dec 2009 18:47:12 GMT

Продолжаем серию постов, которые посвящены базовому управлению объектами PKI в Active Directory. На данный момент мы рассмотрели сценарии публикации и просмотра сертификатов в Active Directory:

На данном этапе нам осталось последнее — удаление сертификатов из AD. Логика здесь очень простая: командой Get-ADPKIObject мы получаем коллекцию объектов, которые представляют собой сертификаты и через конвейер командой Remove-ADPKIObject указываем ID объектов, которые необходимо удалить. Если кто-то уже разбирал код предыдущих скриптов, то ему будет совсем нетрудно понять логику скрипта удаления объектов. Вот он, вместе с комментариями:

function Remove-ADPKIObject {
<#
.Synopsis
    Deletes certificates from Active Directory containers
.Description
    Deletes certificates from Active Directory containers by specifying particular ID or IDs
.Parameter ID
    Specifies certificate ID to delete that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | Remove-ADPKIObject 2
    
    deletes certificate with ID = 2 in certificate viewer
.Outputs
    This command provide a resultant of operation.
#>
    param([int[]]$ID = $(throw "you must specify number of the object to delete"))
    # объявляем массив для хранения сертификатов из контейнера NTAuthCertificates
    begin {$sum = @()}
    process {
        # проверяем тип контейнера входящего объекта
        if ($_.Container -ne "NTAuthCertificates") {
            # если это не NTAuthCertificates, то проверяем, что ID текущего объекта
            # совпадает с ID, который нужно удалить
            if (@($ID) -contains $_.Id) {
                # если совпал, то собираем LDAP-запрос
                $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
                # и удаляем текущий объект из AD
                $retn = $ldap.Delete("certificationAuthority", "CN=$($_.Subject)")
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            }
        # если контейнер текущего объекта является NTAuthCertificates, то собираем их все в массив
        } else {$sum += $_}
    }
    end {
        # проверяем, что массив непустой (т.е. надо что-то удалять из NTAuthCertificates)
        if ($sum) {
            # если массив непустой, то выбираем те элементы, которые нужно сохранить
            # т.е. ID которых не содержится в аргументах скрипта
            $sum = @($sum |?{$ID -notcontains $_.Id})
            # делаем LDAP-запрос к этому контейнеру
            $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
            # проверяем, что после фильтрации, хотя бы один сертификат нужно оставить
            if ($sum.count -ge 1) {
                # записываем первый сертификат. Это необходимо потому что ADSI не поддерживает запись
                # массива сертификатов в свойство cACertificate, а только один сертификат в виде byte[]
                $ldap.put("cACertificate", [byte[]]$sum[0].RawCertificate)
                # а вот простое добавление он поддерживает. Тогда ADSI сам пересоберёт объекты
                # в свойстве в нужный формат данных. На данном этапе я применил маленькую хитрость:
                # как видно, я первый сертификат записываю дважды - предыдущей строкой и в первой итерации
                # текущей строки. Но это не проблема, поскольку метод SetInfo() записывает только уникальные
                # объекты, а дублирующиеся просто отбросит.
                $sum | %{$ldap.cACertificate += ,[byte[]]$($_.RawCertificate)}
                $ldap.SetInfo()
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            # а вот если после фильтрации объектов, у нас ничего не остаётся на запись, то это означает, что все
            # сертификаты из этого контейнера удаляются. Поэтому мы просто удаляем запись NTAuthCertificates.
            } else {
                ([ADSI]"LDAP://$script:ConfigContext").Delete("certificationAuthority", "CN=NTAuthCertificates")
                if ($?) {Write-Host "All certificates was sucessfully deleted from NTAuthCertificates entry ." -ForegroundColor Green
                    Write-Warning "This was last certificate in contaner. NTAuthCertificates entry is removed from Active Directory"
                }
            }
        }
    }
}

И теперь можно подвести краткие итоги. Мы смогли реализовать функционал certutil и других графических утилит (консоли MMC) в PowerShell значительно улучшив читабельность выходных объектов, адаптировали под работу из консоли (синтаксис стал значимо короче и более юзерфрендли) и шаг за шагом делаем из PowerShell единое консольное средство управления различными аспектами PKI.

Можно задать вопрос: а кто целевая аудитория всего этого? Целевая аудитория есть — администраторы PKI. Просто у вас не всегда будет возможность использовать графические консоли для решения этих задач (потому что их функционал далёк от идеального). Можно использовать certutil, который умеет много чего, но тоже имеет свои недостатки. Это и ужасный синтаксис, и вырвиглазный неуправляемый вывод результатов. Вобщем я надеюсь, что рано или поздно PowerShell сможет по-настоящему заменить certutil (который вообще-то ни в чём не виноват) и стать единой консолью всех Windows-администраторов. Вот не знаю на сколько это хорошо или плохо, потому что Microsoft всех насильно переводит на PowerShell (это очень показательно продемонстрировано в MS Exchange, где у вас по сути есть только PowerShell и всё). Обычно, насильно переводят на другой инструмент когда он является УГ и очень тяжело на него перевести людей посредством обычной рекламы. Но является ли PowerShell таким УГ? Я пока не готов ответить на этот вопрос. Моё мнение — PowerShell пока что особой революцией не стал. Даже не смотря на тонны рекламы, пеара и прочего, где восхваляют PowerShell, закидывают ногами CMD/WSH. Это обусловлено тем фактом, что не всегда PowerShell бывает удобней CMD/WSH, особенно в тривиальных задачах. Говорить, что синтаксис стал более простым и компактным тоже нельзя, потому что реально функционала из коробки хватает для решения процентов 10 задач. Всё остальное нужно скриптовать и программировать (да-да!) самому. Благо средств для этого в PowerShell хватает. Во что это обычно выливается? А в то, что в большинстве случаев результирующий объём кода будет не сильно меньше, чем в связке WSH + CMD. В любом случае преимущества PowerShell перед остальными очевидны, но они далеко не определяющие, ведь люди раньше решали свои задачи на WSH/CMD, пирожки продавались, бизнес шёл. С одной стороны Microsoft дал людям простор для творчества, т.е. делать в PowerShell всякие потрясающие штуки и всё такое. Но это не совсем то, что нужно было администраторам. Им нужна одна кнопка на весь экран с надписью «Сделать всё п**дато!». Пока что PowerShell и близко не готов стать такой кнопкой, а является «удочкой». Т.е. удочка у вас уже есть, а что касается конечной рыбы (результата), то дело осталось за малым — написать мега-скрипт. Мне вот интересно, что думают администраторы Exchange (поскольку пока что только они получили полноценную поддержку для своего продукта в PowerShell) — стало ли им жить легче с PowerShell или нет? Если да, то это может быть хорошим знаком, что однажды PowerShell станет такой кнопкой. И не будет более в системе certutil и всеми задачами будет рулить PowerShell (пока что это наиболее логичный сценарий развития событий). А вот если их жизнь не стала легче, то обещанной революции (которая по словам Microsoft уже наступила, как и вендекапец у луноходов) не будет, а будет просто какое-то логическое продолжение предыдущих инструментов для сценариев.

К чему я написал столько букв? К тому, что я ежедневно задаю себе один и тот же вопрос: а зачем я всё это делаю? А ответ найти очень непросто, потому что отмазы вида «проще, удобней, красивее» не годятся для серьёзного аргумента. На самом деле я не ищу ответ на него, а просто говорю себе «так надо» и делаю. Поэтому не надо меня использовать как пример «правильного пользователя PowerShell» и пытаться повторить что-то подобное астрономических масштабов на овер9000 строк — поверьте, оно не стоит того. Используйте его по мере сил. Если чего-то будет не хватать и его решение потребует значительных усилий — посмотрите на готовые утилиты, они наверняка будут уметь то, что вам надо.

Удачи!© One

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell (часть 2)

Camelot — Fri, 11 Dec 2009 21:09:45 GMT

В предыдущем посте мы ознакомились с основными контейнерами с объектами PKI в Active Directory и смогли изучить функциональный аналог ключа dspublish в утилите certutil. Если публикация сертификатов в AD задача простая даже для Certutil, то просмотр содержимого может быть весьма нетривиальным. Например, если вы хотите посмотреть содержимое записи NTAuthCertificates, то придётся выполнить вот такую команду:

certutil –viewstore "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration, ForestRootDomainDN"

такие вещи совершенно неприспособлены к командной строке, поскольку надо набирать много текста и ошибиться весьма просто. Одно хорошо, команда выводит графическое окошко, где мы можем посмотреть содержимое. Но тут есть несколько неудобных моментов: мы не можем посмотреть несколько контейнеров сразу, для каждого контейнера надо выполнять отдельную команду. В этом окошке мы можем только посмотреть на содержимое контейнера и всё. Ни добавить, ни удалить сертификат мы не можем. Для добавления сертификатов мы можем воспользоваться тем же certutil или моим скриптом, который был опубликован в предыдущем посте. Графика — хорошо и замечательно, но мы можем хотеть автоматизировать какие-то задачи или просто посмотреть информацию в консоли. Вы можете подумать, что это не нужно, но преимущество между консольным выводом и графическим диалоговым окном очевидное: из первого можно копировать информацию в буфер обмена. Есть ещё вариант — для просмотра и удаления сертификатов из AD, пользоваться консолью pkiview.msc. Но мы сразу же теряем главную нить — единое средство управления. Т.е. даже похожие операции мы должны выполнять в разных инструментах! Но с появлением PowerShell мы получили единый (хоть и консольный) инструмент, которым можно автоматизировать абсолютно всё! Даже сам PowerShell Вот, собственно код, который в разы упрощает процесс просмотра содержимого контейнеров:

function Get-ADPKIObject {
<#
.Synopsis
    Displays certificates info from Active Directory containers
.Description
    Displays info about certificates that are stored in AD PKI-related containers.
.Parameter Container
    Optional parameter. Specifies particular container to view. May contain one or
    more value from following possible values:
    
    RootCA - retrieves certificates from Certification Authorities container
    SubCA - retrieves certificates from AIA container
    NTAuthCA - retrieves certificates from NTAuthCertificate directory entry.
    
    if no parameter is set, command will return all certificates from all applicable
    containers.
.EXAMPLE
    Get-ADPKIObject RootCA
    
    Retrieves certificates from Certification Authorities container
.EXAMPLE
    Get-ADPKIObject RootCA, AIA
    
    Retrieves certificates from Certification Authorities and AIA containers
.Outputs
    Output AD PKI object collection
#>
[CmdletBinding()]
    param([string[]][ValidateSet("RootCA", "SubCA", "NTAuthCA", "")]$Container)
    # объявляем массив, который будет хранить выходные объекты
    $script:sum = @()
    # это весьма крутая штука будет. Каждый объект будет содержать свойство Id или просто
    # порядковый номер объекта. При дальнейших операциях с этими объектами вам достаточно
    # будет указать его Id вместо длинных и неудобных LDAP/Thumpbrint значений, как это делается
    # в certutil и подобных ему утилитах. Нумерацию начнём с единицы
    $script:n = 1
    # итоговая функция, которая будет разбирать бинарные массивы и готовить выходные объекты
    function _formatter_ ($certs, $type, $name) {
        # поскольку у нас все объекты в AD находятся в бинарном формате, мы импортируем каждый из них
        # в X509Certificate2 объект.
        $certs | %{
            $script:Cert.Import($_)
            # здесь мы создаём образец выходного объекта и обвязываем этот объект необходимыми свойстами и данными
            $current = "" | select @{n='Id';e={$script:n}}, Subject, @{n='Type';e={$type}}, @{n='Container';e={$name}},
                @{n='Thumbprint';e={$script:Cert.Thumbprint}}, @{n='SerialNumber';e={$script:Cert.SerialNumber}}, 
                @{n='ValidFrom';e={$script:Cert.NotBefore}}, @{n='ValidTo';e={$script:Cert.NotAfter}}, 
                @{n='RawCertificate';e={$script:Cert.RawData}}
            # чтобы не писать полный DN поля Subject, мы будем показывать только первую его часть
            # (которая отображается в самом сертификате)
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $current.Subject = $matches[1]
            # добавляем объект в массив выходных объектов
            $script:sum += $current
            # очищаем X509Certificate2
            $script:Cert.Reset()
            # увеличиваем счётчик и обрабатываем следующий элемент
            $script:n++
        }
    }
    # ещё одна суб-функция, которая выдёргивает сертификаты из AD в бинарном виде и отправляет
    # их в _formatter_, который уже сформирует итоговые объекты.
    function _switcher_ ($name) {
        # подключаемся к нужному контейнеру
        $ldap = [ADSI]("LDAP://CN=$name,$script:ConfigContext")
        # как мы знаем, NTAuthCertificates не является контейнером, поэтому для него код будет немного
        # отличаться. А отличие будет состоять в том, что мы не будем залезать в контейнер, а сразу читать
        # свойства объекта NTAuthCA
        if ($name -eq "NTAuthCertificates") {
            # убеждаемся, что длина первого элемента свойства cACertificate больше единицы, т.е. содержит ненулевое
            # значение. Так же проверяем свойство crossCertificatePair, которое содержит Cross-certificates
            # и если оно не нулевое, то отправляем и его на формирование вывода
            if ($ldap.cACertificate[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "CA Certificate" $name
            }
            if ($ldap.crossCertificatePair[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "Cross CA Certificate" $name
            }
            # и переходим к следующему контейнеру
            return
        }
        # если контейнер указан как Certification Authority и/или AIA, то заглядываем
        # внутрь контейнера
        $ldap.psbase.children | %{
        # и заглядываем в каждую запись на исследование свойств cACetificate и crossCertificatePair
            $certs = @($_.cACertificate)
            $ccerts = @($_.crossCertificatePair)
            # проверяем, что свойство имеет ненулевое значение. Если так, то отправляем
            # содержимое этих свойств на формирование вывода
            if ($certs[0].count -gt 1) {_formatter_ $certs "CA Certificate" $name}
            if ($ccerts[0].count -gt 1) {_formatter_ $ccerts "Cross CA Certificate" $name}
        }
    }
    switch ($Container) {
        # конструкцией switch проверяем содержимое аргумента функции, чтобы определить какие именно
        # контейнеры надо обследовать.
        "RootCA" {_switcher_ "Certification Authorities"}
        "SubCA" {_switcher_ "AIA"}
        "NTAuthCA" {_switcher_ "NTAuthCertificates"}
        # если контейнер в аргументе не указан, то проверяем все контейнеры и записи
        "" {
            _switcher_ "Certification Authorities"
            _switcher_ "AIA"
            _switcher_ "NTAUthCertificates"
        }
    }
    # когда вывод будет полностью сформирован, выбрасываем все объекты в консоль
    $script:sum
}

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

и вывод у него вот такой красивый:

Id             : 3
Subject        : Contoso CA
Type           : CA Certificate
Container      : AIA
Thumbprint     : BA8FECE99165E68CE27C9F0AF5F0664FDA39F7A2
SerialNumber   : 5DD87E4CFFE3B3BC43F608EB57C767F7
ValidFrom      : 2009.02.15. 16:31:15
ValidTo        : 2014.02.15. 16:40:11
RawCertificate : {48, 130, 4, 98...}

Id             : 4
Subject        : sysadmins-LV-CA
Type           : Cross CA Certificate
Container      : AIA
Thumbprint     : 1A28B582E21803D2BFE0DAEEF4593DE372C8EC3C
SerialNumber   : 170AD11B0000000000A7
ValidFrom      : 2009.11.24. 19:43:10
ValidTo        : 2011.03.30. 17:06:53
RawCertificate : {48, 130, 7, 94...}

я считаю его достаточно информативным. Но если хотите посмотреть любой сертификат из этого списка, то можно и сделать просмотр. К сожалению я в программировании не шарю и как работать напрямую с библиотекой просмотрщика сертификатов, поэтому я реализовал просмотр обходным путём:

filter View-ADPKIObject {
<#
.Synopsis
    Displays certificates in certificate viewer
.Description
    Displays certificates in certificate viewer by selecting necessary certificates ID.
    Must be placed after Get-ADPKIObject command only.
.Parameter ID
    Specifies certificate ID that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | ViewADPKIObject 1, 3
    
    displays certificate with ID = 2 in certificate viewer
.Outputs
    Script doesn't generate any output except errors
#>
    # судя по конструкции int[] мы можем указать несколько чисел, тогда все выбранные
    # сертификаты будут отображены. Номер указывать обязательно.
    param([int[]]$ID = $(throw "you must specify number of the object to display"))
    # и проверяем входные объекты с конвейера на предмет их ID. Если ID совпадает с
    # одним из ID в аргументах, обрабатываем его. Если ID не совпадает, ничего не делаем.
    if (@($ID) -contains $_.Id) {
        # генерируем в пользовательской папке Temp временный файл с рандомным расширением
        $TempFile = [System.IO.Path]::GetTempFileName() + ".cer"
        # записываем бинарный массив сертификата в файл в виде DER кодировки
        [System.IO.File]::WriteAllBytes($TempFile, $_.RawCertificate)
        # запускаем файл (просмоторщик сертификатов)
        & $TempFile
        # в санитарных целях ждём пол секунды
        Start-Sleep 0.5
        # и удаляем этот файл, чтобы не копился мусор
        del $TempFile -Force
    }
}

Как вы видите, ничего сверх-космического или магического в этом коде нет, самое трудное здесь — придумать логику работы. А остальное — накидать несколько строк кода и у нас PowerShell в лёгкую может соперничать с certutil за право называться единой утилитой управления PKI

Чтобы подкрутить рейтинг PowerShell в этой конкуренции, в следующий раз я покажу как мы можем легко и просто удалять сертификаты из контейнеров AD с использованием PowerShell

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell

Camelot — Wed, 09 Dec 2009 19:35:17 GMT

Подоспела ещё одна задачка для PowerShell'а — управление объектами PKI в Active Directory. Active Directory содержит целый раздел посвящённый PKI и вот из чего он состоит:

CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=Certification Authority, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain

Вот о них мы сегодня и поговорим. В AD есть ещё несколько контейнеров, которые связаны с PKI, но они сегодня интереса представлять не будут. Как мы уже знаем, в:

NTAuthCertificates публикуются все сертификаты CA, которые выдают сертификаты для аутентификации пользователей в домене. В том числе для логона смарт-картой, аутентификации в IIS или для аутентификации EAP-TLS в VPN. Все сертификаты в этой записи хранятся в виде массива;
AIA публикуются сертификаты промежуточных (Intermediate) CA, за счёт чего можно значительно сократить время построения цепочек сертификатов. При этом не обязательно должен содержать сертификаты CA, которые зарегистрированы в текущем лесу. Это могут быть сертификаты промежуточных CA сторонних компаний, сертификаты которых вы используете. По большому счёту сюда должны публиковаться все сертификаты;
CDP публикуются CRL списки CA для ускорения проверки сертификатов в цепочке. Так же, как и в случае с AIA не обязательно может содержать CRL'ы CA только текущего леса. Сюда могут публиковаться и CRL сторонних CA, сертификаты которых вы используете;
Certification Authority публикуются сертификаты корневых CA, которым должен доверять весь лес.

Вы спросите, а зачем это всё, если то же самое можно сделать через групповые политики? Ответ тут достаточно очевиден. Дело в том, что PKI не видит границ доменов и эти сертификаты распространяются по всему лесу вместе с репликацией. Поэтому для добавления нового доверенного корневого CA вам придётся создавать одинаковую политику в каждом домене леса. И вы некоторые объекты (например CRL) не можете распространять через GPO.

Какие у нас есть инструменты для управления данными контейнерами? Их у нас несколько:

ADSIEdit.msc — обеспечивает только просмотр содержимого контейнеров в AD (но сами записи там нечитабельны);
PKIView.msc — позволяет просматривать содержимое каждого контейнера и удалять оттуда сертификаты. C использованием данной консоли мы можем добавлять сертификаты только в NTAuthCertificates. Остальные — только чтение и удаление;
certutil — интерфейс командной строки, который позволяет добавлять, просматривать контейнеры и удалять сертифакты из них.

Кажется, что certutil'а хватит всем. Но у него есть одна большая проблема — ужасный синтаксис. Напрмер, если вы хотите посмотреть CRL'ы в AD, то придётся делать что типа такого:

certutil –viewstore ldap:///CN=MyCA,CN=CRL,CN=CDP,CN=Public%20Key%
20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

этот синтаксис возможно чем-то универсален, но cовершенно неудобный для использования в командной строке, поэтому я поставил задачу решить этот вопрос с помощью PowerShell. И вот как я его решил:

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

#####################################################################
# dspublish.ps1
# Version 0.7
#
# Adds certificates in Active Directory containers
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

# любая ошибка будет фатальной, поэтому при её возникновении останавливаем работу
# скрипта, чтобы предотвратить фатальные изменения в Active Directory
trap {break}
# объявляем глобальные переменные, которые будут использоваться всеми функциями скрипта
$script:ConfigContext = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetDirectoryEntry().distinguishedName
$script:ConfigContext = "CN=Public Key Services,CN=Services,CN=Configuration," + $script:ConfigContext
$script:Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2

function Publish-ADPKIObject {
<#
.Synopsis
    Publishes certificates to Active Directory containers
.Description
    Publishes certificates to Public Key Services containers in Active Directory.
.Parameter File
    Specifies the path to certificate file or X509Certificate2 object.
    Certificates may be passed through pipeline.
.Parameter Container
    Specifies the AD PKI container to publish file. For certificates only
    following containers MUST be used:
    
    RootCA - indicates that certificate will be published to Certification Authorities container
    SubCA - indicates that certificate will be published to AIA container
    NTAuthCA - indicates that certificate will be added to NTAuthCertificate directory
    entry. If not exist, entry will be created.
    
    you MAY specify several containers at once. Certificate will be added to all
    specified containers. Entry names are based on certificate subject.
    
.Parameter Force
    forces object rewrite if object already exist in Active Directory
.EXAMPLE
    dir *.cer | Publish-ADPKIObject RootCA, SubCA
    
    will publish all .CER certificates to Certification Authorities and AIA containers
.EXAMPLE
    Publish-ADPKIObject certificate.cer RootCA -Force
    
    will publish 'Certificte.cer' certificate to Certification Authorities container. If
    object already exist, it will rewrited
.Outputs
    This command provide a resultant of operation.
#>
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [object[]]$file,
        [Parameter(Mandatory = $true, Position = 1)]
        [string[]]$Container,
        [switch]$Force
    )
    begin {
        # функция, которая будет осуществлять запись сертификатов в AD
        function _ldaproutine_ ($ldap, $CN, $script:Cert, $name, $Force) {
            $path = [ADSI]"LDAP://$ldap"
            # убеждаемся, что такой же объект не существует в AD
            if ($($path.psbase.children | ?{$_.cn -eq $CN})) {
                # если существует, проверяем ключ Force, который позволяет перезаписывать
                # объекты
                if ($force) {
                    $ldap = [ADSI]"LDAP://CN=$CN,$ldap"
                    # если ключ Force указан, то мы просто перезаписываем свойство
                    # cACertificate новым сертификатом
                    $ldap.put("cACertificate", $script:Cert.RawData)
                    # предыдущей строкой мы просто перезаписали объект, который теперь
                    # надо записать в AD методом SetInfo()
                    $retn = $ldap.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully rewrited to `'$name`' container" -ForegroundColor Green}
                # если объект уже существует и ключ Force не указан, то просто выводим сообщение, что такой объект уже существует
                } else {Write-Warning "Object already exist in `'$name`' container. Use -Force switch to rewrite"}
            } else {
                # если объект ещё не существует в указанном контейнере, то создаём в нём новый объект
                # с типом certificationAuthority
                $CA = $path.Create("certificationAuthority","CN=$CN")
                # записываем сертификат в свойство cACertificate в бинарном виде из объекта X509Certificate2
                $CA.Put("cACertificate", $script:Cert.RawData)
                # записываем нулями обязательные поля, которые требуются для создания объекта. Использовать как есть.
                $CA.Put("authorityRevocationList", 0)
                $CA.Put("certificateRevocationList",0)
                # когда объект сформирован, записываем его в AD
                $retn = $CA.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
            }
        }
    }
    # рабочая секция, которая будет разбирать входные сертификаты и подготавливать необходимые данные
    # которые необходимы для записи 
    process {
        # выбираем текущий объект сертификата
        $script:Certificate = gi $file -ErrorAction Stop
        # проверяем, что объект не является готовым объектом X509Certificate2
        if ($script:Certificate -isnot [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            # если не является, то это будет файл. Проверяем расширение файла.
            # допускаются только расширения CER и CRT
            if (".cer", ".crt" -contains $script:Certificate.Extension) {
                # если это CER или CRT файл, то конвертируем его в объект X509Certificate2
                $script:Cert.Import($script:Certificate.FullName)
                # в переменную $CN записываем первую часть поля Subject сертификата
                [void]($script:Cert.Subject -match 'CN=([^,]+)')
                $CN = $matches[1]
            }
        # если у нас на конвейер или через аргументы поступил готовый X509Certificate2, то только выбираем
        # поле Subject в отдельную переменную.
        } else {
            $script:Cert = $script:Certificate
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $CN = $matches[1]
        }
        # проверяем аргументы, которые указывают на контейнеры, куда надо записывать наши сертификаты.
        # я не делал проверку этих контейнеров в секции param() через использование ValidateSet
        # поскольку данная функция в будущем будет использоваться и для публикации CRL. А для
        # них нужно вручную прописывать имя записи в контейнере CDP и оно может быть произвольным.
        # отфильтровываем все неправильные контейнеры, которые были заданы при вызове функции
        $Container = $Container | ?{"RootCA","SubCA","NTAuthCA" -contains $_}
        # если после фильтрации ни одного валидного контейнера не осталось, то очень сильно ругаемся.
        if (!$Container) {throw "For certificate containers only following values are applicable: RootCA, SubCA, NTAuthCA"}
        # проверяем, что входной сертификат содержит свойство CertificateAuthority равным True.
        # это свойство соответствует расширению Basic Constraints в сертификате, которое может иметь
        # значения: Subject Type=CA - это сертификат CA и Subject Type=End entity, если это конечный
        # сертификат. А в X509Certificate2 конечный сертификат будет иметь значение False в свойстве
        # CertificateAuthority. Но работу скрипта не прерываем, а просто пропускаем текущий сертификат.
        if (!$script:Cert.Extensions | ?{$_.CertificateAuthority -eq $true}) {
            Write-Warning "Input certificate `'$CN`' is not recognized as CA certificate. Skipping"
            return
        }
        # а теперь подготавливаем необходимые данные для записи в зависимости от названия контейнера
        switch ($Container) {
            "RootCA" {
                # указываем название данного контейнера в AD
                $name = "Certification Authorities"
                # получаем LDAP объект этого контейнера
                $ldap = "CN=$name,$script:ConfigContext"
                # и отправляем всё это в функцию записи
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "SubCA" {
                # здесь то же самое, что и для RootCA
                $name = "AIA"
                $ldap = "CN=$name,$script:ConfigContext"
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "NTAuthCA" {
                $name = "NTAuthCertificates"
                $ldap = [ADSI]"LDAP://CN=$name,$script:ConfigContext"
                # поскольку NTAuthCertificates не является контейнером, а отдельной
                # записью, которая содержит массив сертификатов, то правила записи
                # здесь немного иные. Сначала проверяем, что эта запись уже существует в AD.
                if (!$ldap.cn) {
                    # если нет, то создаём её
                    $CA = ([ADSI]"LDAP://$script:ConfigContext").Create("certificationAuthority","CN=$name")
                    # заполняем обязательные свойства объекта и первый сертификат.
                    $CA.Put("authorityRevocationList", 0)
                    $CA.Put("certificateRevocationList",0)
                    $CA.put("cACertificate", $script:Cert.RawData)
                    # когда объект уже готов, то просто записываем его в AD
                    $retn = $CA.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                    return
                }
                # а вот если эта запись уже есть, то ничего создавать не надо, а просто добавляем
                # новый сертификат вдобавок к существующим. При этом обратите внимание, что объект добавляется
                # как массив (используется запятуя сразу за оператором). Это связано с особенностью работы PowerShell с
                # массивами. Поскольку бинарный сертификат сам по себе является массивом, то при простом добавлении
                # к существующему бинарному массиву, просто сделает ресайз текущего массива. Чтобы новый массив
                # записать как отдельный элемент нового массива - надо при помощи запятой явно это указать
                $ldap.cACertificate += ,$cert.RawData
                # и записываем объект обратно в AD.
                $retn = $ldap.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                $script:Cert.Reset()
            }
        }
    }
}

А примеры использования этого скрипта приведены во встроенном хелпе и сводятся к одной из схем:

Publish-ADPKIObject <certificate> <container> –Force
<certificate> | Publish-ADPKIObject –Force

Причём вы можете указывать несколько контейнеров сразу, например: Publish-ADPKIObject file.cer NTAuthCA, RootCA, SubCA. Я думаю, что этот скрипт получился не такой уж и сложный и его разобрать с помощью моих комментариев не так и сложно. Его можно спокойно расширить под другие контейнеры, например, CDP или KRA. Единственное, что здесь пока не реализовано — санитизация имён объектов. На сколько я знаю, certutil этого тоже не поддерживает. Но сделать её надо. Правда, я пока не нашёл ни одного стандартного механизма, который бы санитизировал имена

PowerShell Powered - http://www.sysadmins.lv

CryptoAPI и управление Certification Authority с помощью PowerShell (часть 4)

Camelot — Fri, 20 Nov 2009 16:40:36 GMT

В продолжении темы исследования COM интерфейсов CryptoAPI для управления службами Certificate Services предлагаю теперь разобрать вопросы KRA — Key Recovery Agents. Сначала напомню уже изученные темы по CryptoAPI:

И на сегодня наш план выглядит достаточно интересно:

Получение списка доступных KRA в лесу и просмотр их сертификатов
Получение списка KRA назначенных на сервере CA;
Назначение новых KRA для CA.

Получение списка доступных KRA в лесу

KRA используется для архивирования закрытых ключей сертификатов в БД CA. В случае если пользователь уничтожил свой закрытый ключ он может его восстановить. Для этого нужно обратиться к администратору CA для извлечения BLOB (Binary Large OBject) в файл. После чего агент восстановления (KRA) использует свой закрытый ключ для расшифровки закрытого ключа из BLOB'а. Учитывая, что я и не только уже рассматривали этот вопрос, я не буду пересказывать принцип работы Key Archival:

Все сертификаты KRA публикуются в forest naming configuration context партиции AD и реплицируется между всеми контроллерами в лесу. Публикация просисходит в точке:

CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain

PS C:\> $ldap = [ADSI]"LDAP://CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=contoso,dc=com"
PS C:\> $ldap

distinguishedName
-----------------
{CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}


PS C:\> $kra = $ldap.psbase.children | %{$_}
PS C:\> $kra

distinguishedName
-----------------
{CN=contoso-DC2-CA,CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}
{CN=Contoso CA,CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}

Мы получили список CA в лесу и посмотрев каждый из них можем посмотреть сколько KRA сертификатов выпустил каждый CA:

PS C:\> $kra[1] | fl *


objectClass            : {top, msPKI-PrivateKeyRecoveryAgent}
cn                     : {Contoso CA}
userCertificate        : {48 130 6 104 48 130 5 80 160 3 2 1 2 2 10 21 29 22 96 0 0 0 0 0 4 48 13 6 9 42 134 72 134 247
                          13 1 1 5 5 0 48 67 49 19 48 17 6 10 9 146 38 137 147 242 44 100 1 25 22 3 99 111 109 49 23 48
                          21 6 10 9 146 38 137 147 242 44 100 1 25 22 7 99 111 110 116 111 115 111 49 19 48 17 6 3 85 4
                          3 19 10 67 111 110 116 111 115 111 32 67 65 48 30 23 13 48 57 48 50 49 53 49 53 48 53 50 53 9
                         0 23 13 49 49 48 50 49 53 49 53 48 53 50 53 90 48 86 49 19 48 17 6 10 9 146 38 137 147 242 44
                         100 1 25 22 3 99 111 109 49 23 48 21 6 10 9 146 38 137 147 242 44 100 1 25 22 7 99 111 110 116
<...>

Свойство UserCertificate в виде массива может содержать сертификаты KRA в виде байтового массива. Например, указанный CA выпустил 2 сертификата KRA:

PS C:\> $kra[1].usercertificate.count
2

И обратившись к индексам этого свойства можно получить конкретные сертификаты: $kra[1].usercertificate[0]. Если CA не выпускал сертификаты для KRA, то свойство UserCertificate будет содержать число ноль:

PS C:\> $kra[0] | fl *


objectClass            : {top, msPKI-PrivateKeyRecoveryAgent}
cn                     : {contoso-DC2-CA}
userCertificate        : {0}
<...>

Поэтому для получения всех сертификатов KRA нужно пройтись по всем членам CN=KRA и выбрать из них ненулевые значения свойства UserCertificate. Если сертификатов больше, чем 1, то они будут храниться в этом свойстве в виде массива. Чтобы посмотреть сам сертификат, вы можете просто сохранить этот массив байтов в файл:

PS C:\> [System.IO.File]::WriteAllBytes("C:\kra.cer",$kra[1].usercertificate[1])
PS C:\> & .\kra.cer

Получение списка KRA назначенных на сервере CA

А теперь вернёмся к интерфейсу ICertAdmin2. С его помощью мы можем посмотреть количество агентов восстановления, которые назначены на CA и посмотреть их сертификаты. Однако, этот интерфейс имеет какой-то баг с PropID, которые связаны с KRA, о которых я писал в предыдущей статье, поэтому для получения этих данных мы будем использовать интерфейс ICertRequest3.

PS C:\> $CertRequest = New-Object -ComObject CertificateAuthority.Request.1
PS C:\> $CertRequest.GetCAProperty("dc1\contoso ca",0x18,0,1,0)
1
PS C:\> $CertRequest.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0)
0
PS C:\> $CertRequest.GetCAProperty("dc1\contoso ca",0x19,0,1,0)
1
PS C:\> $CertRequest.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0)
0

Мы видим, что на сервере DC1 назначен 1 агент восстановления, а на DC2 ни одного. Сегодня мы добавим агентов восстановления на DC2.

Примечание: чем отличаются KRACERTUSEDCOUNT и KRACERTCOUNT? KRACERTCOUNT показывает сколько всего KRA назначено на конкретном сервере CA. А KRACERTUSEDCOUNT показывает сколько из них будет использовать CA при архивации каждого закрытого ключа сертификата и это число может быть меньше, чем общее количество сертификатов KRA. В таком случае CA рандомно выбирает KRACERTUSEDCOUNT сертификатов и шифрует ими закрытый ключ. Например, KRACERTCOUNT = 5, а KRACERTUSEDCOUNT = 3, то CA при архивации ключа выберет рандомно 3 сертификата KRA из списка и зашифрует ими ключ. И только эти 3 агента восстановления могут восстановить ключ, а остальные 2 уже не смогут.

Получение списка KRA назначенных на сервере CA

Чтобы посмотреть сами сертификаты KRA, мы должны воспользоваться PropID = CR_PROP_KRACERT (0x1A).

И вот что мы увидим:

PS C:\> $CertAdmin.GetCAProperty("dc1\contoso ca",0x1A,0,3,0)
-----BEGIN CERTIFICATE-----
MIIGaDCCBVCgAwIBAgIKFR0WYAAAAAAABDANBgkqhkiG9w0BAQUFADBDMRMwEQYK
CZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHY29udG9zbzETMBEGA1UE
AxMKQ29udG9zbyBDQTAeFw0wOTAyMTUxNTA1MjVaFw0xMTAyMTUxNTA1MjVaMFYx
EzARBgoJkiaJk/IsZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgdjb250b3NvMQ4w
DAYDVQQDEwVVc2VyczEWMBQGA1UEAxMNQWRtaW5pc3RyYXRvcjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJG7T5yMninhrkXFQU8WGUr5BYYUeOz10Rkn
<...>

В нулевом индексе мы видим первый сертификат. Последующие будут храниться в других индексах:

$CertAdmin.GetCAProperty("dc1\contoso ca",0x1A,$Index,3,0)

Этот сертификат можно спокойно записать в файл и через GUI просмотреть его свойства. Но вообще это не родной формат сертификата KRA для данного интерфейса, поскольку добавлять сертификаты KRA на сервере CA нужно в ASN1 DER-encoded string формате. Т.е. Flags должен быть не 0, а 2:

$CertAdmin.GetCAProperty("dc1\contoso ca",0x1A,$Index,3,2)

и увидим примерно такое:

PS C:\> $kra = $CertAdmin.GetCAProperty("dc1\contoso ca",0x1a,0,3,2)
PS C:\> $kra
?????A???`  ?????c?♣??????????????????T???????????????????????????????????????T????????????????????????????????????????
??ca♣??????☺???????????????????????????????????????????????????????????????????????????????????????????????????????????
??????????????????????☺????????Є?????????????????☻???????☻??????????????ЎЖ?????????????CA??????Ё????????????h??A???????
??????????????????????????????????????????????╣????????????????????????????????????????????????????????????????????????
?????????????????????C?cЁ??????C???????????????????????????????????????????????????????????????????????????????????????
???????????????????????????????????????Х???CA?????Ё???????CA?????Б????CA??????????????????????a???☺????????????????????
????????????????????????????????????c?????????????????????????????????????H╝??????????????????{?????????????

выглядит весьма уныло, но вот в таком формате и надо записывать сертификаты агентов восстановления в CA.

Назначение новых KRA для CA

Когда мы рассмотрели основные моменты связанные с агентами восстановления в контексте CryptoAPI, мы можем приступить к финальной части — назначению новых агентов восстановления. В принципе, здесь нет ничего сложного, поскольку для добавления KRA нужно сделать 5 вещи:

Получить массив байтов, которые бы представляли сертификат агента восстановления откуда угодно. Хоть из AD, хоть из файла сертификата;
Используя специальный конвертер, разобрать этот массив на пары байтов, сконвертировать эти пары в little-endian hex строку, получить десятичное представление этой hex-строки и получить итоговую символьную строку;
Записать эту строку используя метод SetCAProperty();
Задать новое количество используемых агентов восстановления;
Перезапустить службу CA.

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

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import(".\desktop\kra.cer")
$bytes = $cert.RawData

и переменная $bytes будет содержать такой же байтовый массив.

А вот с конвертером чуть сложнее. Я не нашёл ни одного готового конвертера, который бы выполнял все шаги из пункта 2, поэтому я написал свой конвертер с блек-джеком и шлюхами:

function ConvertTo-DERstring ([byte[]]$bytes) {
    # создаём объект StringBuilder, который нам будет собирать конечную символьную строку
    $SB = New-Object System.Text.StringBuilder
    # преобразовываем каждый байт в его hex значение
    $bytes1 = $bytes | %{"{0:X2}" -f $_}
    # циклом перебираем каждую пару байт
    for ($n = 0; $n -lt $bytes1.count; $n = $n + 2) {
        # переставляем элементы пары местами, чтобы получить little-endian hex-строку
        # после чего получаем десятичное представление этой строки и получаем Unicode
        # символ, который соответствует этому десятичному значению.
        [void]$SB.Append([char](Invoke-Expression 0x$(($bytes1[$n+1]) + ($bytes1[$n]))))
    }
    $SB.ToString()
}

А дальше уже по накатанной дороге:

[Administrator] # создаём COM объект ICertAdmin2
[Administrator] $CertAdmin = new-object -com certificateauthority.admin.1
[Administrator] # выбираем все Enterprise CA
[Administrator] $ldap = [ADSI]"LDAP://CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=contoso,dc=com"
[Administrator] $kra = $ldap.psbase.children | %{$_}
[Administrator] # сразу конвертируем все сертификаты в DER-encoded string
[Administrator] $kra1 = ConvertTo-DERstring $kra[1].usercertificate[0]
[Administrator] $kra2 = ConvertTo-DERstring $kra[1].usercertificate[1]
[Administrator] # можем убедиться на месте, что строка имеет ожидаемый вид
[Administrator] $kra2
?????A???E  ?????c?♣??????????????????T???????????????????????????????????????T????????????????????????????????????????
??ca♣??????☺????????????????????????????K?????????????????????????????????????????????т????????????????????????????????
??????????????????????☺????????Є?????????????????☻???????☻??????????????ЎЖ?????????????CA??????Ё????????????h??A???????
??????????????????????????????????????????????╣????????????????????????????????????????????????????????????????????????
?????????????????????C?cЁ??????C???????????????????????????????????????????????????????????????????????????????????????
???????????????????????????????????????Х???CA?????Ё???????CA?????Б????CA??????????????????????a???☺????????????????????
????????????????????????????????????????????????????????????????????????????????????????????????????????????
[Administrator] # и записываем первую строку сертификат агента восстанвовления в нулевой индекс
[Administrator] $CertAdmin.SetCAProperty("dc2\contoso-dc2-ca",0x1a,0,3,$kra1)
[Administrator] # все последующие строки сертификатов записываются в последующие индексы массива
[Administrator] $CertAdmin.SetCAProperty("dc2\contoso-dc2-ca",0x1a,1,3,$kra2)
[Administrator] # используем PropID = KRACERTUSEDCOUNT (0x18), чтобы сказать сколько у нас будет использоваться агентов
[Administrator] # я буду их использовать все
[Administrator] $CertAdmin.SetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,2)
[Administrator] # перезапускаем службу CertSvc
[Administrator] $wmi = gwmi win32_service -comp dc2 -filter "name='certsvc'"
[Administrator] [void]$wmi.StopService()
[Administrator] [void]$wmi.StartService()
[Administrator] # и проверяем нашу работу:
[Administrator] $CertReq = new-object -com certificateauthority.request.1
[Administrator] $CertReq.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0)
2
[Administrator] $CertReq.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0)
2
[Administrator]

всё.

PowerShell Powered - http://www.sysadmins.lv

CryptoAPI и управление Certification Authority с помощью PowerShell (часть 3)

Camelot — Mon, 16 Nov 2009 16:04:48 GMT

Update 05.12.2009: разработчики подтвердили баг в ICertAdmin2 интерфейсе. Проблема заключается в том, что после первого запроса указанных PropID они кешируются и при смене контекста конфигурации (Certification Authority), этот кеш не очищается.

Прежде чем продолжать исследование CryptoAPI COM интерфейсов, предлагаю посмотреть несколько полезных ссылок и поговорить о багах в интерфейсе ICertAdmin2.

При использовании интерфейса ICertAdmin2, ICertRequest2D (этот интерфейс мы ещё посмотрим в будущих постах) мы используем различные аргументы для получения свойст CA с использованием метода GetCAProerty(). И вот их где мы можем получить числовые значения этих аргументов:

PropID и PropType — 3.2.1.4.3.2 ICertRequestD2::GetCAProperty (Opnum 7)
Flags — EncodingType Enumeration

А теперь поговорим о багах. Как выяснилось, ICertAdmin2::GetCAProperty(), который определён в библиотеке certadm.dll имеет баги с PropID, которые связаны с количественной информацией. Будь то количество сертификатов CA, количество агентов восстановления ключей (Key Recovery Agents) и т.д. И вот в чём это выражается:

DC1 — корневой CA с именем Contoso CA. Имеет 2 сертификата CA и одного назначенного агента восстановления;
DC2 — подчинённый CA с именем Contoso-DC2-CA. Имеет 1 сертификат CA и ни одного назначенного агента восстановления.

Мы будем получать данные как с локального CA, так и с удалённого CA запуская код с каждого сервера. Кратко об используемых PropID:

0x0B — количество сертификатов CA;
0x19 — общее количество агентов восстановления на CA;
0x18 — общее количество используемых агентов восстановления;

И вот какие результаты мы видим, когда собираем эти свойства с сервера DC1:

[Administrator] # создаём COM объек:
[Administrator] $CertAdmin = New-Object -com CertificateAuthority.Admin.1
[Administrator] # получаем список сертификатов CA на локальном серве
[Administrator] # мы видим 2 сертификата, как положено
[Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0xb,0,1,0)
2
[Administrator] # и он то же самое показывает и для удалённого сервера, хотя там всего 1 сертификат
[Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0)
2
[Administrator] # ладно, смотрим, сколько всего KRA у нас на локальном сервере. Их 1, как на самом деле
[Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0x19,0,1,0)
1
[Administrator] # используемых сертификатов тоже 1.
[Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0x18,0,1,0)
1
[Administrator] # как я уже говорил, на DC2 нет агентов восстановления, хотя метод показывает их по одному в обоих случаях
[Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0)
1
[Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0)
1
[Administrator]

собираем ту же информацию, запуская код с сервера DC2:

PS C:\> # создаём COM объект:
PS C:\> $CertAdmin = New-Object -com CertificateAuthority.Admin.1
PS C:\> # получаем список сертификатов CA с локального сервера.
PS C:\> # их мы видим ровно 1, как и должно быть
PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0)
1
PS C:\> # в предыдущем примере мы видели, что на DC1 2 сертификата CA.
PS C:\> # проверим, так ли это?
PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0xb,0,1,0)
1
PS C:\> # wow! обломс, метод возвращает тоже 1. А сколько у нас агентов восстановления?
PS C:\> # и снова облом. На сервере DC1 нет агентов восстановления (хотя предыдущий пример говорит об обратном):
PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0x19,0,1,0)
0
PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0x18,0,1,0)
0

а теперь посмотрим на результаты с использованием того же метода и тех же PropID, но с использованием интерфейса ICertRequest, который определён в библиотеке certcli.dll. Те же тесты уже возвращают правильные результаты:

с DC1:

[Administrator] $request = New-Object -com CertificateAuthority.Request.1
[Administrator] $request.GetCAProperty("dc1\contoso ca",0xb,0,1,0)
2
[Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0)
1
[Administrator] $request.GetCAProperty("dc1\contoso ca",0x19,0,1,0)
1
[Administrator] $request.GetCAProperty("dc1\contoso ca",0x18,0,1,0)
1
[Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0)
0
[Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0)
0
[Administrator]

с DC2:

PS C:\> $request = New-Object -com CertificateAuthority.Request.1
PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0)
1
PS C:\> $request.GetCAProperty("dc1\contoso ca",0xb,0,1,0)
2
PS C:\> $request.GetCAProperty("dc1\contoso ca",0x19,0,1,0)
1
PS C:\> $request.GetCAProperty("dc1\contoso ca",0x18,0,1,0)
1
PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0)
0
PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0)
0
PS C:\>

Поэтому следует с осторожностью относиться к выводу ICertAdmin2::GetCAProperty(), а ещё лучше — использовать этот метод, который реализован в интерфейсе ICertRequest::GetCAProperty(). Чем это вызвано я пока не знаю, но задал я задал вопрос нужным людям, поэтому я дам знать в случае ответа на вопрос.

PowerShell Powered - http://www.sysadmins.lv

CryptoAPI и управление Certification Authority с помощью PowerShell (часть 2)

Camelot — Tue, 10 Nov 2009 16:04:48 GMT

В первой части управления Certification Authority (CA) мы рассмотрели метод GetCAProperty, при помощи которого мы можем получать различные сведения про сервер CA. Сегодня мы посмотрим ещё несколько интересных моментов, которые будут связаны с CRL и опять будет немного треша с CryptoAPI, а именно:

Получение статуса публикации CRL;
Получение Base и Delta CRL из CA в виде файлов;
Отзыв сертификатов;
Извлечение сертификатов из CRL;
Публикация новых CRL.

Начало работы

Для начала мы должны будем создать ICertAdmin2 COM объект для управления CA, который будет использоваться нами для всех сегодняшних операций:

PS C:\> $CertAdmin = New-Object -ComObject "CertificateAuthority.Admin.1"

Получение Base и Delta CRL из CA в виде файлов

Далее мы должны узнать PropID, который бы отвечал за показ CRL вот по этой ссылке: 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). Нас будет интересовать 2 этих ID: CR_PROP_BASECRL (0x11) и CR_PROP_DELTACRL (0x12). Поскольку тип возвращаемых данных будет Binary, то PropType будет равен 3, а Flags выставим в 0 (Base64CRLHeader). Можно и другой указать, от этого только зависит метод записи в файл.

Примечание: напоминаю, что индекс PropType начинается с 1, а Flags с 0 и их возможные значения описаны здесь: GetCAProperty. А так же то, что в Flags первые 2 значения перепутаны местами на MSDN.

И вот как мы их можем получить:

PS C:\> $BaseCRL =  $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x11,0,3,0)
PS C:\> $BaseCRL
-----BEGIN X509 CRL-----
MIIEDTCCAvUCAQEwDQYJKoZIhvcNAQEFBQAwRzETMBEGCgmSJomT8ixkARkWA2Nv
bTEXMBUGCgmSJomT8ixkARkWB2NvbnRvc28xFzAVBgNVBAMTDmNvbnRvc28tREMy
LUNBFw0wOTExMDkwNjI0NDlaFw0wOTExMTcwNjQ0NDlaMIIBzDAbAgpG7E9iAAAA
AACSFw0wOTExMDgxODM5MDBaMCkCCm716aoAAAAAAI8XDTA5MTAyMjE2MjI1OVow
DDAKBgNVHRUEAwoBBDAbAgpxOBcQAAAAAACLFw0wOTA5MjgwNjMzMDBaMBsCCl6/
ZbYAAAAAAIkXDTA5MDkyNDE3MTcwMFowGwIKXnVZiQAAAAAAiBcNMDkwOTI0MTUw
MjAwWjApAgoggMu3AAAAAAAVFw0wOTA1MTcyMDE0MDBaMAwwCgYDVR0VBAMKAQUw
KQIKYRZ2nAAAAAAADRcNMDkwNTAxMTk1MzAwWjAMMAoGA1UdFQQDCgEFMCkCCmJ0
33IAAAAAAAoXDTA5MDQxOTEzMDUwMFowDDAKBgNVHRUEAwoBBDApAgphINAVAAAA
AAAHFw0wOTAzMzExMTEzMDBaMAwwCgYDVR0VBAMKAQUwKQIKYRT3zAAAAAAABhcN
MDkwMzMxMTAzMTAwWjAMMAoGA1UdFQQDCgEFMCkCCmERwOwAAAAAAAUXDTA5MDMz
MTEwMTgwMFowDDAKBgNVHRUEAwoBBDApAgphDxXgAAAAAAAEFw0wOTAzMzExMDE0
MDBaMAwwCgYDVR0VBAMKAQSggakwgaYwHwYDVR0jBBgwFoAUZiAsZ5wOPk1F8vmX
BZdmE1QTJjYwEAYJKwYBBAGCNxUBBAMCAQAwCwYDVR0UBAQCAgDyMBwGCSsGAQQB
gjcVBAQPFw0wOTExMTYwNjM0NDlaMEYGA1UdLgQ/MD0wO6A5oDeGNWh0dHA6Ly9k
YzIuY29udG9zby5jb20vQ2VydEVucm9sbC9jb250b3NvLURDMi1DQSsuY3JsMA0G
CSqGSIb3DQEBBQUAA4IBAQCCNVxtZbAbB5C1bI5Z6PF+Eph2MaRhl9pv0FjYhH/j
Xlvffau1m5bW72No7FC2k8FFU2oHFSZvAVNKgjm6+ECb4iEpzREcHpwsot1TG0kn
Pv+DRGjQ2ndes8OM11v3oYUJxlNOMqY6q03lj/BEJb+ocNerWRay8G0sycy1ABCD
/UPvP9qq54WvwQnJyV5bZJcJG3WYtN7zkZZzf5MR3v+c4OODLiLw5pXgku49USFu
kTuEh5DYcF5zbo6h5IqAW+OP6iMFepxkUEZUb/5VOYK8VcpXDwMzIRzlf+bITHyX
6PVugwm6TXkn9eVrAfJUd70S9LV7XVTz32IykC3tNXFY
-----END X509 CRL-----


PS C:\> $DeltaCRL =  $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x12,0,3,0)
PS C:\> $BaseCRL > base.crl
PS C:\> $DeltaCRL > delta.crl
PS C:\> & .\base.crl
PS C:\> & .\delta.crl
PS C:\>

последние 2 команды просто запускают эти CRL файлы. К сожалению не существует ни одного родного класса, который бы представлял собой объект CRL, поэтому как-то разбирать его на таком уровне пока не представляется возможным. Хотя существуют сторонние библиотеки (например, в Mono есть класс X509CRL).

Получение статуса публикации CRL

Но мы можем кое что узнать о статусе наших CRL. Для этого существует PropID = CR_PROP_CRLSTATE (0x14). Тип возвращаемых данных будет Long, значит PropType будет 1, а Flags будет игнорироваться, поэтому поставим его в 0:

PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x14,0,1,0)
3

Расшифровку этого значения можно найти здесь: 3.2.1.4.2.2.20 PropID = 0x00000014 (CR_PROP_CRLSTATE) "CA CRL State". Число 3 означает, что с CRL у нас всё хорошо (CA_DISP_VALID (0x03)). В принципе, на данном этапе нам больше ничего и не нужно. Но мы можем посмотреть более детальные сведения по каждому типу CRL. Для получения более детальной ошибки мы должны использовать следующие PropID:

CR_PROP_BASECRLPUBLISHSTATUS (0x1E)
CR_PROP_DELTACRLPUBLISHSTATUS (0x1F)

Для этих PropID тип данных так же указан Long, поэтому PropType выставим в 1, а Flags в 0:

PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x1E,0,1,0)
5
PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x1F,0,1,0)
6
PS C:\>

Мы получили число 5 для BaseCRL и 6 для DeltaCRL. Расшифровку этих значений можно посмотреть вот здесь: 3.2.1.4.2.2.30 PropID = 0x0000001E (CR_PROP_BASECRLPUBLISHSTATUS) "Base CRL Publishing Status". Поскольку вывод — не конкретное число, а результат двоичного оператора И (AND), то мы это число должны разбить на составляющие. И вот как это делается:

$Return = $certadmin.GetCAProperty("ServerName\CA Name",0x1E,0,1,0)
$options = 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 | %{$Return -band $_} | ?{$_}
# поскольку значения масок являются результаты возведения двойки в степень
# начиная от 0 до 11, то эту строчку можно переписать более готично.
# Напоминаю, что возведение любого числа в нулевую степень
# всегда вернёт 1. Кажется, это из алгебры 5-6 класса.
$options = 0..11| %{[Math]::Pow(2,$_)} | %{$Return -band $_} | ?{$_}
switch ($options) {
    1 {"The CRL is a base CRL"}
    2 {"The CRL is a delta CRL"}
    4 {"The last CRL publication that was completed and published to the locations specified in the CA"}
    8 {"The CRL is a shadow delta CRL"}
    16 {"The CA MAY publish the CRL to a local store that is not externally accessible.
        This error is returned when publishing to this intermediate store failed"}
    32 {"An error occurred during publication of the CRL.
        The error indicates that the file schema cannot be recognized.The schema must be file: or ldap:"}
    64 {"Publication of the CRL was manually initiated by an administrator"}
    128 {"A CRL signature error was detected. The CSP was not correct"}
    256 {"An error occurred during publication of the CRL to an LDAP URL"}
    512 {"An error occurred during publication of the CRL to a file URL"}
    1024 {"An error occurred during publication of the CRL to an FTP URL. FTP URLs are not supported"}
    2048 {"The CA cannot publish CRLs to HTTP URLs. This error is returned if a CA administrator
        configured the CA to publish CRLs to HTTP URLs"}
}

Следовательно число 5 (1+4) говорит нам о том, что это был Base CRL и он был опубликован успешно. А 6 (2+4) — Delta CRL был опубликован успешно.

Отзыв сертификатов

Интерфейс IcertAdmin2 позволяет нам отзывать сертификаты на сервере CA. Для этого мы воспользуемся методом RevokeCertificate(). Метод достаточно простой и примерная команда для отзыва сертификата будет выглядеть так:

$CertAdmin.RevokeCertificate("ServerName\CA Name", 0123456789,4,(Get-Date).AddDays(1))

0123456789 будет обозначать серийный номер сертификата, 4 — причина отзыва будет Superseded и эффективная дата отзыва (когда сертификат будет помещён в Revoked Certificates) будет 24 часа после выполнения команды. Да, именно этим методом можно отзывать корневые сертификаты .

Извлечение сертификатов из CRL

Примечание: хоть Microsoft и поддерживает извлечение сертификатов из CRL (отмена статуса Revoked), этой возможностью не следует пользоваться в силу определённых причин, как невозможность определеления в какое время сертификат был помещён и извлечён из CRL.

Если сертификат был отозван со статусом Certificate Hold (6), то его можно в любое время вернуть обратно. Для всех остальных типов отзыва такая возможность не поддерживается. Для отмены статуса Revoked нужно использовать этот же метод, только в качестве причины отзыва указать значение MAX_DWORD, которое является 0xffffffff или просто –1:

$CertAdmin.RevokeCertificate("ServerName\CA Name", 0123456789,-1,0)

Публикация новых CRL

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

$CertAdmin.PublishCRLs("ServerName\CA Name",0,0)

Эта команда переопубликует как основной, так и инкрементальный CRL (при публикации Base CRL инкрементальный CRL публикуется всегда, потому что Effective Date у него не может быть меньше, чем у Base CRL). Что касается последнего аргумента, то он бывает ещё полезен, если по каким-то причинам потерялся какой-то файл CRL. Тогда вы можете выставить CRLFlags в 4 (0x4) и тогда CA переопубликует текущие CRL без обновления их содержимого и дат.

На сегодня это всё.

PowerShell Powered - http://www.sysadmins.lv

CryptoAPI и управление Certification Authority с помощью PowerShell

Camelot — Thu, 05 Nov 2009 20:22:36 GMT

Продолжая тему криптографии, предлагаю несколько ближайших постов посвятить вопросам использования CryptoAPI в PowerShell для управления Cerficiation Authority (сокращённо CA). Я считаю эту тему достаточно интересной, хоть у нас есть космическая утилита certutil.exe. Но тот, кто видел хелп к нему, тот знает какой это ужас, автоматизировать что-то с использованием certutil. Microsoft подарил нам не менее космический и православный инструмент автоматизации — PowerShell. К сожалению, вынужден признать, что в ряде задач PowerShell сильно уступает аналогам в cmd и с этим ничего нельзя поделать. Но по мере своих сил буду пытаться доказывать обратное. Одно из преимуществ PowerShell является поддержка .NET, который очень удобен в использовании. Но .NET не всемогущ и не содержит в себе ни единого класса, при помощи которого можно было бы управлять службой certificate services (точнее самим CA). CryptoAPI неплохо документированы на уровне unmanaged code (а это подразумевает использование низкоуровневых языков программирования, как C++). Но, опять, слава ~~сиськамСноверу~~Протоколу у нас есть одна лазейка — COM интерфейсы к CryptoAPI. Изучив немного эти интерфейсы, обнаружил, что они местами очень интересные и досточно легко управляемы. Но это не всегда так, иногда они бывают достаточно сложными для понимания с первого раза. В процессе исследования, были обнаружены вообще нелогичные вещи, с которыми нам придётся считаться.

Эти COM интерфейсы позволили мне реализовать едва ли не половину функционала моего PowerPack'а для PowerGUI. Оценить моё детище можно по этой ссылке: Enterprise PKI management. Я в него вложил достаточно много знаний для того, чтобы упростить жизнь администраторам инфраструктур PKI. Пока прогресс неважный, т.к. я пока только повторяю функционал консолей certmgr.msc, certsrv.msc, ocsp.msc и certutil.exe. Но я надеюсь реализовать там действительно что-то нужное и очень полезное.

Наша отправная точка на MSDN будет находиться здесь: Cryptography Interfaces. Для начала мы поработаем с интерфейсом ICertAdmin2, который зарегистрирован в системе как COM класс CertificateAuthority.Admin.1. Вот как он создаётся:

PS C:\> $CertAdmin = New-Object -ComObject "CertificateAuthority.Admin.1"
PS C:\> $CertAdmin | gm


   TypeName: System.__ComObject#{f7c3ac41-b8ce-4fb4-aa58-3d1dc0e36b39}

Name                     MemberType Definition
----                     ---------- ----------
DeleteRow                Method     int DeleteRow (string, int, Date, int, int)
DenyRequest              Method     void DenyRequest (string, int)
GetArchivedKey           Method     string GetArchivedKey (string, int, int)
GetCAProperty            Method     Variant GetCAProperty (string, int, int, int, int)
GetCAPropertyDisplayName Method     string GetCAPropertyDisplayName (string, int)
GetCAPropertyFlags       Method     int GetCAPropertyFlags (string, int)
GetConfigEntry           Method     Variant GetConfigEntry (string, string, string)
GetCRL                   Method     string GetCRL (string, int)
GetMyRoles               Method     int GetMyRoles (string)
GetRevocationReason      Method     int GetRevocationReason ()
ImportCertificate        Method     int ImportCertificate (string, string, int)
ImportKey                Method     void ImportKey (string, int, string, int, string)
IsValidCertificate       Method     int IsValidCertificate (string, string)
PublishCRL               Method     void PublishCRL (string, Date)
PublishCRLs              Method     void PublishCRLs (string, Date, int)
ResubmitRequest          Method     int ResubmitRequest (string, int)
RevokeCertificate        Method     void RevokeCertificate (string, string, int, Date)
SetCAProperty            Method     void SetCAProperty (string, int, int, int, Variant)
SetCertificateExtension  Method     void SetCertificateExtension (string, int, string, int, int, Variant)
SetConfigEntry           Method     void SetConfigEntry (string, string, string, Variant)
SetRequestAttributes     Method     void SetRequestAttributes (string, int, string)


PS C:\>

Как вы видите, этот интерфейс позволяет использовать достаточно много интересных методов. Давайте начнём с простого (а может быть и не очень простого) — GetCAProperty. По ссылке вообще ничего непонятно, что и как там использовать. Единственное, что я понял — это то, что данный метод принимает 5 параметров в определённом порядке и всё. Поэтому давайте будем считать, что этой странички не существует в природе (кроме случаев, когда будем преследовать порядок расположения аргументов). Пошарившись на MSDN, нашёл более годную ссылку в спецификациях Windows Communications Protocols — 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). И вот как должны выглядеть параметры:

strConfig — имя компьютера и сервера CA в формате ComputerName\CAName.
PropId — ID требуемого свойства. Должно указываться в числовом формате (т.к. тип данных указан Long). Это число можно взять из колонки Numerical Value таблички 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). Например, для получения DeltaCRL надо указать число 18 (0x12).
PropIndex — если свойство индексированное (т.е. содержит несколько искомых объектов), то PropIndex указывает на индекс массива, в котором хранится определённый объект искомого свойства. Например, CA может содержать несколько своих сертификатов. И с использованием PropIndex мы сможем выбирать различные сертификаты, выбирая их из массива. Начало индексирования начинается с нуля. Если свойство неиндексируемое, то это значение будет игнорироваться.
PropType — указываете тип данных, в котором хотите получить конкретное свойство. Во второй таблице уже указаны рекомендованные значения типов данных для каждого набора свойств. Тип данных так же нужно указывать в числовом формате. Однако, здесь индекс начинается не с нуля, а с единицы. Т.е. тип данных String будет иметь значение 4.
Flags — помимо типа возвращаемых данных нам нужно указать формат этих данных. Во второй таблице так же приведены рекомендованные (хотя слово MUST и ещё капсом как бы намекает на обязательность. Хотя, это не совсем так. Если вы в первый раз будете этим заниматься, то используйте значения из второй таблички). А вот здесь индекс начинается с нуля.

Примечание: по всей видимости в табличке с флагами закралась ошибка, т.к. использование первого флага даёт Base64, но с заголовками Begin/End Certificate. А второй — наоборот, без заголовка.

Вам кажется, что это всё ужасно и сложно? Поверьте, это не так. Давайте прочитаем парочку свойств. Например, прочитаем ссылки на CRL и CRT, которые публикуются в CDP и AIA издаваемых сертификатах. Исходя из таблички мы знаем, что CRL'ы вызываются PropID = 0x29 (или 41 в десятичной нотации), а CRT — PropID = 0x2A (или 42). Поскольку это индексируемое свойство, то первая ссылка будет содержаться в индексе 0 (первый индекс массива), а последующие ссылки в индексах 1 и далее и PropIndex мы укажем 0. PropType у нас будет String и числовое значение — 4 (не забываем, что PropType считаются начиная с единицы). Flags может быть любой, т.к. он будет игнорироваться при PropType = 4:

PS C:\> $CertAdmin.GetCAProperty("ca\sysadmins-lv-ca", 41, 0, 4, 0)
http://ca.sysadmins.lv/sysadmins-LV-CA.crl

PS C:\> $CertAdmin.GetCAProperty("ca\sysadmins-lv-ca", 42, 0, 4, 0)
http://ca.sysadmins.lv/sysadmins-LV-CA.crt

PS C:\>

Как вы видите, на самом деле здесь нет ничего страшного. Нужно лишь научиться оперировать табличкой. Давайте для разнообразия посмотрим на сертификат CA. Для этого мы должны найти PropID, который отвечал за сертификат. Это будет PropID = 0xC. Поскольку этот параметр так же индексируемый, то он будет содержать все сертификаты CA, если их там несколько. Самый первый сертификат будет храниться в индексе 0, следующий сертификат в индексе 1 и т.д. Исходя из таблички, PropType должен быть 3. Посмотрим сертификат в Base64 кодировке, т.е. Flags должен быть 0 или 1:

PS C:\> $cert = $CertAdmin.GetCAProperty("ca\sysadmins-lv-ca", 0xc, 0, 3, 0)
PS C:\> $cert
-----BEGIN CERTIFICATE-----
MIIFbTCCA1WgAwIBAgIQPf+vkU1hMoJCe9WRwftYbTANBgkqhkiG9w0BAQUFADBJ
MRIwEAYKCZImiZPyLGQBGRYCbHYxGTAXBgoJkiaJk/IsZAEZFglzeXNhZG1pbnMx
GDAWBgNVBAMTD3N5c2FkbWlucy1MVi1DQTAeFw0wOTA4MDYwNzIxMDFaFw0xNDA4
MDYwNzMwNTRaMEkxEjAQBgoJkiaJk/IsZAEZFgJsdjEZMBcGCgmSJomT8ixkARkW
CXN5c2FkbWluczEYMBYGA1UEAxMPc3lzYWRtaW5zLUxWLUNBMIICIjANBgkqhkiG
9w0BAQEFAAOCAg8AMIICCgKCAgEAwL5wHTMEsMg6yDzqWPd9e/GT856o9OWJrv4Y
9iXtTa5mkdEZsbckVmAJODG28lcI7ScuD0rfceB6/gVn4VMK2SITsOv2XzC3ApRE
zExEIuRmspFlpaDmOvBTYafkzokN2RJ+UQq8M9RSnSBHrOcvNJQYgglbjQOHsg4f
qyMoPoZ+LYjoGZcCtqmR+FMOnalUGohnanf/fQJ/gcoAET6H45rqAB/P90sWOsZo
pwCgGmvJe4GBXbZDg4ADZIbrYm2baxwKJlhsDAhzZ8Fo2irnSBFJavu6+LwQHv8P
fL/ZGHBlf8s+uTeHfluG95bIe8VAGRwEwCyV5t+emBLq4ny5Q21MjWGDD3YjkKjA
lqC7c2mpCC6YVxBArVVm1G7/d8mpBuO5ZzyqIVkEhxZuYPfK6k7EEKx3BuCC97UT
ZcSVJBCHmxbxWm/U30VIpu0HDlbCiHX0OSDRJhv32ppazDonGSp/GiBocXNKTLA+
PyXQqRvObovTFPMutzLQDczeee5zvfJ7Gs7xCskcsLp8uBuhGJMnW87hRglm4p0/
tdIViIbMrwbVxjtHPnp5MARvQBT26ZzE3k0zr9Do3Gi6AY8Jt6ssD6r5CXbBA5SF
iGgp1czWb2xToqJtzuEjG1ssBj5MTMzINa4bMhQs52nXdUI2aG7n7mwoAVR3tHiW
sK1lvdsCAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFHrmiNrp+Fw+BwTeEaI4Iql1oxOrMBAGCSsGAQQBgjcVAQQDAgEAMA0G
CSqGSIb3DQEBBQUAA4ICAQCuLfQSOcRoQ8EcuVMgIVjepuonY1MG7PhPvJ1fyanw
0MeKonNZ4a7gOop7R/8DSGBfnQMQJClVcFTxe8Osa88OkeJmb9LQix9wMfR1GAaw
NwaX6ve0x4Ixr7m3KQEBOc+fAAGNLcxnlIDUD9EiSlFqqH+HkjxREU5RmE0TQFVS
NfNtwFSX0loMuL8mo10m8CD/ETRdq6jXO6vMWll8wBirSD9/Zostn5+t1g6TU4fi
bpR/56ueiRh0px2A1lhDTTGjV7UTqPvavUqJejZJCHf269xJb1r8mc+AJn/O4g4q
WvVsTILLMw+Oit/7ZagFbjZa7jSBRFfEyU4lKnV9oxIO47FTjWgGi7R+Rg8VDWvQ
a5JMhMadUWrz5VQRY9iBr1wlmvZH5100otrikZLfVxQ+HZVccgLvZ4BJpdk+Lzyk
bqZSAwbOJlFF0po+4wWbakhzS/jZLcoO8NzE4SgW3NTcuWYsS2G8ubV139IykSCy
RA9UcyoNNQM8CXr6I2UmhQwBqMrGZIi/rybPRQvlVSssuusfbxIiWMjdo/mQyUH2
A1diiIt1bpkVdJ9yRSDtuldoYe2w0QtId6WWAg2H8bTiF+/cu1kZ//rcK5UQyuku
1ggS22YqWCUrSQ4/heQdP1Ni619sMHFcMYWZTP5XySLiN+BBrs6/4pnJOVNsy742
KQ==
-----END CERTIFICATE-----

PS C:\> $cert > file.cer
PS C:\> & c:\file.cer
PS C:\>

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

$CertAdmin.GetCAProperty("ServerName\CA Name", 0xC, 1, 3, 0)

Я просто увеличил PropIndex на единицу. Чтобы узнать сколько же там всего сертификатов, достаточно посмотреть PropID = 0x0B, PropType = 1 (т.к. команда нам вернёт число, то тип должен быть числовой — Long):

PS C:\> $CertAdmin.GetCAProperty("ca\sysadmins-lv-ca", 0xb, 0, 1, 0)
1
PS C:\>

Вот в данном случае у меня там всего 1 сертификат. На другом сервере у меня 2 сертификата:

[Administrator] $CertAdmin.GetCAProperty("dc1\contoso ca", 0xb, 0, 1, 0)
2
[Administrator]

Если вам это интересно, то советую поупражняться в получении различных свойств в различном формате с использованием ICertAdmin2 интерфейса и таблички: 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7).

Это была первая часть использования CryptoAPI в PowerShell. В следующих частях мы рассмотрим другие интересные методы интерфейса ICertAdmin2.

PowerShell Powered - http://www.sysadmins.lv

PowerShell V2 RTM для Windows XP/Vista/2003/2008

Camelot — Tue, 27 Oct 2009 18:34:36 GMT

Слава ~~сиськамПротоколу~~ Сноверу!

>> PowerShell V2 RTM <<

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell (часть 2)

Camelot — Mon, 19 Oct 2009 18:52:44 GMT

Примечание: данный материал публикуется на правах ТЗ (ТЗ — Тайное Знание) и обязателен для знания администраторам PKI.

В предыдущей части (Certificate chaining engine в PowerShell) мы рассмотрели реализацию certificate chaining engine в .NET в виде класса X509Chain. Но этот рассказ был бы неполным, если мы не поговорили про CAPICOM.Chain. Хоть Microsoft рекомендует использовать .NET, а не CAPICOM для решения данной задачи, я считаю необходимым осветить этот вопрос. Для начала начнём с реализации CAPICOM в PowerShell. По непонятным мне пока причинам мне не удалось завести его в PowerShell на системах Windows Vista и выше, поэтому примеры буду приводить на Windows Server 2003.

PS G:\> $chain = New-Object -ComObject "CAPICOM.Chain"
PS G:\> $chain

Certificates
------------



PS G:\> $chain | gm -MemberType methods


   TypeName: System.__ComObject#{ca65d842-2110-4073-aee3-d0aa5f56c421}

Name                MemberType Definition
----                ---------- ----------
ApplicationPolicies Method     IOIDs ApplicationPolicies ()
Build               Method     bool Build (ICertificate)
CertificatePolicies Method     IOIDs CertificatePolicies ()
ExtendedErrorInfo   Method     string ExtendedErrorInfo (int)


PS G:\>

Так же, как и в .NET у нас есть метод Build(), который запускает certificate chaining engine для указанного сертификата. Но это COM объект и X509Certificate2 объекты не принимает. Поэтому мы средствами этого же CAPICOM получим нужный объект сертификата:

PS G:\> $store = New-Object -ComObject "CAPICOM.Store"
PS G:\> $store.Open(2,"my",128)
PS G:\> $cert = @()
PS G:\> $store.Certificates | %{$cert += $_}
PS G:\> $cert = $cert[1]
PS G:\> $cert


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :



PS G:\>

Вот такой объект сертификата мы получили. Вот его и пропустим через метод Build():

PS G:\> $chain.Build($cert)
False
PS G:\> $chain.Status()
32
PS G:\> $chain.Certificates


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :

Version       : 3
SerialNumber  : 3DFFAF914D613282427BD591C1FB586D
SubjectName   : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.06. 10:21:01
ValidToDate   : 2014.08.06. 10:30:54
Thumbprint    : E82ACC45841280DDEAB9F7847418FA26354457A7
Archived      : False
PrivateKey    :



PS G:\> $chain.ApplicationPolicies()

                                   Name FriendlyName                            Value
                                   ---- ------------                            -----
                                    123 Smart Card Logon                        1.3.6.1.4.1.311.20.2.2
                                    101 Client Authentication                   1.3.6.1.5.5.7.3.2


PS G:\>

Метод вернул False, т.е. наш сертификат не прошёл проверку. Свойство Certificates содержит все сертификаты в текущей цепочке. А метод ApplicationPolicies() показал Application Policies (в прошлом EKU). Ну и метод Status() вернул код ошибки. Все коды ошибок расписаны в описании самого метода. Т.е. ошибка 32 по табличке означает:

CAPICOM_TRUST_IS_UNTRUSTED_ROOT (&H00000020) — The certificate or certificate chain is based on an untrusted root.

Особо углубляться дальше я смысла не вижу, поскольку используя эти примеры можно поупражняться в других задачах с использованием CAPICOM. А вместо этого, мы разберём кое-какие неочевидные, но очень важные вещи.

Когда вышел Remote Desktop Connection 7.0 (который поставляется вместе с Windows 7), Александр Станкевич (MVP: Enterprise Security) заметил очень плохую особенность с ним, а именно — рандомно пропал доступ к терминальным серверам, которые используют SSL для терминальных подключений. В ходе множества проверок было констатировано:

цепочка завершалась на доверенном корневом сертификате (через просмотр сертификата);
CDP/AIA пути были валидные и CRL не были просрочены;
остальные параметры были сконфигурированы верно.

RDP клиент мотивировал отказ в подключении следюущим: «RDP клиент не смог проверить сертификат на отзыв». Причём подключение с предыдущих версий RDC, а так же подключение к TS Web Access через IE было успешным. Как выяснилось на днях, причина была в том, что в новом RDC был изменён алгоритм certificate chaining engine и новая версия RDC больше не доверяла корневым сертификатам в пользовательском хранилище. Переустановка корневого сертификата в компьютерное хранилище решала проблему RDC 7. Но, как я говорил, в Windows 7/2008 R2 было изменено поведение certificate chaining engine в реализации X509Chain. Продемонстрирую небольшую табличку, которая покажет доверие пользовательским корневым сертификатам в CAPICOM и .NET реализациях certificate chaining engine для различных операционных систем:

	X509Chain (.NET)	CAPICOM.Chain (CryptoAPI)
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2

Таблица доверия пользовательскким корневым сертификатам различными движками построения цепочки сертификатов

Следует учитывать, что различные приложения могут использовать свой движок для построения цепочек сертификатов, как RDC 7.0 и PKIView.msc использует CAPICOM, а PowerShell — X509Chain. Однако, у меня есть уверенность, что существует ещё одна реализация этого движка, которую использует Internet Explorer. Это только мои догадки, но они основаны на том, что Internet Explorer (кроме Windows 7 и выше) использует пользовательский контейнер для проверки SSL веб-сайтов, т.е. по симптомам похоже на X509Chain. Однако, этот класс появился только в .Net Framework 2.0, которого, к примеру в оригинальной инсталляции Windows XP/2003 не было. Либо, как вариант, есть возможность настраивать этот момент в каждой реализации движка построения цепочек, но я пока не нашёл как. Это пока всё, что у меня есть по этому поводу.

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell

Camelot — Sat, 17 Oct 2009 20:51:59 GMT

Я предлагаю снова поговорить о certificate chaining engine, о котором мы уже говорили в посте Certificate Chaining Engine — как это работает но в рамках его реализации в .NET и PowerShell. В Windows есть несколько реализаций этого chaining engine. Самые популярные:

CAPICOM — вещь несколько стрёмная и её лучше избегать. Тем более мне не удалось завести его в Vista/Windows 7. Реализация в .NET в виде X509Chain ничуть не хуже, но, в то же время, проще. Итак, предлагаю начать с создания этого объекта с помощью New-Object:

[↓] [vPodans] $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
[↓] [vPodans] $chain

                 ChainContext ChainPolicy                   ChainStatus                   ChainElements
                 ------------ -----------                   -----------                   -------------
                            0 System.Security.Cryptograp... {}                            {}


[↓] [vPodans] $chain | gm -membertype methods


   TypeName: System.Security.Cryptography.X509Certificates.X509Chain

Name        MemberType Definition
----        ---------- ----------
Build       Method     bool Build(System.Security.Cryptography.X509Certificates.X509Certificate2 certificate)
Equals      Method     bool Equals(System.Object obj)
GetHashCode Method     int GetHashCode()
GetType     Method     type GetType()
Reset       Method     System.Void Reset()
ToString    Method     string ToString()


[↓] [vPodans]

Здесь видно, что метод, который будет строить и проверять цепочку будет называться Build() и в качестве аргумента этот метод принимает только объекты x509Certificate2, а возвращать объект типа Boolean — True/False. Объекты такого типа можно найти в провайдере Certififcates (просто выполнить dir cert:\store\container) или импортировать из файла — Импорт сертификатов в PowerShell. Но сначала мы посмотрим, что здесь можнол настроить. А настроить можно ChainPolicy, представляющий собой объект X509ChainPolicy. Эта политика позволяет задавать порядок проверки отзыва сертификатов, соответствие сертификата каким-то certificate policy, наличие определённых application policy (в прошлом известен нам как EKU — Extended Key Usage) и некритичность каких-то ошибок. Мы всё разбирать не будем, а только основное:

[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

Первое, что может быть интересным — Revocation Mode, который задаёт режим проверки отзыва и может иметь 3 вполне понятных значения, которые перечислены в X509RevocationMode:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationmode])
NoCheck
Online
Offline

Тут очень просто:

NoCheck — проверяет цепочку сертификатов без проверки на отзыв любых сертификатов в цепочке;
Online — проверяет сертификаты в цепочке скачивая новые списки CRL из свойства CDP сертификата, игнорируя локальный кеш CRL (используется по умолчанию, как это видно в просмотре свойств ChainPolicy)
Offline — проверяет сертификаты на отзыв с использованием кешированного CRL (если есть).

Если проверяем сертификаты на отзыв, то мы можем выбрать что именно будем проверять и этот выбор перечислен в X509RevocationFlag:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationflag])
EndCertificateOnly
EntireChain
ExcludeRoot

и здесь тоже всё достаточно понятно:

EndCertificateOnly — проверяет на отзыв только сам проверяемый сертификат. Остальные сертификаты в цепочке не проверяются;
EntireChain — проверяет на отзыв абсолютно все сертификаты в цепочке включая корневой сертификат. Правила хорошего тона диктуют нам не включать в корневой сертификат CA поля CDP и AIA, поскольку это лишено смысла и в большинстве случаев с этим флагом вы будете получать невалидную цепочку;
ExcludeRoot — проверяет на отзыв все сертификаты в цепочке, кроме корневого сертификата, что есть религионзно правильно и этот флаг установлен по умолчанию.

Следующий момент определяет флаги проверки, т.е. по каким именно критериям будет проверяться цепочка сертификатов:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509verificationflags])
NoFlag
IgnoreNotTimeValid
IgnoreCtlNotTimeValid
IgnoreNotTimeNested
IgnoreInvalidBasicConstraints
AllowUnknownCertificateAuthority
IgnoreWrongUsage
IgnoreInvalidName
IgnoreInvalidPolicy
IgnoreEndRevocationUnknown
IgnoreCtlSignerRevocationUnknown
IgnoreCertificateAuthorityRevocationUnknown
IgnoreRootRevocationUnknown
AllFlags

Эти флаги так же достаточно понятны и подробно разжёваны в перечислении X509VerificationFlags.

Примечание: эти флаги показывают что будет исключено из проверки, а не наоборот. По умолчанию проверяется всё (установлен NoFlag).

Как можно задавать эти флаги и режимы, если есть такая потребность? Можно пойти двумя способами — правильным и неправильным, хотя оба рабочие:

[↓] [vPodans] # правильный метод:
[↓] [vPodans] $revflag = [System.Security.Cryptography.X509Certificates.X509RevocationFlag]::EndCertificateOnly
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = $revflag
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : EndCertificateOnly
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans] # неправильный метод, но мне он нравится
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = "excluderoot"
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

В принципе, все эти enumeration можно просто указывать в виде строки, а PowerShell уже сам подобъёт его под нужный тип.

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

В принципе, можно делать проверку:

[↓] [vPodans] $valid = (dir cert:\currentuser\my)[1]
[↓] [vPodans] $invalid = (dir cert:\currentuser\my)[0]
[↓] [vPodans] $chain.Build($valid)
True
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
E82ACC45841280DDEAB9F7847418FA26354457A7  CN=sysadmins-LV-CA, DC=sysadmins, DC=lv


[↓] [vPodans]

Я из локального хранилища взял заведомо хороший сертификат и плохой (разумеется, это сертификат с сайта БиЛайн ). Метод Build() вернул True, что означает успешную проверку всей цепочки моего сертификата до доверенного корня. А вот что случилось с сертификатом билайна:

[↓] [vPodans] $chain.reset()
[↓] [vPodans] $chain.Build($invalid)
False
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
EB74DA32E865C78FCB853DDA5FE45962098E1B3B  CN=trust.beeline.ru, OU=DIT, O=Vimpelcom, L=Moscow, S=Moscow, C=RU


[↓] [vPodans] $chain.ChainStatus

                                                     Status StatusInformation
                                                     ------ -----------------
                                               PartialChain Sertificesanas kedi nevareja veidot pie uzticamas saknes...
                                    RevocationStatusUnknown Atsauksanas funkcija nevareja parbaudit sertifikata atsa...
                                          OfflineRevocation Atsauksanas funkcija nevareja parbaudit atsauksanu, jo a...


[↓] [vPodans] $chain.ChainStatus | %{$_.statusinformation.trim()}
Sertificesanas kedi nevareja veidot pie uzticamas saknes iestades.
Atsauksanas funkcija nevareja parbaudit sertifikata atsauksanu.
Atsauksanas funkcija nevareja parbaudit atsauksanu, jo atsauksanas serveris bija bezsaiste.
[↓] [vPodans]

Поскольку при каждой проверке сертификаты в ChainElements накапливаются, то после каждой проверки следует очищать объект методом Reset(). Как и следовало ожидать, сертификат билайна вернул False, показывая, что цепочка у этого сертификата имеет проблемы. В случае неуспешной проверки, будет заполняться свойство ChainStatus. Данное свойство содержит все ошибки, которые были костатированы при проверке цепочки. Для меня пока непонятным стал факт, что ошибки он написал на латышском языке, хотя я его об этом не просил. Откуда он это взял — непонятно, но он сказал, что не смог построить цепочку до доверенного корня и функция проверки отзыва провалилась по всем статьям, поскольку пути в CDP сертификата нерабочие.

Примечание: обязательно следует учитывать тот факт, что при построении цепочки сертификатов и проверке доверия класс X509Chain в Windows 7 и Windows Server 2008 R2 работает в контексте LocalSystem и всегда игнорирует пользовательские контейнеры Trusted Root Certification Authorities. Поэтому если корень цепочки не заканчивается на одном из сертификатов Trusted Root CAs хранилища LocalMachine, то цепочка будет считаться недоверенной. Для предыдущих ОС цепочка может заканчиваться на пользовательском хранилище Current User.

В принципе это всё, что вам следует знать про реализацию certificate chaining engine в .NET и его использование в PowerShell. В качестве бонуса прилагаю скрипт для проверки цепочки сертификатов:

#####################################################################
# Test-Certificate.ps1
# Version 1.0
#
# Passes certificate through certificate chaining engine
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires –Version 2.0

function Test-Certificate {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        $Certificate,
        [System.Security.SecureString]$Password,
        [ValidateSet("NoCheck", "Online", "Offline")]
        [string]$CRLMode = "Online",
        [ValidateSet("EndCertificateOnly", "EntireChain", "ExcludeRoot")]
        [string]$CRLFlag = "ExcludeRoot",
        [ValidateSet("AllFlags", "AllowUnknownCertificateAuthority", "NoFlag", "IgnoreNotTimeValid",
            "IgnoreCtlNotTimeValid", "IgnoreNotTimeNested", "IgnoreInvalidBasicConstraints",
            "IgnoreWrongUsage", "IgnoreInvalidName", "IgnoreInvalidPolicy", "IgnoreEndRevocationUnknown",
            "IgnoreCtlSignerRevocationUnknown", "IgnoreCertificateAuthorityRevocationUnknown",
            "IgnoreRootRevocationUnknown")]
        [string[]]$VerificationFlags = "NoFlag"
    )
    
    begin {
        # создаём объекты X509Certificate2 и X509chain ещё до поступлениея первого объекта сертификата
        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
        $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
        # в X509Chain записываем параметры проверки сертификатов. Как критерии
        # отзыва, так и исключения из проверки
        $chain.ChainPolicy.RevocationFlag = $CRLFlag
        $chain.ChainPolicy.RevocationMode = $CRLMode
        $chain.ChainPolicy.VerificationFlags = $VerificationFlags
        # мини-функция для предоставления понятного вывода на экран о статусе проверки
        # и ошибках в цепочке, если они есть.
        function _getstatus_ ($status, $chain, $cert) {
            if ($status) {
                Write-Host Current certificate $cert.SerialNumber chain and revocation status is valid -ForegroundColor Green
            } else {
                Write-Warning "Current certificate $($cert.SerialNumber) chain is invalid due of the following errors:"
                $chain.ChainStatus | %{Write-Host $_.StatusInformation.trim() -ForegroundColor Red}
            }
        }
    }
    
    process {
        # если аргумент сертификата уже является объектом X509Certificate2, то
        # сразу строим цепочку и получаем статус цепочки вызывая мини-функцию
        if ($_ -is [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            $status = $chain.Build($_)
            _getstatus_ $status $chain $_
        } else {
        # если аргумент не является объектом X509Certificate2, то это будет путь к файлу
        # если указанный путь не существует, то ругаемся и выходим
            if (!(Test-Path $Certificate)) {Write-Warning "Specified path is invalid"; return}
            else {
            # если путь существует, то проверяем, что это путь файловой системы.
            # если это не так, то ругаемся и выходим
                if ((Resolve-Path $Certificate).Provider.Name -ne "FileSystem") {
                    Write-Warning "Spicifed path is not recognized as filesystem path. Try again"; return
                } else {
                # если предварительные проверки прошли успешно, то выбираем объект файла
                    $Certificate = gi $(Resolve-Path $Certificate)
                # и на основании расширения файла через Switch преобразуем файл в
                # X509Certificate2 объект или объекты
                    switch -regex ($Certificate.Extension) {
                    "\.CER|\.DER|\.CRT" {$cert.Import($Certificate.FullName)}
                    "\.PFX" {
                        if (!$Password) {$Password = Read-Host "Enter password for PFX file $certificate" -AsSecureString}
                        # тут пришлось указать контекст хранилища, куда предполагается сохранить сертификат.
                        # на самом деле мы никуда не будем сохранять объект сертификата, это было сделано
                        # по причине отсутствия подходящего конструктора метода Import(), чтобы
                        # можно было указать только путь к файлу и пароль от PFX
                            $cert.Import($Certificate.FullName, $password, "UserKeySet")
                        }
                    "\.P7B|\.SST" {
                        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
                        $cert.Import([system.IO.File]::ReadAllBytes($file.FullName))
                        }
                    default {Write-Warning "Looks like your specified file is not a certificate file"; return}
                    }
                    # полученный объект или объекты сертификатов пропускаем через метод Build() и вызываем
                    # мини-функцию расшифровки статуса проверки
                    $cert | %{
                        $status = $chain.Build($_)
                        _getstatus_ $status $chain $_
                    }
                    # после каждой итерации очищаем объекты сертификата и цепочки
                    $cert.Reset()
                    $chain.Reset()
                }
            }
        }
    }
}

Данный скрипт может принимать аргументы в виде уже готовых объектов X509Certificate2 или с указанием пути к файлу сертификата, например:

dir cert:\currentuser\my | Test-Certificate
Test-Certificate .\mycert.cer

Ну и при желании можно поуказывать там разные параметры и флаги проверки.

PowerShell Powered - http://www.sysadmins.lv

Start/Stop-CertificationAuthority

Camelot — Thu, 15 Oct 2009 16:55:57 GMT

Ещё небольшое дополнение к Certificate Management Pack, который я сейчас пишу. Данный код позволяет запускать и останавливать службу Certification Authority на сервере. Поскольку я для решения этой задачи использую WMI, то ремотинг будет обеспечен. Следует учесть, что все команды по управлению службой CA будут расположены за конвейером после команды Get-CertificationAuthority. Это было сделано в рамках удобства и стандартизации. Когда мы хотим что-то настроить в CA, то сначала должны указать его имя/объект. Поскольку у нас уже есть готовое решение для этого, то почему бы его и не использовать? Код на самом деле очень простой и в нём разберётся даже новичок:

#####################################################################
# Start-Stop CA.ps1
# Version 1.0
#
# Starts and stops Certification Authority service on specified CA
# Requires Get-CertificationAuthority cmdlet:
# http://www.sysadmins.lv/PermaLink,guid,947401b2-312a-4129-860b-4296dfe46cb2.aspx
#
# Usage:
# Get-CertificationAuthority "CAName" | Stop-CertificationAuthority
# stops CA service on CA named CAName
# Get-CertificationAuthority | Start-CertificationAuthority
# starts all Enterprise CAs in current forest
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################

function Start-CertificationAuthority ($CA) {
    process {
        $status = (gwmi Win32_Service -ComputerName $CA.Computer -Filter "Name = 'CertSvc'").StartService()
        if ($status.ReturnValue -eq 0) {
            Write-Host $CA.CAName Certificate Services successfully started on $CA.Computer -ForegroundColor Green
        } else {
            Write-Warning "Unable to start $($CA.CAName) certificate services"
        }
    }
}

function Stop-CertificationAuthority ($CA) {
    process {
        $status = (gwmi Win32_Service -ComputerName $CA.Computer -Filter "Name = 'CertSvc'").StopService()
        if ($status.ReturnValue -eq 0) {
            Write-Host $CA.CAName Certificate Services successfully stopped on $CA.Computer -ForegroundColor Green
        } else {
            Write-Warning "Unable to stop $($CA.CAName) certificate services"
        }
    }
}

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

Update: хочу ещё раз отметить на одну из частых ошибок, которые допускают при написании скриптов в PowerShell. Вы можете просто использовать переменные в двойных кавычках и при использовании этой строки в неё будет подставляться содержимое переменной. Но этого не будет, если вы используете свойство объекта, который хранится в этой переменной, поскольку переменные экспандятся только 1 раз. Этого достаточно для простой переменной, но недостаточно для извлечения содержимого свойста объекта в этой переменной. Ведь сначала нужно извлечь содержимое переменной, а потом прочитать содержимое указанного свойства. Чтобы экспандить такие вещи, переменные в двойных кавычках следует заключать в подвыражение $().

PowerShell Powered - http://www.sysadmins.lv

Windows Server 2008 R2 и Windows Backup (часть 2)

Camelot — Wed, 14 Oct 2009 20:29:30 GMT

В предыдущей части бэкапа в Windows Server 2008 R2 (Windows Server 2008 R2 и Windows Backup (часть 1)) мы рассмотрели основные моменты создания бэкапа средствами PowerShell. Сегодня мы рассмотрим вопросы самого процесса бэкапа и о его хранении.

Проверка успешности бэкапа

Когда процесс бэкапа закончится, можно посмотреть его статус:

[↑] [Administrator] Get-WBSummary


NextBackupTime                  : 0001.01.01. 0:00:00
NumberOfVersions                : 5
LastSuccessfulBackupTime        : 2009.10.07. 14:39:42
LastSuccessfulBackupTargetPath  : \\?\Volume{ca6dbf07-14ad-11de-937f-806e6f6e6963}
LastSuccessfulBackupTargetLabel : Camelot Share-1
LastBackupTime                  : 2009.10.07. 14:39:42
LastBackupTarget                : E:
DetailedMessage                 :
LastBackupResultHR              : 0
LastBackupResultDetailedHR      : 0
CurrentOperationStatus          : NoOperationInProgress

Здесь вы увидите основные сведения о результатах бэкапа. Свойство LastBackupResultHR содержит код возврата. Если это 0, то всё хорошо. Если это не 0, то бэкап не был выполнен удачно. А вот свойство NumberOfVersions показывает сколько уже копий бэкапа содержится в текущем архиве. Более подробно этот момент будет рассмотрен ниже.

Процесс создания и хранения бэкапа

При выполнении бэкапа происходит несколько вещей:

В корне диска назначения бэкапа создаётся структура папок: <путь до диска или сетевой папки>\WindowsImageBackup\<имя компьютера>
После окончания бэкапа система делает теневую копию этого тома (кроме сетевых папок) тома, на котором хранится бэкап.
Обновляется каталог бэкапов.

Если это сетевая папка, то в пути \\Server\BackupShare\WindowsImageBackup создаст папку для каждого компьютера и в ней будет хранить бэкап соответствующего компьютера. При этом последующие операции бэкапа будут копировать архив в эту же папку. Во времена ntbackup.exe мы могли выбирать метод выполнения бэкапа — с использованием VSS или без (это не относилось к SystemState бэкапам), а теперь этот вопрос решён однозначно — VSS используется всегда. Это обусловлено ещё тем, что Server Backup использует VSS для ведения истории бэкапов, что исключает путаницу в архивных копиях. Внимательные читатели могут заметить, что внутри папки бэкапа есть VHD файл (по одному VHD на каждый архивируемый том), который содержит актуальное состояние бэкапа. И тут появляется интересная вещь: каждый новый бэкап копируется в один VHD файл — а куда же деваются предыдущие копии? На самом деле все они хранятся в этом VHD файле, но скрыты за теневыми копиями, которые создаются при каждой операции бэкапа и закрепляются за архивом:

[↑] [Administrator] Get-WBBackupSet


VersionId        : 10/07/2009-10:49
BackupTime       : 2009.10.07. 13:49:41
BackupTarget     : E:
RecoverableItems : Volumes, Files
Volume           : {System (C:)}
Application      : {}
VssBackupOption  : VssCopyBackup
SnapshotId       : 8d6aa8ef-bb24-4ffc-93da-08831bc4ae88

VersionId        : 10/07/2009-11:15
BackupTime       : 2009.10.07. 14:15:36
BackupTarget     : E:
RecoverableItems : Volumes, Files
Volume           : {System (C:)}
Application      : {}
VssBackupOption  : VssCopyBackup
SnapshotId       : ab2c6d39-3447-4c9b-b072-f03d746045c4

<...>

Команда Get-WBBackupSet показывает историю бэкапов системы и ID номер теневой копии, которая содержит файлы архива на момет выполнения конкретного задания бэкапа. При восстановлении из бэкапа консоль MMC считывает эти копии и позволяет восстановить файлы на любой момент времени выполнения бэкапа. Чтобы дать более понятное представление об этом, покажу простой пример:

Выполняется первый бэкап №1.
В BackupTarget создаётся папка с архивом и в VHD файл записываются данные, которые мы архивируем;
В BackupTarget создаётся теневая копия, которая так же содержит эти файлы и закрепляется за этим бэкапом;
Время бэкапа и ID теневой копии записывается в каталог бэкапа;
Выполняется следующий бэкап этого же задания под № 2.
В BackupTarget уже ничего не создаётся, а новые данные добавляются в VHD файл, скрывая данные из бэкапа №1;
В BackupTarget создаётся теневая копия, которая так же содержит новые данные и закрепляется за этим бэкапом (№2);
Время бэкапа и ID теневой копии записывается в каталог бэкапа.
повторяются пункты 5-8.

Несмотря на то, что при непосредственном просмотре VHD файла мы видим только данные сохранённые после последней операции бэкапа, в нём по прежнему хранятся и все предыдущие копии, которые система различает по теневым копиям, которые закреплены за каждым бэкапом. Именно здесь теневые копии играют огромную роль в хранении истории бэкапа. И пока эти теневые копии живы, мы имеем доступ к предыдущим версиям файлов внутри VHD архива. Это даёт следующие преимущества:

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

В большинстве случаев это решение будет являться достаточным для любых операций восстановления. Единственное критичное место здесь будет наличие этих теневых копий. Это может вызвать трудности только при повреждении теневых копий на архивном томе. Но обычно это уже будет означать потерю всех бэкапов. Такие дела.

Как долго хранятся бэкапы на архивном томе?

Хранятся они там сколь угодно долго, пока есть свободное место. Когда свободное место заканчивается, то Server Backup автоматически пытается отыскать себе место. Если у нас выполняются только полные бэкапы, то наиболее старые версии архивов просто удаляются. Если у нас комбинируются полные бэкапы с инкрементальными/дифференциальными, то берётся наиболее старый архив и в него вписываются инкрементальные/дифференциальные архивы, которые были выполнены в промежутках между полными бэкапами до тех пор, пока не освободится достаточно для нового бэкапа места. Таким образом обеспечивается сохранность наиболее новых архивов с удалением более старых. Такая схема автоматической ротации так же будет востребована в большинстве случаев. Для экономии места Server Backup для запланированного задания автоматически делает комбинирование полных и инкрементальных бэкапов. Каждые 2 недели выполняется полный бэкап и ежедневно в промежутках между полными будет выполняться только инкрементальное архивирование.

Такая автонастройка режимов для запланированных бэкапов и авторотация будет достаточно эффективна и проста в сегменте SOHO/SMB, не отвлекая на себя слишком много внимания администратора. От администратора потребуется только создание задания и организация отказоустойчивости тома с архивами.

Совмещение нескольких заданий и индивидуальная ротация архивов

Разработчики Server Backup сделали всё, чтобы упростить процесс выполнения бэкапа в стандартных случаях SOHO/SMB. Но когда появляются особые условия, то тут начинаются свои сложности, хотя это всё относительно преодолимо. Например, вы создали несколько заданий бэкапов, которые отдельно что-то архивируют в одну и ту же точку. Но к каждому заданию предъявляются свои требования по сроку хранения бэкапа.

Пример: это файл-сервер и вы архивируете папку с документами пользователей ежедневно и следует хранить только 7 последние копии. Другое задание архивирует инсталляционные файлы вашей сети раз в неделю и требуется наличие только 4 последних копий. Так же все копии должны копироваться в сетевую папку или на съёмный диск на случай катастрофы и/или ада и Израиля. В такой ситуации мы потеряем возможность использования авторотации архивов и прочих плюшек. Давайте посмотрим, как будет выглядеть примерный скрипт:

# подключаем оснастку Server Backup
Add-PSSnapin Windows.Serverbackup
# создаём задание бэкапа
$profiles = New-WBPolicy
# создаём и добавляем в задание бэкапа архивируемую папку
$source = New-WBFileSpec -FileSpec "D:\Users"
Add-WBFileSpec -Policy $profiles -FileSpec $source
# указываем локальный том, на который будет копироваться архив
$target = New-WBBackupTarget -VolumePath "E:"
Add-WBBackupTarget -Policy $profiles -Target $target
# выполняем бэкап
Start-WBBackup -Policy $profiles
# проверяем код возврата с результатом выполнения бэкапа
if ((Get-WBSummary).LastBackupResultHR -eq 0) {
    # переименовываем архив в более понятное имя
    $newname = "Profiles_$(Get-Date -f dd.MM.yyyy)"
    Ren E:\WindowsImageBackup -NewName $newname
    # копируем архив в сетевую папку
    copy e:\$newname \\server\backups\profiles
    # удаляем все архивы из сетевой папки, которые старше 7 дней
    dir \\server\backups\profiles | ?{$_.lastwritetime -lt (Get-Date).AddDays(-7)} | del -Force
} else {
    # ругаемся, что бэкап не был завершён успешно
}

И уже этот файл отдельно зашедулить в Task Scheduler. В такой ситуации дополнительных шагов не требуется, т.к. пока живы теневые копии, вы можете восстанавливать файлы из них (наличие самого архива не требуется). А если теневых копий уже не осталось (например, том с архивами был отформатирован), то для восстановления данных просто копируете папку с архивом в корень любого тома с именем WindowsImageBackup и тогда этот архив будет определён системой как пригодный для восстановления. Так вы можете делать несколько раздельных заданий с индивидуальным расписанием бэкапа и ротацией.

Если ротация архивов в сетевой папке достаточно проста и укладывается в одну строчку, то с локальными архивами придётся подключать утилиты CMD, а именно — diskshadow.exe! Вам нужно внутри diskshadow выполнить Delete Shadows ID {GUID}, где GUID — ID теневой копии, которая закреплена за конкретным бэкапом и его можно получить из вывода Get-WBBackupSet (свойство SnapshotID)

[↑] [Administrator] diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2007 Microsoft Corporation
On computer:  CAMELOT,  2009.10.13. 22:18:05


DISKSHADOW> delete shadows ID {8d6aa8ef-bb24-4ffc-93da-08831bc4ae88}
Deleting shadow copy {8d6aa8ef-bb24-4ffc-93da-08831bc4ae88}...

1 shadow copy deleted.

DISKSHADOW>

Вот таким образом можно удалять старые теневые копии архивов по одиночке. При удалении теневой копии при следующей операции бэкапа будет обновлён каталог бэкапов. Чтобы удалить все предыдущие архивы кроме текущего внутри diskshadow нужно выполнить:

Delete Shadows Oldest E:

где E: — путь к тому с архивами.

Сами данные из VHD файла будут удалены только при следующей операции бэкапа. Однако, это не относится к архивам, которые содержат SystemState. Для ротации архивов SystemState придётся воспользоваться уже другой утилитой — wbadmin.exe:

wbadmin delete systemstatebackup –version: datetime

где datetime — дата и время выполнения бэкапа. Эту дату можно получить так же из вывода командлета Get-WBBackupSet (свойство VersionID). Чтобы удалить все бэкапы SystemState, кроме текущего следует выполнить:

wbadmin delete systemstatebackup –backuptarget:E: –deleteoldest

и для удаления всех наиболее старых архивов SystemState с сохранением N копий выполнить:

wbadmin delete systemstatebackup –keepversions:N

где N — количество копий SystemState, которые должны быть сохранены.

Исходя из изученного нами материала можно сделать такую вещь: локально хранить стандартный архив с несколькими заданиями бэкапа, а в сетевой папке каждый тип архива отдельно и применять к ним раздельную ротацию. Единственное, что мне пришло на ум — использовать CSV файл для каталогизации теневых копий. Вот как это примерно выглядит:

# подключаем оснастку Server Backup
Add-PSSnapin Windows.Serverbackup
# создаём задание бэкапа
$profiles = New-WBPolicy
# создаём и добавляем в задание бэкапа архивируемую папку
$source = New-WBFileSpec -FileSpec "D:\Users"
Add-WBFileSpec -Policy $profiles -FileSpec $source
# указываем локальный том, на который будет копироваться архив
$target = New-WBBackupTarget -VolumePath "E:"
Add-WBBackupTarget -Policy $profiles -Target $target
# выполняем бэкап
Start-WBBackup -Policy $profiles
# проверяем код возврата с результатом выполнения бэкапа
if ((Get-WBSummary).LastBackupResultHR -eq 0) {
    # переименовываем архив в более понятное имя
    $newname = "Profiles_$(Get-Date -f dd.MM.yyyy)"
    Ren E:\WindowsImageBackup -NewName $newname
    # копируем архив в сетевую папку
    copy e:\$newname \\server\backups\profiles
    # удаляем все архивы из сетевой папки, которые старше 7 дней
    dir \\server\backups\profiles | ?{$_.lastwritetime -lt (Get-Date).AddDays(-7)} | del -Force
    # читаем наш собственный каталог бэкапов
    $csv = Import-Csv E:\ProfileBackup.csv
    # и считаем сколько там записей
    $count = $csv.count
    # если записей больше 7, то считаем сколько лишних архивов нужно удалить.
    # если меньше 7 записей, то ничего удалять не надо и просто добавляем новую запись
    if ($count -gt 7) {
        $old = $count - 7
        # генерируем случайное имя для скрипта, который будет использоваться в diskshadow
        $file = [System.IO.Path]::GetRandomFileName()
        # выбираем все лишние архивы и пропускаем их по конвейеру на удаление
        $csv | sort | select -First $old | %{
            # записываем команду во временный файл
            "delete shadows ID {$($_.SnapshotID)}" > $Env:TEMP\$file
            # и запускаем diskshadow в режиме скрипта
            diskshadow -s $Env:TEMP\$file
        }
        del $Env:TEMP\$file
    }
    # считываем данные о последнем бэкапе
    $current = Get-WBBackupSet | select -Last 1  | select VersionID, SnapshotId
    # и добавляем его в массив объектов действующих бэкапов
    $csv += $current
    # чтобы не было путаницы, снова сортируем объекты и пишем обратно в CSV файл
    $csv | sort | select -Last 7 | Export-Csv E:\ProfileBackup.csv -NoTypeInformation
} else {
    # ругаемся, что бэкап не был завершён успешно
}

В принципе, это только один вариант реализации подобной задачи и не обвешена никакими проверками. Однако, учитывая, что данный код публикуется на правах ТЗ (ТЗ — Тайное Знание), поэтому может использоваться как шаблон алгоритма такой кастомной ротации. Данный скрипт только демонстрирует логику, которой вы можете воспользоваться и подпилить под свои условия самостоятельно.

Вот и всё, наверное, что я хотел рассказать про бэкап в Windows Server 2008 R2. В Windows 7 нет командлетов для бэкапа, поэтому свои хотелки придётся реализовывать только средствами CMD (wbadmin, vssadmin, diskshadow). И это будет значительно сложнее, чем вариант с командлетами повершела.

PowerShell Powered - http://www.sysadmins.lv

Windows Server 2008 R2 и Windows Backup (часть 1)

Camelot — Wed, 07 Oct 2009 20:43:07 GMT

2 недели назад я выступал на рижском IT Pro с темой бэкапа в Windows Server 2008 R2 с помощью PowerShell. Доклад получится немного скомканный и на ряд вопров из зала я не смог ответить, т.к. эти вопросы требуют достаточно много времени на формулировку ответа. Поэтому я здесь подниму этот вопрос снова и постараюсь ответить на неотвеченные вопросы.

Я думаю, что уже все знают про отсутствие ntbackup.exe в системах начиная с Windows Server 2008. Его теперь заменяет отдельный системный компонент Windows Backup (или Server Backup) и, который, устанавливается как компонент сервера в оснастке Server Manager. Первая версия Server Backup была достаточно грубой и примитивной. Она позволяла бэкапить только тома целиком блочным методом без возможности выбора отдельных файлов и папок. Блочный метод работает на уровень ниже, чем файловая система, поэтому никакой речи о файлах быть не могло. Так же ему требовался выделенный том под хранение бэкапа и при инициализации тома под бэкапы, он форматировался. Бэкап SystemState производился отдельно и его нельзя было включить в состав бэкапа отдельного тома. Иными словами, первая версия была непотребна чуть более чем полностью, поэтому в отношении него говорить просто не о чем.

С выходом Windows Server 2008 R2 ситуация немного улучшилась. После тысяч жалоб от покупателей и срачей на форумах в новой системе добавился бэкап на уровне файловой системы (как и ntbackup), сохранив и улучшив первоначальную версию Server Backup. Новая версия бэкапа отличается следующими характеристиками по сравнению с первой версией:

Добавлена возможность бэкапа файлов и папок
Добавлена возможность комбинирования объектов бэкапа. Например, к бэкапу отдельных папок и файлов можно добавлять бэкап SystemState
Теперь можно делать инкрементальный бэкап для SystemState (включено по умолчанию)
Улучшенная поддержка PowerShell

Как и раньше, командлеты для Server Backup поставляются в виде отдельной оснастки, которая подключается командой:

Add-PSSnapin Windows.ServerBackup

И все командлеты для бэкапа будут иметь префикс WB (от Windows Backup):

[↑] [↑]

CommandType     Name -----------     ---- Cmdlet          Add-WBBackupTarget Cmdlet          Add-WBBareMetalRecovery Cmdlet          Add-WBFileSpec Cmdlet          Add-WBSystemState Cmdlet          Add-WBVolume Cmdlet          Get-WBBareMetalRecovery Cmdlet          Get-WBDisk Cmdlet          Get-WBJob Cmdlet          Get-WBPolicy Cmdlet          Get-WBSchedule Cmdlet          Get-WBSummary Cmdlet          Get-WBSystemState Cmdlet          Get-WBVolume Cmdlet          Get-WBVssBackupOptions Cmdlet          New-WBBackupTarget Cmdlet          New-WBPolicy Cmdlet          Remove-WBBackupTarget Cmdlet          Remove-WBBareMetalRecovery Cmdlet          Remove-WBFileSpec Cmdlet          Remove-WBPolicy Cmdlet          Remove-WBSystemState Cmdlet          Remove-WBVolume Cmdlet          Set-WBPolicy Cmdlet          Set-WBSchedule Cmdlet          Set-WBVssBackupOptions Cmdlet          Start-WBBackup

[↑]

[Administrator] Add-PSSnapin windows.serverbackup [Administrator] gcm *-wb* Definition ---------- Add-WBBackupTarget [-Policy]  [-Target... Add-WBBareMetalRecovery [-Policy]  [-V... Add-WBFileSpec [-Policy]  [-FileSpec] ... Add-WBSystemState [-Policy]  [-Verbose... Add-WBVolume [-Policy]  [-Volume]  [-Verbos... Get-WBBareMetalRecovery [-Policy]  [-V... Get-WBDisk [-Verbose] [-Debug] [-ErrorAction  [-Ve... Get-WBJob [[-Previous] ] [-Verbose] [-De... Get-WBPolicy [-Editable] [-Verbose] [-Debug] [-E... Get-WBSchedule [-Policy]  [-Verbose] [... Get-WBSummary [-Verbose] [-Debug] [-ErrorAction ... Get-WBSystemState [-Policy]  [-Verbose... Get-WBVolume [-Disk]  [-Verbose] [-Debug... Get-WBVssBackupOptions [-Policy]  [-Ve... New-WBBackupTarget [-Disk]  [[-Label]  [-NonRecur... New-WBPolicy [-Verbose] [-Debug] [-ErrorAction <... Remove-WBBackupTarget [-Policy]  [-Tar... Remove-WBBareMetalRecovery [-Policy]  ... Remove-WBFileSpec [-Policy]  [-FileSpe... Remove-WBPolicy [[-Policy] ] [-All] [-... Remove-WBSystemState [-Policy]  [-Verb... Remove-WBVolume [-Policy]  [-Volume] <... Set-WBPolicy [-Policy]  [-Force] [-Ver... Set-WBSchedule [-Policy]  [-Schedule] ... Set-WBVssBackupOptions [-Policy]  [-Vs... Start-WBBackup [-Policy]  [-Async] [-F... [Administrator]

Мы видим достаточно приличное количество командлетов и часть из них мы используем для работы. Все задания бэкапов в ServerBackup являются политиками бэкапа. Следовательно, командлетом New-WBPolicy мы будем создавать каждое задание бэкапа:

[↑] [Administrator] $pol = New-WBPolicy
[↑] [Administrator] $pol


Schedule            :
BackupTargets       :
VolumesToBackup     :
FilesSpecsToBackup  :
FilesSpecsToExclude :
BMR                 : False
SystemState         : False
VssBackupOptions    : VssCopyBackup



[↑] [Administrator]

Мы создали объект новой политики бэкапа, который имеет ряд свойств. Эти свойства по названиям уже отражают своё назначение. Давайте сначала выберем объекты бэкапа. Например, добавим какую-нибудь папку, которую мы захотим бэкапить. Новые объекты бэкапа создаются в 2 этапа:

Создание самого объекта командой New-WBFileSpec
Добавление этого объекта в политику бэкапа командой Add-WBFileSpec

Будь то отдельная папка или отдельный том. Это не относится только к Bare Metal Recovery (полный бэкап системного тома, SystemState и всех системных файлов) и к самому SystemState. Они могут сразу добавляться в политику.

[↑] [Administrator] $source1 = New-WBFileSpec -FileSpec "C:\Users"
[↑] [Administrator] $source1 | ft -a

FilePath  FileName IsRecursive IsIncludeSpec
--------  -------- ----------- -------------
C:\Users\ *               True          True


[↑] [Administrator] $exclusion = New-WBFileSpec -FileSpec "C:\Users\vpodans" -Exclude
[↑] [Administrator] $exclusion | ft -a

FilePath          FileName IsRecursive IsIncludeSpec
--------          -------- ----------- -------------
C:\Users\vpodans\ *               True         False


[↑] [Administrator] $source2 = New-WBFileSpec -FileSpec "D:\Users" -NonRecursive
[↑] [Administrator] $source2 | ft -a

FilePath  FileName IsRecursive IsIncludeSpec
--------  -------- ----------- -------------
D:\Users\ *              False          True


[↑] [Administrator] $source1, $source2, $exclusion | Add-WBFileSpec -Policy $pol
[↑] [Administrator] $pol


Schedule            :
BackupTargets       :
VolumesToBackup     :
FilesSpecsToBackup  : {C:\Users\*, D:\Users\*}
FilesSpecsToExclude : {C:\Users\vpodans\*}
BMR                 : False
SystemState         : False
VssBackupOptions    : VssCopyBackup



[↑] [Administrator]

Первой командой мы задали бэкап всей папки C:\Users. Второй командой мы посмотрели объект этой точки. Как видно из таблички, эта папка будет бэкапить полностью включая все подпапки. Но я не хочу бэкапить папку профиля одного из пользователей. Для этого в командлете New-WBFileSpec есть ключ –Exclude, который исключит эту папку из бэкапа. В следующей строке это видно по состоянию свойства IsIncludeSpec = $false. И чтобы исключить рекурсивную обработку папки (т.е. нам нужно бэкапить содержимое только текущей папки не трогая подпапки совсем) для неё достаточно указать ключ –NonRecursive. под каждую категорию вы можете добавлять пути для бэкапа через запятую в одной команде. Но для каждой категории надо писать новую команду. В конце мы видим, что наша политика уже обросла какими-то данными. Если мы захотим сюда добавить ещё бэкап целого тома или физического диска, то нам уже придётся работать с командлетами Get/Add-WBDisk и Get/Add-WBVolume:

[↑] [Administrator] Get-WBDisk


DiskName       : WDC WD3200JS-00PDB0 ATA Device
DiskNumber     : 1
DiskId         : d5fae841-0000-0000-0000-000000000000
TotalSpace     : 320072933376
FreeSpace      : 3591163904
Volumes        : {New Volume (S:\VM\Core), Camelot Share-2 (F:)}
ContainsBackup : False
BackupVolumeId : 00000000-0000-0000-0000-000000000000
Properties     : Dynamic, ValidTarget

<...>
[↑] [Administrator] $disk = Get-WBDisk | ?{$_.disknumber -eq 1}
[↑] [Administrator] Get-WBVolume -Disk $disk


VolumeLabel : New Volume
MountPath   : S:\VM\Core
MountPoint  : \\?\Volume{06d04bb0-1949-11de-a731-001fd08fc2f1}
FileSystem  : NTFS
Property    : ValidSource
FreeSpace   : 2133585920
TotalSpace  : 18875416576

VolumeLabel : Camelot Share-2
MountPath   : F:
MountPoint  : \\?\Volume{62bda1e6-b515-4102-b03f-40b7896ab0f3}
FileSystem  : NTFS
Property    : ValidSource
FreeSpace   : 1453031424
TotalSpace  : 301192970240



[↑] [Administrator]

Командлет Get-WBDisk отобразит нам все физические диски, которые подключены к системе (с учётом аппаратного рейда, разумеется). Если захотим добавить этот диск в бэкап, то отфильтровываем через Where-Object (или просто вопросительный знак) и добавляем его в политику командой Add-WBDisk. Get-WBDisk нам так же потребуется и для просмотра логических томов, поскольку Get-WBVolume в качестве аргумента принимает только объекты, полученные от команды Get-WBDisk. Т.е. сначала выбираем диск и только потом просматриваем нужные тома. И отфильтровав нужный том добавляем в политику, например:

[↑] [Administrator] Get-WBVolume -Disk $disk


VolumeLabel : New Volume
MountPath   : S:\VM\Core
MountPoint  : \\?\Volume{06d04bb0-1949-11de-a731-001fd08fc2f1}
FileSystem  : NTFS
Property    : ValidSource
FreeSpace   : 2133585920
TotalSpace  : 18875416576

VolumeLabel : Camelot Share-2
MountPath   : F:
MountPoint  : \\?\Volume{62bda1e6-b515-4102-b03f-40b7896ab0f3}
FileSystem  : NTFS
Property    : ValidSource
FreeSpace   : 1453031424
TotalSpace  : 301192970240



[↑] [Administrator] $volume = Get-WBVolume -Disk $disk | ?{$_.volumelabel -eq "new volume"}
[↑] [Administrator] Add-WBVolume -Policy $pol -Volume $volume


VolumeLabel : New Volume
MountPath   : S:\VM\Core
MountPoint  : \\?\Volume{06d04bb0-1949-11de-a731-001fd08fc2f1}
FileSystem  : NTFS
Property    : ValidSource
FreeSpace   : 2133585920
TotalSpace  : 18875416576



[↑] [Administrator] $pol


Schedule            :
BackupTargets       :
VolumesToBackup     : {New Volume (S:\VM\Core)}
FilesSpecsToBackup  : {C:\Users\*, D:\Users\*}
FilesSpecsToExclude : {C:\Users\vpodans\*}
BMR                 : False
SystemState         : False
VssBackupOptions    : VssCopyBackup



[↑] [Administrator]

Если я вдруг не захочу уже бэкапить добавленный том, то его можно спокойно удалить (фактически командами Remove-WB* можно удалить что угодной из политики):

Remove-WBVolume -Policy $pol -Volume $volume

Теперь настало время выбрать точки, в которые мы будем копировать наш бэкап. Точки назначения добавляются в бэкап тоже задаются в 2 этапа:

New-WBBackupTarget — создаёт объект точки назначения бэкапа
Add-WBBackupTarget — добавляет эту точку в политику бэкапа

[↑] [Administrator] $target = New-WBBackupTarget -VolumePath "F:"
[↑] [Administrator] $target = New-WBBackupTarget -VolumePath "E:"
[↑] [Administrator] Add-WBBackupTarget -Policy $pol -Target $target


Label                  : Camelot Share-1
WBDisk                 :
WBVolume               : Camelot Share-1 (E:)
Path                   : \\?\Volume{ca6dbf07-14ad-11de-937f-806e6f6e6963}
TargetType             : Volume
InheritAcl             : False
PreserveExistingBackup : False



[↑] [Administrator] $pol


Schedule            :
BackupTargets       : {E:}
VolumesToBackup     : {}
FilesSpecsToBackup  : {C:\Users\*, D:\Users\*}
FilesSpecsToExclude : {C:\Users\vpodans\*}
BMR                 : False
SystemState         : False
VssBackupOptions    : VssCopyBackup



[↑] [Administrator]

Вы так же можете указать бэкап сразу в сеть. Для этого в команде New-WBBackupTarget вместо параметра –VolumePath использовать параметр –NetworkPath и за ним уже указывать UNC путь к сетевой папке. Однако, следует учесть несколько нюансов:

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

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

Теперь у нас есть 2 варианта: начать выполнение бэкапа немедленно, или регистрация нашей политике в системе для периодического выполнения в автоматическом режиме (по внутреннему шедулеру). В первом случае достаточно выполнить команду:

Start-WBBackup –Policy $pol

или зашедулить командой Set-WBSchedule:

[↑] [Administrator] Set-WBSchedule -Policy $pol -Schedule "10.08.2009 21:00"

tresdiena, 2009. gada 7. oktobri 21:00:00


[↑] [Administrator] $pol


Schedule            : {2009.10.07. 21:00:00}
BackupTargets       : {E:}
VolumesToBackup     : {}
FilesSpecsToBackup  : {C:\Users\*, D:\Users\*}
FilesSpecsToExclude : {C:\Users\vpodans\*}
BMR                 : False
SystemState         : False
VssBackupOptions    : VssCopyBackup



[↑] [Administrator] Set-WBPolicy –Policy $pol

И командой Set-WBPolicy наша политика регистрируется в системе. Шедулинг следует указывать в следующей форме:

Month.Day.Year Hours:Minutes

И теперь каждый день в 21:00 будет выполняться наше задание.

Сегодня мы рассмотрели основные моменты создания политики бэкапа в Windows Server 2008 R2 с использованием PowerShell. В следующей (или следующих) рассмотрим вопросы управления этими политиками и вопросы каталогизации/ротации архивов.

PowerShell Powered - http://www.sysadmins.lv

Get-CertificationAuthority

Camelot — Tue, 06 Oct 2009 18:15:39 GMT

А знаете ли вы как можно легко получить список всех Enterprise CA в текущем домене? А в текущем лесу? Оказывается это очень легко! ADSI — самый лучший способ, если вы хотите пошариться в своей базе AD. Список таких CA находится по пути:

CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=Domain, DC=COM

Последние 2 значения уже будут отличаться в зависимости от имени домена. Чтобы получить список объектов по этому пути нужно просто создать соответствующий LDAP объект. Объект делается просто, сначала указывается тип объекта [ADSI], следом идёт префикс ссылки LDAP:// (почти как HTTP://) и после префикса уже этот путь (который называется Distinguished Name или просто DN):

[Administrator] $CA = [ADSI]"LDAP://CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=co
ntoso,DC=COM"
[Administrator] $CA


distinguishedName : {CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}
Path              : LDAP://CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=contoso,DC
                    =COM
[Administrator] $CA.distinguishedName
CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

Если посмотреть этот путь в ADSIEdit.msc, то мы увидим, что это контейнер. А раз это контейнер, то нам нужно в него заглянуть. Здесь, к сожалению, нельзя сделать dir $CA.distinguishedName, а так хочется. Чтобы посмотреть содержимое нужно использовать свойство Children (ворненк, дети отаке!):

[Administrator] $ca.Children


distinguishedName : {CN=contoso-DC2-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=co
                    ntoso,DC=com}
Path              : LDAP://CN=contoso-DC2-CA,CN=Enrollment Services,CN=Public Key Services, CN=Services, CN=Configurati
                    on, DC=contoso,DC=COM

distinguishedName : {CN=Contoso CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contos
                    o,DC=com}
Path              : LDAP://CN=Contoso CA,CN=Enrollment Services,CN=Public Key Services, CN=Services, CN=Configuration,
                    DC=contoso,DC=COM



[Administrator]

Уже отсюда невооружённым глазом видны имена CA. Собственно, можно показать только имя самого CA и компьютера, на котором работает этот CA:

[Administrator] $ca.Children | ft Name, DNSHostName

Name                                                        DNSHostName
----                                                        -----------
{contoso-DC2-CA}                                            {dc2.contoso.com}
{Contoso CA}                                                {DC1.contoso.com}


[Administrator]

Здесь есть один важный нюанс. Если получить этот LDAP объект в PowerShell 1.0, то он будет содержать только Distinguished Name, а свойство Children будет отсутствовать в нём. Для этого нужно воспользоваться свойством PSBase, в котором уже будет Children. Командой Select можете выводить на экран и другие свойства, какие вы захотите:

PS C:\> $ca.children


MemberType          : Method
OverloadDefinitions :
TypeNameOfValue     : System.Management.Automation.PSMethod
Value               :
Name                : children
IsInstance          : True



PS C:\> $ca.psbase.children

distinguishedName
-----------------
{CN=contoso-DC2-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}
{CN=Contoso CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com}


PS C:\> $ca.psbase.children | select Name, DNSHostname

Name                                                        DNSHostname
----                                                        -----------
{contoso-DC2-CA}                                            {dc2.contoso.com}
{Contoso CA}                                                {DC1.contoso.com}


PS C:\>

Поэтому для обратной совместимости между версиями лучше использовать PSBase. В этом объекте будут содержаться не только CA вашего домена, а во всех доменах вашего леса, поскольку эта часть AD реплицируется как Forest naming context, т.е. между всеми контроллерами в лесу. Жизнь была бы неинтересной, если в каждом новом домене приходилось бы переписывать хвост (которая определяет домен, в котором следует искать) каждый раз. Для универсальности можно пойти на военную хитрость — раздобыть FQDN текущего домена, разобрать его и воткнуть в LDAP запрос. Получить имя текущего домена можно очень просто, с использованием статического метода GetCurrentDomain() класса System.DirectoryServices.ActiveDirectory.Domain. На самом деле у этого класса есть ещё куча других полезных методов, поэтому не лишним будет заглянуть по ссылке.

PS C:\> [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()


Forest                  : contoso.com
DomainControllers       : {DC1.contoso.com}
Children                : {}
DomainMode              : Windows2003Domain
Parent                  :
PdcRoleOwner            : DC1.contoso.com
RidRoleOwner            : DC1.contoso.com
InfrastructureRoleOwner : DC1.contoso.com
Name                    : contoso.com



PS C:\>

И свойство Name будет содержать имя нашего домена. Что дальше? А дальше, вполне очевидно, что нам надо заменить все точки на строку вида ", DC=". Вот так:

PS C:\> "contoso.com" -replace "\.", ", DC="
contoso, DC=com

А перед первым именем эту часть можно написать ручками. В итоге универсальная часть кода получится вот такая:

$domain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name
$domain = "DC=" + $domain -replace '\.', ", DC="
$CA = [ADSI]"LDAP://CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, $domain"

Вот теперь у нас есть всё необходимое, чтобы написать простеньку функцию:

function Get-CertificationAuthority ([string]$CAName) {
    $domain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name
    $domain = "DC=" + $domain -replace '\.', ", DC="
    $CA = [ADSI]"LDAP://CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, $domain"
    $CAs = $CA.psBase.Children | %{
        $current = "" | Select CAName, Computer
        $current.CAName = $_ | %{$_.Name}
        $current.Computer = $_ | %{$_.DNSHostName}
        $current
    }
    if ($CAName) {$CAs = @($CAs | ?{$_.CAName -eq $CAName})}
    if ($CAs.Count -eq 0) {throw "Sorry, here is no CA that match your search"}
    $CAs
}

Если выполнить эту функцию без аргументов, то она вернёт все CA в лесу. Но можно указать и какой-то один для каких-то других целей.

PowerShell Powered - http://www.sysadmins.lv

Get-TextEncoding

Camelot — Sun, 04 Oct 2009 11:07:34 GMT

По мотивам предыдущего поста и срача в ньюсгруппе microsoft.public.windows.powershell перепубликовываю скрипт Роберта Робело для определения кодировки, в которой сохранён файл.

filter Get-TextEncoding {
#requires -Version 2.0
    begin {
        [string]$BOM_Unicode = [Text.Encoding]::Unicode.GetPreamble()
        [string]$BOM_UTF7 = [Text.Encoding]::UTF7.GetPreamble()
        [string]$BOM_UTF8 = [Text.Encoding]::UTF8.GetPreamble()
        [string]$BOM_BigEndian = [Text.Encoding]::BigEndianUnicode.GetPreamble()
        [string]$BOM_UTF32 = [Text.Encoding]::UTF32.GetPreamble()
    }
    process {
        if ($_ -is 'IO.FileInfo') {
            $bytes = Get-Content -Literal $_.pspath -Encoding Byte -Total 4 -ErrorAction SilentlyContinue
            $value = if ($bytes) {
                if ($bytes[0..1] -as 'String' -eq $BOM_Unicode) {'Unicode'}
                elseif ($bytes[0..2] -as 'String' -eq $BOM_UTF7) {'UTF7'}
                elseif ($bytes[0..2]  -as 'String' -eq $BOM_UTF8) {'UTF8'}
                elseif ($bytes[0..1] -as 'String' -eq $BOM_BigEndian) {'BigEndian'}
                elseif ($bytes[0..3] -as 'String' -eq $BOM_UTF32) {'UTF32'}
                # undetermined, no BOM
                else {'Unknown'}
            # undetermined, zero bytes
            } else {'Unknown'}
            $_ | Add-Member NoteProperty Encoding $value -PassThru
        # not an IO.FileInfo
        } else {$_}
    }
}

ну и использование достаточно простое:

dir *.ps1 | Get-TextEncoding | Format-Table Name, Encoding

Уже тут видно мелкий косячок подсветки в PowerGUI. Name должно быть такого же цвета, что и Encoding. А выглядеть это будет примерно так:

[↓] [vPodans] dir desktop\*.ps1 | Get-TextEncoding | ft name, encoding

Name                                                        Encoding
----                                                        --------
Untitled1.ps1                                               BigEndian
untitled2.ps1                                               UTF8


[↓] [vPodans]

Не забудьте, что это будет работать только в V2. Для PowerShell 1.0 придётся чуточку подпилить его.

PowerShell Powered - http://www.sysadmins.lv

PowerShell ISE vs PowerGUI

Camelot — Sat, 03 Oct 2009 15:19:24 GMT

Когда пользователь начинает работать с PowerShell, то со временем перед ним возникает вопрос — какой редактор (вернее сказать, среду разработки) выбрать? Решений уже достаточно много, чтобы было из чего выбирать:

PowerShell ISE
PowerGUI
PrimalScript
PowerShellPlus
…

в большинстве случаев выбор делают между первыми двумя продуктами. Иногда споры об этом переходят в разряд религиозных войн. Истинные фанаты PowerShell выбирают ISE. В принципе, как просто редактор он вполне неплох, т.к. уже есть в коробке (начиная с первых CTP версий PowerShell V2) и для работы с ним никаких телодвижений делать не надо. Однако с ним есть ряд трудностей:

IntelliSense

В ISE отсутствует IntelliSense (автозавершение команд и свойств/методов объекта). А это весьма необходимая функция в среде разработки. Мне кажется, что это поняли уже все, кроме разработчиков PowerShell ISE. Вот как это может выглядеть:

Подсказки (ToolTips)

При наведении курсора на команду, не отображаются подсказки (Tooltips). В PowerGUI это выглядит действительно классно, точь-в-точь как в Visual Studio:

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

Multiple runspaces

В ISE включена поддержка одноврменного редактирования нескольких скриптов (за счёт табов). Однако, все табы выполняются в одном runspace, что часто приводит к негативным последствиям, когда в двух разных табах используются одинаковые имена переменных. В связи с этим, данные из определённой переменной одного таба будут мигировать во второй таб, если эта переменная ещё не определена. Это может привести к неожиданным результатам работы скрипта.

Кодировка сохраняемых файлов

ISE по умолчанию сохраняет файлы в Big Endian кодировке. Вроде бы ничего криминального, но... Set-Authenticodesignature не умеет подписывать скрипты в Big Endian кодировке! Поэтому вы не сможете подписать штатными средствами ни один скрипт, который был сохранён в ISE! Для этого нужно прибегать к грязным хакам. Т.е. использовать такую строку, которая переопределит кодировку, в которой скрипт будет сохранён:

$psISE.CurrentFile.Save([Text.Encoding]::UTF8)

Исполнение сохранённых скриптов и Execution Policy

Вы можете в нём исполнять свой сценарий до тех пор, пока не сохраните его в файл. А вот когда вы редактируете уже сохранённый скрипт, то получаете бонус в виде того, что скрипт не будет исполняться внутри ISE, если у вас политика исполнения скриптов выставлена в AllSigned. ISE об этом честно предупреждает:

Т.е. он сохраняет файл и пытается его запустить. В PowerGUI сделано куда более гуманно. Из основного редактора код условно копируется и вставляется в консоль PowerShell. Т.е. вы можете спокойно редактировать и отлаживать свой скрипт и только когда он будет готов к работе — подписывать скрипт. В случае с ISE вам придётся либо после каждого изменения сохранять и переподписывать скрипт (а это дико неудобно), либо выделять весь код и выбирать Run Selection. А это тоже не очень удобно. Плюс, сохранение скрипта перед исполнением ведёт к другой проблеме. Вы не сможете отменить изменения на более раннее состояние.

Поддержка профиля $Profile

В ISE вы не можете использовать свой профиль (который в консоли содержится в переменной $Profile), а только поддерживать дополнительный профиль, который находится в той же папке, что и основной, но под именем Microsoft.PowerShellISE_profile.ps1

Отслеживание изменений в файле

ISE не поддерживает проверку файла на изменения, хотя это должно быть удобно. Я часто редактирую свои файлы дома на нотебуке и на работе. Папка со скриптами синхронизируется между домом и работой через Live Sync. Я достаточно редко закрываю редактор, поэтому вечером сохраняю файл (который уже открыт в редакторе на работе) и всё. Утром, придя на работу я могу без переоткрытия файла могу продолжать его редактировать. PowerGUI просто сообщит, что файл был изменён и сам предложит загрузить последнюю сохранённую версию. С ISE придётся вручную переоткрывать файл.

About

Я не могу вспомнить программ, которые бы имели меню Help, но внутри не имели подменю About. но это просто мелочи уже, которые не влияют на удобство разработки скриптов.

Updated 04.10.2009

Если подвести это всё в табличку, то получится примерно так:

	PowerShell ISE	PowerGUI	PowerShell Plus
Built-In
Is free
Fast start
Powershell Support	100%	<100%	<100%
External PowerShell window
Remote PowerShell tab
IntelliSense
Multiple Runspaces
ToolTips
Syntax highlighting
Error syntax highlighting
Error autocorrection
Changed lines highlighting
Outline support
Support for signing
Can sign within IDE
Run signed scripts in external window
Readable command help
Configurable editor panes
Variable pane
PS $Profile support
BreakPoints
Code templates
Print from editor
Script autosave

Примечание: последнее изменение таблицы 16.03.2010

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

Однако, хочу ещё раз напомнить, что PowerGUI никогда не закроет первую строчку в таблице, что для религиозных фанатиков будет самым главным преимуществом и, который, затмит остальные недостатки ISE. Но мой выбор в этом вопросе достаточно очевиден.

PowerShell Powered - http://www.sysadmins.lv

PS FCIV 1.0

Camelot — Thu, 01 Oct 2009 19:12:11 GMT

После небольшого перерыва продолжаю допиливать свой вариант FCIV на PowerShell. И радостно могу сообщить, что уже есть версия 1.0, т.е. полностью отвечающая нашим требованиям. Что изменилось в новой версии?

Основная команда переименована с Get-PsFCIV в Start-PsFCIV;
Включена предварительная проверка файлов на блокировку;
В связи с предыдущим пунктом, к параметру Show добавлен аргумент – Locked. В это свойство помещаются заблокированные файлы (а для них нельзя подсчитать хеш);
Включена проверка пути. Если путь к исходной папке не является путём файловой системы, то скрипт будет генерировать ошибку;
Исправлена ошибка невозврата на исходный путь, если в процессе работы произошла фатальная ошибка;
Параметр Show теперь выводит файлы из указанных категорий в красивое графическое окошко с использованием Out-GridView. Однако, следует учесть, что использование Out-GridView требует, чтобы был установлен .NET Framework 3.5 SP1.
Добавлен режим Quiet, который ничего не выводит на экран, а только генерирует коды возврата (LastExitCode). Коды возврата обновлены.
Пофиксены сообщения режимов Verbose и Debug.
Исправлены мелкие неточности в коде и произведена небольшая оптимизация кода.

А теперь и on-line справка по всем параметрам по просьбе трудящихся.

Path <String> — путь к папке, файлы которой следует посчитать или проверить. Допускаются относительные пути. Данный параметр обязателен.
XML <String> — путь к XML файлу, который содержит сведения о файлах. Если указанный файл не существует, то после пересчёта файлов по этому пути будет создан новый файл БД со сведениями о файлах. Параметр обязателен.
Include <String> — опциональный параметр в котором вы можете указать только конкретный файл из папки. В таком случае будет проверена не вся папка, а только указанный файл. В настоящее время параметр не поддерживает подстановочные знаки (wildcard), типа '*.ext' из-за обеспечения поддержки файлов с метасимволами (например, в имени содержатся квадратные скобки).
Action <String> — опциональный параметр, который указывает на действие над файлами, у которых не совпадают хеши или сведения о дате изменения и размере файла. Может принимать значение Rename или Delete. В первом случае к проблемным файлам добавляется расширение .BAD, а во втором файл просто удаляется.
Show <String[]> — опциональный параметр, в котором указываются категории файлов для дальнейшего анализа. В зависимости от результата проверки каждый файл (его имя) помещается в ту или иную категорию. Требует установленного .Net Framework 3.5 SP1. Может принимать один или несколько аргументов из списка:
- Bad — содержит имена всех файлов, у которых обнаружен несовпадающий хеш или не совпадает дата/время изменеия и/или размер файла;
- Locked — в эту категорию помещаются файлы хеш которых проверить не удалось по причине блокировки файла в монопольном режиме каким-то приложением;
- Missed — содержит имена файлов, для которых есть запись в XML файле БД, но самого файла уже не существует (по любым причинам);
- New — в эту категорию попадают только имена новых файлов, для которых соответствующей записи ещё нет в XML файле. Новые файлы добавляются только в режиме Rebuild или когда файл БД создаётся с нуля.
- Ok — сюда попадают файлы с успешным статусом проверки, т.е. хеш, дата/время изменения и размер файла совпадают со значениями в XML файле;
- Total — содержит имена всех обработанных файлов вне зависимости от результата проверки;
- Unknown — содержит имена файлов, для которых нельзя сопоставить хеш. Такая ситуация возможна, если в параметрах функции указан только хеш SHA1, но для файла в БД записан только MD5 хеш и наоборот.
Recurse <Switch> — ключ, который включает проверку файлов не только в указанной папке, но и во всех вложенных папках.
Rebuild <Swtich> — ключ, который задаёт особый режим работы скрипта — «освежение». Если этот ключ указан, то производится сверка файлов из БД с реальными файлами. Если файл более не существует, то соответствующая запись для него удаляется из БД. После чего целевая папка (и подпапки при указанном ключе –Recurse) проверяется на наличие новых файлов. Для каждого нового файла добавляется соответствующая запись в XML файл.
SHA1 <Switch> — задаёт алгоритм хеширования, который будет использоваться для подсчёта новых файлов и/или для проверки уже существующих записей в XML файле.
MD5 <Switch> — задаёт алгоритм хеширования, который будет использоваться для подсчёта новых файлов и/или для проверки уже существующих записей в XML файле.
Quiet <Switch> — включает несопровождаемый режим работы скрипта. Если ключ указан, то итоговая статистическая информация не выводится на экран, а в зависимости от результата проверки генерируется код возврата (LastExitCode). Код возврата может принимать одно из следующих значений:
- 0 — в процессе работы скрипта все файлы были успешно проверены и их хеш, дата/время изменения и размер соответствуют записям в БД. Так же, данный код возврата будет сгенерирован, если создавался новый файл БД и все файлы были успешно в него добавлены;
- 1 — в процессе проверки были обнаружены файлы с несовпадающим хешем и/или датой/временем и размером;
- 2 — в процессе проверки было обнаружено, что для записи в БД нет соответствующего файла;
- 3 — в процессе проверки были обнаружены файлы, для которых не удалось сопоставить алгоритм хеширования с хранимым в БД алгоритмом хеширования для файла. Такая ситуация возможна, если в параметрах функции указан только хеш SHA1, но для файла в БД записан только MD5 хеш и наоборот;
- 4 — в процессе работы скрипта для некоторых файлов не удалось подсчитать хеш по причине блокировки файла в монопольном режиме другим приложением;
- 5 — скрипт выполнялся в режиме Rebuild (освежения файла БД)
Verbose <Switch> — включает отображение дополнительной информации о ходе проверки файлов.
Debug <Switch> — включает отображение отладочной информации о ходе работы скрипта.

Несколько примеров использования:

Start-PsFCIV C:\Files db.xml -SHA1 -Recurse -Show Bad, Missed

будет проверена папка C:\Files и все вложенные папки. Файл db.xml должен быть размещён непосредственно в этой папке. Если файл не существует, то будет создан с нуля. После проверки будет показано графическое окно с именами файлов, которые попали в категорию Bad и Missed. Для каждой категории будет отдельное графическое окно.

Start-PsFCIV C:\Files db.xml -SHA1 -MD5 -Include data.dat

будет проверен только файл data.dat в папке C:\Files с использованием SHA1 алгоритмом хешиования. Если для файла в БД записан только MD5 хеш, то проверка будет произведена с использованием MD5. Если файл БД (db.xml) не существует, то создастся новый файл БД со сведениями о файле data.dat. Файл будет подсчитан с использованием как SHA1, так и MD5.

Start-PsFCIV C:\Files db.xml -SHA1 -MD5 -Rebuild

будет произведено освежение файла БД для папки C:\Files. Все записи, для которых соответствующего файла не обнаружено, будут удалены. Если в папке есть файлы, для которых нет соответствующей записи, то они будут обсчитаны с использованием алгоритмов SHA1 и MD5 и будут добвлены в XML файл. Файл db.xml должен существовать, иначе скрипт вернёт фатальную ошибку.

Start-PsFCIV C:\Files db.xml -SHA1 -Quiet

Папка C:\Files будет проверена в несопровождаемом режиме с использованием алгоритма SHA1. По умолчанию никакой информации на экране не будет. После окончания работы, в зависимости от результатов проверки, скрипт сгенерирует соответствующий код возврата (0-5).

И, собственно, сам скрипт:

1 PS1 file
38,3 KB PSFCIV_1.0.ps1

И как обычно, любые замечания, комментарии постить в каменты.

PowerShell Powered - http://www.sysadmins.lv

Certificate management pack

Camelot — Mon, 14 Sep 2009 19:02:32 GMT

Представлю на обозрение пробный скрипт по управлению сертификатами в хранилище Certificate Store — CertMgmtPack.ps1, который (как я надеюсь) может найти применение на серверах Windows Server 2008 R2 Server Core и реализован на основе наших недавних исследований:

Версия пока что 0.47 (т.к. предстоит добавить ещё разного функционала и допилить существующий). Пока что мне удалось реализовать функционал импорта сертификатов из файлов в store и экспорт из store в файлы сертификатов.

1 PS1 file
15,8 KB CertMgmtPack.ps1

Примечание: скрипт работает только в PowerShell V2. В каждую функцию вложена справка, которую вы можете прочитать набрав Get-Help Import/Export-Certiifcate.

После подключения скрипта (используя dot-sourcing) у вас будут доступны 2 функции:

Export-Certificate
Import-Certificate

И пару слов о том, как их использовать.

Import-Certificate

содержит следующие параметры:

Path <String> — путь к файлу сертификата, который может иметь следующий набор расширений: CER, DER, PFX, P7B, SST. Распознавание типов сертификатов осуществляется по расширению файла. Данная функция может принимать параметр пути из конвейера следующим путём:
```
dir *.cer | Import-Certificate
```
Параметр обязательный.

Password <SecureString> — пароль для PFX файла. Пароль не требуется для остальных типов файлов. Однако, хочу предупредить, что пароли не принимаются в открытом виде, а должны передаватьсякак SecureString. Это можно реализовать различными способами, например, вот так:
```
Read-Host "Enter password for PFX file" –AsSecureString
```

Storage <String> — указывает контекст импорта сертификата, т.е. это будет хранилище текущего пользователя (по умолчанию) или в хранилище компьютера (требуются права локального администратора). Может принимать значения User или Computer. Если параметр не указан, то берётся значение по умолчанию — User.
Container <String> — указывает контейнер размещения сертификата. Это может быть один из: AuthRoot, CA, Disallowed, My (по умолчанию), REQUEST, Root, SmartCardRoot, Trust, TrustedPeople, TrustedPublisher, UserDS. Расшифровка контейнеров (сопоставление названиям в оснастке CertMgr.msc) приведена внутри скрипта в хелпе функции. Если параметр не указан, то применяется параметр по умолчанию — My.
Exportable <Switch> — применяется только для импорта PFX файлов. Данный ключ помечает импортируемый сертификат как экспортируемый. Это означает, что вы после процедуры импорта сможете снова экспортировать сертификат с закрытым ключом. Эсли ключ Exportable не указан, то закрытый ключ сертификата не помечается как экспортируемый и при экспорте у вас не будет возможности экспортировать закрытый ключ данного сертификата.
StrongProtection <Switch> — применяется только для импорта PFX файлов. Данный ключ включает режим усиленной защиты закрытого ключа PFX файла. Это означает, что для каждой попытки использования закрытого ключа от этого сертификата потребуется ручной ввод пароля. Данный ключ нельзя использовать, если Storage указан как Computer, поскольку компьютерные сертификаты не поддерживают такой режим. Это связано с тем, что компьютерные сертификаты используются в контексте учётной записи LocalSystem и lsass.exe не предоставляет пользователю UI для ввода пароля. В любом случае, если вы попробуете это сделать, скрипт выдаст соответствующую ошибку и импорт произведён не будет.

И пару примеров, как использовать функцию:

$pass = Read-Host "Enter password for PFX" –AsSecureString
Import-Certificate mycert.pfx -Password $pass -Exportable

импортирует файл mycert.pfx в контейнер Personal хранилища текущего пользователя и пометит ключ как экспортируемый.

Import-Certificate mycert.pfx -Password $pass -StrongProtection

Импортирует файл mycert.pfx в контейнер Personal хранилища текущего пользователя, пометит ключ как неэкспортируемый и включит режим усиленной защиты закрытого ключа, что потребует ввод пароля пользователя каждый раз при его использовании.

Import-Certificate certs.p7b –Storage 'Computer' –Container 'TrustedPublisher'

Импортирует все сертификаты из файла certs.p7b в контейнер Trusted Publishers компьютерного хранилища.

Экспорт сертификатов

Path <String> — указывает путь к папке (не к файлу!), в которую будут экспортированы все указанные сертификаты. Парамер обязателен.
Type <String> — указывает тип экспортируемых сертификатов. Может принимать одно из значений: CERT, PFX, PKCS12, PKCS7, SST (Serialized Store). Параметр так же обязателен.
Password <SecureString> — задаёт пароль для экспортируемых PFX файлов (в качестве типа экспортируемых сертификатов указано PFX или PKCS12 и является для них обязательным). Параметр не принимает значение в виде простой строки, а только SecureString.
Storage <String> — указывает контекст поиска экспортируемых сертификатов, т.е. поиск будет производиться в компьютерном хранилище или хранилище текущего пользователя (по умолчанию). Может принимать значения CurrentUser или LocalMachine. Если параметр не указан, то берётся значение по умолчанию — User.
Container <String> — указывает контейнер размещения сертификата (или сертификатов). Это может быть один из: AuthRoot, CA, Disallowed, My (по умолчанию), REQUEST, Root, SmartCardRoot, Trust, TrustedPeople, TrustedPublisher, UserDS. Расшифровка контейнеров (сопоставление названиям в оснастке CertMgr.msc) приведена внутри скрипта в хелпе функции. Если параметр не указан, то поиск производится в контейнере по умолчанию — My.
Thumbprint <String> — задаёт критерий поиска сертификатов по отпечатку ключа (соответствующее поле Thumbprint сертификата). Можно указывать как полный отпечаток, так и любую его часть.
Subject <String> — задаёт критерий поиска сертификатов по полю Subject. Можно указывать как полный Subject, так и любую его часть.
Issuer <String> — задаёт критерий поиска по конкретному издателю сертификата. Можно указывать как полный CN издателя, так и любую его часть.
SerialNumber <String> — задаёт критерий поиска по серийному номеру сертификата. Можно указывать как точный серийный номер, так и любую его часть.
NotAfter <String> — задаёт критерий поиска по дате истечения сертификата. Дата задаётся в формате dd.MM.yyyy (день.месяц.год). В результате использования этого параметра будут отобраны сертификаты, которые истекут не позднее указанной даты.
NotBefore <String> — задаёт критерий поиска по дате начала действия сертификате. Как и в NotAfter дата указывается в формате dd.MM.yyyy и в результате использования этого параметра будут отобраны сертификаты, действие которых начинается не раньше указанной даты.
DeleteKey <Swtich> — используется только при экспорте сертификатов вместе с закрытыми ключами в PFX файлы. Данный ключ при успешном экспорте удаляет закрытый ключ данного сертификата из хранилища.

Я не смог провести полноценное тестирование функции экспорта, поэтому гарантировать 100% работу пока не могу. Но вы, уважаемые читатели, можете мне в этом помочь.

И несколько примеров использования:

Export-Certificate c:\certs -Type 'PKCS7'

Экспортирует все сертификаты из Current User\Personal в один PKCS7 файл с именем ExportedCertificates.p7b (это имя зашито на уровне скрипта).

Export-Certificate c:\certs -Type 'cert' -Storage 'LocalMachine' -Container 'Root' -SerialNumber '663'

Экспортирует все сертификаты из контейнера доверенных центров сертификации (Trusted Root CAs) компьютерного хранилища, у которых в серийном номере встречается последовательность 663 в CER файлы. При этом каждый сертификат будет экспортирован в индивидуальный файл с именем, которое строится по схеме: SubjectCN_Thumprint.CER, например: Thawte Premium Server CA_4F65566336DB6598581D584A596C87934D5F2AB4.cer

Export-Certificate c:\certs -Type 'PKCS12' -Password $pass -DeleteKey -Subject 'UserName'

Экспортирует все сертификаты из Current User\Personal в PFX файлы у которых в любом месте поля Subject есть UserName. При успешном экспорте закрытый ключ сертификата будет удалён из хранилища и будет содержаться только в PFX файле.

В связи с тем, что CN поля Subject может содержать недопустимые символы для имён файлов, мне скорее всего придётся искать другой метод именования экспортируемых сертификатов и чтобы они были распознаваемые. Если вы обнаружите какие-то ошибки или будут пожелания, то пишите мне в коментарии или на почту. По мере дописывания я буду выкладывать новые версии скрипта.

PowerShell Powered - http://www.sysadmins.lv

Экспорт PFX с удалением ключа из хранилища в PowerShell

Camelot — Thu, 10 Sep 2009 19:07:54 GMT

Короткая заметка. Когда вы экспортируете сертификат вместе с закрытым ключом, то можете заметить такую опцию:

К сожалению, метод Export() у объектов X509Certificate2 не позволяет штатно проделывать данную операцию. Это можно сделать через CAPICOM.PrivateKey.Delete(), но данная возможность отсутствует в PowerShell, в то время, как вы можете это сделать в VBS. Это связано с весьма паршивой поддержкой COM со стороны PowerShell, поэтому для реализации функционала этой галочки вам придётся проделать следующие шаги:

Получить объект X509Certificate2 самого сертификата;
Экспортировать его в PFX;
Открыть хранилище в режиме ReadWrite;
Удалить данный сертификат из хранилища;
Экспортировать объект сертификата уже не в PFX, а в Cert;
Импортировать этот экспортированный объект Cert (хотя, на самом деле там будет массив байтов, но это не столь существенно).

На языке PowerShell это выглядеть будет примерно так:

# получаем объект сертификата с закрытым ключом
$cert = (dir cert:\currentuser\my)[0]
# записываем пароль для PFX файла
$pass = Read-Host "Password" -AsSecureString
# экспортируем его в PFX формат
$bytes = $cert.Export("pfx", $pass)
# и записывем его в файл
[System.IO.File]::WriteAllBytes('mycert.pfx', $bytes)
# снова экспортируем данный объект, но уже в Cert формат
$tempcert = $cert.Export("Cert")
# создаём объект нашего хранилища
$store = New-Object system.security.cryptography.X509Certificates.X509Store "my", "CurrentUser"
# открываем его на чтение и на запись
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
# удаляем текущий сертификат с закрытым ключом из хранилища
$store.Remove($cert)
# записываем обратно Cert объект в хранилище, теперь уже без закрытого ключа
$store.Add($tempcert)
$store.Close()

Это только образец кода и его не стоит использовать прямо в таком виде, т.к. вы должны точно убедиться, что у вас PFX файл создался и он валидный. В противном случае вы останетесь совсем без закрытого ключа. И ещё раз напоминаю, при работе с хранилищем – не забывайте его закрывать после работы.

PowerShell Powered - http://www.sysadmins.lv

Импорт сертификатов в PowerShell

Camelot — Wed, 09 Sep 2009 19:20:18 GMT

В предыдущих статьях мы с вами уже изучили методы экспорта сертификатов из хранилища Certificate Store в файл:

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

Для импорта нам потребуется метод x509Certificate.Import(), который так же как и метод Export() имеет несколько конструкторов. Мы можем выбрать один универсальный, который подойдёт нам для всех типов файлов сертификатов и это будет конструктор: X509Certificate2.Import Method (String, SecureString, X509KeyStorageFlags). В качестве аргументов он принимает следующее:

String – путь к файлу сертификата
SecureString – строка с паролем. Требуется только для импорта PFX сертификатов, т.к. остальные типы файлов не содержат закрытых ключей и защищать их паролем нет смысла. Если это не PFX, то значение этого аргумента просто выставляется в $null.
объект типа X509KeyStorageFlags, который описывает область хранения сертификатов.

Давайте немного разберёмся с флагами последнего аргумента:

DefaultKeySet – указывает, что сертификат предназначен для импорта в контейнер Personal хранилища CurrentUser (дефолт).
Exportable – используется только для PFX файлов и говорит, будет ли возможность экспортировать сертификат с закрытым ключом. Если мы этот флаг не указываем, то после импорта не будет возможности снова экспортировать в PFX файл.
MachineKeySet – указывает, что сертификат будет установлен в хранилище компьютера (LocalSystem).
PersistKeySet – используется только для PFX и сохраняет пароль от PFX файла в сертификате. Данный пароль будет использован при дальнейшем экспорте в PFX файл (будет работать только с флагом Exportable).
UserKeySet – указывает, что сертификат будет установлен в пользовательское хранилище.
UserProtected – используется только для PFX файлов и для пользовательских сертификатов. Этот флаг включает Private Key Strong Protection, который при каждом использовании закрытого ключа будет требовать ввода пароля.

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

Т.к. X509KeyStorageFlags на самом деле является перечислителем (enumerator), то создавать его объект не обязательно и флаги можно просто использовать как строки. PowerShell уже сам подобъёт эти флаги к нужному типу данных.

т.к. у нас ещё нет готового объекта сертификатов, то мы его просто создаём:

$certs = New-Object system.security.cryptography.x509certificates.x509certificate2

И в этом объекте у нас будет метод Import(), которым мы уже воспользуемся:

$path = "mycert.pfx"
$password = Read-Host "Type password for PFX certificate" -AsSecureString
$flags = "UserKeySet, Exportable"
$certs.Import($path, $password, $flags)

Обратите внимание, что вы за один раз можете указать несколько флагов для KeyStorage, просто перечислив их через запятую. Теперь $certs у нас содержит x509Certificate2 объект нашего сертификата:

[↓] [vPodans] $certs = New-Object system.security.cryptography.x509certificates.x509certificate2
[↓] [vPodans] $path = "mycert.pfx"
[↓] [vPodans] $password = Read-Host "Type password for PFX certificate" -AsSecureString
Type password for PFX certificate: *
[↓] [vPodans] $flags = "UserKeySet, Exportable"
[↓] [vPodans] $certs.Import($path, $password, $flags)
[↓] [vPodans] $certs

Thumbprint                                Subject
----------                                -------
0F5157A8342C66493E7B1354530DD7A9F980BC69  CN=vPodans


[↓] [vPodans]

как видите, у нас всё случилось, PFX файл был успешно прочитан и помещён в объект x509Certificate2. Но это только половина дела, поскольку этот сертификат пока существует только самом в объекте, но не в хранилище. Для того, чтобы записать объект в хранилище мы должны поработать с хранилищем. За него отвечает класс X509Store. Мы создадим этот объект с нуля и укажем какой именно контейнер в каком хранилище открывать. Для этого мы воспользуемся следующим конструктором: X509Store Constructor (StoreName, StoreLocation). Здесь я подробно останавливаться не буду, поскольку названия хранилищ и контейнеров мы уже рассматривали в одном из предыдущих постов: Простой экспорт сертификатов в PowerShell, в этом посте все контейнеры показаны в первом снимке консоли. В нашем случае StoreName будет My (Personal), а Store Location будет CurrentUser (контекст текущего пользователя):

$store = New-Object system.security.cryptography.X509Certificates.X509Store "My", "CurrentUser"

Создали мы объект хранилища, теперь нам надо его открыть в режиме ReadWrite:

$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)

Этот флаг открытия хранилища указывать надо обязательно, иначе у вас просто не будет к нему доступа. Теперь когда хранилище открыто, можно методом Add(), который в качестве аргумента принимает только x509Certificate2 объекты (он у нас уже есть в переменной $certs):

$store.Add($certs)
$store.Close()

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

Вот и всё, собственно, у нас теперь PFX файл был успешно импортирован в хранилище.

Когда вы импортируете сертификаты из p7b (PKCS#7) файла, то в нём может быть несколько сертификатов, поэтому здесь поменяется всего 2 строчки. Поскольку у нас в одном файле может быть несколько сертификатов, то для их чтения из файла будем использовать не x509Certificate2 объект, а специальный массив таких объектов – x509Certificate2Collection, о котором мы уже говорили в предыдущем посте:

$bytes = [System.IO.File]::ReadAllBytes($path)
$certs = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$certs.Import($bytes)

Мы сначала прочитали байтовый массив из файла и засунули его в коллекцию x509Certificate2 объектов. Т.к. сертификатов там несколько, а метод Add() у x509Store за раз может взять только один объект – воспользуемся циклом:

$certs | %{$store.Add($_)}

А в остальном схема импорта p7b файлов будет такая же. Вот и всё, что я хотел рассказать по импорту сертификатов из файлов в хранилище. В принципе, используя эти знания вы уже можете затачивать код под свои нужды, тем более я везде, где это было необходимо, указывал ссылки на MSDN, где вы можете узнать более подробно этот материал. Но чтобы сделать жизнь чуточку проще, я постараюсь написать несколько полезных функций для управлениями сертификатами в PowerShell, что будет весьма актуально для Windows Server 2008 R2 Server Core.

Спасибо за внимание

PowerShell Powered - http://www.sysadmins.lv

Сложный экспорт сертификатов в PowerShell

Camelot — Mon, 07 Sep 2009 20:28:36 GMT

Продолжая тему экспорта сертификатов поговорим о более сложных вещах, чем простой экспорт сертификата из хранилища в CER/DER файл. На сей раз расскажу про экспорт сертификатов из хранилища в PFX (Personal Information Exchange Syntax Standard) и PKCS#7 (Cryptographic Message Syntax Standard) формат. Будет немного треша, но в пределах разумного.

Для экспорта сертификата в PFX нам потребуется выполнить половину кода из предыдущей статьи: Простой экспорт сертификатов в PowerShell.

Сначала выберем объект сертификат из хранилища:

$cert = (dir cert:\currentuser)[4]

Как вы помните, если экспортировать сертификат в PFX нам нужно указывать пароль:

Следовательно, конструктор метода Export(X509ContentType), который мы использовали нам уже не подойдёт, поскольку в этот конструктор нельзя вложить пароль. Мы можем воспользоваться одним из оставшихся конструкторов:

SecureString/String представляют собой аргумент для пароля. Я бы не советовал использовать простую строку для хранения пароля, а SecureString. Для этого мы сделаем такую строчку:

$password = Read-Host "Password" –AsSecureString

А теперь по аналогии с примером из предыдущего поста укажем тип сертификата как PFX и применим наш метод Export(X509ContentType, SecureString):

$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx
$bytes = $cert.Export($type, $password)

У нас снова получится массив байтов, т.к. этот метод возвращает только его. Но что с этим бинарным мусором делать? Я сначала по наивности предположил, что его так же запаковать в Base64 и записать в файл. Да, у меня всё вышло хорошо, данные были записаны в файл и Certificate Import Wizard принял его за валидный PFX файл. Но у меня всё обломалось на стадии ввода пароля, т.к. этот визард не хотел его брать. Ввиду отсутствия практики в этих делах, пришлось попросить помощи на одном из бложиков технета, откуда и пришёл ответ, что этот Certificate Import Wizard не декодирует файл обратно из Base64, поэтому для записи в файл нужно писать сразу байты:

[System.IO.File]::WriteAllBytes('certificate.pfx', $bytes)

В качестве первого аргумента указывается путь к файлу и вторым аргументом наш массив. Лично я без подсказки долго бы ещё ломал голову, что сделать с этим массивом, чтобы получить нужный эффект.

Но это всё относительно просто. Когда я задался вопросом “а как экспортировать в PKCS#7?”, то пришлось убить несколько часов на выяснение этого процесса. PKCS#7 удобен тем, что в себе может содержать кучу сертификатов и главным образом используется для хранения цепочки сертификатов (Certificate Chain). Например, особенно наблюдательные пользователи при посещении многих HTTPS сайтов могут заметить, что поле AIA есть только у самих SSL сертификатов, а у промежуточных CA его уже нету. Но этих сертификатов нету и в хранилище сертификатов (Certificate Store). Напрашивается вопрос: а как же система построила эту цепочку сертификатов при отсутствующем AIA в сертификатах? Оказывается, всё очень просто, в RFC2246 есть хороший момент:

certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

Это означает, что веб-сервер может вместе с SSL сертификатом отправлять клиенту и цепочку сертификатов, которая как раз и есть в формате PKCS#7. Если что, это было просто введение к назначению данного типа сертификатов.

Предупреждаю сразу, что методы x509Certificate2.Export Method нам не сгодятся, т.к. в описании метода есть ремарка:

The contentType parameter accepts only the following values of the X509ContentType enumeration: Cert, SerializedCert, and Pkcs12. Passing any other value causes a CryptographicException to be thrown.

Хоть класс System.Security.Cryptography.X509Certificates.X509ContentType и имеет в себе атрибут PKCS7, но метод Export класса x509Certificate2 его просто не принимает. Это был провал! Но делать нечего, пришлось искать. Наткнулся я вот на один замечательный пост: PKCS7 (p7b) bag of certificates and powershell. Но там пример как раз наоборот – как извлечь сертификаты из p7b файла и вывести их в виде x509Certificate2 объектов:

[reflection.assembly]::LoadWithPartialName("System.Security")
$data = [System.IO.File]::ReadAllBytes("certificates.p7b")
$cms = new-object system.security.cryptography.pkcs.signedcms
$cms.Decode($data)
$cms.Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | echo

Автор поста вообще удивительный человек. Просто взял и выложил код без каких-либо комментариев, предполагая, что все знают что делает этот код в деталях. Попробую за него сделать это я. Данный код читает бинарный мусор из файла (обратите внимание, что используется обратная операция экспорта PFX бинарного массива в файл). Далее создаётся объект CMS (Cryptographic Message Syntax). И что мы с него имеем:

[↓] [vPodans] [void][reflection.assembly]::LoadWithPartialName("System.Security")
[↓] [vPodans] $cms = new-object system.security.cryptography.pkcs.signedcms
[↓] [vPodans] $cms


Version      : 0
ContentInfo  : System.Security.Cryptography.Pkcs.ContentInfo
Detached     : False
Certificates : {}
SignerInfos  : {}



[↓] [vPodans] $cms | gm -MemberType methods


   TypeName: System.Security.Cryptography.Pkcs.SignedCms

Name             MemberType Definition
----             ---------- ----------
CheckHash        Method     System.Void CheckHash()
CheckSignature   Method     System.Void CheckSignature(bool verifySignatureOnly), System.Void CheckSignature(System....
ComputeSignature Method     System.Void ComputeSignature(), System.Void ComputeSignature(System.Security.Cryptograph...
Decode           Method     System.Void Decode(byte[] encodedMessage)
Encode           Method     byte[] Encode()
Equals           Method     bool Equals(System.Object obj)
GetHashCode      Method     int GetHashCode()
GetType          Method     type GetType()
RemoveSignature  Method     System.Void RemoveSignature(int index), System.Void RemoveSignature(System.Security.Cryp...
ToString         Method     string ToString()


[↓] [vPodans]

Мы имеем объект с 5 свойствами и различными методами. В коде используется метод Decode() и как видно в описании метода, в качестве аргумента принимается массив байтов, полученный из p7b файла. Этот метод преобразует этот массив обратно в массив объектов x509Certificate2, что видно из последней строки кода. Более-менее тут что-то понятно. Следовательно, для экспорта нам нужно проделать операцию наоборот, создать объект CMS, в свойство Certificates запихать x509Certificate2 объекты сертификатов и применить метод Encode(). Чтобы использовать этот метод у нас в свойстве Certificates должны храниться x509Certificate2 объекты наших сертификатов, которые хотим экспортировать. Но тут меня ждал облом, т.к. свойство Certificates является Read-only и записать туда ничего нельзя. Однако, PowerTab мне показал, что там есть что-то интересное:

[↓] [vPodans] $cms.Certificates.
                                ╔═ $cms.Certificates. ═════════════╗
                                ║ $cms.Certificates.PSBase         ║
                                ║ $cms.Certificates.Add(           ║
                                ║ $cms.Certificates.AddRange(      ║
                                ║ $cms.Certificates.Clear(         ║
                                ║ $cms.Certificates.Contains(      ║
                                ║ $cms.Certificates.CopyTo(        ║
                                ║ $cms.Certificates.Equals(        ║
                                ║ $cms.Certificates.Export(        ║
                                ║ $cms.Certificates.Find(          ║
                                ║ $cms.Certificates.GetEnumerator( ║
                                ║ $cms.Certificates.GetHashCode(   ║
                                ║ $cms.Certificates.GetType(       ║
                                ║ $cms.Certificates.Import(        ║
                                ║ $cms.Certificates.IndexOf(       ║
                                ║ $cms.Certificates.Insert(        ║
                                ║ $cms.Certificates.Remove(        ║
                                ║ $cms.Certificates.RemoveAt(      ║
                                ║ $cms.Certificates.RemoveRange(   ║
                                ║ $cms.Certificates.ToString(      ║
                                ║ $cms.Certificates.Item(          ║
                                ║ $cms.Certificates.Capacity       ║
                                ║ $cms.Certificates.Count          ║
                                ╚═[1] 1-22 (22/22)]════════════════╝

Я испробовал несколько по смыслу похожих методов, как Add, AddRange и Import, но всё неудачно. Сертификаты никак не хотели туда помещаться. После некоторого времени возни я бросил это занятие, как бесполезное, т.к. там ловить нечего:

[↓] [vPodans] $cms.Certificates | gm
Get-Member : No object has been specified to the get-member cmdlet.
At line:1 char:23
+ $cms.Certificates | gm <<<<
    + CategoryInfo          : CloseError: (:) [Get-Member], InvalidOperationException
    + FullyQualifiedErrorId : NoObjectInGetMember,Microsoft.PowerShell.Commands.GetMemberCommand

[↓] [vPodans]

Вобщем, всякие вариации с этим CMS объектов никаких успехов не приносили до тех пор, пока я не посмотрел тип этого свойства Certificates:

[↓] [vPodans] $cms.Certificates.GetType().FullName
System.Security.Cryptography.X509Certificates.X509Certificate2Collection

Я отправился на MSDN читать макулатуру по этому классу (точнее по его членам): X509Certificate2Collection Members. Если вы ещё не забыли, то мы ищем способ разобрать наш x509Certificate2 объект на массив байтов, который бы соответствовал формату PKCS#7. Здесь из годных методов я нашёл метод Add(X509Certificate2). У меня уже есть этот объект, поэтому мы его можем добавить в объект X509Certificate2Collection. Данный класс по сути представляет массив объектов x509Certificate2. Давайте сделаем:

[↓] [vPodans] $cert = (dir cert:\currentuser\my)[4]
[↓] [vPodans] $cert1 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
[↓] [vPodans] $cert1.Add($cert)
0
[↓] [vPodans] $cert1

Thumbprint                                Subject
----------                                -------
0F5157A8342C66493E7B1354530DD7A9F980BC69  CN=vPodans


[↓] [vPodans]

ну хорошо, преобразовали мы x509Certificate2 в X509Certificate2Collection, а что дальше? Нам по прежнему нужен этот дурацкий массив байтов. После этого я посмотрел на метод X509Certificate2Collection Export Method (X509ContentType) нового класса и прочитал ремарки:

This method supports content types that do not require a password.

Вот тут я и сказал “слава ~~сиськам~~Протоколу!”. Данный метод позволяет экспортировать объекты сертификатов в любой тип, который не требует пароля (т.е. всё, кроме PFX/PKCS#12). А дальше уже по отработанной схеме:

[↓] [vPodans] $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs7
[↓] [vPodans] $bytes = $cert1.Export($type)
[↓] [vPodans] [System.IO.File]::WriteAllBytes('certificate.p7b', $bytes)
[↓] [vPodans]

Вот таким долгим и тяжёлым (для меня, во всяком случае) я смог его победить и научиться экспортировать сертификаты в PKCS#7.

Что нас ждёт дальше? А дальше, возможно, поговорим про SerializedCert и SerializedStore (а может и не будем говорить) и уже импорт сертификатов из файлов в Certificate Store. А на сегодня, пожалуй, хватит.

PowerShell Powered - http://www.sysadmins.lv

Простой экспорт сертификатов в PowerShell

Camelot — Sun, 06 Sep 2009 09:46:46 GMT

С различной периодичностью на ньюсгруппах и англоязычных форумах встречаю вопрос, как экспортировать сертификаты из хранилища (Certificate Store) или сертификаты цифровых подписей файлов в .CER или .DER файл. Сегодня я продемонстрирую простой метод для экспорта этих сертификатов.

На самом деле разница между экспортом сертификата из хранилища сертификатов и подписанного файла заключается только в методе извлечения самого сертификата в x509Certificate2 объект. Давайте начнём с самого простого – экспорт сертификата из хранилища. В PowerShell уже есть свой провайдер для этого хранилища и свой PSDrive:

[↓] [vPodans] dir cert:\


Location   : CurrentUser
StoreNames : {SmartCardRoot, UserDS, AuthRoot, CA...}

Location   : LocalMachine
StoreNames : {SmartCardRoot, AuthRoot, CA, Trust...}



[↓] [vPodans] dir cert:\currentuser


Name : SmartCardRoot

Name : UserDS

Name : AuthRoot

Name : CA

Name : AddressBook

Name : Trust

Name : Disallowed

Name : My

Name : Root

Name : TrustedPeople

Name : TrustedPublisher

Name : REQUEST



[↓] [vPodans] dir cert:\currentuser\my


    Directory: Microsoft.PowerShell.Security\Certificate::currentuser\my


Thumbprint                                Subject
----------                                -------
9C5E4DCEF6598C1298894F62D4BD16E601B8C780  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
4BB89D732920DD91DE66983DDF2CC4EEC272A802  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
14B931DB4790403CCE2A3D03B62638FC7A0D5F34  CN=Administrator, OU=Administrators, DC=sysadmins, DC=lv


[↓] [vPodans]

Если просто посмотреть содержимое Cert:\, то мы увидим там 2 хранилища

CurrentUser – представляет хранилище текущего пользователя, т.е. является аналогом графической консоли CertMgr.msc
LocalMachine – представляет хранилище локального компьютера и является аналогом графической консоли MMC – Certificates, запущенной в контексте LocalComputer.

Внутри уже видны контейнеры, которые мы видим в виде папок в MMC консоли. А дальше уже хранятся наши сертификаты. Эти сертификаты здесь представлены в виде массива x509Certificate2.

[↓] [vPodans] (dir cert:\currentuser\my)[0].gettype().FullName
System.Security.Cryptography.X509Certificates.X509Certificate2
[↓] [vPodans]

Если посмотреть свойства этого объекта через Get-Member, то мы сможем там увидеть метод Export(). Но лучше посмотреть этот метод на MSDN, т.к. он имеет несколько конструкторов: x509Certificate2.Export Method. Из них нас заинтересует только первый конструктор, который Export(X509ContentType). Остальные 2 необходимы для экспорта с паролем (только для PFX). Но, как мы видим из описания метода, нам надо ещё указать x509ContentType объект, который будет указывать нам на тип экспортируемого сертификата. Типы экспортируемых сертификатов можно посмотреть по ссылке: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509contenttype.aspx или в консоли PowerShell:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509contenttype])
Unknown
Cert
SerializedCert
Pfx
Pkcs12
SerializedStore
Pkcs7
Authenticode

Нас сейчас будет интересовать только тип Cert (только открытая часть сертификата).

Теперь мы уже знаем достаточно много, чтобы уже начать писать код. Мы сейчас получим объект сертификата, укажем тип экспортируемого сертификата и выполним метод Export():

$cert = (dir cert:\currentuser\My)[0]
$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$ExportedData = $cert.Export($type)

Но это ещё не всё. Посмотрите, что у вас находится в переменной $ExportedData! Там на самом деле огромный массив байтов (в среднем более 2-20 тысяч элементов). Это же и указано в описании метода, что он возвращает. Именно массив байтов. Но что с ним делать? Я сам по-началу думал об этом, пока не вспомнил про одну вещь:

У нас есть выбор, как экспортировать сертификат – в DER или Base64 кодировке. Когда я писал про PsFCIV, то у меня была такая же ситуация. Hasher у меня так же возвращал массив байтов, который мы сразу же загоняли в Base64 кодировку. В нашем случае потребуется то же самое:

$base64Data = [System.Convert]::ToBase64String($ExportedData)

И на выходе мы молучим длинную Base64 строку, которую уже и нужно экспортировать в файл любым удобным для вас методом:

$base64Data > path\file.cer
Set-Content -Path path\file.cer -Value $base64Data

вы можете убедиться в этом просто открыв .CER файл. Чтобы получить объект сертификата из цифровой подписи файла, то мы можем просто воспользоваться командлетом Get-AuthenticodeSignature и выбрать свойство SignerCertificate. Если подпись файла дополнительно подписана сертификатом сервера времени, то вы можете использовать так же и свойство TimeStampCertificate:

[↓] [vPodans] $a.SignerCertificate

Thumbprint                                Subject
----------                                -------
9E95C625D81B2BA9C72FD70275C3699613AF61E3  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...


[↓] [vPodans] $a = Get-AuthenticodeSignature .\Desktop\EASetup.exe
[↓] [vPodans] $a.SignerCertificate

Thumbprint                                Subject
----------                                -------
9E95C625D81B2BA9C72FD70275C3699613AF61E3  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...


[↓] [vPodans] $a.TimeStamperCertificate

Thumbprint                                Subject
----------                                -------
4D6F357F0E6434DA97B1AFC540FB6FDD0E85A89F  CN=Microsoft Time-Stamp Service, OU=nCipher DSE ESN:85D3-305C-5BCF, OU=MOP...


[↓] [vPodans]

В этих свойствах сертификаты уже хранятся в виде объектов x509Certificate2 и дальше их можно экспортировать тем же самым путём, как мы это делали для сертификатов из Certificate Store. Собственно, для извлечения сертификатов из цифровых подписей файлов я написал неплохой скриптик, который добавляет в контекстное меню элемент Export Certificate:

и по нажатию на него цифровая подпись будет экспортирована в MyDocs\FileName.ext.cer, где FileName.ext – оригинальное имя файла и к нему просто пристыковывается расширение CER. В скрипте предусмотрены несколько диалоговых окон о состоянии сертификата:

файл подписан и хеш файла соответствует хешу в цифровой подписи:

файл подписан, но хеш файла не соответствует хешу в цифровой подписи:

файл не содержит цифровых подписей:

В двух последних случаях сертификат не экспортируется никуда по очевидным причинам. И, собственно скрипты-инсталляторы этого контекстного меню с рабочим кодом для:

PowerShell 1.0:

1 PS1 file
8,97 KB ExportCertificate_ps1.0.ps1

PowerShell V2:

1 PS1 file
8,34 KB ExportCertificate_ps2.0.ps1

В следующих статьях я планирую поговорить про импорт сертификатов в Certificate Store, а так же и экспорт сертификатов с закрытыми ключами в PFX файл с использованем Windows PowerShell.

PowerShell Powered - http://www.sysadmins.lv

Проверка блокировки файла приложениями

Camelot — Sat, 05 Sep 2009 19:46:15 GMT

Иногда бывает необходимость проверить, заблокирован ли файл каким-то приложением в монопольном режиме, прежде чем совершать какое-то действие над ним. Например, мой скрипт Get-PsFCIV.ps1 очень сильно ругается краснотой, если файл заблокирован, т.к. System.IO.StreamReader, который у меня используется для подсчёта хешей файлов требует, чтобы файл никем не был занят. Принцип проверки файла заключается в том, что мы пробуем получить доступ к файлу через System.IO.StreamReader и если это нам не удалось, значит файл заблокирован. Вот и решил написать такой удобный фильтр, который можно использовать и отдельно, просто для проверки блокировки файлов:

filter Test-FileLock {
    # проверяем, откуда пришли данные - из конвейера или через аргументы фильтра
    # и создаём объекты текущего элемента
    if ($args[0]) {$filepath = gi $(Resolve-Path $args[0]) -Force} else {$filepath = gi $_.fullname -Force}
    # отфильтровываем папки
    if ($filepath.psiscontainer) {return}
    # задаём переменную $locked в исходное значение $false
    $locked = $false
    # создаём ловушку для ошибки доступа. Если ловушка сработает, то переменная 
    # $locked выставляется в $true, что будет означать, что файл заблокирован
    # в монопольном режиме каким-то приложением
    trap {
        Set-Variable -name locked -value $true -scope 1
        continue
    }
    # открываем файл в режиме read/write. Если файл заблокирован, то ошибка будет
    # поймана ловушкой
    $inputStream = New-Object system.IO.StreamReader $filepath
    # если файл не был заблокирован, то закрываем StreamReader
    if ($inputStream) {$inputStream.Close()}
    # выводим результаты на экран в виде хеш-таблицы
    @{$filepath = $locked}
}

фильтр можно запускать как с аргументами, так и в конвейере:

[↓] [vPodans] Test-FileLock ntuser.dat

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.dat    True


[↓] [vPodans] Test-FileLock ntuser.ini

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.ini    False


[↓] [vPodans] dir ntuser.dat -Force | Test-FileLock

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.dat    True


[↓] [vPodans] dir ntuser.ini -Force | Test-FileLock

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.ini    False


[↓] [vPodans]

надеюсь, этот фильтр кому-нибудь сгодится ещё

PowerShell Powered - http://www.sysadmins.lv

Управление PowerShell ExecutionPolicy в домене

Camelot — Mon, 17 Aug 2009 15:50:42 GMT

Короткая заметка.

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

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

Однако, не везде у нас есть возможность использования такой настройки через GP, поскольку такая настройка есть только в ОС, в которых PowerShell поставляется по умолчанию – это Windows Server 2008, Windows Server 2008 R2 и Windows 7. Для остальных ОС такой настройки нету в политиках. Но не всё так плохо, как может показаться:

>> Administrative Templates for Windows PowerShell <<

Вам достаточно установить этот шаблон на компьютер, с которого вы управляете групповыми политиками. Данная политика будет размещена в секции: Computer Configuration –> Administrative Templates –> Windows Components –> Windows PowerShell.

Этот шаблон устанавливается на ОС не ниже Windows XP.

PowerShell Powered - http://www.sysadmins.lv

Замена служебных символов в запросах WMI

Camelot — Fri, 24 Jul 2009 20:32:55 GMT

Мне вчера на почту пришёл комментарий на пост: Смена владельца папки или файла в PowerShell (часть 2), в котором сообщалось об ошибке, которую генерирует скрипт, если в пути есть служебные мета-символы, как апостроф (одиночкая кавычка). А дело было в том, что этот мета-символ нужно дополнительно эскейпить (помимо обратных слешей в пути). То же касается и квадратных скобок. Одиночные кавычки эскейпятся очень просто – одним обратным слешем:

[↓] [vPodans] $path = "C:\Users\vPodans\text'text.txt"
[↓] [vPodans] $path = $path -replace "\\|'", '\$0'
[↓] [vPodans] $path
C:\\Users\\vPodans\\text\'text.txt
[↓] [vPodans] gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"


__GENUS          : 2
__CLASS          : Win32_LogicalFileSecuritySetting
__SUPERCLASS     : Win32_SecuritySetting
__DYNASTY        : CIM_Setting
__RELPATH        : Win32_LogicalFileSecuritySetting.Path="C:\\Users\\vPodans\\text'text.txt"
<...>

Но с квадратными скобками такой фокус не прошёл:

[↓] [vPodans] $path = "C:\Users\vPodans\text[text.txt"
[↓] [vPodans] $path = $path -replace "\\|\[", '\$0'
[↓] [vPodans] $path
C:\\Users\\vPodans\\text\[text.txt
[↓] [vPodans] gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"
Get-WmiObject : Invalid query
At line:1 char:5
+ gwmi <<<<  Win32_LogicalFileSecuritySetting -filter "path='$path'"
    + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

[↓] [vPodans]

попытка заэскейпить квадратные скобки при помощи бэктика (`) успехом не увенчалась:

[↓] [vPodans] $path = "C:\Users\vPodans\text[text.txt"
[↓] [vPodans] $path = $path -replace "\\", '\$0'
[↓] [vPodans] $path = $path -replace "\[", '`$0'
[↓] [vPodans] gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"
[↓] [vPodans]

он вообще файл не нашёл так. На удачу решил опробовать хитрый вариант – не эскейпить символ, а вписать его char номер из таблицы ASCII. И вот что у меня вышло:

[↓] [vPodans] $path = "C:\Users\vPodans\text[text.txt"
[↓] [vPodans] $path = $path -replace "\\", '\$0'
[↓] [vPodans] [int][char]"["
91
[↓] [vPodans] $path = $path -replace "\[", "$([char]91)"
[↓] [vPodans] $path
C:\\Users\\vPodans\\text[text.txt
[↓] [vPodans] gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"


__GENUS          : 2
__CLASS          : Win32_LogicalFileSecuritySetting
__SUPERCLASS     : Win32_SecuritySetting
__DYNASTY        : CIM_Setting
__RELPATH        : Win32_LogicalFileSecuritySetting.Path="C:\\Users\\vPodans\\text[text.txt"
<...>

И этот финт сработал! Тот же самый манёвр делается и для второй квадратной скобки:

[↓] [vPodans] $path = "C:\Users\vPodans\text[text].txt"
[↓] [vPodans] $path = $path -replace "\\", '\$0'
[↓] [vPodans] $path = $path -replace "\[", "$([char]91)"
[↓] [vPodans] [int][char]"]"
93
[↓] [vPodans] $path = $path -replace "\]", "$([char]93)"
[↓] [vPodans] $path
C:\\Users\\vPodans\\text[text].txt
[↓] [vPodans] gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"


__GENUS          : 2
__CLASS          : Win32_LogicalFileSecuritySetting
__SUPERCLASS     : Win32_SecuritySetting
__DYNASTY        : CIM_Setting
__RELPATH        : Win32_LogicalFileSecuritySetting.Path="C:\\Users\\vPodans\\text[text].txt"
<...>

Но в именах файлов и папок может содержаться один коварный символ – backtick (`). Его заэскейпить не представляется возможным, поэтому единственный выход с ним – прописывать путь в одинарных кавычках, чтобы этот мета-символ использовался в качестве литерала. В связи с чем я немного подрихтовал пост, ссылка на который приведена в начале этого поста.

PowerShell Powered - http://www.sysadmins.lv

Восстановление функциональности классов WMI

Camelot — Sat, 18 Jul 2009 13:45:06 GMT

В своём предыдущем блоге я писал заметку про то, как можно случайно удалить классы WMI – PowerShell - убийца WMI классов? И недавно узнал, как можно восстановить эту функциональность обратно. Сами Win32 классы находятся в библиотеке CIMWIN32.MOF, которая и повреждается при удалении классов. Чтобы вернуть эти классы – достаточно перекомпилировать эту библиотеку:

C:\Windows\System32\wbem\MOFComp CIMWIN32.MOF

[↑] [system32] gwmi win32_share

Name                                    Path                                    Description
----                                    ----                                    -----------
ADMIN$                                  C:\Windows                              Remote Admin
C$                                      C:\                                     Default share
D$                                      D:\                                     Default share
IPC$                                                                            Remote IPC
P$                                      P:\                                     Default share
print$                                  C:\Windows\system32\spool\drivers       Printer Drivers
Work                                    D:\Users\vpodans\Work
Z$                                      Z:\                                     Default share
_Shared Documents                       D:\Users\_Shared Documents


[↑] [system32] [wmiclass]'win32_share'


   NameSpace: ROOT\cimv2

Name                                Methods              Properties
----                                -------              ----------
Win32_Share                         {Create, SetShare... {AccessMask, AllowMaximum, Caption, Description...}


[↑] [system32] ([wmiclass]'win32_share').delete()
[↑] [system32] gwmi win32_share
Get-WmiObject : Invalid class
At line:1 char:5
+ gwmi <<<<  win32_share
    + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

[↑] [system32] cd wbem
[↑] [wbem] MOFComp CIMWIN32.MOF
Microsoft (R) MOF Compiler Version 6.0.6000.16386
Copyright (c) Microsoft Corp. 1997-2006. All rights reserved.
Parsing MOF file: CIMWIN32.MOF
MOF file has been successfully parsed
Storing data in the repository...
Done!
[↑] [wbem] gwmi win32_share

Name                                    Path                                    Description
----                                    ----                                    -----------
ADMIN$                                  C:\Windows                              Remote Admin
C$                                      C:\                                     Default share
D$                                      D:\                                     Default share
IPC$                                                                            Remote IPC
P$                                      P:\                                     Default share
print$                                  C:\Windows\system32\spool\drivers       Printer Drivers
Work                                    D:\Users\vpodans\Work
Z$                                      Z:\                                     Default share
_Shared Documents                       D:\Users\_Shared Documents


[↑] [wbem]

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

PowerShell Powered - http://www.sysadmins.lv

PS FCIV (часть 3)

Camelot — Thu, 09 Jul 2009 21:43:12 GMT

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

1PS1 file
25,5 KB PSFCIV_0.85.ps1

Итак, как с этим скриптом начинать работать. В скрипте есть 3 обязательных параметра: путь к папке, которую нужно посчитать или проверить, путь к XML файлу (если файла нету, то он будет создан) и как минимум 1 алгоритм хеширования. Т.е. минимум это должно выглядеть вот так:

.\PSFCIV_0.85.ps1 C:\Temp –xml DB.XML –sha1

При этом можно указать алгоритм –md5 или оба сразу (-sha1 –md5). В таком случае для каждого файла будет сгенерировано 2 хеша. Без указания любого из этих параметров будет сгенерирована ошибка и работа будет остановлена.

Опциональные параметры:

-Include file.ext – будет произведена проверка только указанного файла;
-Recurse – будет произведена проверка всех файлов в папке и подпапках;
-Rebuild – особый режим обновления XML файла, из которого будут удалены устаревшие записи и если есть новые файлы в папке или папках, то они будут добавлены в XML файл. Данный ключ требует наличия XML файла. Если файл БД не будет обнаружен, то будет выведена соответствующая ошибка. При этом режиме проверка целостности файлов не проверяется.
-Verbose brief/full – включает один из режимов вывода информации о ходе проверки на консоль. Можно выбрать Brief – упрощённый или Full – максимальный.
-Show Total/New/Ok/Bad/Miss – включает дополнительный режим вывода на экран одной из выбранных категорий. Например, всех проверенных файлов, только новых файлов, которые добавлены в БД, только файлов, которые прошли проверку, только файлы с несоответствующим хешем или только файлы, для которых есть запись в БД, но самого файла уже нету.
-Force Rename/Delete – включает режим действия над проблемными файлами. Можно выбрать – переименования (тогда к файлу будет добавлено расширение .BAD) или удаления файла.

На данном этапе реализована работа в соответствии с логикой (которая описана тут: PS FCIV (часть 1)) и односторонняя совместимость с FCIV. Т.е. этой утилите можно скармливать XML файл, который сгенерирован с помощью этого скрипта. В скрипте начата реализация поддержки альтернативных БД, которые не совместимы с FCIV XML. Плюс планируется обеспечение двусторонней поддержки FCIV – т.е. скрипт сможет корректно воспринимать и обрабатывать XML файлы, которые сгенерированы утилитой FCIV. Ну и оптимизация самого кода. Сам скрипт снабжён достаточно плотными комментариями, поэтому будет совсем нетрудно с ним разобраться. По мере дописывания кода буду выкладывать более актуальные версии файла.

Update 27.07.2009

Скрипт PsFCIV.ps1 переписан в виде Advanced Function под именем Get-PsFCIV. Теперь его достаточно загрузить в консоль используя dot-sourcing.
Добавлена справка для функции. После загрузки функции в консоль достаточно набрать команду: Get-Help Get-PsFCIV
По умолчанию на экран не выводится никакой информации, а только коды возврата. Коды возврата описаны в справке.
Изменён ключ -Verbose. Теперь используется стандартный ключ -Verbose для вывода расширенной информации. Аргументы не принмаются.
Добавлен стандартный ключ -Debug для вывода диагоностической информации.
Добавлена поддержка обработки XML файла сгенерированного утилитой FCIV (т.е. совместимость с FCIV теперь двусторонняя).
Ключ -Force заменён на ключ -Action с сохранением аргументов.
К ключу -Show добавлен ещё один аргумент Unknown для индикации файлов с неопределённым результатом проверки. Такое состояние у файла может быть в случае, если не удалось сопоставить алгоритмы хеширования. Т.е. когда при вызове функции указывается алгоритм –SHA1, но в XML файле есть только MD5 хеш и наоборот.

1 PS1 file
32,4 KB PSFCIV_0.88.ps1

PowerShell Powered - http://www.sysadmins.lv

PS FCIV (часть 2)

Camelot — Fri, 03 Jul 2009 20:26:05 GMT

Продолжаем повествование о процессе разработки функционального аналога FCIV.

Подсчёт хешей и кодирование в Base64 String

Как я уже упоминал, самая первая и основная функциональная часть – функция подсчёта хешей. Я уже делал скрипт, который считает хеши: Полезная безделушка Hash SHA1 на PowerShell, который и стал основой моего скрипта. Однако, по одной причине саму считалку пришлось обрезать. Если посмотреть справку по FCIV (http://support.microsoft.com/kb/841290), то он не записывает в БД реальный хеш файла, а пропускает его ещё через Base64 кодировку и закодированный хеш уже записывается в XML файл. В .NET уже есть стандартный кодировщик Base64, который на входе принимает массив байтов. Если посмотреть на указанный пост из моего блога, то там я приводил вывод объекта $hasher, который как раз и является байтовым массивом, который мы потом преобразовывали в строку. Здесь же преобразовывать в строку ничего не нужно, а сразу подаём этот массив в конвертер. Вот как выглядит функция подсчёта хеша:

function _hashbytes_ ($type, $file) {
    switch ($type) {
        "sha1" {$hasher = [System.Security.Cryptography.SHA1]::Create()}
        "md5" {$hasher = [System.Security.Cryptography.MD5]::Create()}
    }
    $inputStream = New-Object System.IO.StreamReader ($file)
    $hashBytes = $hasher.ComputeHash($inputStream.BaseStream)
    $inputStream.Close()
    $hashBytes
}

в качестве аргументов мы принимаем тип хеша – MD5 или SHA1 и сам файл:

[↓] [vPodans] _hashbytes_ sha1 wsr.txt
7
11
122
247
126
249
232
24
193
38
194
124
237
202
26
183
178
64
173
45
[↓] [vPodans] [System.Convert]::ToBase64String($(_hashbytes_ sha1 wsr.txt))
Bwt693756BjBJsJ87coat7JArS0=
[↓] [vPodans] [System.Convert]::ToBase64String($(_hashbytes_ md5 wsr.txt))
kshzMfHPdtuXdL6l/vWwPA==
[↓] [vPodans]

я подсчитал SHA1 хеш для текстового файла и на выходе получил такой же по структуре массив байтов, как и в предыдущей статье. И далее я этот массив подал в качестве аргумента для конвертера Base64 строки (статический метод ToBase64String класса System.Convert), а на выходе уже получил правильную Base64 строку. Именно эту строку FCIV записывает в файл. То же самое будем делать и мы. Кстати говоря. обратное преобразование делается через тот же класс System.Convert, но с использованием метода FromBase64String:

[↓] [vPodans] [System.Convert]::FromBase64String("Bwt693756BjBJsJ87coat7JArS0=")
7
11
122
247
126
249
232
24
193
38
194
124
237
202
26
183
178
64
173
45
[↓] [vPodans] -join ([System.Convert]::FromBase64String("Bwt693756BjBJsJ87coat7JArS0=") | %{"{0:X2}" -f $_})
070B7AF77EF9E818C126C27CEDCA1AB7B240AD2D
[↓] [vPodans]

как видите, массив байтов получился точно такой же. Второй строкой я показал, как можно собрать строку самого хеша, которую показывают различные программы подсчёта хешей. Как можно заметить все числа в массиве меньше, чем 256, т.е. не превышают значения 2⁸, что является 1 байтом в двоичной форме. В цикле Foreach-Object я преобразовываю каждый байт в HEX и собираю в единую строку оператором –Join, который доступен только в PowerShell V2. Но можно собрать и через [System.String]::Join() для PowerShell 1.0.

Генерация FCIV-совместимого XML файла

Если посмотреть в статью по FCIV, то увидим, что он использует свою нестандартную XML схему:

    <?xml version="1.0" encoding="utf-8" ?>
- <FCIV>
    - <FILE_ENTRY>
          <name>wsr.txt</name>
          <SHA1>Bwt693756BjBJsJ87coat7JArS0=</SHA1>
      </FILE_ENTRY>
     - <FILE_ENTRY>
          <name>0</name>
          <SHA1>xd/Rh0JyuW/I6sxPzY4sULyjS38=</SHA1>
      </FILE_ENTRY>
</FCIV>

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

Внимание: хоть FCIV и непривередлив к дополнительным полям в XML, но он начинает сильно ругаться, если поле Name написано с большой буквы. Его нужно заполнять так, как он есть в экземпляре, т.е. все маленькие буквы.

Объект, который будет хранить все данные о файле будет вот такой:

$object = "" | Select Name, Size, TimeStamp, SHA1, MD5

Т.е. мы в XML будем писать имя файла, его размер в байтах, время и дату последней модификации файла и хеши SHA1 и MD5. Если при создании БД мы будем использовать только один хеш, то второй будет просто пустым. Для сборки XML нам потребуется потребуется функция. Эту схему можно разложить на 3 составные части:

заголовок XML и открывающийся тег <FCIV>. Это присуствует только в начале XML файла и всё. Этот тег и заголовок больше нигде в XML не встречается. Поэтому header и открывающийся тег нужно поместить в скриптоблок Begin функции.
А вот теги <FILE_ENTRY> они повторяются для каждой записи. Следовательно этот тег будем заполнять в конструкции Process функции. Т.е. в каждой итерации Process будет создаваться новый тег <FILE_ENTRY>. Но внутри этого тега есть ещё вложенные теги, которые описывают наш файл. Чтобы решить эту задачу мы должны внутри конструкции Process (которая по сути будет являться циклом) написать ещё один цикл, который будет разбирать входящий объект и данные из его свойств записывать во вложенные теги.
В конце XML файла будет закрывающийся тег </FCIV>, его будем помещать в скриптоблок End нашей функции.

Вот такая функция у меня получилась:

function _toxml_ {
# в Begin создаём заголовок XML и открывающийся тег <FCIV>
    Begin {
        $xmlstring += "<?xml version=`"1.0`" ?>`n <FCIV>`n"
    }
# в Process будут по одному поступать объекты, которые описывают файл.
    Process {
# для каждого файла у нас будет один тег <FILE_ENTRY>
        $xmlstring += " <FILE_ENTRY>`n"
# чтобы вручную не создавать и не заполнять вложенные теги мы простым foreach
# перечисляем теги, какие у нас будут в XML и за счёт переменных автоматом
# создаём их в XML и заполняем их данными. Для этого свойства объектов должны
# называться так же, как и теги.
        foreach ($child in ("name", "Size", "TimeStamp", "SHA1", "MD5")) {
            $xmlstring += " <$child>$($_.$child)</$child>`n"
        }
# когда текущий объект обработан, закрываем тег и ждём следующий объект файла
        $xmlstring += " </FILE_ENTRY>`n"
    }
# когда объекты закончились, закрываем первый тег <FCIV> и подаём полученный XML дальше
    End {
        $xmlstring += "</FCIV>`n"
        $xmlstring
    }
}

в ходе испытаний нарвался на одну засаду. В XML существуют некоторые символы как ‘&’, ‘<’, ‘>’ и другие (полный список перечислен тут: http://www.hdfgroup.org/HDF5/XML/xml_escape_chars.htm), которые нужно эксейпить, поскольку являются метасимволами в XML. Эти символы (в частности одинарная кавычка и амперсанд) могут присутствовать в имени файла. Погуляв по сайту MSDN нашёл выход. Выход заключается в использовании метода Escape класса System.SecurityElement. Поэтому после того как массив объектов (которые описывают каждый файл) будет собран его нужно пропустить через фильтр и только после этого собирать XML вышеприведённой функцией. Вот как выглядит фильтр:

filter _escxml_ {
    $_.name = [Security.SecurityElement]::Escape($_.name)
    $_
}

Напоминаю, что мы должны эскейпить только свойство Name нашего объекта.

Преобразование FCIV-совместимого XML в массив объектов

Вот мы уже научились правильно создавать XML файл, который будет полностью совместим со схемой, которая используется в самом FCIV. Теперь у нас возникает задача чтения этого XML и преобразования в массив объектов. Сначала я долго горевал, плакал и бился головой об стену, что нельзя использовать Import-CliXML, но преобразование типов решило задачу ничуть не сложнее:

function _fromxml_ ($xml) {
    $sum = ([xml]$(gc -LiteralPath $xml)).FCIV.FILE_ENTRY | %{$_ | Select Name, Size, TimeStamp, SHA1, MD5}
    $sum
}

сначала читаем файл и преобразовываем его в типа данных XML, опускаем теги FCIV и FILE_ENTRY и в цикле разбираем вложенные теги и собираем объект. Получилось достаточно просто. На сегодня, я думаю, что хватит, продолжение следует.

PowerShell Powered - http://www.sysadmins.lv

PS FCIV (часть 1)

Camelot — Thu, 02 Jul 2009 19:38:14 GMT

После продолжительного затишья вызванного различными причинами (как выступление на MCP клубе в Москве), продолжаю тему PowerShell. На этот раз реализованный на PowerShell аналог File Checksum Integrity Verifier (FCIV) с расширенным функционалом по просьбе Артёма Проничкина.

У каждого системного администратора имеется некоторый файловый ресурс, который содержит такие вещи как инсталляционные ресурсы для своей компании и зачастую эти ресурсы достаточно большие и очень важно отслеживать целостность каждого файла, что он не был случайно модифицирован dbhecjv или как-то иначе повреждён. А так же контролировать появление новых файлов и удаление имеющихся файлов. Так же при обмене файловыми ресурсами можно использовать данный скрипт (который будет опубликован чуть позже) для проверки целостности передачи данных по сети. Например, сформировали комплект файлов для пересылки по сети. Сначала заготавливается исходная БД и это всё передаётся по сети в точку назначения, где применяют этот же скрипт и приложенную БД и проверяют, все ли файлы пришли целыми.

Для решения этой задачи Microsoft в своё время выпустила утилиту FCIV - http://support.microsoft.com/kb/841290. Суть работы этой утилиты заключается в том, что она в указанной папке (и подпапках по желанию) подсчитывает хеш каждого файла и заносит его значение в свою БД. БД представляет собой обычный XML файл, который содержит имя и хеш-сумму для файла. При повторной проверки утилита считывает данные из XML файла, подсчитывает для каждого файла хеш и сравнивает его с тем, который записан в БД. Собственно, это весь функционал утилиты. Чтобы расширить функционал этой утилиты пришлось написать свой скрипт, который решает эту задачу. Причём этот скрипт будет полностью совместим с FCIV, хоть и использует свои механизмы подсчёта файлов и генерации XML файла.

Самое первое – правильно составить логику работы скрипта:

ищем XML
если XML есть
    берём список файлов из XML
    эталонные хеши тоже из XML
    реальные хеши добываем при обсчёте файлов
    сравниваем со всеми вытекающими последствиями
    если файл есть в XML, а в папке нету - плачем
если XML нету
    ничего не сравниваем
    считаем хеши всех файлов в папке
    записываем их в XML

Как оказалось, FCIV оказался непривередливым в отношении полей в XML файле, поэтому я решил добавить 2 своих поля – дата последней модификации и размер файла в байтах. Добавив 2 новых поля я позволил немного сократить общее время работы скрипта: как известно, подсчёт хешей для файлов процесс ресурсоёмкий (по CPU и по времени) и если мы при сравнении обнаружим, что изменились либо дата последней модификации, либо размер файла, то пересчитывать для него хеш совершенно не обязательно, поскольку есть 100% вероятность, что он не совпадёт с тем, что записан в БД. Итак, описание функционала скрипта:

возможность подсчёта хешей файлов не только в текущей папке, но и подпапках;
возможность проверки только одного файла из БД;
возможность проверки файлов только с определёнными расширениями;
возможность подсчёта хешей: MD5 или SHA1. А так же есть возможность подсчёта обоих типов хешей с записью всех результатов в файл БД;
возможность контроля даты и времени последней модификации файла с точностью до секунды и размера файла с точностью до байта;
3 режима вывода служебной информации: без вывода, с минимальным выводом и с полным выводом служебной информации;
итоговая статистика, которая будет показывать общее количество проверенных файлов и количество файлов с определённым статусом (хороший/изменённый/отсутствующий/вновь добавленный);
полная обратная совместимость с FCIV;
возможность указания действия для изменённых файлов на выбор (переименование или удаление);
поскольку БД статическая и при сверке новые файлы в каталогах не проверяются и устаревшие записи не удаляются, поэтому был добавлен отдельный режим ReSync, который будет очищать записи для несуществующих более файлов и заносить в БД новые файлы, которые появляются в проверяемых папках.

Тело скрипта разбито на несколько функциональных частей:

функция подсчёта хешей;
генерация FCIV-совместимого XML файла;
преобразование FCIV-совместимого XML файла в массив объкектов;
организация итоговой статистики работы;
обеспечение основной логики работы.

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

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event6 (The 110-meter hurdles)

Camelot — Mon, 15 Jun 2009 21:15:38 GMT

Бег на 110 метров с барьерами.

Beginner Division

Задача:

В исходном файле скрипта найти все ошибки и исправить их. При запуске скрипта на рабочем столе должны появиться 3 ярылка: на сам скрипт, на веб-сайт Hey, Scripting Guys! и ярлык на блокнот (notepad.exe).

Решение:

Всё копировать не буду, а только приведу уже готовый скрипт. Сам текст скрипта можно взять тут: Hey, Scripting Guy! Opening Ceremonies and 2009 Scripting Games Event 6 Details (Beginner and Advanced; 110-meter hurdles). Исходные ошибочные строки привёл в комментарии:

#==========================================================================
#
# PowerShell:  AUTHOR: Ed Wilson , msft,  6/15/2009
#
# NAME: Beg_6.ps1
#
# COMMENT: Key concepts are listed below:
#1. Uses wscript.shell to create three shortcuts on the desktop. The first is a shortcut
#2. to this actual script. It uses the scriptfullName property to assign the path.
#3. The second is a simple Web site URL shortcut. The third one is a shortcut to
#4. Notepad.
#==========================================================================
$ErrorActionPreference = "SilentlyContinue"
Set-PSDebug -Strict
New-Variable -Name objShell #instance of the wshSHell object
New-Variable -Name strDesktop #pointer to desktop special folder
New-Variable -Name objShortCut #used to set properties of the shortcut. Comes from using createShortCut
New-Variable -Name objURL #used to set properties of webshortcut.
# было: $oShell = New-Object -ComObject ("WScript.Shell") - ошибка в имени переменной
$objShell = New-Object -ComObject ("WScript.Shell")
$strDesktop = $objShell.SpecialFolders.item("Desktop")

$objShortCut = $objShell.CreateShortcut($strDesktop + "\Shortcut Script.lnk")
# было: $objShortCut.TargetPath = $MyInvocation.ScriptName - неверное свойство
$objShortCut.TargetPath = $MyInvocation.MyCommand
$objShortCut.WindowStyle = 0
$objShortCut.Hotkey = "CTRL+SHIFT+F"
$objShortCut.IconLocation = "notepad.exe, 2"
$objShortCut.Description = "Shortcut Script"
$objShortCut.WorkingDirectory = $strDesktop
# было: $objShortCut.Save - при вызове метода забыли скобки
$objShortCut.Save()

# $wshShell = New-Object -ComObject wscript.shell - не нужно совсем
# было: $objURL = $objShell.CreateShortcut($strDesktop & "\The Microsoft Scripting Guys.url")
# вместо + поставили & из VBS
$objURL = $objShell.CreateShortcut($strDesktop + "\The Microsoft Scripting Guys.url")
$objURL.TargetPath = "http://www.ScriptingGuys.com"
# было: $objURL.Discription = "Scripting Guys". Такого свойства в URL файлах нету.
$objURL.Save()

# было: $wshNetwork = New-Object -ComObject wscript.network - не нужно свсем
# было: $objShortCut = $objShell.CreateShortcut($strDesktop + "\notepad.link")
# расширение не LNK, а LINK
$objShortCut = $objShell.CreateShortcut($strDesktop + "\notepad.lnk")
# было: $objShortCut.TargetPath = "notpad.exe" - пропустили букву E
$objShortCut.TargetPath = "notepad.exe"
$objShortCut.IconLocation = "notepad.exe, 0"
$objShortCut.description = "notepad"
$objShortCut.Save()

Если запустить этот скрипт из файла, то получится 3 ярлыка и первый будет вести именно на файл самого скрипта.

Advanced Division

и снова задача на парсинг текста. Потребуется файл network trace_adv6.txt из Competitors pack.

Задача:

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

Решение:

Самая первая задача, которая перед нами встаёт – создание регулярного выражения. Выражение у меня получилось вот такое:

^\d+\W+(\d+)\D+(\d+)\D+(\d+) ms (.*)

Что оно делает: оно откидывает порядковый номер прыжка (hop), любую небуквенную последовательность (в общем смысле [A-Za-z0-9]) и выбирает первую последовательность чисел. Эта последовательность будет будет являться временем первой попытки посылки ICMP пакета. Далее откидывается любая нечисловая последовательность и выбирается первая же числовая последовательность, которая будет являться второй попыткой посылки ICMP пакета. То же самое делаем до 3-й попытки текущего прыжка включительно. После выкидываем пробел и последовательность букв “ms”, за ней 2 пробела и захватываем всё до конца строки, что будет являеться адресом и/или именем маршрутизатора. Т.к. перед порядковыми номерами прыжков (до 9 включительно) присуствует пробел, то его можно средать методом Trim() и уже подставлять выражение. Из захваченного времени нужно на лету посчитать среднее значение. И вот что у меня вышло:

[↓] [vPodans] gc "Network Trace_Adv6.txt" | ?{$_.trim() -match "^\d+\W+(\d+)\D+(\d+)\D+(\d+) ms  (.*)"} | %{
>>     $current = "" | Select @{n='Average';e={[int](([int]$matches[1]+[int]$matches[2]+[int]$matches[3])/3)}},
>>     @{n='Name';e={$matches[4]}}
>>     $current
>> } | ft -a
>>

Average Name
------- ----
      1 r10.ntwk.nwtraders.com [192.168.227.82]
      1 r20.ntwk.nwtraders.com [192.168.169.1]
      1 r50.ntwk.nwtraders.com [192.226.42.47]
     13 r70.ntwk.nwtraders.com [192.226.42.12]
     34 r12.ntwk.nwtraders.com [192.226.42.9]
     34 r40.ntwk.nwtraders.com [192.226.42.22]
    104 r22.ntwk.nwtraders.com [192.226.34.80]
    105 r32.ntwk.nwtraders.com [192.226.47.10]
    125 r35.ntwk.nwtraders.com [192.226.41.198]
    173 r37.ntwk.nwtraders.com [192.226.38.14]
    173 r38.ntwk.nwtraders.com [192.226.226.119]
    389 192.168.216.5
    390 r60.ntwk.nwtraders.com [192.168.236.9]


[↓] [vPodans]

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

$sum = @()
gc "Network Trace_Adv6.txt" | ?{$_.trim() -match "^\d+\W+(\d+)\D+(\d+)\D+(\d+) ms  (.*)"} | %{
    $current = "" | Select @{n='Average';e={[int](([int]$matches[1]+[int]$matches[2]+[int]$matches[3])/3)}},
    @{n='Name';e={$matches[4]}}
    $sum += $current
}
$(for ($i = 0; $i -le $sum.Count; $i++ ) {
    if ($sum[$i].Average -lt $sum[$i + 1].Average) {$sum[$i]}
    if ($i -eq ($sum.Count - 1)) {$sum[$i]}
}) | ft @{l='Average';e={$_.Average};a='left'}, @{l='Name';e={$_.name}} -AutoSize

[↓] [vPodans] $sum = @()
[↓] [vPodans] gc "Network Trace_Adv6.txt" | ?{$_.trim() -match "^\d+\W+(\d+)\D+(\d+)\D+(\d+) ms  (.*)"} | %{
>>     $current = "" | Select @{n='Average';e={[int](([int]$matches[1]+[int]$matches[2]+[int]$matches[3])/3)}},
>>     @{n='Name';e={$matches[4]}}
>>     $sum += $current
>> }
>> $(for ($i = 0; $i -le $sum.Count; $i++ ) {
>>     if ($sum[$i].Average -lt $sum[$i + 1].Average) {$sum[$i]}
>>     if ($i -eq ($sum.Count - 1)) {$sum[$i]}
>> }) | ft @{l='Average';e={$_.Average};a='left'}, @{l='Name';e={$_.name}} -AutoSize
>>

Average Name
------- ----
1       r50.ntwk.nwtraders.com [192.226.42.47]
13      r70.ntwk.nwtraders.com [192.226.42.12]
34      r40.ntwk.nwtraders.com [192.226.42.22]
104     r22.ntwk.nwtraders.com [192.226.34.80]
105     r32.ntwk.nwtraders.com [192.226.47.10]
125     r35.ntwk.nwtraders.com [192.226.41.198]
173     r38.ntwk.nwtraders.com [192.226.226.119]
389     192.168.216.5
390     r60.ntwk.nwtraders.com [192.168.236.9]


[↓] [vPodans]

А теперь обратите внимание на одну вещь, о которой не все знают:

  ft @{l='Average';e={$_.Average};a='left'}

при форматировании Format-Table вы можете атрибутум A (от слова align) двигать содержимое колонки относительно названия. В первом примере у меня стандартное форматирование и выравнивание Avarage по правому краю. Здесь же я содержимое выравнил по левому краю, чтобы не сливались цифры. Хотя это решается удалением –AutoSize, но мне нравится этот ключ вобщем, об этой фиче не забывайте.

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event5 (The 400-meter race)

Camelot — Sun, 14 Jun 2009 10:16:39 GMT

Beginner Division

задача на работу с реестром.

Задача:

Найти текущее значение максимального количества закачек в Internet Explorer
Увеличить это число на другое значение
при чтении этого значения предусмотреть проверку существования этого параметра

Решение:

Ключи и значения реестра для этой задачи можно найти тут: http://support.microsoft.com/kb/282402. В принципе, очень просто тут:

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
    Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
    [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
} else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
    Write-Warning "MaxConnectionsPerServer property doesn't exist"
    [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
} else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}

и вот вывод:

[↓] [vPodans] $path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
[↓] [vPodans] if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
[↓] [vPodans] if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
>>     Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
>> if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
>>     Write-Warning "MaxConnectionsPerServer property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}
>>
WARNING: MaxConnectionsPer1_0Server property doesn't exist
WARNING: MaxConnectionsPerServer property doesn't exist
[↓] [vPodans] $path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
[↓] [vPodans] if (!(Test-Path $path)) {New-Item -ItemType Registry -Path $path -Force}
[↓] [vPodans] if (!(Get-ItemProperty $path).MaxConnectionsPer1_0Server) {
>>     Write-Warning "MaxConnectionsPer1_0Server property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPer1_0Server' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPer1_0Server is: " + (Get-ItemProperty $path).MaxConnectionsPer1_0Server}
>> if (!(Get-ItemProperty $path).MaxConnectionsPerServer) {
>>     Write-Warning "MaxConnectionsPerServer property doesn't exist"
>>     [void](New-ItemProperty -Path $path -Name 'MaxConnectionsPerServer' -Value 10 -PropertyType 'DWord')
>> } else {"MaxConnectionsPerServer is: " + (Get-ItemProperty $path).MaxConnectionsPerServer}
>>
MaxConnectionsPer1_0Server is: 10
MaxConnectionsPerServer is: 10
[↓] [vPodans]

как бы ничего сложного.

Advanced Division

работа с тэгами файлов. Потребуются файлы TechEd1.JPG, TechEd2.JPG и TechEd3.JPG из Competitors Pack.

Задача:

прочитать следующие EXIF свойства файлов:
Имя
когда снимок был сделан
свойство Make
и модель камеры, которой был сделан снимок

Решение:

Задача не такая и сложная, на самом деле, как кажется. Для начала нам потребуется класс System.Drawing.Bitmap и его метод GetPropertyItem. Для работы с этим классом нужно подключить библиотеку System.Drawing.dll:

[void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")

и создать объект System.Drawing.Bitmap:

$drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg

Этот объект будет содержать всё нам необходимое. Чтобы посмотреть нужные нам свойства, нужно получить где-то список всех ID, которым соответствуют эти свойства. К сожалению я не нашёл такого списка на MSDN, а только отдельными частями в интернете:
http://www.exif.org/specifications.html

там в конце PDF файла есть Appendix с таблицой ID на эту тему. Если посмотреть в таблицу, то увидим, что Model находится под ID = 272. Глянем, что там есть:

[↓] [vPodans] $drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg
[↓] [vPodans] $drawing.GetPropertyItem(271).value
67
97
110
111
110
0
[↓] [vPodans]

Как-то не очень радует такой вывод. Но если внимательно посмотреть на эти цифры, то можно заметить, что они не превышают число 256, что подсказывает, что это массив ASCII байтов. Эти ASCII байты можно сконвертировать в элемент вот так: [char]ASCII_Number. А т.к. это массив, то его нужно собрать либо методом ToString() или оператором –Join, который есть в PowerShell V2:

[↓] [vPodans] $drawing = New-Object system.drawing.bitmap -ArgumentList .\TechEd1.jpg
[↓] [vPodans] $drawing.GetPropertyItem(271).value
67
97
110
111
110
0
[↓] [vPodans] -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
Canon
[↓] [vPodans]

Вот так оно всяко лучше стало. По такой же схеме выбираем и собираем все остальные свойства:

[void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")
dir *.jpg | %{
    $drawing = New-Object system.drawing.bitmap -ArgumentList $_
    $photo = "" | Select Name, Author, Make, Model, DateTaken
    $photo.Name = $_.Name
    $photo.Author = -join ($drawing.GetPropertyItem(315).value | %{[char]$_})
    $photo.Make = -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
    $photo.Model = -join ($drawing.GetPropertyItem(272).value | %{[char]$_})
    $photo.DateTaken = -join ($drawing.GetPropertyItem(36867).value | %{[char]$_})
    $photo
} | ft -AutoSize

[↓] [vPodans] [void][reflection.assembly]::loadfile("C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll")
[↓] [vPodans] dir *.jpg | %{
>>     $drawing = New-Object system.drawing.bitmap -ArgumentList $_
>>     $photo = "" | Select Name, Author, Make, Model, DateTaken
>>     $photo.Name = $_.Name
>>     $photo.Author = -join ($drawing.GetPropertyItem(315).value | %{[char]$_})
>>     $photo.Make = -join ($drawing.GetPropertyItem(271).value | %{[char]$_})
>>     $photo.Model = -join ($drawing.GetPropertyItem(272).value | %{[char]$_})
>>     $photo.DateTaken = -join ($drawing.GetPropertyItem(36867).value | %{[char]$_})
>>     $photo
>> } | ft -AutoSize
>>

Name        Author     Make   Model               DateTaken
----        ------     ----   -----               ---------
TechEd1.JPG Ed Wilson  Canon  Canon PowerShot G9  2009:05:12 10:41:03
TechEd2.JPG Ed Wilson  Canon  Canon PowerShot G7  2009:05:12 10:25:59
TechEd3.JPG Ed Wilson  Sony   A-9                 2009:05:12 10:26:48


[↓] [vPodans]

Вобщем, как видите, тут тоже ничего сверхсложного нету.

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event4 (The high jump)

Camelot — Sat, 13 Jun 2009 21:17:31 GMT

Прыжки с шестом.

Beginner Division

Потребуется файл HighJumperDatabase.mdb из Competitors Pack.

Задача:

опросить MDB файл и вывести имя лучшего прыгуна c шестом (хотя там цифры немного странные для этой дисциплины).

Решение:

Никогда не приходилось работать с Access, поэтому пришлось честно гуглить: http://www.visualbasicscript.com/m_43134/tm.htm. Его я взял за основу, только немного подрихтовал и вот что получилось:

# создаём массив, который будет содержать все результаты
$sum = @()
# подключения к БД. Наглый копипаст с форума.
# более-менее внятное описание этого кода тут:
# http://technet.microsoft.com/en-us/magazine/2009.05.scriptingguys.aspx
$adOpenStatic = 3
$adLockOptimistic = 3
$MDBConn = New-Object -comobject ADODB.Connection
$MDBConn.Open("provider=microsoft.jet.oledb.4.0;data source=$pwd\HighJumperDatabase.mdb")
$Record = New-Object -comobject ADODB.RecordSet
$Record.Open('select * from [High Jumper Data]',$MDBConn,$adOpenStatic,$adLockOptimistic)
$Record.MoveFirst()
do {
    # делаем объект текущего атлета и забиваем в него нужные значения
    $current = "" | Select @{n='Name';e={$Record.Fields.Item("Name").Value}},
    @{n='Personal Best';e={$Record.Fields.Item("Personal Best").Value}},
    @{n='Season Best';e={$Record.Fields.Item("Season Best").Value}}
    # добавляем текущего участника в массив
    $sum += $current
    # переходим на следующую итерацию
    $Record.MoveNext()
} until ($Record.EOF)
# закрываем все подключения
$Record.Close() 
$MDBConn.Close()
# сортируем и выводим лучшего спортсмена
$sum | Sort "Season Best", "Personal Best" | select Name -Last 1

Кстати, отличное решение этой задачи нашёл на VBS. Человек уложился в 4(!) строчки:

Set adoCon = CreateObject("ADODB.Connection")
adoCon.Open "DRIVER=Microsoft Access Driver (*.mdb);DBQ=HighJumperDatabase.mdb"
Winner = adoCon.Execute("SELECT TOP 1 Name FROM [High Jumper Data] ORDER BY [Personal Best] DESC")("Name")
WScript.Echo "Expected Winner: " & Winner

Есть мнение, что фанаты PowerShell должны дружно застрелиться хотя это просто вопрос запроса к базе Access.

Advanced Division

потребуется файл High Jump Stats_Adv4.txt из Competitors Pack.

В файле перечислены имена прыгунов с шестом и через запятую перечислены высОты планки.

Задача:

на основании этих данных построить произвольный (желательно красивы) график в Excel.

Решение:

Т.к. я графики тоже никогда не рисовал, поэтому тоже пришлось обратиться к гуглу. И вышло примерно такое:

# переименовываем txt файл в CSV. Теперь не нужно конвертировать тектовый файл в
# формат Excel, т.к. при переименовании Excel сам это сделает
ren "High Jump Stats_Adv4.txt" "High Jump Stats_Adv4.csv"
# выполняем обычную рутину для создания COM объекта для Excel
$excel = New-Object -ComObject excel.application
$file = $excel.Workbooks.Open("$pwd\High Jump Stats_Adv4.csv")# | Out-Null
$excel.Visible = $false
$excel.DisplayAlerts = $false
$sheet = $excel.Worksheets.Item(1)
# добавляем диаграмму
#$chart = $excel.Charts.Add()
# задаём диапазон для диаграммы
$Range = $sheet.Range("A1:l1")
# добавляем элемент Chart с нужным диапазоном. Я выбрал 10 первых попыток
# для первого атлета. 
$chart = $excel.Charts.Add()
$chart.SetSourceData($Range)
$chart.ChartStyle = 27
# сохраняем Chart в файл формата Excel и закрываем работу
$file.SaveAs("$pwd\High Jump Stats_Adv4.xlsx")
$excel.Quit()
gps excel | stop-process
# переименовываем CSV файл обратно в TXT
ren "High Jump Stats_Adv4.csv" "High Jump Stats_Adv4.txt"

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event3 (The shot put)

Camelot — Fri, 12 Jun 2009 07:07:50 GMT

3-е задание на парсинг текста.

Beginner Division

Потребуется файл Shot Put.txt из Competitors Pack.

Задача:

В файле есть 2 абзаца. Нужно первый абзац записать в файл Shot Put A.txt, а второй абзац записать в Shot Put B.txt.
Переименовать файл Shot Put.txt в Shot Put.old.

Решение:

Если внимательно посмотреть на файл, то в нём можно найти одну уникальную последовательность - `r`n`r`n. Она разделяет 2 абзаца. Поэтому эту последовательность можно использовать в качестве разделителя для Get-Content:

[↓] [vPodans] $file = gc '.\Shot Put.txt' -Delimiter "`r`n`r`n"
[↓] [vPodans] $file[0]
This is the first paragraph of the shot put text file. It will
need to be placed into the first text file which you will create.
The shot put is an event involving putting and heavy metal ball.
The object of the event is to throw the put as far as possible,
or to put the shot : anyway, you get the idea.




[↓] [vPodans] $file[1]
This is the second paragraph of the shot put text file. it
contains information you will need to put into the second
file which you will also create.
[↓] [vPodans]

Если со вторым абзацем понятно, то у первого очень много пробелов и пустых строк. Их можно удалить при помощи метода Trim(), который использовался уже в Event1. Собственно, само решение:

$file = gc '.\Shot Put.txt' -Delimiter "`r`n`r`n" | %{$_.trim()}
$file[0] > 'Shot Put A.txt'
$file[1] > 'Shot Put B.txt'
ren '.\Shot Put.txt' 'Shot Put.old'

Advanced Division

потребуется файл Wordlist_ADV3.txt из Competitors Pack.

Задача:

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

Решение:

В принципе, тут есть только одно простое решение (считайте, что нагло стырено у Васи):

gc .\Wordlist_ADV3.txt | ?{$_ -replace '[^AEIOUY]' -match '^(.)\1*$'} > 'Wordlist_ADV3_new.txt'

суть решения заключается в том, чтобы из каждого слова убрать все согласные и проверить, что в слове используется только одна гласная 1 или более раз. Этот регексп описан в PowerShell Cookbook на странице 494.

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event2 (The long jump)

Camelot — Thu, 11 Jun 2009 07:00:41 GMT

Beginner Division

Тут очень простое задание из серии фаллометрии

Задача:

Показать данные своего процессора (процессоров) в соответствии с рисунком

Решение:

Тут нам потребуется WMI класс Win32_Processor. И из него выберем нужные данные. При этом я проверю, что значения не равны $null или нулю. Если это так, то в это поле впишу текст N/A для читабельности. Вот что получилось:

$Host.UI.RawUI.BackgroundColor = "Black"
cls
$processor = gwmi win32_processor | Select AddressWidth, L2CacheSize, L2CacheSpeed, L3CacheSize,
L3CacheSpeed, MaxClockSpeed, Name, NumberOfCores, NumberOfLogicalProcessors
$processor | gm -MemberType NoteProperty | %{
    if ($processor.$($_.name) -eq $null -or $processor.$($_.name) -eq 0) {$processor.$($_.name) = "N/A"}
}
Write-Host 'Strength evaluation for LocalHost' -ForegroundColor Green
Write-Host 'Speed ... ' $processor.MaxClockSpeed `
`n'L2 Cache Size:' $processor.L2CacheSize `
`n'L2 Cache Speed:' $processor.L2CacheSpeed `
`n'L3 Cache Size:' $processor.L3CacheSize `
`n'L3 Cache Speed:' $processor.L3CacheSpeed -ForegroundColor Yellow
Write-Host Strength ... `
`n'Number of Cores:' $processor.NumberOfCores `
`n'Number of Logical Processors:' $processor.NumberOfLogicalProcessors `
`n'Name: `t`t`t`t' $processor.Name -ForegroundColor Magenta
Write-Host Agility ... `
`n'Address Width:' $processor.AddressWidth -ForegroundColor Cyan

И вот вывод:

[↓] [vPodans] $processor = gwmi win32_processor | Select AddressWidth, L2CacheSize, L2CacheSpeed, L3CacheSize,
>> L3CacheSpeed, MaxClockSpeed, Name, NumberOfCores, NumberOfLogicalProcessors
>> $processor | gm -MemberType NoteProperty | %{
>>  if ($processor.$($_.name) -eq $null -or $processor.$($_.name) -eq 0) {$processor.$($_.name) = "N/A"}
>> }
>> Write-Host 'Strength evaluation for LocalHost' -ForegroundColor Green
>> Write-Host 'Speed ... ' $processor.MaxClockSpeed `
>> `n'L2 Cache Size:' $processor.L2CacheSize `
>> `n'L2 Cache Speed:' $processor.L2CacheSpeed `
>> `n'L3 Cache Size:' $processor.L3CacheSize `
>> `n'L3 Cache Speed:' $processor.L3CacheSpeed -ForegroundColor Yellow
>> Write-Host Strength ... `
>> `n'Number of Cores:' $processor.NumberOfCores `
>> `n'Number of Logical Processors:' $processor.NumberOfLogicalProcessors `
>> `n'Name:  $processor.Name -ForegroundColor Magenta
>> Write-Host Agility ... `
>> `n"Address Width: `t`t`t`t" $processor.AddressWidth -ForegroundColor Cyan
>>
Strength evaluation for LocalHost
Speed ...  2834
L2 Cache Size: 6144
L2 Cache Speed: 2000
L3 Cache Size: N/A
L3 Cache Speed: N/A
Strength ...
Number of Cores: 4
Number of Logical Processors: 4
Name:                Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
Agility ...
Address Width: 64
[↓] [vPodans]

По всей видимости оно получилось как и требовалось.

Advanced Division

И тут нас снова ждут соревнования. Здесь нам потребуется файл LongJump_Adv2.xls из Competitors Pack. Файл содержит данные об участниках прыжков в длину и результаты их 3-х попыток.

Задача:

На основании результатов 3-х попыток в колонку Result записать лучший результат из 3-х попыток
На основании результатов третей попытки для каждого участника, выбрать лучший результат из них и вывести на экран
Сравнить лучший результат из 3-х попыток для каждого участника с их средним результатом в сезоне. Такой графы я не нашёл, есть только лучший результат в сезоне. Вот с ним я и сравнивал. Если прыгун превзошёл свой личный рекорд сезона, то в графу Exceed,Achieve,Under Perform вписать Exceed. Если повторил, то Achieve или Under Perform, если лучший результат сегодня был хуже результата по сезону.
Отсортировать всю таблицу по графе Exceed,Achieve,Under Perform именно в таком порядке. Т.е. сперва идут те, кто улучшил свой показатель, потом – кто повторил и в самом конце те, кто не смог повторить свой результат в сезоне. И сохранить в файл с таким же именем.

Решение:

Вася Гусев решил окончательно сломать всем мозг разбором XLS в CSV, обработать его и собрать обратно в CSV – тиснуть сюда. Когда я это увидел – стало как-то не очень хорошо. Я решил работать прямо с XLS. И вот что у меня получилось:

# массив, который будет содержать результаты последней попытки прыжков, на основании
# которых нужно вывести лучший результат
$lastattempt = @()
# создаём COM объект и прочую рутину.
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $false
$excel.DisplayAlerts = $false
$excel.Workbooks.Open('C:\Users\vPodans\LongJump_Adv2.xls') | Out-Null
# у нас есть известное кол-во участников - 18. 19-я строка - это заголовки.
# поэтому я исходя из этого решил работать с колонкой Result (8-я по счёту). Т.к.
# некоторые попытки были провалены и в таблице стояли крестики. Чтобы вручную не парсить
# это всё, я в ячейку воткнул экселовскую формулу MAX, которая всё за меня сделает.
2..19 | %{$excel.Cells.Item($_,8).Value2 = "=max(e$_`:g$_)"
    # заодно в $lastattempt запишем результат последней попытки для текущего прыгуна
    $lastattempt += $excel.Cells.Item($_,7).Value2
    # сравниваем лучший результат за сегодня с результатом за сезон
    if ($excel.Cells.Item($_,8).Value2 -lt $excel.Cells.Item($_,4).Value2) {
    # и в соответствующую графу пишем результат
        $excel.Cells.Item($_,9).Value2 = "Under Perform"
    # вот тут пришлось использовать читы. Я не очень силён в custom sort в экселе, поэтому
    # рядышком я для каждого статуса Exceed/Achieve/.. я приписываю число. Вот по этому числу
    # я потом буду сортировать таблицу
        $excel.Cells.Item($_,10).Value2 = "3"
    } elseif ($excel.Cells.Item($_,8).Value2 -eq $excel.Cells.Item($_,4).Value2) {
        $excel.Cells.Item($_,9).Value2 = "Achieve"
        $excel.Cells.Item($_,10).Value2 = "2"
    } else {
        $excel.Cells.Item($_,9).Value2 = "Exceed"
        $excel.Cells.Item($_,10).Value2 = "1"
    }
}
# выбираем из LastAttempt лучший результат, попутно заменяя крестики на нолики (лол) и выводя лучший результат
$lastattempt | %{if ($_ -eq "x") {$_ = 0};$_} | sort | select -last 1
# выбираем диапазон изменения таблицы при сортировке. Заголовки не трогаем, поэтому начинаем с 2
$selection = $excel.Range("a2:j19")
# указываем колонку, по которой будем сортировать
$range = $excel.Range("j2:j19")
# сортируем
[void]$selection.Sort($range,"1")
# удаляем читерские числа, которые использовались для сортировки.
2..19 | %{$excel.Cells.Item($_,10).Value2 = ""}
# готово.
$excel.Save()
$excel.Quit()

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

PowerShell Powered - http://www.sysadmins.lv

Scripting Games 2009 – Event1 (The 100-meter dash)

Camelot — Wed, 10 Jun 2009 12:16:53 GMT

И оно свершилось! Хотя официально Scripting Games начинаются только 15-го июня, но уже со вчерашнего дня стали известны уже 2 задания. Для начала немного информации, что и как:

Условия участия и публикации: Details Leaked About the 2009 Summer Scripting Games!
Официальная страница Scripting Games: Hey, Scripting Guy! Там публикуются все задания
Материал для заданий находится в the Competitor's Pack.
Публиковать свои решения нужно на сайте http://scriptinggames.poshcode.org/ Требуется аутентификация с OpenID (а почему не LiveID?).

В принципе, вы можете решать задания как угодно, т.к. засчитываются все, которые отвечают условиям задания.

Итак, Event1 и оба дивизиона:

Beginner Division

Из Competitors Pack нам потребуется файл 100 Meter Event.txt

Задача:

Выяснить, как читать файл?
Как прочитать из каждой строки поля Name, Country, Time?
Как отсортировать содержимое файла по полю Name?
Выбрать 3-х победителей из списка. Победителем считается тот, у кого самое маленькое время в колонке Time
Показать поля Name, Country и Time для первых 3-х победителей.

Решение:

Побегав курсором по файлу я обнаружил тот факт, что разделителем между столбцом Name и Country является табулятор ([Tab]), а между Country и Time стоит один пробел во второй строке, а в остальных строках стоит [Tab]. Следовательно, варианты использования командлетов с параметром –Delimeter не прокатят и нужно будет разбирать всё регулярными выражениями. Первый вопрос наталкивает на необходимость чтения файла не через Get-Content, а через [system.io.file]::ReadAllText(). Но я не вижу особого криминала в использовании родного для PowerShell командлета Get-Content. Это будет несложно. Основная проблема в том, как составить регулярное выражение. Я решил разобрать имя на First Name и LastName (т.к. правильней, всё же, будет, когда сначала идёт имя, а потом фамилия), далее выбрать Country от табуляции до первого числа. Причём, тут потребуется каждую часть сделать именованной (named capture). Если открыть PowerShell In Action на 111 странице, то там можно найти описание, как делать named captures. У меня регулярное выражение получилось вот такое:

^(?<ln>\w+)..(?<fn>.*)\t(?<country>.+)(?<time>\d\.\d+)

Что делает это выражение:

в секцию LN (LastName) попадают все буквы до первого небуквенного знака.
далее пропускаем 2 символа (запятую и пробел).
в секцию FN (FirstName) попадает всё до первой табуляции.
после табуляции идёт Country и в него запишем всё, вплоть до первого числового знака.
И числа записываем в секцию Time.

Давайте проверим его:

[↓] [vPodans] $file = gc '.\100 Meter Event.txt'
[↓] [vPodans] $file[1] -match "^(?<ln>\w+)..(?<fn>.*)\t(?<country>.+)(?<time>\d\.\d+)"
True
[↓] [vPodans] $matches

Name                           Value
----                           -----
country                        Australia
ln                             Aaberg
fn                             Jesper
time                           8.57
0                              Aaberg, Jesper    Australia 8.57


[↓] [vPodans] $file[11] -match "^(?<ln>\w+)..(?<fn>.*)\t(?<country>.+)(?<time>\d\.\d+)"
True
[↓] [vPodans] $matches

Name                           Value
----                           -----
country                        Japan
ln                             Hansen
fn                             Anne Grethe
time                           8.85
0                              Hansen, Anne Grethe    Japan    8.85


[↓] [vPodans]

и теперь соберём объект с нужными свойствами и отправим его на выход. На выходе отсортируем объекты по параметру Time и выберем первые 3 объекта:

gc "100 Meter Event.txt" | ?{$_ -match "^(?<ln>\w+)..(?<fn>.*)\t(?<country>.+)(?<time>\d\.\d+)"} |%{
    $obj = "" | Select @{n='Name';e={$matches.fn + " " + $matches.ln}},
    @{n='Country';e={$matches.country}},@{n='Time';e={$matches.time}}
    $obj
} | sort time | select -First 3 | ft -AutoSize

и вот вывод:

[↓] [vPodans] gc "100 Meter Event.txt" | ?{$_ -match "^(?\w+)..(?.*)\t(?.+)(?\d\.\d+)"} |%{
>>     $obj = "" | Select @{n='Name';e={$matches.fn + " " + $matches.ln}},
>>     @{n='Country';e={$matches.country}},@{n='Time';e={$matches.time}}
>>     $obj
>> } | sort time | select -First 3 | ft -a
>>

Name          Country     Time
----          -------     ----
Jesper Aaberg Australia   8.57
David Pelton  Austria     8.6
Wilson Pais   Germany     8.62


[↓] [vPodans]

решил ещё отформатировать в Format-Table с ключом –AutoSize для красоты. Признаюсь, что это задание меня сильно озадачило. Для меня оно оказалось очень непростым (такие дела).

Advanced Division

Для этой задачи нам потребуется файл Personal Information Cards_ADV1.txt из Competitors Pack.

Задача:

найти самую короткую строку в файле, которая содержит какой-либо текст.
вывести на экран 3 самые короткие строчки

Решение:

В файле много пустых строк, но это не проблема. Итак, one-liner решение:

gc "Personal Information Cards_ADV1.txt" | ?{$_.trim().length -ne 0} | sort length | select -First 3

[↓] [vPodans] gc "Personal Information Cards_ADV1.txt" | ?{$_.trim().length -ne 0} | select –First 3
PPID
Claims
Street
[↓] [vPodans]

Странно, что в Advanced Division получилось такое простое задание.

PowerShell Powered - http://www.sysadmins.lv

Cmdlet wrapping и PsBoundParameters

Camelot — Mon, 08 Jun 2009 21:41:52 GMT

Работая с функциями в PowerShell можно столкнуться с одной особенностью – в качестве передачи аргументов в функции или скрипты вы можете использовать почти всё, кроме ключей (данных типа Switch). Их передавать можно, но тут есть одна особенность. Обычно это ощущается, когда вы работаете с командлетами. Возьмём простой пример:

function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
Write-Host '$Path is:' $Path
Write-Host '$Filter is:' $Filter
Write-Host '$Force is:' $Force
}

и вызовем эту функцию:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>> Write-Host '$Path is:' $Path
>> Write-Host '$Filter is:' $Filter
>> Write-Host '$Force is:' $Force
>> }
>>
[↓] [vPodans] Test C:\ * -force
$Path is: C:\
$Filter is: *
$Force is: True
[↓] [vPodans]

В принципе, всё как и ожидалось. Но если внимательно посмотреть на последний аргумент, то мы увидим лишь True, т.е. увидим факт, что ключ Force был передан. Однако, PowerShell не умеет подставять (биндить) переменную $Force (равно как и другие переменные) как именованный параметр в другую команду. Чтобы в этом убедиться, мы попробуем сымитировать нашу функцию как командлет Get-ChildItem:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>> Get-ChildItem $Path $Filter $Force
>> }
>>
[↓] [vPodans] Test C:\ * -Force
Get-ChildItem : A positional parameter cannot be found that accepts argument 'True'.
At line:2 char:14
+ Get-ChildItem <<<<  $Path $Filter $Force
    + CategoryInfo          : InvalidArgument: (:) [Get-ChildItem], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

[↓] [vPodans]

Как видно, командлет Get-ChildItem не смог сопоставить последний аргумент ни с одним из своих параметров. Т.е. по факту выполнилась следующая строка:

Get-ChildItem -Path C:\ -Filter * True

PowerShell не смог сказать командлету, что мы указали ключ Force и хотим именно его передать в командлет. По факту в этом коде Get-ChildItem не знал, какие параметры ему были переданы и подставлял их на основе номера позиции параметра. А т.к. у Get-ChildItem нету параметра с порядковым номером 3 (с номером 1 идёт Path или LiteralPath, а с номером 2 идёт Filter. Остальные параметры именованные), то мы получили ошибку. Но всё же, как выкручиваться из этой ситуации? Вы можете как угодно пытаться подставить аргументы, но ничего не выйдет. Для этих целей в PowerShell V2 появилась специальная переменная - $PSBoundParameters. Эта переменная по сути представляет собой хэш-таблицу:

[↓] [vPodans] function Test ([string]$Path, [String]$Filter, [switch]$Force) {
>> $PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force

Key                                                         Value
---                                                         -----
Force                                                       True
Path                                                        C:\
Filter                                                      *


[↓] [vPodans]

В отличии от первого примера переменная $PSBoundParameters содержит не только значения переменных, но и их имена (в перовм примере я вручную дописывал имена переменных), которые используются в качестве именованных параметров. Т.е. при подстановке аргументов в команду, она сначала выбирает имя переменной в качестве именованного параметра и значение переменной подставляет в качестве аргумента этого параметра. Синтаксис использования этой переменной очень прост:

function Name ($arg1, $arg2, $arg3 ... $argN) {
Command @PSBoundParameters
}

и в результате будет исполняться вот такая команда:

Command –arg1 <значение $arg1> –arg2 <значение $arg2> –arg3 <значение $arg3> … –argN <значение $argN>

Т.е. будут подставляться именованные параметры и значения переменных соответствующих аргументов. Давайте проверим, как это подействует на наш пример с Get-ChildItem:

function Test ([string]$Path, [String]$Filter, [switch]$Force) {
Get-ChildItem @PSBoundParameters
}

[↓] [vPodans] function Test ([string]$Path, [String]$Filter, [switch]$Force) {
>> Get-ChildItem @PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force


    Directory: C:\


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d--hs       10.07.2007.     19:44            $Recycle.Bin
d--hs       09.03.2008.     17:53            Boot
d----       23.11.2008.     19:41            inetpub
d-rh-       26.06.2007.     22:27            MSOCache
d----       09.03.2008.     17:41            PerfLogs
<...>

И вы можете видеть, что у нас всё получилось в наилучшем виде! В сравнении с предыдущим примером фактически выполнилась следующая команда:

Get-ChildItem -Path C:\ -Filter * -Force

Для формирования аргументов для командлетов в функциях (так называемые wrapped cmdlets) это самый красивый и идеальный вариант. Если вы захотите изменить логику стандартных командлетов или добавить в них свой функционал, то $PSBoundParamters сделает за вас очень много лишней работы. Но это не единственное полезное применение для этой переменной. Она так же позволяет сократить возможность ошибки при вызове функции внутри скрипта или другой функции, которая принимает те же аргументы. Давайте посмотрим ещё один пример:

function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
    Write-Host '$Path in Test is:' $Path
    Write-Host '$Filter in Test is:' $Filter
    Write-Host '$Force in Test is:' $Force
    Write-Host --------------------------------
    function Test2 ([switch]$Force, [string[]]$Path, [String]$Filter) {
        Write-Host '$Path in Test2 is:' $Path
        Write-Host '$Filter in Test2 is:' $Filter
        Write-Host '$Force in Test2 is:' $Force
    }
    Test2 @PSBoundParameters
}

Что мы делаем: мы создали функцию Test, которая принимает набор аргументов. Внутри этой функции есть другая функция Test2, которая принимает те же аргументы. Далее из функции Test вызываем функцию Test2 и с помощью $PSBoundParameters передаём в неё аргументы. Обратите внимание, что в функции Test2 я изменил порядок аргументов. Это сделано для того, чтобы показать, что $PSBoundParamters отсортирует наши аргументы. А теперь внимание на экран:

[↓] [vPodans] function Test ([string[]]$Path, [String]$Filter, [switch]$Force) {
>>     Write-Host '$Path in Test is:' $Path
>>     Write-Host '$Filter in Test is:' $Filter
>>     Write-Host '$Force in Test is:' $Force
>>     Write-Host --------------------------------
>>     function Test2 ([switch]$Force, [string[]]$Path, [String]$Filter) {
>>         Write-Host '$Path in Test2 is:' $Path
>>         Write-Host '$Filter in Test2 is:' $Filter
>>         Write-Host '$Force in Test2 is:' $Force
>>     }
>>     Test2 @PSBoundParameters
>> }
>>
[↓] [vPodans] Test C:\ * -Force
$Path in Test is: C:\
$Filter in Test is: *
$Force in Test is: True
--------------------------------
$Path in Test2 is: C:\
$Filter in Test2 is: *
$Force in Test2 is: True
[↓] [vPodans]

И смотрите, что у нас получилось. А у нас получилось, что функция Test2 получила тот же набор аргументов, причём они были подставлены в правильном соответствии. Фактически строка Test2 @PSBoundParameters была преобразована в:

Test2 -Path $Path -Filter $Filter -Force $true

Т.е. в вариант, который мы вынуждены использовать в PowerShell 1.0. Плюс, мы имеем возможность подставлять позиционно ключи (объекты типа Switch), что есть очень позитивно.

PowerShell Powered - http://www.sysadmins.lv

PowerShell flow control и конвейеры

Camelot — Mon, 01 Jun 2009 17:25:14 GMT

Иногда замечаю, что некоторые скриптописатели получают “поломанный” конвейер, когда данные из одной команды вышли, но никуда не пришли. Возьмём простой пример:

[↓] [vPodans] foreach ($n in 1..3) {$n}
1
2
3
[↓] [vPodans]

Тут всё просто, циклом foreach перебираются данные и выводятся на экран. Мы привыкли, что всё, что выводится на экран можно передать дальше на конвейер. В принципе, это правильно, за исключением ряда случаев, когда это не работает. Чтобы убедиться в этом – передадим вывод этой команды через конвейер на Set-Content:

[↓] [vPodans] foreach ($n in 1..3) {$n}
1
2
3
[↓] [vPodans] foreach ($n in 1..3) {$n} | Set-Content file.txt
An empty pipe element is not permitted.
At line:1 char:28
+ foreach ($n in 1..3) {$n} | <<<<  Set-Content file.txt
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : EmptyPipeElement

[↓] [vPodans]

и мы получаем ошибку, что у нас пустой конвейер. Если написать простой проверочный фильтр:

filter Test-Input {'current $_ is: ' + $_}

и проверить, что у нас приходит с конвейера в этот фильтр, то вы получите такую же ошибку и можете долго гадать, почему так, на экране данные есть, а в конвейер ничего не поступает. Причиной этому является то, что flow control (не знаю, как это на русский первести) конструкции не транслируют свой вывод в конвейер и вот список этих конструкций:

If…Else
If…ElseIf
For
Foreach
While
Do…While
Do…Until
Switch

Чтобы при использовании этих конструкций вывод транслировался на конвейер их нужно заключить в подвыражение – $( ):

[↓] [vPodans] $(foreach ($n in 1..3) {$n}) | Set-Content file.txt
[↓] [vPodans] gc file.txt
1
2
3
[↓] [vPodans] $(foreach ($n in 1..3) {$n}) | Test-Input
current $_ is: 1
current $_ is: 2
current $_ is: 3
[↓] [vPodans]

я заключил цикл Foreach в подвыражение и теперь данные стали поступать на конвейер. Это хорошо видно по выводу фильтра Test-Input, который приведён выше. Вот таким нехитрым способом мы решили проблему пустых конвейеров

PowerShell Powered - http://www.sysadmins.lv

Копирование файлов с графическим Progress Bar

Camelot — Sat, 23 May 2009 23:23:37 GMT

Навеяно множеством мотивов:

Как мне кажется, с Write-Progress вряд ли получится что-то хорошее, поэтому немного сориентировался и нашёл вот это: PowerShell Script: Copy-FilePlus. Именно этот скрипт взят за основу визуального окна. А за основу логики был взят мой простенький скрипт копирования файлов с сохранением структуры каталогов:Лёгкая разминка. Приведённый по ссылке на Copy-FilePlus вариант Хала Роттенберга является достаточно базовым, поскольку не позволяет копировать за раз множество файлов, плюс требуется вводить имя конечного файла. Я решил его немного расширить и добавить следующий функционал:

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

заранее оговорюсь, что скрипт обладает одним недостатком: не будет единого прогресс-бара для всех файлов, а только для каждого файла свой (издержки .NET). Зато хоть что-то и весьма актуально при копировании больших файлов. Код получился несколько солидным, но я его постарался снабдить комментариями о коде и о логике, на которой он работает. Причём следуя примеру Роттенберга я скрипт тоже оформил в Advanced Function. По advanced functions я в скрипте вложил ссылки, как почитать о них во встроенной справке PowerShell. И, собственно, сам код:

########################################################
# Copy files with GUI.ps1
# Version 1.3
#
# Copies single or couple files with GUI progressbar
# 
# Original idea: Oisín Grehan
# First edition: Hal Rottenberg
# Second edition: Vadims Podans
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
########################################################

# сразу после названия идёт описание к функции. После загрузки функции в консоль
# её справка будет доступна в консоли. Достаточно будет набрать:
# Get-Help Copy-FilesPlus
# вобщем, как в настоящих командлетах
function Copy-FilesPlus {
<#
.Synopsis
    Copies files and folders displaying GUI progress bar.
.Description
    This is a script, that demonstrates how PowerShell can use
    useful .NET types and PowerShell V2 capabilities.
.Parameter Path
    Specifies the filename or FileInfo object representing file to be copied.
    Objects can be passed through a pipeline.
.Parameter Destination
    Specifies the path for resulting copy operation
.Parameter Recurse
    Gets the items in the specified locations and in all child items of the locations.
    Used only when source directory passed through argument list. 
.Parameter Force
    Creates directory structure in destination folder and copies files to
    their source respective folders (Tree copy).
.EXAMPLE
    PS > Copy-FilesPlus -Path C:\tmp -Destination e:\Users
    
    This will copy only files from C:\tmp to E:\Users
.EXAMPLE
    PS > Get-Item C:\tmp\windows7.iso | Copy-FilesPlus -Destination E:\Users
    
    This will copy specified file from C:\tmp folder to e:\Users
.EXAMPLE
    PS > Get-Childitem D:\Shared | Copy-FilesPlus -Destination E:\ 
    
    This will copy all files from Shared folders to E: drive root directory
.EXAMPLE
    PS > Get-Childitem D:\Shared -Recurse | Copy-FilesPlus -Destination E:\ -Force
    
    This will copy all files in Shared folder and subfolders. Shared folder will be a
    tree root point. All directory structure will be copied with files to destination folder.
.EXAMPLE
    PS > Copy-FilesPlus C:\Users\User E:\ -Recurse
    
    This will copy all files from User folder and subfolders to destination directory without
    copying source folders tree
.EXAMPLE
    PS > Copy-FilesPlus C:\Users\User E:\ -Recurse -Force
    
    This will copy all files in User folder and subfolders. User folder will be a
    tree root point. All directory structure will be copied with files to destination folder.
.ReturnValue
    Genrally, script don't return anything, except errors!
.Link
    about_functions
    about_functions_advanced
    about_functions_advanced_methods
    about_functions_advanced_parameters
#Requires -Version 2.0
#>

# ну и теперь фишки от advanced functions в V2. CmdletBinding делает
# подстановку передаваемых аргументов в функцию. Если аргумент не передан
# то PowerShell попросит его ввести, а не вывалится с ошибкой
[CmdletBinding()]
    param (
        # первый аргумент. Он является обязательным и он может принимать значения
        # из конвейера. Причём, внутри блока Process {} для обозначения текущего элемента
        # можно использовать, как переменную $path, так и $_.
        [Parameter(Mandatory = $true,ValueFromPipeline = $true)]
        $Path,
        [Parameter(Mandatory = $true)]
        [string]$Destination,
        [switch]$Recurse,
        [switch]$Force
    )
    begin {
        # пробуем создать папку назначения, куда будут копироваться файлы.
        [void](md $Destination -Force -ea 0)
        # вот тут я сделал переменную для счётчика. Счётчик мне потребуется для того,
        # чтобы при использовании ключа -Force и если файлы передаются по конвейеру
        # можно было брать точку начала дерева структуры, которая будет копироваться.
        $n = 0
        # временная функция, которая выполняет само копирование. Тут нужно учесть то,
        # что путь назначения должен указываться в полном формате с указанием имени
        # конечного файла. Относительные пути тут не поддерживаются. Поэтому дальше
        # в коде я буду сохранять имя оригинального файла. т.е. переименовывание файлов
        # на лету не поддерживается
        function _routinecopy_ ([string]$Destination) {
            process {
                Add-Type -AssemblyName microsoft.visualbasic
                [Microsoft.VisualBasic.FileIO.FileSystem]::CopyFile($_, $Destination, 
                [Microsoft.VisualBasic.FileIO.UIOption]::AllDialogs,
                [Microsoft.VisualBasic.FileIO.UICancelOption]::ThrowException)
            }
        }
    }
    process {
        try {
            # вот здесь я проверяю, откуда пришли файлы - через аргументы или через конвейер
            # если данные пришли из обоих путей, то приоритет за конвейером
            if ($_) {
                # проверяем, что объект существует и что это объект файловой системы
                $File = gi $Path.FullName -ea stop | ?{$_.PsProvider -match "FileSystem$"}
                if ($File) {
                    # если объект в порядке и выполняется только первая итерация конвейера
                    # то мы задаём точку начала дерева. Весь путь от этой точки до имени файла
                    # будет копироваться в папку назначения
                    if ($n -eq 0) {
                        # здесь отрезаем от файла структуру папок, которая будет являться границей дерева
                        $RootPoint = $Path.FullName -replace $([regex]::Escape($Path.Name))
                        # заодно на основе этой структуры делаем регулярное выражение. Этим регулярным
                        # выражением будем у всех последующих файлов отрезать начало и оставлять необходимую
                        # часть дерева
                        $RootRegEx = [regex]::Escape($RootPoint.Substring(0,$RootPoint.Length -1))
                        # важно, что эту операцию нужно проделать единожды, чтобы точка монтирования дерева
                        # больше не менялась в процессе. Поэтому увеличиваем счётчик и тогда в течении текущего
                        # процесса копирования код сюда не вернётся
                        $n++
                    }
                    # проверяем, что нужно ли копировать дерево или нет.
                    if ($Force) {
                        # если копируем дерево, то выбрасываем папки и работаем только с файлами
                        $File = $File | ?{!$_.PsIsContainer}
                        if ($File) {
                            # если есть файлы для копирования, то выбираем весь путь папок до текущего файла
                            # и заранее приготовленным регэкспом отрезаем начало. В переменную $rep мы запишем
                            # дерево папок от точки монтирования дерева до имени файла
                            $rep = $Path.Directory.ToString() -replace $RootRegEx
                            # а теперь к папке назначения пристыковываем дерево папок от точки монтирования до имени файла
                            $DestFolder = Join-Path $Destination $rep
                            # заранее создаём начальный хвостик папок в целевой папке и подавляем вывод на экран
                            [void](md $DestFolder -Force -ea 0)
                            # а теперь к новому конечному пути пристыковываем имя файла
                            $Dest = Join-Path $DestFolder $Path.Name
                            # и теперь подаём текущий файл в функцию копирования. Вот тут мы и увидим прогресс-бар.
                            $Path.FullName | _routinecopy_ $Dest
                        }
                    } else {
                        # если структуру папок копировать не надо, то все файлы, что пришли с конвейера будут копироваться
                        # в папку назначения без создания структуры папок.
                        if (!$_.PsIsContainer) {
                            $Dest = Join-Path $Destination $File.Name
                            $File | _routinecopy_ $Dest
                        }
                    }
                # если объект не существует или это не объект файловой системы (защита от дураков, да-да :)), то ругаемся
                } else {throw "Input object does not represent any applicable FileSystem object"}
            } else {
                # если данные об источнике копирования переданы через аргументы, то проверяем, что заданный путь допустим
                # и объект, который мы получим после Get-Item является объектом файловой системы
                $File = gi $Path -ea stop | ?{$_.PsProvider -match "FileSystem$"}
                if ($File) {
                    # если всё хорошо, то указанный файл или папка становятся точкой монтирования дерева
                    $RootPoint = Resolve-Path $Path
                    # если ключи -Force -Recurse не указаны, то копируется либо указанный файл или все файлы в указанной
                    # папке в папку назначения
                    if (!$Recurse) {
                        dir $RootPoint | ?{!$_.PsIsContainer} | %{$Dest = Join-Path $Destination $_.Name
                            $_.FullName | _routinecopy_ $Dest}
                    # хитрый режим, когда рекурсивно выбираются все файлы в указанной папке и всех подпапках и копируются
                    # в папку назначения без сохранения структуры (т.е. в папке назначения будет большая куча файлов).
                    } elseif ($Recurse -and !$Force) {
                        dir $RootPoint -Recurse | ?{!$_.PsIsContainer} | %{$Dest = Join-Path $Destination $_.Name
                            $_.FullName | _routinecopy_ $Dest}
                    # если указаны оба ключа, то мы повторяем структуру исходных папок относительно точки монтирования дерева
                    # в папке назначения
                    } elseif ($Recurse -and $Force) {
                        dir $RootPoint -Recurse | ?{!$_.PsIsContainer} | %{
                            # тут мы делаем то же самое, что и в случае, когда файлы пришли с конвейера
                            $RootRegEx = [regex]::Escape($RootPoint)
                            $rep = $_.Directory.ToString() -replace $RootRegEx
                            $DestFolder = Join-Path $Destination $rep
                            [void](md $DestFolder -Force -ea 0)
                            $Dest = Join-Path $DestFolder $_.Name
                            $_.FullName | _routinecopy_ $Dest
                        }
                    }
                } else {throw "Input object does not represent any applicable FileSystem object"}
            }
        } catch {$_}
    }
}

Вот такой скриптик у меня получился. Местами даже очень умный, почти как я . Как мне кажется, на этом коде тоже можно чему-то поучиться. Если будут вопросы – то welcome в комментарии.

PowerShell Powered - http://www.sysadmins.lv

PowerTab 0.99beta2

Camelot — Sat, 16 May 2009 22:05:57 GMT

Сегодня самый главный PowerShell Guy – Marc van Orsouw, он же MoW, он же /\/\o\/\/ выпустил очередную версию PowerTab, в которой исправлены баги, которые были замечены в работе с PowerShell V2 CTP3, плюс добавлена поддержка Windows 7 и Windows Server 2008 R2. Один из наиболее значимых багов – зависание окна автозавершения. Это выглядело вот так:

[vPodans] dir -include *.log [vPodans] ╔═ - ══════════════╗ ║ -Debug ║ ║ -ErrorAction ║ ║ -ErrorVariable ║ ║ -Exclude ║ ║ -Filter ║ ║ -Force ║ ║ -Include ║ ║ -LiteralPath ║ ║ -Name ║ ║ -OutBuffer ║ ║ -OutVariable ║ ║ -Path ║ ║ -Recurse ║ ║ -UseTransaction ║ ║ -Verbose ║ ║ -WarningAction ║ ║ -WarningVariable ║ ╚═[4] 1-17 [17]════╝

т.е. по этому меню можно было перемещаться вниз. Но при любом нажатии стрелки вверх – оно намертво прилипало к экрану:

[vPodans] dir -include *.log [vPodans] bla-bla-bla═════════════╗ The term 'bla-bla-bla' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and t ry again. ║ -ErrorAction ║ At line:1 char:12-ErrorVariable ║ + bla-bla-bla <<<< xclude ║ + CategoryInfo : ObjectNotFound: (bla-bla-bla:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException ║ -Include ║ [vPodans] ║ -LiteralPath ║ ║ -Name ║ ║ -OutBuffer ║ ║ -OutVariable ║ ║ -Path ║ ║ -Recurse ║ ║ -UseTransaction ║ ║ -Verbose ║ ║ -WarningAction ║ ║ -WarningVariable ║ ╚═[4] 1-17 [17]════╝

а учитывая, что я частенько промахиваюсь со стрелками, то вот такую картину видел тоже часто. И убрать это можно было только через Clear-Host, он же CLS. Сейчас установил новую версию PowerTab – проблема исчезла

Ну и поддержка новых систем тоже будет многим по душе.

Собственно PowerTab взять можно тут (смотреть аттачменты посте):

http://thepowershellguy.com/blogs/posh/archive/2009/05/15/powertab-0-99b2-ctp3-fix.aspx

PowerShell Powered - http://www.sysadmins.lv

Скрипты PowerShell в GPO

Camelot — Wed, 06 May 2009 16:15:00 GMT

А знаете ли вы, что скрипты PowerShell можно очень легко и удобно использовать в качестве startup/shutdown и logon/logoff скриптов в GPO?

Сценарий для Windows Server 2003/2008

В обычной жизни при двойном клике на .ps1 файл – он откроется в редакторе, но не будет исполнен. Это было сделано в целях безопасности, что у PS1 файлов PerceivedType выставлен как Text и расширение PS1 отсутствует в переменной %pathext%. Но это совсем не значит, что мы не можем использовать эти скрипты в GPO или Task Sheduler. Ларчик открывается очень просто:

Суть сводится к тому, что в Script Name указывается путь к исполняемому модулю PowerShell. А вот уже в Script Parameters уже указываете путь к скрипту. Причём тут следует обратить внимание, что если путь задаёте через переменные (например, если у вас несколько контроллеров домена, то целесообразно запускать скрипт из папки NetLogon того контроллера, который вас аутентифицирует), то переменные нужно указывать в формате CMD, т.е. %variable%. В результате вы получите вот такой вид настроенного логон-скрипта:

Т.е. реализуется это всё очень просто. Однако, здесь есть одно большое “НО” – для реализации логон-скриптов в среде Windows Server 2003/2008 у вас должна быть реализована политика подписанных скриптов. В противном случае скрипт просто не исполнится, даже если у вас политика запуска скриптов выставлена в Unrestricted. Это обусловлено тем, что скрипт исполняется не с локального диска, а с сетевого. Это можно очень легко проверить:

[vPodans] Set-ExecutionPolicy unrestricted
[vPodans] Get-ExecutionPolicy
Unrestricted
[vPodans] & $env:logonserver\netlogon\get.ps1

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can
potentially harm your computer. Do you want to run \\DC1\netlogon\get.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"):

У вас каждый раз будет спрашиваться разрешение на запуск скрипта. Т.к. логонные скрипты выполняются в фоне и не взаимодействуют с пользователем, то вы просто не сможете никак нажать кнопку R. Тем более, как видно из снимка, у нас нету возможности сделать Run always. Именно по этой причине требуются только подписанные скрипты. Но это не проблема, учитывая, что я у себя в блоге написал 2 поста по практической реализации инфраструктуры подписанных скриптов, тем более, это наоборот повышает безопасность запуска скриптов PowerShell.

Но если очень хочется выполнять логонные и стартапные скрипты без внедрения цифровых подписей, то есть один workaround - узел, на котором размещены скрипты в сети (обычно это сам контроллер домена) нужно добавить в интернет-зону Local Intranet. Тогда скрипты из сети будут равноценны локальным и политика RemoteSigned спокойно разрешит такой запуск.

Сценарий для Windows Server 2008 R2/Windows 7

Пока что Windows Server 2008 R2 и Windows 7 не RTM, но уже известно, что в них уже нативно поддерживаются скрипты PowerShell в качестве логонных и стартапных, поскольку в этих системах PowerShell установлен и включен по умолчанию. И выглядит это вот так:

В табе Scripts располагаются классические скрипты как .BAT, .CMD, .VBS, .JS и в комментарии не нуждаются. Но в новых системах добавлен ещё один таб PowerShell scripts. Вы можете прямо указывать на .PS1 файлы без указания программы, которая будет их отрабатывать. Иными словами эти скрипты теперь ничем не отличаются от тех же скриптов CMD/WSH. Но в проводнике PS1 файлы всё равно не будут исполняться, а открываться в редакторе (ISE/Notepad/PowerGUI). Ну и ещё одна заметка:

Вы можете выбирать в каком порядке эти скрипты будут исполняться – до или после классических скриптов в первом табе. На практике есть один небольшой недостаток – при логоне частенько проскакивает консоль PowerShell, что есть не очень хорошо. Правда, следует учитывать, что новые системы ещё только Release Candidate (скриншоты сделаны с беты), поэтому есть надежда, что это будет исправлено. В отличии от предыдущего варианта, когда скрипты PowerShell адаптируются под классические – здесь не обязательно подписывать скрипты, хотя для этого придётся выставить политику запуска в Unrestricted, что не есть безопасно. Поэтому я бы посоветовал везде, где это возможно – использовать цифровые подписи для скриптов. И ещё раз напомню, что данная вкладка в GPO доступна только в Windows Server 2008 R2/Windows 7 и, скорее всего, в последующих версиях и применяться будет тоже только к ним. Если у вас домен под управлением Windows Server 2008 R2, а клиенты – Windows Vista, то эти логонные скрипты работать не будут, даже если на последних всеми правдами и неправдами установлен PowerShell.

As always enjoy the automation of tools within powershell.exe! © Flowering Weeds

PowerShell Powered - http://www.sysadmins.lv

Создание объектов в PowerShell

Camelot — Mon, 04 May 2009 14:06:08 GMT

А знаете ли вы, что объекты типа PsObject можно создавать очень легко?

Очень часто в скриптах мы создаём свои кастомайзенные объекты, наделяем их необходимыми свойствами, в которые уже записываем данные, полученные в процессе работы скрипта. Как это делается в классическом случае:

$Object = New-Object System.Management.Automation.PSObject
$Object | Add-Member NoteProperty Computer  ([PSObject]$null)
$Object | Add-Member NoteProperty Name  ([PSObject]$null)
$Object | Add-Member NoteProperty Path  ([PSObject]$null)
$Object | Add-Member NoteProperty Description  ([PSObject]$null)
...

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

[vPodans] $Object = New-Object System.Management.Automation.PSObject
[vPodans] $Object | Add-Member NoteProperty Computer  ([PSObject]$null)
[vPodans] $Object | Add-Member NoteProperty Name  ([PSObject]$null)
[vPodans] $Object | Add-Member NoteProperty Path  ([PSObject]$null)
[vPodans] $Object | Add-Member NoteProperty Description  ([PSObject]$null)
[vPodans] $object | gm


   TypeName: System.Management.Automation.PSCustomObject

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       System.Boolean Equals(Object obj)
GetHashCode Method       System.Int32 GetHashCode()
GetType     Method       System.Type GetType()
ToString    Method       System.String ToString()
Computer    NoteProperty  Computer=null
Description NoteProperty  Description=null
Name        NoteProperty  Name=null
Path        NoteProperty  Path=null


[vPodans]

Но этот процесс можно сделать ещё более простым и коротким:

$Object = "" | Select Computer, Name, Path, Description

Смотрим:

[vPodans] $Object = "" | Select Computer, Name, Path, Description
[vPodans] $object | gm


   TypeName: Selected.System.String

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       System.Boolean Equals(Object obj)
GetHashCode Method       System.Int32 GetHashCode()
GetType     Method       System.Type GetType()
ToString    Method       System.String ToString()
Computer    NoteProperty  Computer=null
Description NoteProperty  Description=null
Name        NoteProperty  Name=null
Path        NoteProperty  Path=null


[vPodans]

Видите, в результате объект получился такой же, зато как эффективно! Но и это ещё не всё. Если с Add-Member мы могли сразу присваивать значения параметру через параметр –Value командлета Add-Member, то и здесь мы можем на стадии создания объекта ему что-то присвоить. Присвоение производится по схеме:

$var = "" | Select @{n = "PropertyName";e={"PropertyValue"}}

Для примера сделаем простой объект с несколькими свойствами и сразу при создании запишем в них значения:

$Object = "" | Select @{n='Computer';e={"компик"}},`
@{n='Name';e={"имя"}},@{n="Path";e={"вот тут путь какой-то"}}

проверяем:

[vPodans] $Object = "" | Select @{n='Computer';e={"компик"}},`
>> @{n='Name';e={"имя"}},@{n="Path";e={"вот тут путь какой-то"}}
>>
[vPodans] $Object | gm


   TypeName: Selected.System.String

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       System.Boolean Equals(Object obj)
GetHashCode Method       System.Int32 GetHashCode()
GetType     Method       System.Type GetType()
ToString    Method       System.String ToString()
Computer    NoteProperty System.String Computer=компик
Name        NoteProperty System.String Name=имя
Path        NoteProperty System.String Path=вот тут путь какой-то


[vPodans] $Object | fl *


Computer : компик
Name     : имя
Path     : вот тут путь какой-то



[vPodans]

Вот такими небольшими трюками мы позволяем делать PowerShell очень удобным и простым инструментом.

Вобщем, как говорится - As always enjoy the automation of tools within powershell.exe! © Flowering Weeds

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

PowerShell Powered - http://www.sysadmins.lv

Лёгкая разминка

Camelot — Wed, 08 Apr 2009 22:15:28 GMT

На ньюсгруппах недавно попросили скрипт с использованием PowerShell, который бы рекурсивно определённую папку на предмет содержания определённых файлов и копировал эти файлы в другую папку. Причём файлы копироваться должны вместе с деревом папок, относительно корня. Корень в данном случае является папка, откуда начинается рекурсивный поиск. Действительно, такие задачи встречаются, поэтому мой вариант кому-то может оказаться полезным.

$RootPoint = "D:\Users\Shared Documents"
$dest = 'E:\DestFolder'
$rep = $RootPoint.Replace("\","\\")
dir $RootPoint -Include *.msi -Recurse | %{
    $suf = $_.directory.tostring() -replace $rep
    New-Item -itemtype d -path $($dest + $suf) -force -ea 0
    copy $_ $("$dest" + "$suf")
}

Этот скрипт будет искать все MSI файлы в папке D:\Users\Shared Documents и подпапках. Если файл будет найден, то он будет скопирован в E:\SomeFolder с повторением структуры папок. Для начала я заэскейпил слеши в исходной папке. И в цикле уже отрезаю путь до корня обычным оператором –replace. После чего хвост пристыковываю к пути назначения, чтобы получить новую структуру папок и создаю нужные папки в месте назначения. И последней строкой копирую сам файл в уже подготовленную папку.

Решений для этой задачи на самом деле очень много и я постарался сделать наиболее простой вариант, для разминки мозгов, так сказать :)

PowerShell Powered - http://www.sysadmins.lv

Управление безопасностью общих папок (сетевых шар) в PowerShell (часть 5)

Camelot — Wed, 04 Mar 2009 14:22:45 GMT

По просьбе читателей, а так же с учётом востребованности (судя по сообщениям форумов и ньюсгрупп) я нашёл время переписать скрипт ShareUtils.ps1 с поддержкой работы с удалёнными машинами и попутно пофиксив недочёты, которые были найдены за время эксплуатации предыдущей версии скрипта. Предыдущая версия опубликована здесь: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!188.entry

Технический функционал изменился только возможностью работы с удалёнными компьютерами, но синтаксис был изменён (а так же удалены лишние функции) по аналогии с PrinterUtils и имеет примерно следующий вид:

New-Share –Computer <Computer> –Name <Name> –Path <Path> –Description <Description>
где Computer – имя или IP адрес компьютера, на котором необходимо расшарить папку. (не обязательный параметр). Если не указан, используется текущий компьютер.
Name - сетевое имя для папки;
Path - путь к физической папке;
Description описание к сетевой папке. При наличии пробелов - заключить в кавычки (не обязательный параметр);
Remove-Share –Computer <Computer> –Name <Name> – отменяет расшаривание на папке. Сама папка не удаляется.
где Computer – имя или IP адрес компьютера, на котором нужно отменить расшаривание папки. (не обязательный параметр). Если не указан, используется текущий компьютер.
Name - сетевое имя папки;
Get-Share –Computer <Computer> –Name <Name> – получает основные сведения и списки DACL Share Permissions с указанных или всех сетевых папок.
где Computer – имя или IP адрес компьютера, с которого нужно получить сведения о сетевых папках. (не обязательный параметр). Если не указан, используется текущий компьютер.
Name - имя сетевой папки (не обязательный параметр). Если не указан, то выбираются все сетевые папки с типом Disk Drive (в которые системные шары не входят).
Set-SharePermission –User <User> –AceType <AceType> –AccessMask <AccessMask> – устанавливает единственный Share Permission ACE для указанного в аргументах пользователя.
User - имя пользователя/группы, которой предоставляется доступ;
AceType - тип доступа. Этот параметр должен иметь одно из значений Allow/Deny;
AccessMask - маска доступа. Этот параметр должен иметь одно из значений FullControl/Change/Read;

Функция не может быть вначале строки, а только после конвейера Get-Share или другого источника с подходящими данными (например, если данные были сохранены в CSV/XML файле, то их можно использовать в качестве источника: Import-Csv path.csv | Set-SharePermission Everyone Allow Change). При этом все текущие права на сетевую папку будут удалены и записан только указанный в аргументах пользователь/группа.
Add-SharePermission –User <User> –AceType <AceType> –AccessMask <AccessMask> – добавляет указанного в аргументах пользователя к Share Permissions выбранной сетевой папки (или папок)
User - имя пользователя/группы, которой предоставляется доступ;
AceType - тип доступа. Этот параметр должен иметь одно из значений Allow/Deny;
AccessMask - маска доступа. Этот параметр должен иметь одно из значений FullControl/Change/Read;

Функция не может быть вначале строки, а только после конвейера Get-Share или другого источника с подходящими данными (например, если данные были сохранены в CSV/XML файле, то их можно использовать в качестве источника: Import-Csv path.csv | Add-SharePermission Everyone Allow Change).
Remove-SharePermission –User <User> – удаляет указанного пользователя из DACL выбранной сетевой папки (папок). Не может быть вначале строки, а только на выходе конвейера, откуда поступают объекты сетевых папок. Например, Get-Share | Remove-SharePermission Everyone – удалит группу Everyone из всех SharePermissions всех расшаренных папок на локальном компьютере. Разрешения NTFS при этом не изменяются.
где User - имя пользователя/группы, которого следует удалить из ACL сетевой папки.

Примеры использования практически идентичные, как и в PrinterUtils: http://www.sysadmins.lv/PermaLink,guid,22c0550d-0c46-44ca-97ce-2b0bccbb51de.aspx

И, собственно, сам код:

########################################################
# ShareUtils.ps1
# Version 0.9
#
# Functions for advanced share management
#
# Note:
# Previous version is published at my former blog:
# http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!188.entry
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
######################################################## 

# внутренняя функция, которая преобразовывает числовой код возврата операции записи DACL
# в текстовое значение.
function _ShareUtils_Get-Code ($write) {
switch ($write.ReturnValue) {
   "0" {"Success"}
   "2" {"Access Denied"}
   "8" {"Unknown Failure"}
   "9" {"Invalid Name"}
   "21" {"Invalid Parameter"}
   "22" {"Duplicate Share"}
   "23" {"Redirected Path"}
   "24" {"Unknown Device or Directory"}
   "25" {"Net Name Not Found"}
   default {"Unknown error $write.ReturnValue"}
   }
}

# функция для извлечения сведений и DACL с существующих сетевых папок.
# обязательна для использования функций Add-SharePermission и Set-SharePermission
# если компьютер не указан, то используется текущий. Если имя сетевой паки не указано,
# то возвращается список сведений и DACL всех сетевых папок на локальном или удалённом компьютере
function Get-Share ($computer = ".", $name) {
    if ($name) {
        $shares = gwmi Win32_Share -ComputerName $computer -Filter "name = '$name'"
    } else {
        $shares = gwmi Win32_Share -ComputerName $computer -Filter "type = 0"
    }
    $ShareInfo = @()
    foreach ($share in $shares) {
        $ShareSec = gwmi Win32_LogicalShareSecuritySetting -ComputerName $computer -filter "name='$($share.name)'" 
        if ($shareSec) {
            $SD = $sharesec.GetSecurityDescriptor()
            $ShareInfo += $SD.Descriptor.DACL | % {
                $_ | select @{e={$share.ClassPath.Server};n='Computer'},
                @{e={$share.name};n='Name'},
                @{e={$share.Path};n='Path'},
                @{e={$share.Description};n='Description'},
                AccessMask,
                AceFlags,
                AceType,
                @{e={$_.trustee.Name};n='User'},
                @{e={$_.trustee.Domain};n='Domain'},
                @{e={$_.trustee.SIDString};n='SID'}
            }
        } else {
            Write-Warning "Specified share not exist or you may not have sufficient rights to access them!"
        }
$ShareInfo
    }
}

# функция записи обновлённых сведений в сетевые папки. Не может быть первой в строке, а только после
# конвейера, откуда поступают данные для записи. Если папка не расшарена, то скрипт её расшарит
# автоматически и запишет необходимые сведения о сетевой папке.
function Set-Share {
    $ShareInfo = @($input)
    $ShareInfo | select -unique Computer, Name, Path, Description | % {
        $Computer = $_.Computer
        $name = $_.name
        $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
        $ace = ([WMIClass] "Win32_Ace").CreateInstance()
        $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
        $sd.DACL = @()
        $ShareInfo | ? {$_.Computer -eq $Computer -and $_.name -eq $name} | % {
            $SID = new-object security.principal.securityidentifier($_.SID)
            [byte[]] $SIDArray = ,0 * $SID.BinaryLength
            $SID.GetBinaryForm($SIDArray,0)
            $Trustee.Name = $_.user
            $Trustee.SID = $SIDArray
            $ace.AccessMask = $_.AccessMask
            $ace.AceType = $_.AceType
            $ace.AceFlags = $_.AceFlags
            $ace.trustee = $Trustee
            $SD.DACL += $ace.psObject.baseobject
        }
# проверяется наличие расшаренной папки. Если папка есть, то в неё записывается только SecurityDescriptor
# в противном случае она расшаривается и в неё производится полная запись всех данных
        $share = gwmi Win32_Share -ComputerName $computer -Filter "name = '$name'"
        if ($share) {
            $inParams = $share.psbase.GetMethodParameters("SetShareInfo")
            $inParams.Access = $SD
            $write = $share.psbase.invokemethod("SetShareInfo", $inParams, $null)
            Write-Host "Setting DACL on current share: $name on server $computer" -ForegroundColor green
            _ShareUtils_Get-Code $Write
        } else {
            $shareobject = [wmiClass]"\\$computer\root\cimv2:win32_Share"
            $inParams = $shareobject.psbase.GetMethodParameters("Create")
            $inParams.name = $_.name
            $inParams.path = $_.path
            $inParams.Description = $_.Description
            $inParams.Type = 0
            $inParams.Access = $SD
            $write = $shareobject.psbase.invokemethod("Create", $inParams, $null)
            Write-Host "Processing current share: $name on server $computer" -ForegroundColor green
            _ShareUtils_Get-Code $Write
        }
    }
}

function _Create-SDObject ($user, $AceType, $AccessMask) {
    # преобразование текстового вида прав в числовые значения
    $masks = @{FullControl = 2032127; Change = 1245631; Read = 1179817}
    $types = @{Allow = 0; Deny = 1}
    # создание необходимых свойств для объекта. Для поддержки удалённого управления
    # было добавлено свойство Computer, которое будет принимать от Get-Share аналогичное
    # значение. Тем самым обеспечивается сквозная трансляция имени компьютера, где
    # находится сетевая папка, по конвейеру для последующей записи
    $AddInfo = New-Object System.Management.Automation.PSObject
    $AddInfo | Add-Member NoteProperty Computer  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty Name  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty Path  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty Description  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty AccessMask  ([uint32]$null)
    $AddInfo | Add-Member NoteProperty AceFlags  ([uint32]$null)
    $AddInfo | Add-Member NoteProperty AceType  ([uint32]$null)
    $AddInfo | Add-Member NoteProperty User  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty Domain  ([PSObject]$null)
    $AddInfo | Add-Member NoteProperty SID  ([PSObject]$null)
    # заполнение объекта данными, которые были указаны в качестве аргументов вызова функции и возврат
    # объекта в вызывающую функцию
    $AddInfo.Name = $name
    $AddInfo.User = $user
    $AddInfo.SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
    $AddInfo.AccessMask = $masks.$AccessMask
    $AddInfo.AceType = $types.$AceType
    $AddInfo
}

function Set-SharePermission ($user, $AceType, $AccessMask) {
    # принимаются данные с конвейера 
    $ShareInfo = @($input)
    $AddInfo = _Create-SDObject $user $AceType $AccessMask
    # в этом цикле перебираются по именам все имена расшаренных папок и для каждой из них
    # записывается указанный в аргументах пользователь с удалением текущих ACE из ACL шары
    # это видно по тому, что никакая часть $ShareInfo не передаётся по конвейеру на запись
    foreach ($share in ($ShareInfo | select -Unique Computer, Name)) {
        $AddInfo.Computer = $share.Computer
        $AddInfo.Name = $share.name
        $AddInfo.Description = $Share.Description
        $AddInfo | Set-Share
    }
}

# просто добавляет нового участника безопасности к текущему DACL расшаренной папки.
# NTFS Acl не изменяется.
function Add-SharePermission ($user, $AceType, $AccessMask) {
    $ShareInfo = @($input); $ShareInfoNew = @()
    $AddInfo = _Create-SDObject $user $AceType $AccessMask
    foreach ($Share in ($ShareInfo | select -Unique Computer, Name)) {
        $AddInfo.Name = $Share.name
        $AddInfo.Computer = $Share.Computer
        $AddInfo.Description = $Share.Description
        # вот этой строкой мы из списка всех сетевых папок итеративно перебираем каждую шару
        $ShareInfoNew = @($ShareInfo | ?{$_.name -eq $Share.name})
        # в хвост списка ACL каждой сетевой шары добавляем новый ACE
        $ShareInfoNew += $AddInfo
        # и подаём на запись
        $ShareInfoNew | Set-Share
    }
}

# основная функция для удаления единичного ACE из ACL сетевой папки. Процесс сводится к извлечению
# текущего списка (или списков) ACL и фильтрации ACE в этом списке по методу Not Equal. Всё, что не подпадает под
# это действие записываются обратно в переменную, а всё, что подпало (указанный пользователь) обратно
# в переменную $ShareInfo не записывается.
function Remove-SharePermission ($user) {
    $shares = @($input)
    # просто берём списки ACL, которые пришли по конвейеру и выкидываем оттуда все ACE,
    # в которых фигурирует указанный в аргументах пользователь/группа и записывем ACE обратно в ACL
    $shares | ? {$_.user -ne $user} | Set-Share
}

# основная функция для создания новых сетевых папок на локальном компьютере. Здесь я использую упрощённый
# вариант создания сетевой папки, но учитывая один большой нюанс я добавил одно действие. Суть проблемы
# изложена тут: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!170.entry
# поэтому при создании новой сетевой папки я вручную создаю с нуля список ACL, который содержит
# только группу Everyone и с правом Allow Read.
function New-Share ($computer = $env:COMPUTERNAME, $name, $path, $Description) {
    $user = (new-object security.principal.securityidentifier "S-1-1-0").translate([security.principal.ntaccount])
    $AddInfo = _Create-SDObject $user.Value Allow Read
    $AddInfo.Computer = $computer
    $AddInfo.Path = $path
    $AddInfo.Description = $Description
    $AddInfo | Set-Share
}

# отменяет расшаривание сетевой папки. Сама же физическая папка не изменяется.
function Remove-Share ($computer = ".", $name) {
    $share = gwmi Win32_Share -ComputerName $computer -Filter "name = '$name'"
    if (!$share) {
        Write-Warning "Specified network share doesn't exist!"
    } else {
        $write = $share.delete()
        Write-Host "Deleting network share $name on computer $computer:"
        _ShareUtils_Get-Code $write
    }
}

PowerShell Powered - http://www.sysadmins.lv

Странности Set-Acl

Camelot — Sun, 01 Mar 2009 20:44:06 GMT

Наткнулся на него когда готовил ответ для ньюсгрупп. Как известно, владелец объекта может спокойно изменять списки ACL объектов минуя все их ограничения пользуясь неоткланяемым правом владения объектом. Поэтому, если из ACL объекта удалить все ACE и сохранить, то мы из проводника можем в любой момент вызвать вкладку Security объекта и задать требуемые ACE. Однако, это возможно только из графического интерфейса проводника сделать. При использовании скрипта и командлета Set-Acl мы этого сделать не сможем. Продемонстрирую проблему:

[C:\] whoami
contoso\administrator
[C:\] Get-Acl C:\Test | fl


Path   : Microsoft.PowerShell.Core\FileSystem::C:\Test
Owner  : CONTOSO\administrator
Group  : CONTOSO\Domain Users
Access :
Audit  :
Sddl   : O:LAG:DUD:PAI



[C:\] $acl = Get-Acl C:\Test
[C:\] $accessrule = New-Object System.Security.AccessControl.FileSystemAccessRule("Administrator","FullControl", "Allow"
)
[C:\] $acl.AddAccessRule($accessRule)
[C:\] $acl | Set-Acl C:\Test
Set-Acl : Attempted to perform an unauthorized operation.
At line:1 char:15
+ $acl | Set-Acl <<<<  C:\Test
    + CategoryInfo          : PermissionDenied: (C:\Test:String) [Set-Acl], UnauthorizedAccessException
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetAclCommand

[C:\]

Как видите, текущий пользователь (администратор) является владельцем папки. Но все ACE в ACL пустые (секция Access). Пользуясь правами владельца, всё же, я не могу ничего сделать с этим списком. Как выяснилось в процессе исследования, пользователю-владельцу, который собирается менять ACL необходимо иметь явно назначенное или унаследованное разрешение TakeOwnership. Никаких Read/ChangePermissions и прочих не надо. Теперь я из проводника добавлю себе право TakeOwnership и попробую снова исполнить код:

[C:\] Get-Acl C:\Test | fl


Path   : Microsoft.PowerShell.Core\FileSystem::C:\Test
Owner  : CONTOSO\administrator
Group  : CONTOSO\Domain Users
Access : CONTOSO\administrator Allow  TakeOwnership, Synchronize
Audit  :
Sddl   : O:LAG:DUD:PAI(A;OICI;0x180000;;;LA)



[C:\] $acl = Get-Acl C:\Test
[C:\] $accessrule = New-Object System.Security.AccessControl.FileSystemAccessRule("Administrator","FullControl", "Allow"
)
[C:\] $acl.AddAccessRule($accessRule)
[C:\] $acl | Set-Acl C:\Test
[C:\] Get-Acl C:\Test | fl


Path   : Microsoft.PowerShell.Core\FileSystem::C:\Test
Owner  : CONTOSO\administrator
Group  : CONTOSO\Domain Users
Access : CONTOSO\Administrator Allow  TakeOwnership, Synchronize
         CONTOSO\Administrator Allow  FullControl
Audit  :
Sddl   : O:LAG:DUD:PAI(A;OICI;0x180000;;;LA)(A;;FA;;;LA)



[C:\]

Как видите, теперь всё получилось. Я не понимаю, зачем мне нужно иметь право TakeOwnership, чтобы изменить ACL, если я являюсь владельцем. В реальной среде это может вызвать определённые трудности, как неадекватное поведение скрипта, который будет сыпать ошибками (в связи с чем появился вопрос на ньюсгруппах).

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

$path = "C:\Test"
$user = "Administrator"
$path = $path.replace("\", "\\")
$SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
$ace = ([WMIClass] "Win32_ace").CreateInstance()
$Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
$SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[byte[]] $SIDArray = ,0 * $SID.BinaryLength
$SID.GetBinaryForm($SIDArray,0)
$Trustee.Name = $user
$Trustee.SID = $SIDArray
$ace.AccessMask = [System.Security.AccessControl.FileSystemRights]"FullControl"
$ace.AceFlags = "0x3"
$ace.AceType = 0
$ace.Trustee = $trustee
# читаем текущий ACL с объекта
$oldDACL = (gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'").GetSecurityDescriptor().Descriptor.DACL
# добавляем его к пустому объекту DACL
$SD.DACL = $oldDACL
# и добавляем новый ACE
$SD.DACL += @($ace.psobject.baseobject)
# устанавливаем флаг SE_DACL_PRESENT
$SD.ControlFlags = "0x4"
$folder = gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"
$folder.setsecuritydescriptor($SD)

Я больше склонен доверять WMI и констатировать факт, что он работает честно – даёт мне делать с объектом что угодно и как угодно признавая мои права владения.

Я считаю, что Set-Acl был сильно не прав, отказав мне в изменении пустых ACE, поэтому отрепортил это дело на connect:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=418906&SiteID=99

PowerShell Powered - http://www.sysadmins.lv

Подписывание скриптов PowerShell – практическая реализация (часть 2)

Camelot — Tue, 17 Feb 2009 06:36:22 GMT

В предыдущем посте я показал, как можно легко и удобно подписывать скрипты и как усилить безопасность их исполнения, а так же предупредить несанкционированное изменение кода. Но, как я уже отметил, подписывать каждый раз скрипт из консоли не особо удобно. Например, если вы занимаетесь финальной отладкой скрипта в редакторе, как PowerGUI или PowerShell ISE, то в конце отладки вы просто сохраняете скрипт и закрываете редактор. Понятно, что ещё отдельно запускать консоль PowerShell будет неудобно. Поэтому я написал небольшой скрипт с установщиком, который позволит из проводника по правому нажатию на PS1 файл вы сможете подписывать скрипты.

Чтобы поместить свой элемент в контекстное меню при нажатии на PS1 файлы (на других типах файлов его не будет) нам нужно добавить некоторые значения в реестр по пути:

HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell

подключ с названием нашего элемента – Sign It и в нём уже команду, которая будет отрабатываться при нажатии на него. Я решил не изобретать велосипед и воспользовался приёмами, которые использовал ещё в старом блоге: Полезная безделушка Hash SHA1 на PowerShell. Шапка по сути осталась та же, только тело (исполняемый модуль) изменился. И вот, что получилось для PowerShell 1.0 (для V2 опубликую ниже):

#####################################################################
# Sign PS1 Script.ps1
# Version 1.5
#
# Automatically sign PowerShell script from .PS1 file context menu
# Fully compatible with PowerShell 1.0
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################

$FilePath = Read-Host "Specify path to hold SignIt.PS1"
if (Test-Path $FilePath) {
    $FilePath = $FilePath + "\" + "SignIt.ps1"
    $RegPath = "Registry::HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell\Sign It\command"
    $RegValue = "C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -noninteractive -noprofile -command $FilePath '%1'"
    New-Item -Path $RegPath -Force -ErrorAction SilentlyContinue
    if (Test-Path $RegPath) {
        New-ItemProperty -Path $RegPath -Name "(Default)" -Value $RegValue
        New-Item -ItemType file -Path $FilePath -Force
        if (Test-Path $FilePath) {
            $exefile = 'param ($file)
$cp = new-object Microsoft.CSharp.CSharpCodeProvider
$cpar = New-Object System.CodeDom.Compiler.CompilerParameters
$HideWindow = 0x0080
$ShowWindow = 0x0040
$Code = @"
using System;
using System.Runtime.InteropServices;
namespace Win32API
{
    public class Window
    {
        [DllImport("user32.dll")]
        public static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int x, int y, int cx, int cy, uint uFlags);
    }
}
"@
$cp.CompileAssemblyFromSource($cpar, $code)
$PSHandle = (Get-Process –id $pid).MainWindowHandle
[Win32API.Window]::SetWindowPos($PSHandle, 0, 0, 0, 0, 0, $HideWindow)
function _msgbox_ ($title, $text, $type = "None") {
    [void][reflection.assembly]::LoadWithPartialName("System.Windows.Forms")
    $msg = [Windows.Forms.MessageBox]::Show($text, $title, [Windows.Forms.MessageBoxButtons]::ok, 
    [Windows.Forms.MessageBoxIcon]::$type)
}
$cert = @(dir cert:\currentuser\my -codesigning)[0]
if (!$cert) {
    _msgbox_ -title "Error" -text "Here is no valid signing certificate!" -type "Error"
    exit
}
$status = Set-AuthenticodeSignature "$file" $cert -TimestampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
if ($status.status -eq "Valid") {
    _msgbox_ -title "Success" -text "Script is now signed! Enjoy!"
} else {
    _msgbox_ -title "Error" -text $status.StatusMessage -type "Error"
}
exit'
            Set-Content -Path $FilePath -Value $exefile
            &$filepath $filepath
        }
        else {
            Write-Warning "Unable to create file in: $FilePath. Path is incorrect or you haven't sufficient permissions"
        }
    }
    else {
        Write-Warning "Unable to create registry key. May be you haven't sufficient permissions to HKLM hive"
    }
}

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

Примечание: такой метод установки справедлив только для V2. При использовании PowerShell 1.0 установщик следует запускать непосредственно из консоли PowerShell.

Заметка: Здесь следует обратить внимание на блок кода, который идёт после PARAM в переменной $exefile. Данный блок кода скрывает саму консоль PowerShell и показывает только графическую часть, которая исполняется из скрипта. Функция скрытия консоли честно взята из блога Васи Гусева: Win32 API из PowerShell 1.0. Данный метод работает как в PowerShell V2 CTP3, так и в PowerShell 1.0.

И вариант скрипта для PowerShell V2:

#####################################################################
# Sign PS1 Script.ps1
# Version 1.5
#
# Automatically sign PowerShell script from .PS1 file context menu
#
# Require PowerShell V2, not compatible with PowerShell 1.0
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

$FilePath = Read-Host "Specify path to hold SignIt.PS1"
if (Test-Path $FilePath) {
    $FilePath = $FilePath + "\" + "SignIt.ps1"
    $RegPath = "Registry::HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell\Sign It\command"
    $RegValue = "C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -noprofile -command $FilePath '%1'"
    New-Item -Path $RegPath -Force -ErrorAction SilentlyContinue
    if (Test-Path $RegPath) {
        New-ItemProperty -Path $RegPath -Name "(Default)" -Value $RegValue
        New-Item -ItemType file -Path $FilePath -Force
        if (Test-Path $FilePath) {
            $exefile = 'param ($file)
function _msgbox_ ($title, $text, $type = "None") {
    [void][reflection.assembly]::LoadWithPartialName("System.Windows.Forms")
    $msg = [Windows.Forms.MessageBox]::Show($text, $title, [Windows.Forms.MessageBoxButtons]::ok,
    [Windows.Forms.MessageBoxIcon]::$type)
}
$cert = @(dir cert:\currentuser\my -codesigning)[0]
if (!$cert) {
    _msgbox_ -title "Error" -text "Here is no valid signing certificate!" -type "Error"
    exit
}
$status = Set-AuthenticodeSignature "$file" $cert -TimestampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
if ($status.status -eq "Valid") {
    _msgbox_ -title "Success" -text "Script is now signed! Enjoy!"
} else {
    _msgbox_ -title "Error" -text $status.StatusMessage -type "Error"
}
exit'
            Set-Content -Path $FilePath -Value $exefile
            &$filepath $filepath
        }
        else {
            Write-Warning "Unable to create file in: $FilePath. Path is incorrect or you haven't sufficient permissions"
        }
    }
    else {
        Write-Warning "Unable to create registry key. May be you haven't sufficient permissions to HKLM hive"
    }
}

Так же, после копирования файла установщик попытается сразу подписать рабочий скрипт, чтобы этого не пришлось делать потом вручную. После этого в контекстном меню PS1 файлов будет элемент Sign It:

И если у пользователя есть сертификат для подписи скриптов, то при нажатии на этот элемент получите сообщение:

В противном случае получите ошибку:

Вот так можно значимо упростить процесс подписывания скриптов не открывая консоль PowerShell. Но если файлов будет много, то ничего не мешает основную часть кода засунуть в цикл Foreach. Например:

$cert = @(dir cert:\currentuser\my -codesigning)[0]
dir -Include *.ps1 -Recurse | %{Set-AuthenticodeSignature "$_" $cert}

На этом пока о подписывании скриптов всё, что я хотел рассказать.

Update 30.08.2009: немного переделал скрипты с учётом следующих поправок:

Добавлена возможность подписывания скриптов с использованием сервера времени VeriSign, который в подписи ставит подписанную VeriSign' ом цифровую метку времени.
Исправлены ошибки с выводом сообщений о результате операции. Например, если пользователь отменял операцию подписи, либо происходила другая ошибка в процессе подписывания, то появлялось сообщение о том, что файл подписан (хотя это было не так). Сейчас сделана проверка поля Status.
в связи с этим изменил код в посте на обновлённый.

И, собственно, кнопки для скачивания скриптов:

для PowerShell 1.0

1 PS1 file
8,42 KB SignIt_ps1.0.ps1

для PowerShell 2.0

1 PS1 file
7,85 KB SignIt_ps2.0.ps1

PowerShell Powered - http://www.sysadmins.lv

Подписывание скриптов PowerShell – практическое руководство (часть 1)

Camelot — Mon, 16 Feb 2009 06:56:08 GMT

Как известно практически всем пользователям PowerShell, в целях безопасности была введена политика запуска скриптов. Которая имеет 4 режима:

Restricted – запрещено исполнять любые скрипты, возможна работа только в интерактивной консоли
AllSigned – все скрипты должны быть криптографически подписаны
RemoteSigned – только полученные из недоверенных источников (например, интернет) скрипты должны быть подписаны
Unrestricted – наименее безопасный уровень, допускается исполнение любых скриптов

В версии V2 (пока ещё CTP3) скрипты PowerShell приравняли к исполняемым файлам и эти файлы стали неотключаемо мониториться политикой Software Restriction Policies. Я об этом уже писал ранее: PowerShell V2 и Software Restriction Policies. Поначалу меня это сильно напрягало, но после пришёл к мнению, что это правильно. Неправильно только то, что мы этого не видим (ps1 расширение нигде не фигурирует). С этим бороться можно двумя методами – явно указывать пути, откуда разрешён запуск .ps1 файлов или подписать их все.

Если компьютеров в сети больше одного, то самое идеальное для решения задачи будет наличие домена Active Directory и, по возможности, Enterprise Certification Authity (CA). Наличие домена решит массу задач, как распространение политики SRP в пределах домена, распространение сертификата в пределах домена, контроль версии сертификата, которым подписаны скрипты.

Итак, для начала нам нужно получить сертификат, которым будут подписываться скрипты. В целях безопасности следует создать ограниченную учётную запись пользователя из под которой администратор (в большинстве случаев) будет подписывать скрипты. В книге PowerShell In Action для генерации сертификата предлагается использовать makecert.exe, который входит в состав Visual Studio SDK, но как мне кажется более правильным будет использование CA. В Windows Server CA для этих целей есть уже готовый шаблон, который называется Code Signing. Но принципиальной разницы нету, каким инструментом вы будете генерировать сертификат и я опишу процесс получения сертификата с использованием доменного CA.

Если CA у нас уже установлен, то открываем оснастку Certification Authority и переходим в раздел Certificate Templates. Нажимаем правой кнопкой и выбираем Manage. Откроется редактор шаблонов. Если у вас Enterprise или Datacenter редакции Windows Server, то вы можете создать свой настроенный шаблон. Но я не вижу в этом необходимости. На данном этапе нам необходимо разрешить ограниченному пользователю запрашивать сертификаты этого шаблона. Для этого в закладке Security шаблона Code Signing нужно разрешить чтение и запрос сертификата ограниченному пользователю. Когда эта процедура проделана, редактор шаблонов можно закрыть. После чего в оснастке Certification Authority снова нажать правой кнопкой на разделе Certificate Templates –> New –> Certificate Template to Issue и в списке выбрать шаблон Code Signing.

После чего нужно залогиниться этим пользователем, запустить оснастку Certificate Manager (Start –> Run… –> certmgr.msc) и выполнить запрос сертификата. В списке шаблонов должен быть и добавленный нами Code Signing. Когда сертификат будет запрошен не надо закрывать оснастку сертификатов. Далее нам потребуется экспортировать открытую часть сертификата в x509 файл (с расширением .cer). Экспорт открытой части нам потребуется для проверки подписи и организации доверия подписи в пределах домена. Экспортированный сертификат необходимо теперь доставить администратору(-ам), который отвечает за групповую политику.

В групповых политиках (чаще всего в доменной политике) необходимо создать новую политику Software Restriction Policies и в Additiona Rules добавить правило сертификата (Certificate Rule) и указать экспортированный сертификат. Это необходимо затем, что PowerShell для проверки доверия сертификата ищет его в контейнере Trusted Publishers и только Software Restriction Policies позволяет централизовано распространять сертификаты в этот контейнер.

Теперь можно приступать к подписыванию скриптов. Для этих целей используется командлет Set-AuthenticodeSignature и синтаксис его такой:

Set-AuthenticodeSignature $file $cert

Где $file – путь к скрипту и $cert – объект сертификата, который получается следующим образом:

$cert = @(dir cert:\CurrentUser\My -codesigning)[0]

здесь мы явно указываем, что нам нужен сертификат, у которого в EKU (Enchanced Key Usage) указан Code Sgining. В нашем случае он будет всего 1. Но если их окажется несколько, то мы выберем самый первый. Вот как это будет выглядеть на практике:

[Desktop] Set-ExecutionPolicy allsigned [Desktop] Get-ExecutionPolicy AllSigned [Desktop] .\uptime.ps1 File C:\Documents and Settings\Signer\Desktop\uptime.ps1 cannot be loaded. The file C:\Documents and Settings\Signer \Desktop\uptime.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing" for more details.. At line:1 char:13 + .\uptime.ps1 <<<< + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException [Desktop] $cert = @(dir cert:\currentuser\my -codesigning)[0] [Desktop] $cert Directory: Microsoft.PowerShell.Security\Certificate::currentuser\my Thumbprint Subject ---------- ------- 42E5B32A19885C6ADCF9683BDA1C871E0FE5E0DB CN=Signer, CN=Users, DC=contoso, DC=com [Desktop] Set-AuthenticodeSignature uptime.ps1 $cert Directory: C:\Documents and Settings\Signer\Desktop SignerCertificate Status Path ----------------- ------ ---- 42E5B32A19885C6ADCF9683BDA1C871E0FE5E0DB Valid uptime.ps1 [Desktop] .\uptime.ps1 System Uptime for DC1 is: 1 days 4 hours 19 minutes 20 seconds [Desktop]

Я наглядно показал, как это работает. Мы сначала перевели политику исполнения скриптов в AllSigned и убедились, что неподписанный скрипт не исполняется. После чего я подписал этот скрипт и попробовал снова. Как видите, скрипт теперь исполнился.

Если не будет выполнено условие распространения сертификата посредством политики SRP в контейнер Trusted Publishers, то вы получите вот такое сообщение:

[Desktop] .\uptime.ps1

Do you want to run software from this untrusted publisher?
File C:\Documents and Settings\Signer\Desktop\uptime.ps1 is
published by CN=Signer, CN=Users, DC=contoso, DC=com and is not trusted
on your system. Only run scripts from trusted publishers.
[V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help
(default is "D"):d
File C:\Documents and Settings\Signer\Desktop\uptime.ps1 cannot be loaded because you have elected to no
t run this software now.
At line:1 char:12
+ .\uptime.ps1 <<<<
[Desktop]

Вот таким образом мы решаем задачу исполнения только проверенного набора скриптов. В этом смысле PowerShell 1.0 менее безопасный и удобный, поскольку мы не можем политикой SRP блокировать исполнение PS1 файлов как класс и имеем только один выход – принудительное подписывание скриптов. В версии V2 политика исполнения скриптов удобно интегрируется с SRP. Удобство интегрирования в том, что SRP помимо распространения сертификата в пределах домена так же на основе этого правила разрешает исполнять эти скрипты в обход общего ограничения на PS1 файлы.

В следующем посте я расскажу, как можно упростить процесс подписывания скриптов. Так что не отключаемся

PowerShell Powered - http://www.sysadmins.lv

Get-SystemUptime

Camelot — Sun, 15 Feb 2009 18:07:38 GMT

Этот скрипт написал скорее для себя, но весьма полезный. В Windows XP/Windows Server 2003 аптайм можно было легко посмотреть в свойствах сетевого подключения, которое как правило работает постоянно. Но в Windows Vista/Windows Server 2008 до него добираться далеко. Смотреть в Task Manager не удобно, поскольку он показывает аптайм в часах, а в уме высчитывать дни как-то неудобно. Вот и набросал функцию, которую положил себе в профиль:

function Get-SystemUptime ($computer = "$env:computername") {
    $lastboot = [System.Management.ManagementDateTimeconverter]::ToDateTime(
    "$((gwmi  Win32_OperatingSystem -computername $computer).LastBootUpTime)")
    $uptime = (Get-Date) - $lastboot
    Write-Host "System Uptime for $computer is: " $uptime.days "days" $uptime.hours `
    "hours" $uptime.minutes "minutes" $uptime.seconds "seconds"
}

Концепция очень простая – берётся дата и время последней загрузки системы и вычитается из текущей даты и времени. Здесь важно отметить, что WMI возвращает нам дату в своём формате, который нужно преобразовать в тип DateTime.

PowerShell Powered - http://www.sysadmins.lv

ConvertFrom-StringData

Camelot — Tue, 10 Feb 2009 08:43:49 GMT

Тут обнаружился один интересный командлет – ConvertFrom-StringData, который позволяет преобразовывать строку в хэш-таблицы. Скажем, есть файл вида:

ключ1 = значение1
ключ2 = значение2
ключ3 = значение3
ключ4 = значение4

при этом иногда очень хочется работать с этими строками как с объектами. Т.е. при указании объекта и его ключа, например, $a.key1 получить его значение. Как это делается в хэш-таблицах. Вот пример:

[vPodans] $a = @{"key1"="value1";"key2"="value2"}
[vPodans] $a

Name                           Value
----                           -----
key2                           value2
key1                           value1


[vPodans] $a.key1
value1
[vPodans] $a.key2
value2
[vPodans]

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

[vPodans] $a = "key1 = value1"
[vPodans] $a
key1 = value1
[vPodans] $a.GetType().FullName
System.String
[vPodans] $b = ConvertFrom-StringData -StringData $a
[vPodans] $b

Name                           Value
----                           -----
key1                           value1


[vPodans] $b.GetType().FullName
System.Collections.Hashtable
[vPodans] $b.key1
value1
[vPodans]

сперва я создал строку, которая состоит из пары ключ = значение, в чём мы можем убедиться в типе данных. Вторым этапом я сконвертировал эту строку в хэш-таблицу. Однако, следует учесть, что такое возможно только для строки, но не массива строк. Вот так легко попасть в засаду:

[vPodans] $a = gc keys.txt
[vPodans] $a
key1 = value1
key2 = value2
key3 = value3
key4 = value4
[vPodans] $a[0]
key1 = value1
[vPodans] ConvertFrom-StringData -StringData $a
ConvertFrom-StringData : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'StringData
'. Specified method is not supported.
At line:1 char:35
+ ConvertFrom-StringData -StringData <<<<  $a
    + CategoryInfo          : InvalidArgument: (:) [ConvertFrom-StringData], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgument,Microsoft.PowerShell.Commands.ConvertFromStringDataCommand

[vPodans]

командлет Get-Content (или его алиас GC, не путать с глобальным каталогом) читает файл построчно в виде массива. Следовательно каждая строка является отдельным элементом массива. Как быть в такой ситуации? На первый взгляд может показаться, что можно Get-Content разобрать через Foreach-Object и уже отдельные элементы массива подавать конвертеру в качестве строк. Смотрим:

[vPodans] $a = gc keys.txt | %{ConvertFrom-StringData -StringData $_}
[vPodans] $a

Name                           Value
----                           -----
key1                           value1
key2                           value2
key3                           value3
key4                           value4


[vPodans] $a.key1
[vPodans] $a.GetType().FullName
System.Object[]
[vPodans] $a[0].key1
value1
[vPodans]

Как видите, мы на выходе получили не одну хэш-таблицу, а массив одиночных хэш-таблиц и для доступа к его ключам и значениям нужно ещё указывать номер элемента в массиве. Чтобы решить данную проблему нужно каким-то образом прочитать файл не построчно, а в виде целой строки. Для чтения файла целиком можно воспользоваться методом ReadAllText класса File Class. Как видно из описания метода, он читает текст в единую строку. Давайте посмотрим, что у нас получится:

[vPodans] $a = [io.file]::ReadAllText("keys.txt")
[vPodans] $a
key1 = value1
key2 = value2
key3 = value3
key4 = value4


[vPodans] $a.GetType().FullName
System.String
[vPodans] $b = ConvertFrom-StringData -StringData $a
[vPodans] $b

Name                           Value
----                           -----
key2                           value2
key4                           value4
key1                           value1
key3                           value3


[vPodans] $b.key1
value1
[vPodans] $b.key2
value2
[vPodans] $b.key3
value3
[vPodans] $b.key4
value4
[vPodans]

или просто в одну строчку:

ConvertFrom-StringData -StringData ([io.file]::ReadAllText("keys.txt"))

Вот так просто в стиле The PowerShell Way (в одну строчку) можно текстовые файлы сконвертировать в хэш-таблицы и работать с ними как с объектами, что есть удобно и полезно.

PowerShell Powered - http://www.sysadmins.lv

Получение установочного ключа Windows из PowerShell

Camelot — Thu, 05 Feb 2009 17:31:53 GMT

Давненько я ничего не постил в блог. Причины разные, это и проблема отыскать интересный материал для блога и лень. Но сегодня нашёл что написать. Это портированный скрипт с VBS для извлечения установочного ключа Windows и других продуктов, как Microsoft Office.

итак, исходный вариант на VBS, который был найден на просторах интернета:

Set WshShell = WScript.CreateObject("WScript.Shell")
strDigitalProductId="HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId"
strXPKey=GetKey(WshShell.RegRead(strDigitalProductId))
MsgBox "Key:"&strXPKey
Function GetKey(rpk)
    Const rpkOffset=52:i=28
    szPossibleChars="BCDFGHJKMPQRTVWXY2346789"
    Do 'Rep1
        dwAccumulator=0 : j=14
        Do
            dwAccumulator=dwAccumulator*256
            dwAccumulator=rpk(j+rpkOffset)+dwAccumulator
            rpk(j+rpkOffset)=(dwAccumulator\24) and 255
            dwAccumulator=dwAccumulator Mod 24
            j=j-1
        Loop While j>=0
    i=i-1 : szProductKey=mid(szPossibleChars,dwAccumulator+1,1)&szProductKey
    if (((29-i) Mod 6)=0) and (i<>-1) then
    i=i-1 : szProductKey="-"&szProductKey
    End If
    Loop While i>=0 'Goto Rep1
GetKey=szProductKey
End Function

Учитывая мои почти нулевые познания в VBS пришлось сильно повозиться, чтобы понять его работу в VBS и активно сотрудничать с гуглом.

И столкнулся с некоторыми трудностями:

rpk(j+rpkOffset)=(dwAccumulator\24) and 255

вот здесь происходит деление. Но не простое деление, а деление с получением целого числа от частного с отрезанием десятичной части без округления. Возможно в VBS правила округления стандартные, но в PowerShell округление происходит несколько иначе, если у нас число с половинкой, например: 1,5; 5,5; 67,5. В таких случаях PowerShell округляет число до ближайшего чётного числа. Примеры:

[vPodans] [math]::Round(0.5)
0
[vPodans] [math]::Round(1.5)
2
[vPodans] [math]::Round(2.5)
2
[vPodans] [math]::Round(3.5)
4
[vPodans] [math]::Round(4.5)
4
[vPodans] [math]::Round(5.5)
6
[vPodans] [math]::Round(6.5)
6
[vPodans] [math]::Round(7.5)
8
[vPodans] [math]::Round(8.5)
8
[vPodans]

Как видите с использованием математической функции округления вы никогда не получите нечётное число, если округлять такие числа. Есть ещё вариант форматирования строки. Но он при отбрасывании дробной части округляет половинки до бОльшего целого числа (хотя нужно до меньшего, что и делает VBS в данном случае):

[vPodans] (0.5).tostring("F00")
1
[vPodans] (1.5).tostring("F00")
2
[vPodans] (2.5).tostring("F00")
3
[vPodans] (3.5).tostring("F00")
4
[vPodans] (4.5).tostring("F00")
5
[vPodans] (5.5).tostring("F00")
6
[vPodans]

ну и я не нашёл ничего лучше, как написать простенький регексп и им отрезать ненужный хвостик. Суть регекспа будет заключаться в извлечении из строки только цифр начиная от начала строки до первого нечислового символа. Как я уже писал в предыдущем блоге в регулярных выражениях начало строки обозначается знаком возведения в степень – ^. Только числа - \d. Т.к. число может состоять из множества цифр, то я добавил символ умножения – *, чтобы сказать: от нуля и более символов. Получилось вот так:

[vPodans] 3456.356345 -match "^\d*"
True
[vPodans] $matches

Name                           Value
----                           -----
0                              3456


[vPodans] $matches[0]
3456
[vPodans]

я применил свой шаблон к произвольному дробному числу и оно попало под шаблон. Используя особую переменную $matches, которая в виде массива хранит все совпадения оператора –match, я могу извлекать ту часть сроки, которая попала под шаблон. Т.к. $matches у нас массив, то для вставки совпавшей части в код я буду обращаться к нужному элементу этого массива. В моём случае совпадение только одно, поэтому $matches будет массивом из единственного элемента и обращаться к его значению нужно по первому индексу, т.е. $matches[0].

Далее, мы видим оператор And. Здесь я тоже попал в засаду, поскольку подумал, что это аналог –AND в PowerShell. Однако после чтения документации выяснилось, что это Bitwise AND, т.е. побитовый “И”. Следовательно при портировании необходимо использовать не –AND, а –BAND. Разница у них в том, что оба числа преобразовываются в двоичный формат и побитово выполняется операция логического умножения. Подробности здесь: http://msdn.microsoft.com/en-us/library/z0zec0b2(VS.71).aspx.

szProductKey=mid(szPossibleChars,dwAccumulator+1,1)&szProductKey

оператор MID в VBS (как и в древнем досовском бейсике) вырезает часть строки и является аналогом метода Substring(), который есть в PowerShell. Однако тут я жестоко попался на следующее: в PowerShell любая нумерация индексов и символов начиная с нуля. Т.е. чтобы извлечь только первый символ из строки мне нужно указать стартовый индекс ноль - 0:

[vPodans] "here string".substring(0,1)
h
[vPodans]

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

string = "here string"
msgbox mid(string,1,1)

Следовательно при портировании скрипта из вышеупомянутой строки убираем “+1”, который, видимо, был добавлен ввиду особенности нумерации символов строки в VBS. Для кого-то это может показаться пустяком, но для меня это всё было открытием, поскольку я на VBS не написал ни одного скрипта (даже который просто мапит шару при логоне) и его синтаксис для меня достаточно сложен и не всегда понятен.

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

########################################################
# Get-ProductKey.ps1
# Version 1.0
#
# Retrieve Windows XP/2003/Vista/2008 setup key
#
# Note: not works on Windows Vista/2008 activated by KMS Server
# Note: translated from VBS script
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
########################################################

function Get-ProductKey {
    $rpk = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\" -Name DigitalProductId).DigitalProductId
    $i = 28
    $rpkOffset = 52
    $PossibleChars = "BCDFGHJKMPQRTVWXY2346789"
    do {
        $Accumulator = 0
        $j = 14
        do {
            $Accumulator = $Accumulator * 256
            $Accumulator = $rpk[$j + $rpkOffset] + $Accumulator
            $Accumulator / 24 -match "^\d*" | Out-Null
            $rpk[$j + $rpkOffset] = $matches[0] -band 255
            $Accumulator = $Accumulator % 24
            $j--
            } while ($j -ge 0)
        $i--
        $ProductKey = $PossibleChars.Substring($Accumulator, 1) + $ProductKey
        if ((29 - $i) % 6 -eq 0 -and $i -ne -1) {
            $i--
            $ProductKey = "-" + $ProductKey
        }
    } while ($i -ge 0)
$ProductKey
}

Примечание: Данный скрипт не будет возвращать установочный ключ для VLK систем Windows Vista и Windows Server 2008, которые были активированы через KMS сервер. Здесь ключ будет показан только для OEM и коробочных версий. На сколько я знаю в данном случае (как у меня на нотебуке с Vista Business) при активации через KMS ключ не хранится в системе и скрипт будет возвращать буквы B:

[vPodans] Get-ProductKey
BBBBB-BBBBB-BBBBB-BBBBB-BBBBB
[vPodans]

объяснение этому здесь: http://www.rjlsoftware.com/support/faq/sa.cfm?q=289&n=81

з.ы. ссылка не показывается в IE8 RC1, только верхний баннер Поэтому пришлось совершить грех и воспользоваться мозиллой

Так же можно получать установочные ключи не только для самой ОС, но и для приложений тоже (разработки Microsoft, разумеется), как Microsoft Office. Для этого достаточно изменить ветку реестра на:

HKLM\Software\Microsoft\Office\11.0\Registration\{GUID}\DigitalProductID

Этот путь будет справедлив для Office 2003. Где хранит этот ProductID Office 2007 я не нашёл у себя. Но вообще мысль понятна, в каком направлении искать

Удачи!

PowerShell Powered - http://www.sysadmins.lv

Функции и фильтры в PowerShell

Camelot — Mon, 12 Jan 2009 19:04:29 GMT

Пока не буду больше ничего писать про новые командлеты в PowerShell V2 CTP3, а вернусь к истории - 1.0. Как показала практика, функции в скриптах администраторов завоевали очень высокую популярность и этому есть причина - функции позволяют однажды написать блок кода и потом его использовать много раз. Но не все знают всех возможностей функций и их разновидностей в PowerShell. Сегодня мы поговорим о том, на чём чаще всего спотыкаются начинающие пользователи PowerShell.

Аргументы в функциях

В общем смысле функции строятся по такому принципу:

function FunctionName ($arg1, $arg2, $argN) { scriptoblock }

сначала мы говорим, что это будет функция и даём ей имя. В скобках указываем список принимаемых аргументов и после, в фигурных скобках указываем блок кода, который будет исполняться при вызове функций. Но функция сама по себе малоинтересна. Как правило в неё передаются какие-то данные и мы их должны как-то получать внутри функции. Данные в функции мы можем передавать двумя методами:

используя список аргументов (как в указанном примере)
по конвейеру

в первом случае всё просто. Если при объявлении функции мы указываем список аргументов, то при вызове функции эти переменные будут принимать значения. Возьмём простой пример:

function abc ($a, $b, $c) {
Write-Host '$a = ' $a
Write-Host '$b = ' $b
Write-Host '$c = ' $c
}

[vPodans] function abc ($a, $b, $c) {
>> Write-Host '$a = ' $a
>> Write-Host '$b = ' $b
>> Write-Host '$c = ' $c
>> }
>>
[vPodans] abc arg1 arg2 arg3
$a =  arg1
$b =  arg2
$c =  arg3
[vPodans]

Чтобы вызвать функцию - достаточно написать её название и разделяя проблелом передавать ей значения. Вот здесь кроется первая частая ошибка начинающих при работе с PowerShell. Дело в том, что в некоторых языках программирования функции вызываются иначе: functionname (arg1, arg2, argN). В PowerShell же формат вызова функций вот такой: functionname arg1 arg2 argN. При объявлении функции указывать список принимаемых аргументов не обязательно (но рекомендуется для читаемости скрипта). В таком случае все аргументы будут помещены в специальную переменную $args, которая будет являться массивом аргументов. Но кроме аргументов в функции можно передавать параметры-ключи, как в командлетах (например, -Verbose, -WhatIf и т.д.). Это делается при помощи указания типа аргумента. Данный тип называется [switch]:

function abc ($a, $b, [switch]$parameter) {
Write-Host '$a = ' $a
Write-Host '$b = ' $b
Write-Host 'parameter switch status = ' $parameter
}

[vPodans] function abc ($a, $b, [switch]$parameter) {
>> Write-Host '$a = ' $a
>> Write-Host '$b = ' $b
>> Write-Host 'parameter switch status = ' $parameter
>> }
>>
[vPodans] abc 1 5 -parameter
$a =  1
$b =  5
parameter switch status =  True
[vPodans] abc 1 5
$a =  1
$b =  5
parameter status =  False
[vPodans]

это очень удобно, когда одним ключом по аналогии с командлетом можно выбирать режим работы функции. Просто в фнукции проверяете статус ключа True или False и в зависимости от этого выбираете режим.

Конвейер и функции

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

[vPodans] function sum {$_ * 2}
[vPodans] 1..5 | sum
[vPodans]

Мы захотели просто умножить каждое число на 2. Но результата нету. Это вторая частая ошибка начинающих пользователей, которые путают функцию с конвейерным циклом Foreach-Object:

[vPodans] function sum {$_ * 2}
[vPodans] 1..5 | %{sum}
2
4
6
8
10
[vPodans]

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

[vPodans] function input {$input}
[vPodans] 1..5 | input
1
2
3
4
5
[vPodans]

Однако, данный метод очень непроизводителен, когда требуется произвести некоторую операцию над каждым элементом конвейера. Поскольку мы должны сначала ждать, пока по конвейеру будут собраны все данные в переменную $input и только потом начнётся сама обработка. Т.к. переменная $input является массивом, то мы не можем прямо к ней использовать переменную текущего элемента $_. Как вариант, можно в самой функции разобрать переменную $input циклом и получить требуемый результат:

[vPodans] function sum {$input | %{$_ * 2}}
[vPodans] 1..5 | sum
2
4
6
8
10
[vPodans]

Задача хоть и решена, но кроме потери производительности у нас ещё вырос объём кода. Что тоже не есть хорошо. Чтобы избавиться от переменной $input можно использовать этап функции - Process. Что это такое и с чем его едят можно узнать из замечательного поста Дмитрия Сотникова - $input Gotchas. Материал по ссылке изложен достаточно подробно и он будет понятен даже тем, у кого есть хотя бы базовые навыки английского языка. Итак:

[vPodans] function sum {process {$_ * 2}}
[vPodans] 1..5 | sum
2
4
6
8
10
[vPodans]

на этапе Process мы отказываемся в дополнительном разборе переменной $input, поскольку этап Process уже начинает исполняться при поступлении первого элемента на вход конвейера. Следовательно мы получаем выигрыш в скорости работы. Но для таких вещей, как обработка каждого элемента в функции в PowerShell есть одна разновидность функции и называется фильтр! По сути фильтр является той же функцией, которая помещена в цикл Foreach-Object. Фильтры в PowerShell используются так же, как и функции:

filter FilterName ($arg1, $arg2) {scriptoblock}

[vPodans] filter sum {$_ * 2}
[vPodans] 1..5 | sum
2
4
6
8
10
[vPodans]

это то же самое, что и:

[vPodans] function sum {$_ * 2}
[vPodans] 1..5 | %{sum}
2
4
6
8
10
[vPodans]

Как видите, вариантов решений задачи в функциях существует много и каждый может использовать тот, что ему по душе. Можно сказать, что это мелочи? Да, можно. Но именно вот такие мелочи будут влиять на эстетическую красоту, производительность и ресурсопотребление ваших скриптов в работе. Причём разница в производительности и ресурсопотреблении может доходить до 100(!) раз, в зависимости от выбранного метода. Об этом я уже говорил в своём предыдущем блоге на примере циклов: Foreach, Foreach-Object и оптимизация циклов в PowerShell.

PowerShell Powered - http://www.sysadmins.lv

PowerShell V2 и Software Restriction Policies

Camelot — Tue, 06 Jan 2009 07:19:18 GMT

Как моим читателям известно я недавно репортил баг на connect (подробности здесь - Первые впечатления от PowerShell V2 CTP3) и сегодня получил ответ следующего содержания (если кто-то не может туда попасть):

Software restriction policies intentionally apply to PowerShell scripts now in V2
Posted by Microsoft on 2009.01.05. at 10:49

следовательно это теперь не баг, а фича. Фича by design. Ещё раз ссылка на connect:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=389878&SiteID=99

И в моём предыдущем посте по этой проблеме временный workaround следует считать постоянным. Я сильно надеюсь, что к релизу подготовят документацию по этому вопросу. И мне до сих пор не ясно, будут ли сделаны какие-то изменения в самой политике SRP (ведь блокируемого расширения .ps1 в списке политики SRP нету). Я считаю, что они должны произведены, чтобы не было никаких неизвестностей при настройке политики. Как это будет реализовано - время покажет. Но для тех, кто планирует использовать PowerShell V2 и Software Restriction Policies будет полезно это знать. Неприятно, конечно же, но что поделать.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - Active Directory/Workgroup

Camelot — Mon, 05 Jan 2009 13:35:10 GMT

Продолжая цикл постов о новых командлетах в PowerShell V2 CTP3 хочу рассказать про несколько командлетов для управлением компьютера как клиента в домене Active Directory или рабочей группе. Отмечу сразу, что эти командлеты не управляют доменом Active Directory, а только компьютером-клиентом домена (не знаю, как по-русски правильно сформулировать мысль). По сути эти командлеты повторяют аналог утилиты netdom.exe и вот их список:

Add-Computer
Remove-Computer
Rename-Computer
Reset-ComputerMachinePassword
Test-ComputerSecureChannel

и ещё 2 на закуску:

Restart-Computer
Stop-Computer

Ну и как обычно - рассмотрим каждый из них:

1) Add-Computer - добавляет компьютер к домену Active Directory или перемещает компьютер между рабочими группами (Workgroup). Данный командлет содержит следующие параметры и ключи:

-ComputerName - параметр. Имя компьютера, который нужно включить в домен или рабочую группу. Можно указывать как NetBIOS имена, так и FQDN (Fully Qualified Domain Name) и IP адреса компьютеров. Для локального компьютера можно использовать точку ( . ) или localhost или не указывать этот параметр совсем, поскольку по умолчанию будет использовать именно локальная машина. Так же можно указывать несколько компьютеров перечисляя их через запятую. Имена можно передавать в командлет по конвейеру по свойству ComputerName.
-Credential - параметр. Учётные данные для аутентификации в домене или на удалённых компьютерах рабочей группы. Формат учётных данных такой же, как и в подключениях WMI. Для этого можно использовать командлет Get-Credential. Данный параметр следует использовать только при необходимости использования альтернативных учётных данных. Если не указан, то будут использоваться учётные данные текущего пользователя.
-DomainName - параметр. DNS имя домена, куда будет подключаться компьютер. Этот параметр является обязательным при подключении к домену.
-WorkgroupName - параметр. Название рабочей группы, в которую перемещается компьютер. Обязателен при переводе компьютера из одной рабочей группы в другую.
-OUPath - параметр. Если заранее учётная запись компьютера заранее не создана в AD, то указание этого параметра позволяет добавить компьютер в нужный OU с созданием учётной записи в нём. Если этот параметр не указан, то компьютер будет помещён в контейнер по умолчанию - CN Computers. Так же этот параметр не нужно указывать при перемещении компьютера между рабочими группами.
-Server - параметр. Используется только при подключении к домену. Позволяет выбирать контроллер домена, который будет производить ввод компьютера в домен и установку пароля компьютера в домене. Параметр опциональный и может иметь смысл при добавлении машин в домен в удалённых сайтах. Указывается в формате DomainName\DCName.
-Unsecure - ключ. Операция по вводу компьютера в домен или рабочую группу будет производиться без установки защищённого канала между клиентом и сервером (контроллером домена). В домене с жёсткими политиками безопасности данный ключ может дать сбой.
-Reboot - ключ. Как известно любое изменение местоположения компьютера в сети (ввод в домен, вывод из домена, смена рабочей группы) требуют перезагрузки машины.

Примечание: может показаться, что ключ -Reboot очень полезный, но мне так не кажется. И вот почему. Если командлет сам не перезагружает машину после завершения операции, то это нужно сделать вручную. Но перезагружать машину можно только в случае если всё прошло успешно. Но если по каким-то причинам ожидаемый результат не был достигнут, то компьютер будет перезагружен в пустую. Я на этом не настаиваю, но мне это видится именно так.

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

По умолчанию данный командлет не выводит результат на экран, поэтому для вывода результата исполнения можно использовать ключи -PassThru или -Verbose. Так же командлет имеет такие полезные ключи как -Confirm для ручного подтверждения выполнения операции и -WhatIf для моделирования работы командлета. И несколько примеров использования командлета:

Add-Computer -DomainName contoso.com -Credential (Get-Credential) -OUPath OU=Test,OU="3th floor",DC=Contoso,DC=com -Reboot
Add-Computer -ComputerName (Get-Content Comps.txt) -WorkgroupName MSHome -PassThru

2) Remove-Computer - удаляет компьютер из домена или рабочей группы. Содержит параметры -ComputerName, -Credential (учётные данные пользователя, который имеет право на вывод машины из домена или локального администратора, если компьютер перемещается в рабочих группах), -Reboot, -Confirm, -PassThru и -WhatIf. Правила использования этих параметров и ключей такие же, что и для Add-Computer, но только в контексте удаления, а не ввода машины во что-то. Пример:

Remove-Computer -ComputerName computer1, computer2 -Credential contoso.com\Administrator -PassThru -Reboot - выводит компьютер из домена. Следует учесть, что при выполнении команды будет запрошен пароль учётной записи, указанной в Credential.
Remove-Computer MyComputer - просто удаляет компьютер из рабочей группы (интересно, куда? )

Примечание: ни в коем случае не удаляйте так контроллеры домена. Их сначала нужно понизить до роли рядового сервера командой dcpromo и только потом с помощью UI, netdom или командлета Remove-Computer выводить из домена.

3) Rename-Computer - переименовывает компьютер или компьютеры в рабочей группе или домене Active Directory. Обычно использует следующие параметры:

-ComputerName - имя компьютера, которые нужно переименовать. Можно не указывать, если переименовывается локальный компьютер. Если компьютер находится в домене, то следует указывать его полное FQDN имя. Не поддерживает указание нескольких компьютеров, только одного.
-NewComputerName - новое имя компьютера. Если машина находится в домене, то переименовывается и её учётная запись.
-Credential - учётные данные. Данный параметр является обязательным при переименовании удалённых компьютеров-членов домена (кроме переименовывания локального компьютера).

так же командлет содержит такие ключи как -Confirm, -Reboot и -WhatIf.

Примечание: ни в коем случае не пытайтесь этим командлетом переименовать контроллер домена!

4) Reset-ComputerMachinePassword - сбрасывает пароль учётной записи компьютера в базе Active Directory. Используется только для доменных компьютеров. Данный командлет можно использовать при трудностях аутентификации компьютера в домене или при устаревании пароля. Несколько типичных случаев, когда требуется сброс пароля компьютера - компьютер не аутентифицировался в домене более 30 или 60 дней, в зависимости от настроек домена; компьютер был восстановлен из бэкапа (SystemState), срок которого старше 30 или 60 дней или компьютер был восстановлен из образа без дополнительного восстановления актуального SystemState и другие случаи.. Подробности этой темы выходят за рамки этого поста.

Из актуальных параметров содержит -ComputerName (можно указывать несколько компьютеров. Допускаются FQDN, NetBIOS имена или IP адреса), -Server - имя контроллера домена, который будет производить сброс пароля (не обязательный параметр) и -Credental - имя пользователя, который имеет права сброса паролей указанных компьютеров. Из ключей можно выделить такие как -Confirm и -WhatIf. Общий синтаксис такой:

Reset-ComputerMachinePassword (get-content comp.txt) - переустановит пароль всех компьютеров из списка comp.txt
Reset-ComputerMachinePassword - переустановит пароль текущего компьютера
Reset-ComputerMachinePassword -Server dc1.contoso.com -Credential (Get-Credential) -Confirm - переустановит пароль локального компьютера на контроллере домена с именем DC1 и с вводом альтернативных учётных записей. После запуска потребует подтверждения операции.

5) Test-ComputerSecureChannel - проверяет возможность установки безопасного канала между клиентом и сервером. Работает только в домене и возвращает True или False. Имеет один параметр и ключ:

-Server - параметр. Имя компьютера в домене (допускается использовать FQDN, NetBIOS имена или IP адрес). Допускается указание только одного компьютера, с которым хотите проверить работоспособность безопасного канала. Параметр обязательный, поскольку нету смысла проверять защищённый канал с самим собой
-Repair - ключ. Если команда выводит False, то при указании этого ключа команда будет пытаться восстановить его.

И содержит дополнительные ключи как -Confirm и -WhatIf.

Я не придумал к какой категории присвоить эти 2 командлета и решил их описать здесь. Кстати, очень удобные командлеты:

6) Restart-Computer и Stop-Computer. Первый командлет перезагружает локальный или удалённый компьютер (или несколько), а второй выключает их совсем. Это очень полезно, поскольку я видел как минимум 5 различных решений перезагрузки/выключения компьютеров в скриптах PowerShell. Как правило это либо WMI, либо использование штатного shutdown.exe (кстати говоря, я им пользуюсь всегда) либо ещё что-нибудь. Теперь можно будет этот момент стандартизировать. Много говорить про них не буду, а скажу только, что эти командлеты используют метод Win32Shutdown WMI класса Win32_OperatingSystem. Следовательно эти командлеты обладают всеми новыми возможностями, которые описаны в предыдущей статье: Обзор новых командлетов PowerShell V2 CTP3 - WMI. Одно из преимуществ - можно использовать фоновую работу. Скажем, отправить в ребут сотню компьютеров и пока это всё происходит спокойно работать в консоли (шутка ). Поэтому в этих командлетах можно использовать такие параметры и ключи как -AsJob, Impersonate, Authentication, ComputerName и другие. Из уникальных отмечу один параметр:

-ThrottleLimit - указывает количество одновременных удалённых подключений для конкретно этой команды. Если компьютеров будет много в этой команде, то чтобы не загружать сеть можно ограничить, скажем, по 10-20 одновременных подключений. По умолчанию максимум одновременно установлено 32 подключения.

и ключ:

-Force - без комментариев. Точнее перезагружает или выключает компьютер без спроса, форсирует закрытие всех приложений, что может быть риском потери данных, если они в этот момент не были сохранены.

На сегодня вроде всё. Вроде ничего не пропустил.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - WMI

Camelot — Sun, 04 Jan 2009 18:37:15 GMT

Windows Management Instrumentarion или просто WMI в PowerShell V2 так же претерпел изменения, а точнее дополнения по сравнению с версией 1.0. Я планирую более подробно описать новые и обновлённые параметры командлета Get-WMIObject:

1) -List - ключ. Позволяет получать список классов для системы или список свойств и методов для конкретного класса:

[vPodans] Get-WmiObject -List


   NameSpace: ROOT\cimv2

Name                                Methods              Properties
----                                -------              ----------
__NotifyStatus                      {}                   {StatusCode}
__ExtendedStatus                    {}                   {Description, Operation, ParameterInfo, ProviderName...}
Win32_PrivilegesStatus              {}                   {Description, Operation, ParameterInfo, PrivilegesNotHeld...}
Win32_JobObjectStatus               {}                   {AdditionalDescription, Description, Operation, ParameterIn...
__SecurityRelatedClass              {}                   {}
__Trustee                           {}                   {Domain, Name, SID, SidLength...}
Win32_Trustee                       {}                   {Domain, Name, SID, SidLength...}
__NTLMUser9X                        {}                   {Authority, Flags, Mask, Name...}
....

По умолчанию, без указания других параметров, параметр -List выводит список классов, которые расположены в контейнере по умолчанию Root\CimV2. Но можно указывать и другие контейнеры при помощи параметра -NameSpace. Например:

Get-WmiObject -Namespace root\default -List

Или для конкретного класса:

[vPodans] Get-WmiObject Win32_share -List | select * | fl


Name             : Win32_Share
__GENUS          : 1
__CLASS          : Win32_Share
__SUPERCLASS     : CIM_LogicalElement
__DYNASTY        : CIM_ManagedSystemElement
__RELPATH        : Win32_Share
__PROPERTY_COUNT : 10
__DERIVATION     : {CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER         : THOR
__NAMESPACE      : ROOT\cimv2
__PATH           : \\THOR\ROOT\cimv2:Win32_Share
Path             : \\THOR\ROOT\cimv2:Win32_Share
Derivation       : {CIM_LogicalElement, CIM_ManagedSystemElement}
Methods          : {Create, SetShareInfo, GetAccessMask, Delete}
Scope            : System.Management.ManagementScope
Options          : System.Management.ObjectGetOptions
ClassPath        : \\THOR\ROOT\cimv2:Win32_Share
Properties       : {AccessMask, AllowMaximum, Caption, Description...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers       : {CreateBy, DeleteBy, dynamic, Locale...}
Site             :
Container        :



[vPodans]

здесь мы видим доступные методы (Create, SetShareInfo и другие), а так же свойства объекта класса (AccessMask, AllowMaximum, Caption и другие). Можно и более подробно посмотреть методы или свойства объекта:

Get-WmiObject Win32_share -List | %{$_.methods} - получение подробных сведений о методах объекта класса
Get-WmiObject Win32_share -List | %{$_.properties} - получение подробных сведений о свойствах объекта класаа

Кстати говоря, в PowerShell 1.0 параметр -List не работал для конкретных классов, а только для перечисления самих классов. Т.е. приведённые выше 2 команды в 1.0 не работают. Теперь этот недостаток исправлен.

2) -AsJob - ключ. Позволяет выполнять команду в фоновом режиме. Это новая возможность в PowerShell V2, которая позволяет запускать некоторые команды в фоновом режиме не блокируя при этом саму консоль. Коллега, Вася Гусев, уже делал скринкаст по фоновым работам в PowerShell (и не только о них) на TechDays.ru (потребуется авторизация с помощью LiveID или OpenID). И я так же планирую обсудить в своём блоге этот вопрос в обозримом будущем.

3) -Authentication - параметр. Позволяет задавать уровень аутентификации к удалённой машине. Возможные уровни аутентификации могут быть:

-1 (Unchanged) - я не смог найти описание этому уровню, но он в Windows XP/Windows Server 2003 используется для локальных подключений на себя.
0 (Default) - необходимый уровень будет согласовываться между сервером и клиентом в зависимости от настроек Windows Authentication.
1 (None) - не использует аутентификацию. Все уровни безопасности будут проигнорированы. Не следует использовать этот уровень, поскольку с ним аутентифицироваться не удастся (разве что в случае разрешённых анонимных подключений на сервере).
2 (Connect) - клиент аутентифицируется только при установке подключения. После установки подключения аутентификационные данные не проверяются.
3 (Call) - пересылаемые учётные данные проверяются при каждом запросе клиента. Учётные данные криптографически подписываются, но не шифруются. Пересылаемые данные во время сессии не подписываются и не шифруются. Гарантируется, что во время пересылки аутентификационных данных они не были никоим образом изменены.
4 (Packet) - похож на уровень Call с учётом того, что сервер проверяет что данные пришли от ожидаемого клиента. Так же учётные данные подписываются и не шифруются. Данные не подписываются и не шифруются (используется по умолчанию при сетевых подключениях).
5 (PacketIntegrity) - подписываются как учётные данные, так и сами пересылаемые данные. Данный уровень гарантирует, что с момента отправки от клиента до получения данных сервером любые данные не были изменены. Но данные (в том числе учётные) по прежнему не шифруются.
6 (PacketPrivacy) - все передаваемые данные между клиентом и сервером подписываются и шифруются.

В версии 1.0 можно было изменять уровни аутентификации, но там были свои сложности. Например, при первом подключении нельзя было указывать свой уровень аутентификации, а только при последующих обращениях к серверу. Например так:

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.Authentication = 6 или PacketPrivacy

4) -Authority - параметр. Позволяет клиенту выбирать, кто будет его аутентифицировать (например, LSA удалённой машины или сервер Active Directory) при указании параметра -Credentials.

5) -DirectRead - ключ. Если указывается, то производится прямой доступ к классу без привязки к нему более высших или производных классов. Реальной пользы я тут пока что не вижу.

6) -Impersonation - параметр. В этом параметре можно указывать уровень имперсонализации при удалённых подключениях. Может иметь следующие значения:

0 (Default) - так же не смог найти описания для него. Во всяком случае в самом WMI такой уровень нигде не определён и скорее всего это какой-то производный уровень из нескольких внутри самого PowerShell.
1 (Anonymous) - При указании этого уровня учётные данные клиента скрываются. По факту WMI в современных версиях ОС скорее всего не поддерживает этот уровень, а переводит его в уровень Identify и использует его для имперсонализации клиента. В Windows 2000 было так, во всяком случае. Да и особого смысла в нём нету, поскольку с таким уровнем ничего сделать не удастся в общем смысле.
2 (Identify) - позволяет объектам запрашивать учётные данные вызывающего пользователя, но не использовать их. Следовательно удалённый объект не сможет установить вас в контексте безопасности (т.е. подтвердить, что вы именно тот за кого себя выдаёте). С таким уровнем обычно можно только прочитать ACL списки объектов (и то не всегда), но не более.
3 (Impersonate) - позволяет объектам использовать учётные данные вызывающего пользователя. Это в свою очередь позволяет пользователю использовать свои учётные данные для произведения любых операций над объектами в пределах прав пользователя на этот объект (обычно эти права задаются ACL списками). Данный уровень используется в PowerShell по умолчанию. Поэтому для использования уровня Impersonate данный параметр указывать не обязательно.
4 (Delegate) - это уровень транзитивной делегации учётных данных. Это позволяет удалённым объектам передавать ваши учётные данные другим объектам на других машинах. Иными словами, когда пользователь с машины A подключается к машине B, то в этом случае используется уровень Impersonate между A и B. Но если для завершения операции объекту с машины B нужно получить ещё объект с машины C, то Delegate позволит машине B аутентифицироваться на машине C с учётными данными, которые были получены от машины A. Если совсем грубо, то пользователь просто разрешает запрашиваемым объектам использовать его учётные записи для своих нужд. Безусловно, это большой риск, когда объект может распоряжаться полученными учётными данными как хочет, поэтому все пользователи и компьютеры, которые будут участвовать в транзакции (например, пользователь и компьютеры A, B и C) должны быть помечены как Trusted For Delegation в Active Directory.

В версии 1.0 так же можно было изменять уровень имперсонализации с теми же сложностями, которые были и у параметра Authentication. А именно - нельзя было изменять этот уровень при первом подключении к WMI. Делалось это так:

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.Impersonation = 4 или Delegate

7) -EnableAllPrivileges - ключ. Данный ключ включает все привилегии безопасности (семейство SeSecurity Privilege), которыми обладает пользователь. Я уже не раз отмечал, что при работе в системе из графической оболочки Explorer, LSA (Local Security Authority) прозрачно для пользователя включает привилегии при необходимости. Однако, в целях безопасности для скриптов LSA по умолчанию не включает их. Привилегии безопасности нужны для многих операций, как смена владельца объектов, редактирования списков ACL множества объектов, выполнение критических для системы операции как удаление журналов событий, восстановления системы из точек восстановления и т.д. И только WMI нам предлагает интерфейс для их использования. Причём теперь это делается простым указанием ключа при использовании командлета Get-WmiObject. В общем смысле в версии 1.0 нельзя было из скриптов включать привилегии, хотя по факту данный функционал был заложен и активно использовался:

$a = Get-WmiObject Win32_share -filter "Name = 'sharename'"
$a.PSBase.Scope.Options.EnablePrivileges = $true

В этом отношении PowerShell является менее безопасным, чем, к примеру, VBS, который позволяет включать только необходимые привилегии безопасности (например для смены владельца объекта только SeRestorePrivilege и SeTakeOwnershipPrivilege). Причём VBS может очень гибко работать с подключаемыми привилегиями, что делает код более безопасным. В PowerShell они включаются все сразу и отдельные привилегии включать нельзя.

Вот, в принципе и рассмотрели основые полезные и интересные нововведения в командлет Get-WmiObject для работы с WMI в PowerShell V2 CTP3. Я допускаю, что эти параметры к релизу вряд ли претерпят существенные изменения и будут справедливы и в финальной версии V2.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - SystemRestore

Camelot — Sat, 03 Jan 2009 11:45:20 GMT

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

Get-ComputerRestorePoint
Checkpoint-Computer
Restore-Computer
Enabe-ComputerRestore
Disable-ComputerRestore

Мой вариант костылей для версии 1.0 описан здесь: SystemRestore и PowerShell. По сути в версии 1.0 доступно большинство функционала V2, но только в виде самописных функций, в V2 уже есть всё (или почти всё) в коробке. Для работы этих командлетов так же потребуются клиентские версии ОС Windows XP/Windows Vista. Посмотрим их попорядку:

1) Get-ComputerRestorePoint - получает список доступных точек восстановления.

Get-ComputerRestorePoint 490 - 490 - опциональный параметр, который позволяет получить сведения о конкретной точке восстановления.

[System32] Get-ComputerRestorePoint

CreationTime           Description                    SequenceNumber    EventType         RestorePointType
------------           -----------                    --------------    ---------         ----------------
2008.12.29. 21:14:04   Windows Installer installed... 490               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.29. 21:56:01   Windows Update                 491               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.29. 21:58:55   Windows Update                 492               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2008.12.31. 1:38:08    Windows Update                 493               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.01. 21:53:49   Windows Installer installed... 494               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.01. 22:03:01   Windows Installer installed... 495               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.02. 1:38:06    Windows Update                 496               BEGIN_SYSTEM_C... APPLICATION_INSTALL
2009.01.02. 19:45:27   Windows Installer installed... 497               BEGIN_SYSTEM_C... APPLICATION_INSTALL


[System32] Get-ComputerRestorePoint 490 | select *


__GENUS          : 2
__CLASS          : SystemRestore
__SUPERCLASS     :
__DYNASTY        : SystemRestore
__RELPATH        : SystemRestore.SequenceNumber=490
__PROPERTY_COUNT : 5
__DERIVATION     : {}
__SERVER         : THOR
__NAMESPACE      : root\default
__PATH           : \\THOR\root\default:SystemRestore.SequenceNumber=490
CreationTime     : 20081229191404.400068-000
Description      : Windows Installer installed Quest PowerGUI 1.5.3.
EventType        : 100
RestorePointType : 0
SequenceNumber   : 490
Scope            : System.Management.ManagementScope
Path             : \\THOR\root\default:SystemRestore.SequenceNumber=490
Options          : System.Management.ObjectGetOptions
ClassPath        : \\THOR\root\default:SystemRestore
Properties       : {CreationTime, Description, EventType, RestorePointType...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers       : {dynamic}
Site             :
Container        :



[System32]

Если посмотреть внимательней, то можно легко заметить, что данный командлет (как и все остальные, которые относятся к SystemRestore) реализован через тот же WMI класс SystemRestore. Поэтому на эти командлеты будут накладываться ограничения, которые накладывает этот класс. Это и версия ОС и права доступа. В данном случае для работы с командлетами восстановления системы нужны права администратора и для Windows Vista - проход запроса UAC.

2) Checkpoint-Computer - создаёт новую точку восстановления. Синтаксис командлета может быть такой:

Checkpoint-Computer -RestorePointType Application_Install -Description CustomDescription

-RestorePointType может иметь следующие значения:

APPLICATION_INSTALL
APPLICATION_UNINSTALL
DEVICE_DRIVER_INSTALL
MODIFY_SETTINGS
CANCELLED_OPERATION

-Description может иметь любое значение, поскольку это будет всего лишь описание. Но лучше использовать рекомендованные значения для описаний, которые документированы в статье MSDN: Restore Point Description Text. Стандартизация в наше время - это очень важно. Время создания точки восстановления на моём нотебуке составило чуть больше минуты и на экране консоли будет такой псевдографический прогресс-бар:

я вот тоже хочу как-нибудь научиться делать такие прогресс-бары.

3) Restore-Computer - восстанавливает компьютер до указанной точки восстановления:

Restore-Computer -RestorePoint 490 -Confirm -WhatIf

в параметре -RestorePoint указывается номер точки восстановления, который можно получить командой Get-ComputerRestorePoint. Данный командлет обладает ещё опциональными параметрами -Confirm, который будет требовать подтверждения пользователя и -WhatIf, который будет полезен в отладочных целях.

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

4) Enable-ComputerRestore - включает режим восстановления системы для всех дисков или для определённых.

Enable-ComputerRestore -Drive "C:\" -WhatIf

Параметры -Drive и -WhatIf являются не обязательными. Если не указан -Drive, то восстановление системы будет включено для всех допустимых дисков в системе.

5) Disable-ComputerRestore - отключает режим восстановления системы для всех дисков или определеённых:

Disable-ComputerRestore -Drive "C:\" -WhatIf

Параметры -Drive и -WhatIf являются не обязательными. Если не указан -Drive, то восстановление системы будет отключено для всех дисков в системе.

К сожалению функционал изменения настроек SystemRestore, как резервирование места для точек восстановления, время хранения, периодичность создания точек не реализован в командлетах. А ведь лишним это не будет однозначно. Поэтому в отношении CTP3 эти вещи придётся реализовывать с помощью WMI самостоятельно.

PowerShell Powered - http://www.sysadmins.lv

Обзор новых командлетов PowerShell V2 CTP3 - Eventlog

Camelot — Fri, 02 Jan 2009 20:11:19 GMT

PowerShell V2 CTP3 вышел уже давно (23 декабря прошлого года), но всё никак не доходили руки осветить новые командлеты. Сегодня постараюсь рассказать о новых возможностях работы с журналами событий готовыми командлетами. Функционал этих командлетов я уже реализовывал немного раньше:

Но плюс новых командлетов в том, что это уже готовые командлеты, а не костыли в виде отдельных функций. Безусловно, ещё не всё работает как положено, но обзор уже делать можно. Итак, список командлетов:

Get-WinEvent
New-EventLog
Write-EventLog
Clear-Eventlog
Limit-EventLog
Remove-EventLog

начнём попорядку:

1) Get-WinEvent. Данный командлет призван заменить ранее использовавшийся командлет Get-Eventlog. Синтаксис команды может быть следующий:

[System32] Get-WinEvent -ListLog * | ft -a

LogName                                                                   MaximumSizeInBytes RecordCount  LogMode
-------                                                                   ------------------ -----------  -------
Application                                                                         20971520       17003 Circular
DFS Replication                                                                     15532032           6 Circular
HardwareEvents                                                                      20971520           0 Circular
Internet Explorer                                                                    1052672           0 Circular
Key Management Service                                                              20971520           0 Circular
ODiag                                                                               16777216         267 Circular
OSession                                                                            16777216         544 Circular
Security                                                                            33554432       16904 Circular
System                                                                              20971520       43146 Circular
Windows PowerShell                                                                  15728640       16803 Circular
ForwardedEvents                                                                     20971520             Circular
Microsoft-Windows-Backup                                                             1052672           6 Circular
Microsoft-Windows-Bits-Client/Analytic                                               1052672             Circular
Microsoft-Windows-Bits-Client/Operational                                            1052672        2226 Circular
....

Показ всех журналов событий в системе, включая журналы в Application and Services Logs (для Vista/2008). Вместо звёздочки можно указать конкретный журнал событий.

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

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

[System32] Get-WinEvent -ListProvider *

Name                                                        LogLinks
----                                                        --------
.NET Runtime                                                {Application}
.NET Runtime Optimization Service                           {Application}
Active Server Pages                                         {Application}
Application                                                 {Application}
Application Error                                           {Application}
Application Hang                                            {Application}
Application Management                                      {Application}
ASP.NET 1.1.4322.0                                          {Application}
ASP.NET 2.0.50727.0                                         {Application}
CardSpace 3.0.0.0                                           {Application}
Chkdsk                                                      {Application}
Crystal Reports                                             {Application}
DataDynamics ActiveBar 1.0                                  {Application}
Desktop Window Manager                                      {Application}
devenv                                                      {Application}
....

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

Get-WinEvent -ProviderName "Application Hang"

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

[System32] Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1 | select *


Message              :
Id                   : 1002
Version              :
Qualifiers           : 0
Level                : 2
Task                 : 101
Opcode               :
Keywords             : 36028797018963968
RecordId             : 16431
ProviderName         : Application Hang
ProviderId           :
LogName              : Application
ProcessId            :
ThreadId             :
MachineName          : Thor
UserId               :
TimeCreated          : 2008.12.21. 17:19:47
ActivityId           :
RelatedActivityId    :
ContainerLog         : application
MatchedQueryIds      : {}
Bookmark             : System.Diagnostics.Eventing.Reader.EventBookmark
LevelDisplayName     :
OpcodeDisplayName    :
TaskDisplayName      :
KeywordsDisplayNames : {}
Properties           : {System.Diagnostics.Eventing.Reader.EventProperty, System.Diagnostics.Eventing.Reader.EventPrope
                       rty, System.Diagnostics.Eventing.Reader.EventProperty, System.Diagnostics.Eventing.Reader.EventP
                       roperty...}



[System32]

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

[System32] Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1 | gm -MemberType noteproperty


   TypeName: System.Diagnostics.Eventing.Reader.EventLogRecord

Name    MemberType   Definition
----    ----------   ----------
Message NoteProperty  Message=null


[System32]

в членах объекта мы видим, что свойство Message заткнуто заглушкой (Message=null) и оно ничего не возвращает. Но текст события можно извлечь из свойства Properties:

[System32] (Get-WinEvent -ProviderName "Application Hang" -MaxEvents 1).properties

Value
-----
mstsc.exe
6.0.6002.18000
ac0
01c9637bc8453f5e
8
{67, 0, 114, 0...}


[System32]

текст тут невнятный совсем. Для некоторых событий он возвращает такой же текст, что и в графическом журнале событий (и которые корректно отображаются командлетом Get-EventLog). Те события, которые не показывает корректно Get-EventLog в новом командлете уже не показывают ничего. Тут вся надежда на разработчиков, что они наконец-то сделают возможность полностью видеть тексты всех эвентов журнала событий, в противном случае придётся снова забивать костыли с помощью адского WMI. Но тут следует обратить внимание на параметр MaxEvents. Без его указания поиск только нескольких событий (например, первых 10 с использованием Select -First 10) займёт значительное время, поскольку команда будет работать пока весь журнал не будет прочёсан. Этот параметр является аналогом параметра -Newest для Get-EventLog. Поэтому если вы хотите посмотреть только часть событий, то используйте этот параметр. В общем смысле это выглядит так:

старая нотация: Get-EventLog application -Source "Application Hang" -Newest 5
новая нотация: Get-WineVent -ProviderName "Application Hang" -MaxEvents 5

И ещё одно хорошее отличие нового командлета - теперь не обязательно указывать журнал для поиска. Вы можете указать только поставщика событий и количество событий для вывода. Это очень удобно.

Следовательно можно судить, что новый командлет Get-WinEvent является значимо более лучшим, чем прежний Get-EventLog. Хотя его применимость в настоящее время весьма сомнительна, поскольку работу с текстом событий так никто и не сделал.

2) New-EventLog. Нетрудно догадаться, что этот командлет создаёт новый журнал событий:

New-EventLog -LogName "Custom EventLog" -Source "Custom Source"

[System32] New-EventLog -LogName "Custom EventLog" -Source "Custom Source"
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
     512      7 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 162 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32] Get-WinEvent -ListProvider "custom Source"

Name                                                        LogLinks
----                                                        --------
Custom Source                                               {Custom EventLog}


[System32]

Всё очень просто. Внизу я сделал проверку, что наш провайдер событий успешно зарегистрировался и он будет писать только в журнал Custom EventLog. Так же можно и добавлять события (поставщиков) к существующим журналам. Для этого в параметре -LogName нужно указать существующий журнал.

3) Write-Eventlog. Так же по смыслу можно догадаться, что данный командлет добавляет записи в журнал событий. Общий синтаксис его такой:

Write-EventLog -LogName "Custom EventLog" -Source "Custom Source" -EntryType Information -EventID 1 -Message "Привет мир!"

EntryType может иметь следующие значения: Error, Warning, Information, SuccessAudit, FailureAudit. Об этом я уже говорил ранее здесь. Смотрим:

[[System32] Write-EventLog -LogName "Custom EventLog" -Source "Custom Source" -EntryType Information -EventID 1 -Message
"Привет мир!"
[System32] Get-WinEvent -ProviderName "Custom source"

TimeCreated                   ProviderName                                             Id Message
-----------                   ------------                                             -- -------
2009.01.02. 21:05:06          Custom Source                                             1


[System32] Get-WinEvent -ProviderName "Custom source" | select *


Message              :
Id                   : 1
Version              :
Qualifiers           : 0
Level                : 4
Task                 : 1
Opcode               :
Keywords             : 36028797018963968
RecordId             : 1
ProviderName         : Custom Source
ProviderId           :
LogName              : Custom EventLog
ProcessId            :
ThreadId             :
MachineName          : Thor
UserId               :
TimeCreated          : 2009.01.02. 21:05:06
ActivityId           :
RelatedActivityId    :
ContainerLog         : custom eventlog
MatchedQueryIds      : {}
Bookmark             : System.Diagnostics.Eventing.Reader.EventBookmark
LevelDisplayName     :
OpcodeDisplayName    :
TaskDisplayName      :
KeywordsDisplayNames : {}
Properties           : {System.Diagnostics.Eventing.Reader.EventProperty}



[System32] (Get-WinEvent -ProviderName "custom source").Properties

Value
-----
Привет мир!


[System32]

Первой строкой мы создали новое событие в журнале, второй посмотрели общую сводку по провайдеру Custom Source, которого мы создали ранее. В нём уже зарегистрировано одно событие, которое мы посмотрели в расширенном виде. И последней строкой посмотрели текст созданного события.

Спросите вы, какая польза от этого, ведь кроме программистов это мало кому нужно? А польза есть от него. Для примера можно взять резервное копирование. Например, у администратор регулярно выполняются скрипты, которые делают резервное копирование данных. И создав нового провайдера или новый журнал администратор может в скрипт добавить код, который будет лог копирования помещать в журнал событий помимо стандартной процедуры отправки лога к себе на почту. Это может оказаться очень удобным! Так же данный командлет содержит параметр -WhatIf, который следует использовать в отладочных целях.

4) Clear-EventLog. Очистка журнала:

Clear-EventLog -LogName "Custom EventLog"

тут всё проще постого. Указываете имя журнала и очищаем его:

[System32] Clear-EventLog "Custom EventLog"
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
     512      7 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 165 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32]

Во второй строчке мы уже видим, что нами созданный журнал очистился от тестового сообщения. Данный командлет содержит параметр -WhatIf, который следует использовать в отладочных целях.

5) Limit-EventLog. Позволяет изменять размер журнала и политику перезаписи журнала. Общий синтаксис такой:

Limit-EventLog -LogName "Custom EventLog" -MaximumSize 64mb -OverflowAction OverWriteOlder -RetentionDays 10

[System32] Limit-EventLog -LogName "Custom EventLog" -MaximumSize 64mb -OverflowAction OverWriteOlder -RetentionDays 10
[System32] Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  20 480      0 OverwriteAsNeeded      17 011 Application
  65 536     10 OverwriteOlder              0 Custom EventLog
  15 168      0 OverwriteAsNeeded           6 DFS Replication
  20 480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20 480      0 OverwriteAsNeeded           0 Key Management Service
  16 384      0 OverwriteAsNeeded         267 ODiag
  16 384      0 OverwriteAsNeeded         544 OSession
  32 768      0 OverwriteAsNeeded      16 908 Security
  20 480      0 OverwriteAsNeeded      43 165 System
  15 360      0 OverwriteAsNeeded      16 920 Windows PowerShell


[System32]

Здесь мы задали размер журнала в 64 мегабайта и политику перезаписи старых логов старше 10 дней.

6) Remove-EventLog. Удаляет журнал событий или провайдера событий:

Remove-EventLog -Source "Custom Source" - удаляет провайдера событий из системы
Remove-EventLog -LogName "Custom EventLog" - удаляет указанный журнал из системы

И этот командлет содержит параметр -WhatIf.

В принципе, есть ещё командлет Remove-Event, который должен позволять удалять события из журналов событий, но мне пока что не удалось заставить его работать. Но вообще удаление эвентов из журналов событий - плохая и порочная практика, которая ни к чему хорошему не приведёт.

Вот мы и рассмотрели все новые командлеты в PowerShell V2 CTP3, которые относятся к работе с журналами событий (эвентлогами). В самом начале поста я привёл ссылки, на альтернативные решения, которые повторяют функционал этих командлетов для версии 1.0, но и даже умеют немножко больше (например, архивация и ротация архивов эвентлогов). В целом можно оценить позитив от новых командлетов, которые позволяют нам более удобным способом работать с журналами событий. Но всё равно нужно ждать рабочего решения, который смог бы получать тексты сообщений из журналов Windows Vista/Windows Server 2008, поскольку без него все эти нововведения мало кому будут нужны. Вобщем, как-то так.

PowerShell Powered - http://www.sysadmins.lv

Первые впечатления от PowerShell V2 CTP3

Camelot — Mon, 29 Dec 2008 20:38:01 GMT

Как и ожидалось - негативные. Я не знаю почему, но я настолько привык к версии 1.0, что V2 уже стал отвергать на подсознательном уровне, отрицая все потенциальные преимущества V2. Да, в 1.0 много чего не было сделано, приходилось конструировать собственные костыли, чтобы получить нужный результат, но 1.0 казался как-то роднее и приятней. Я тянул до последнего и вчера совершил героическое обновление PowerShell 1.0 до V2 CTP3. При этом следовал чётким инструкциям ReleaseNotes - корректно деинсталлировал версию 1.0 и потом установил V2 CTP3. Баг был обнаружен мною уже при втором запуске консоли или через 1 минуту после установки.

Суть проблемы: на своём ноутбуке с Windows Vista SP1 я использую Software Restriction Policies и действие по умолчанию Disallowed. Для необходимых путей добавлены исключения с действием Unrestricted и из стандартного набора удалёно расширение .chm и всё. А к чему я это всё? Вот мой второй запуск консоли PowerShell V2 CTP3 (после возвращения политики SRP в исходное состояние):

Windows PowerShell V2 (Community Technology Preview - Features Subject to Change)
Copyright (C) 2008 Microsoft Corporation. All rights reserved.

File D:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 cannot be loaded because its executi
on is blocked by software restriction policies. For more information, contact your system administrator.
At line:1 char:2
+ . <<<<  'D:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1'
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\Users\vPodans> Get-ExecutionPolicy
RemoteSigned
PS C:\Users\vPodans>

С dot sourced скриптами дела обстояли так же:

PS C:\Users\vPodans> "Get-Date" | Set-Content -Path .\date.ps1
PS C:\Users\vPodans> Get-Content .\date.ps1
Get-Date
PS C:\Users\vPodans> . .\date.ps1
File C:\Users\vPodans\date.ps1 cannot be loaded because its execution is blocked by software restriction policies. For
more information, contact your system administrator.
At line:1 char:2
+ . <<<<  .\date.ps1
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\Users\vPodans>

Любые попытки исполнения файлов скриптов завершились ничем. Первым делом я проверил настройки политик SRP и убедился, что расширения PS1 нету. Причём все файлы скриптов замечательно открываются по двойному клику в PowerGUI и в системном журнале Application никаких записей об этом не зарегистрировано. Далее я попробовал включить расширенное логирование работы Software Restriction Policies:

reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" /v LogFileName /d saferlog.txt

и попробовал снова запустить консоль PowerShell. В итоге я получил файл примерно такого содержания:

svchost.exe (PID = 1152) identified C:\Windows\system32\consent.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 856) identified C:\Windows\system32\DllHost.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 856) identified C:\Windows\system32\DllHost.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 1152) identified C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
powershell.exe (PID = 2688) identified D:\Users\Administrator\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}

Первой строчкой отображена попытка запуска запуска приложения с повышенными привилегиями. Далее (самая последняя строчка) видно, что файл профиля (Microsoft.PowerShell_profile.ps1) был действительно блокирован политикой. Но на каком основании блокирован и почему нету соответствующей записи в журнале Application мне до сих пор неизвестно. Я так же произвёл аудит доступа к файлу профиля, но там ничего подозрительного не увидел. Вобщем вот такие дела, господа.

Решение: в качестве временного решения в политику SRP было добавлено 2 исключения:

%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal%WindowsPowerShell/*.ps1
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal%WindowsPowerShell/PowerTab/*.ps1

Для этих двух правил уровень нужно выставить Unrestricted. Ради интереса я попробовал выставить уровень Basic User и что интересно - PS1 файлы так же блокируются, как и при отсутствии этих дополнительных исключений!

Я не знаю, что такого там натворили разработчики PowerShell в CTP3 (я не знаю, была ли такая проблема в более ранних CTP версиях или нет), но мне кажется тут попахивает не просто какой-то ошибкой в коде, а нечто более глобальным, что загрузка PS1 файлов каким-то образом ловится и отшивается политиками Software Restriction Policies. Заодно можно посетовать на практически отсутствующие инструменты отслеживания работы политик SRP (расширенное логирование не сильно помогает в этом деле). Если у кого-то есть возможность повторить ситуацию (работа PowerShell V2 CTP3 с работающей политикой SRP), то отпишитесь в комментах о результатах. Если данный баг подтвердится, то не забудьте подтвердить его здесь:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=389878&SiteID=99

PowerShell Powered - http://www.sysadmins.lv

Байты, килобайты, мегабайты и гигабайты

Camelot — Tue, 23 Dec 2008 22:00:36 GMT

В PowerShell есть замечательная возможность нативно оперировать с этими префиксами. Достаточно написать размер в килобайтах или мегабайтах, PowerShell автоматически переведёт его в байты:

[vPodans] 5kb
5120
[vPodans] 10mb
10485760
[vPodans] 40gb
42949672960
[vPodans]

Видите, все значения сами переводятся в байты. Особо не перестарайтесь, потому что TB не является константой и автоматически не преобразовывается. Но когда мы собираем информацию о системе, например, объём физической памяти или жёстких дисков средствами WMI, то данные обычно указываются в байтах и приходится вручную их как-то переводить в килобайты, мегабайты или гигабайты. Штатного функционала для решения данной задачи нету, поэтому приходится использовать примерно такой ход:

(2048 / 1kb).tostring("F00")

и в результате мы получим число 2. Мы 2048 байт разделили на килобайты, чтобы получить значение в килобайтах (если делим на 1MB, то значение получим в мегабайтах соответственно) с округлением до целого числа. Для округления до определённого знака после запятой, то в скобках нужно указать точность, например:

[vPodans] (20000 / 1kb).tostring("F00")
20
[vPodans] (20000 / 1kb).tostring("F01")
19,5
[vPodans] (20000 / 1kb).tostring("F02")
19,53
[vPodans] (20000 / 1kb).tostring("F03")
19,531
[vPodans]

используя эти данные можно написать простенькую функцию, которая будет делать обратное преобразование. Причём она это будет делать автоматически, т.е. сама выбирать в чём отображать значение, в байтах, килобайтах, мегабайтах или гигабайтах. Критерии выбора префикса очень простые - числа от 1 до 1000. Если число выше, то увеличиваем префикс до тех пор, пока не получим число от 1 до 1000. Например, 10485760 делим на 1kb и получаем 10240 килобайт. Такое представление не очень понятное. Поэтому мы ещё раз разделим на 1kb и получим цифру 10, но префикс уже будет - мегабайты. Вот такую функцию предложил Rob Campbell на ньюсгруппах (я её немного подрихтовал, чтобы выглядела более элегантно):

function to_kmg ($bytes, [int]$precision = 0) {
foreach ($i in ("Bytes","KB","MB","GB","TB")) {
    if (($bytes -lt 1024) -or ($i -eq "TB")){
        $bytes = ($bytes).tostring("F0" + "$precision")
        return $bytes + " $i"
        } else {
            $bytes /= 1KB
        }
    }
}

функция просто по очереди перебирает префиксы и проверяет, чтобы число было в пределах от 0 до 1024 (для двоичной системы мне кажется, что лучше использовать именно 1024, а не 1000). Если нет (а оно значит больше, чем 1024), то добавляем следующий префикс и уменьшаем число снова на 1024. Вот так просто это делается. Попробуем проверить функцию на примерах, которые были показаны в самом начале поста:

[vPodans] function to_kmg ($bytes, [int]$precision = 0) {
>> foreach ($i in ("Bytes","KB","MB","GB","TB")) {
>>     if (($bytes -lt 1000) -or ($i -eq "TB")){
>>         $bytes = ($bytes).tostring("F0" + "$precision")
>>         return $bytes + " $i"
>>         } else {
>>             $bytes /= 1KB
>>         }
>>     }
>> }
>>
[vPodans] to_kmg 5120
5 KB
[vPodans] to_kmg 10485760
10 MB
[vPodans] to_kmg 42949672960
40 GB
[vPodans]

Второй аргумент ($precision) позволяет указывать точность значения в знаках после запятой. Вот почти и всё. Однако, есть одно "но". WMI некоторые размеры отдаёт не в байтах (как для дисков), а в килобайтах (как для физической памяти). Поэтому для работы этой функции аргумент $bytes должен быть либо точного размера в байтах, либо с явным указанием префикса (например, 100kb).

Кстати говоря, тут будет полезным почитать по двоичным и десятичным префиксом. Порядок применения префиксов описан в документе IEC-60027-2:

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

PowerShell Powered - http://www.sysadmins.lv

SystemRestore и PowerShell

Camelot — Mon, 22 Dec 2008 13:40:46 GMT

По мотивам темы на форуме - http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=4255895&SiteID=40. PowerShell без проблем может управлять восстановлением системы - SystemRestore средствами WMI. За это отвечает классы

Примечание: SystemRestore доступно только на клиентских версиях - Windows XP/Windows Vista. В серверных редакицях Windows Server нереализовано никак.

вот так выглядит GUI окно системы восстановления в Windows Vista:

Следует так же учесть, что эти классы не находятся в пространстве имён по умолчанию Root\Cimv2, а в Root\Default. Для просмотра всех точек восстановления нужно просто получить объект данного класса (если вы работаете под управлением Windows Vista, то потребуется запустить консоль с повышенными привилегиями!). При получении объекта класса не забудьте указать правильный путь размещения класса в пространстве имён:

[System32] gwmi -Namespace "root\default" -class systemrestore


__GENUS          : 2
__CLASS          : SystemRestore
__SUPERCLASS     :
__DYNASTY        : SystemRestore
__RELPATH        : SystemRestore.SequenceNumber=473
__PROPERTY_COUNT : 5
__DERIVATION     : {}
__SERVER         : THOR
__NAMESPACE      : root\default
__PATH           : \\THOR\root\default:SystemRestore.SequenceNumber=473
CreationTime     : 20081220184403.157460-000
Description      : Scheduled Checkpoint
EventType        : 100
RestorePointType : 7
SequenceNumber   : 473
......

у меня этих точек восстановления несколько, поэтому я показал только первую точку. Здесь нам будут интересны следующие свойства - Description (название точки восстановления), EventType (тип точки восстановления) и SequenceNumber (порядковый номер точки восстановления). Эти значения нам пригодятся для создания новых точек восстановления и отката системы до определённой точки. Если посмотреть методы класса, то получим:

[System32] gwmi -Namespace "root\default" -class systemrestore | gm


   TypeName: System.Management.ManagementObject#root\default\SystemRestore

Name                MemberType   Definition
----                ----------   ----------
CreationTime        Property     System.String CreationTime {get;set;}
Description         Property     System.String Description {get;set;}
EventType           Property     System.UInt32 EventType {get;set;}
RestorePointType    Property     System.UInt32 RestorePointType {get;set
SequenceNumber      Property     System.UInt32 SequenceNumber {get;set;}
__CLASS             Property     System.String __CLASS {get;set;}
__DERIVATION        Property     System.String[] __DERIVATION {get;set;}
__DYNASTY           Property     System.String __DYNASTY {get;set;}
__GENUS             Property     System.Int32 __GENUS {get;set;}
__NAMESPACE         Property     System.String __NAMESPACE {get;set;}
__PATH              Property     System.String __PATH {get;set;}
__PROPERTY_COUNT    Property     System.Int32 __PROPERTY_COUNT {get;set;
__RELPATH           Property     System.String __RELPATH {get;set;}
__SERVER            Property     System.String __SERVER {get;set;}
__SUPERCLASS        Property     System.String __SUPERCLASS {get;set;}
ConvertFromDateTime ScriptMethod System.Object ConvertFromDateTime();
ConvertToDateTime   ScriptMethod System.Object ConvertToDateTime();
Delete              ScriptMethod System.Object Delete();
GetType             ScriptMethod System.Object GetType();
Put                 ScriptMethod System.Object Put();


[System32]

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

[System32] [wmiclass]'\\.\root\default:systemrestore' | gm -MemberType method


   TypeName: System.Management.ManagementClass#ROOT\default\SystemRestore

Name                 MemberType Definition
----                 ---------- ----------
CreateRestorePoint   Method     System.Management.ManagementBaseObject CreateRestorePoint(System.String Description,...
Disable              Method     System.Management.ManagementBaseObject Disable(System.String Drive)
Enable               Method     System.Management.ManagementBaseObject Enable(System.String Drive, System.Boolean Wa...
GetLastRestoreStatus Method     System.Management.ManagementBaseObject GetLastRestoreStatus()
Restore              Method     System.Management.ManagementBaseObject Restore(System.UInt32 SequenceNumber)


[System32]

вот тут и хранятся наши методы. Методы Enable и Disable позволяют глобально включать режим восстановления системы или отключать для определённого диска. Чтобы включить мониторинг для всей системы в целом или для конкретного диска нужно выполнить:

# объявляем класс:
$sysrestore = [wmiclass]'\\.\root\default:systemrestore'
# выбираем одно из нужных действий. Обратите внимание, что для изменения состояния
# мониторинга всей системы скобки не должны быть пустые, а содержать пустые двойные кавычки
$sysrestore.Enable("")
$sysrestore.Enable("c:\")
$sysrestore.Disable("")
$sysrestore.Disable("c:\")

Для создания новой точки воспользуемся методом CreateRestorePoint:

$sysrestore = [wmiclass]"\\.\root\default:systemrestore"
$sysrestore.CreateRestorePoint("MyRestorePoint", 0, 100)

где MyRestorePoint - название точки восстановления, 0 - тип точки восстановления (возможные значения можно посмотреть по ссылке на MSDN) и 100 - тип события. Давайте создадим новую точку восстановления:

[System32] $sysrestore = [wmiclass]"\\.\root\default:systemrestore"
[System32] $sysrestore.CreateRestorePoint("MyRestorePoint", 0, 100)


__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 1
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ReturnValue      : 0



[System32]

Значение RetrunValue = 0 говорит, что точка восстановления создана. Убедимся в этом:

[System32] gwmi -Namespace "root\default" -class systemrestore | select -Last 1


__GENUS          : 2
__CLASS          : SystemRestore
__SUPERCLASS     :
__DYNASTY        : SystemRestore
__RELPATH        : SystemRestore.SequenceNumber=475
__PROPERTY_COUNT : 5
__DERIVATION     : {}
__SERVER         : THOR
__NAMESPACE      : root\default
__PATH           : \\THOR\root\default:SystemRestore.SequenceNumber=475
CreationTime     : 20081221183404.006675-000
Description      : MyRestorePoint
EventType        : 100
RestorePointType : 0
SequenceNumber   : 475



[System32]

Вот теперь мы видим нашу точку восстановления с названием MyRestorePoint и её SequenceNumber стал на 1 больше. Чтобы откатиться на эту точку восстановления нужно выполнить метод Restore с указанием SequenceNumber:

$sysrestore = [wmiclass]"\\.\root\default:systemrestore"
$sysrestore.Restore("475")
(gwmi win32_operatingsystem).reboot()

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

[System32] gwmi -Namespace "root\default" -class systemrestoreconfig


__GENUS           : 2
__CLASS           : SystemRestoreConfig
__SUPERCLASS      :
__DYNASTY         : SystemRestoreConfig
__RELPATH         : SystemRestoreConfig.MyKey="SR"
__PROPERTY_COUNT  : 5
__DERIVATION      : {}
__SERVER          : THOR
__NAMESPACE       : ROOT\default
__PATH            : \\THOR\ROOT\default:SystemRestoreConfig.MyKey="SR"
DiskPercent       : 15
MyKey             : SR
RPGlobalInterval  : 86400
RPLifeInterval    : 4294967295
RPSessionInterval : 1



[System32]

тут всё просто. DiskPercent показывает процент дискового пространства, которое выделяется под восстановление системы. RPGlobalInterval показывает периодичность создания точек восстановления (а для Windows Vista создание теневых копий) в секундах. RPLifeInterval - время жизни точек восстановления (и теневых копий для Windows Vista) в секундах (по умолчанию 90 дней). Эти параметры можно изменять простым переприсвоением и применением новых значений скриптметодом Put(). К сожалению, провайдер SystemRestore не позволяет удалять точки восстановления (вообще это можно с использованием функции SRRemoveRestorePoint, но это уже совсем другая история программирования).

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

########################################################
# SystemRestore.ps1
# Version 1.0
#
# Functions for System Restore management
# Note: available for Windows XP and Windows Vista only!
#
# Vadims Podans (c) 2008
# http://www.sysadmins.lv/
########################################################

# функция для преобразования кода возврата в текстовое значение
function _SysRestore_Get-Code ($Action) {
switch ($Action.ReturnValue) {
   "0" {"Success"}
   default {"Unknown error $Action.ReturnValue"}
   }
}

# простая функция получения списка всех доступных точек восстановления в табличном виде
function Get-SystemRestore {
gwmi -Namespace "root\default" -class systemrestore | Select Description, @{n="Date/Time";
e={([System.Management.ManagementDateTimeconverter]::ToDateTime($_.CreationTime)).tostring()}},
@{n="Point number"; e={$_.SequenceNumber}} | ft -AutoSize
}

# функция включения или отключения System Restore для указанного диска или, если диск не указан
# то действие будет принято для всей системы в целом. А так же позволяет откатывать систему
# в более раннее состояние.
function Set-SystemRestoreStatus ($Status, $arg) {
# собственно, само действие включения или отключения System Restore
switch ($status) {
    "Enable" {$action = ([wmiclass]'\\.\root\default:systemrestore').Enable("$arg")}
    "Disable" {$action = ([wmiclass]'\\.\root\default:systemrestore').Disable("$arg")}
# процесс отката системы в более раннюю точку восстановления
    "Restore" {$RP = gwmi -Namespace "root\default" -class systemrestore | ?{$_.SequenceNumber -eq [int]$arg}
# проверяем, что указанная точка восстановления существует.
    if ($RP) {
# если существует, то проводим процесс восстановления в указанную точку
        $action = ([wmiclass]'\\.\root\default:systemrestore').Restore("$arg")
        Write-Host "Performing system restore to earlier status ..."
# получаем код возврата операции
        _SysRestore_Get-Code $action
# если восстановление системы прошло успешно, то принудительно перезагружаем систему 
        if ($(_SysRestore_Get-Code $action) -eq "Success") {
            Write-Warning "To complete System Restore system will reboot in 15 sec"
            shutdown.exe -r -t 15 -f
            }
        }else {
        Write-Host "Specified restore point does not found!"
        }
    }
    "Create" {$action = ([wmiclass]'\\.\root\default:systemrestore').CreateRestorePoint("$arg", 0, 100)}
}
# здесь происходит только генерация сообщения о ходе выполнения операций
if ($arg -and ("Enable", "Disable" -contains $status)) {
    Write-Host "Setting SystemRestore status to $status on" $arg
    _SysRestore_Get-Code $action
    } else {
    Write-Host "Setting SystemRestore status to $status on all drives: "
    _SysRestore_Get-Code $action
    }
}

# функция для изменения настроек System Restore
function Set-SystemRestoreSetting ($setting, $value) {
# получаем текущие настройки
$SRSetting = gwmi -Namespace "root\default" -class systemrestoreconfig
# проверяем выбранный параметр, который будет изменяться
switch ($setting) {
    "DiskSpace" {
# т.к. дисковое место указывается в процентах, то проверяем, что указано число от 1% до 99%
        if ($value -lt 99 -and $value -gt 1) {
            $SRSetting.DiskPercent = $value
        } else {
        Write-Warning "Disk space percentage must be integer and vlaue must be between 1-99"}
    }
# установка глубины точек восстановлений. Указывается в днях. По истечении этого времени
# точки восстановления удаляются, высвобождая место для более новых точек восстановления
    "HistoryDepth" {
        $SRSetting.RPLifeInterval = [int]$value * 86400
    }
# частота автоматического создания точек восстановлений
    "Frequency" {
# извлекаем из заданного параметра периодичности последние 4 символа, которые образуют префикс
# в днях или часах и выставляем множитель для получения секунд. Если это часы, то множитель будет
# 3600, а если в днях, то множитель будет 86400 секунд
        $time = $value.substring($value.length - 4, 4)
        switch ($time) {
            "hour" {$sec = 3600}
            "days" {$sec = 86400}
        }
# извлекаем из заданного параметра периодичности все символы, чтобы получить целочисленное значение
# кроме последних 4, которые являются текстовыми и обозначают лишь префикс
        $SRSetting.RPGlobalInterval = $sec * $value.substring(0, $value.length - 4)
        }
    default {Write-Warning "Parameter must be DiskSpace or HistoryDepth or Frequency"}
    }
# применение новых параметров
$SRSetting.Put()
}

Синтаксис функций может быть следующий:

Get-SystemRestore - показывает в табличном виде все существующие точки восстановления. Аргументов не принимает.
Set-SystemRestoreStatus Enable c:\ - включает режим SystemRestore.
где c:\ - диск, для которого включается мониторинг SystemRestore. Параметр опциональный. Если не указан, то включается для всех дисков.
Set-SystemRestoreStatus Disable c:\ - отключает режим systemRestore.
где c:\ - диск, для которого выключается мониторинг SystemRestore. Параметр опциональный. Если не указан, то выключается для всех дисков.
Set-SystemRestoreStatus Restore 5 - производит откат системы до указанной точки восстановления. После отката произойдёт принудительная перезагрузка системы.
где 5 - номер точки восстановления. Номер можно получить выполнив функцию Get-SystemRestore.
Set-SystemRestoreStatus Create "MyNewRestorePoint" - создаёт новую точку восстановления
где MyNewRestorePoint - название точки восстановления.
Set-SystemRestoreSetting DiskSpace 10 - задаёт резервируемое место для точек восстановления в процентах от ёмкости диска.
где 10 - процент диска, которое отводится под SystemRestore. Может иметь значение от 1 до 99
Set-SystemRestoreSetting HistoryDepth 10 - задаёт время хранения точек восстановления
где 10 - количество дней, в течении которого будут храниться точки восстановления. Более старые будут автоматически удаляться.
Set-SystemRestoreSetting Frequence 5days - задаёт частоту автоматического создания точек восстановления.
где 5days - периодичность создания точек восстановления в днях. Можно указывать и в часах, например, 10hour (будет делать автоматические точки восстановления каждые 10 часов). В общем смысле сначала идёт число и потом без пробелов суффикс days или hour.

PowerShell Powered - http://www.sysadmins.lv

Управление EventLog в PowerShell с использованием WMI

Camelot — Tue, 09 Dec 2008 20:00:42 GMT

В предыдущей части мы рассмотрели возможности управления журналами событий средствами .NET Framework, а так же рассмотрели проблематику использования .NET (из моего предыдущего блога) - Странности Get-Eventlog и не совсем богатый функционал. В этом посте мы разберём данный вопрос, но с использованием WMI и все примеры будут выполняться системе под управлением Windows Vista.

В WMI за журнал событий отвечают следующие классы:

WMI, как и .NET поддерживает удалённую работу с использованием ключа -ComputerName, поэтому на этом заострять внимание не будем. За публикацию списка журналов в системе отвечает класс Win32_NTEventlogFile:

[vPodans] gwmi Win32_NTEventlogFile FileSize LogfileName Name NumberOfRecords -------- ----------- ---- --------------- 8458240 Application C:\Windows\System32\Winevt... 16154 69632 DFS Replication C:\Windows\System32\Winevt... 6 69632 HardwareEvents C:\Windows\System32\Winevt... 0 69632 Internet Explorer C:\Windows\System32\Winevt... 0 69632 Key Management Service C:\Windows\System32\Winevt... 0 69632 ODiag C:\Windows\System32\Winevt... 267 1118208 OSession C:\Windows\System32\Winevt... 524 20975616 System C:\Windows\System32\Winevt... 42472 12652544 Windows PowerShell C:\Windows\System32\Winevt... 14208 [vPodans]

Стандартная процедура вывода списка журналов в системе. А теперь и сами эвенты:

[vPodans] gwmi win32_ntlogevent -filter "logfile='application'" | select -first 1 Category : 0 Category String : Event Code : Event Identifier : Type Event : Insertion Strings : Log File : Message : The User Profile Service has started successfully. Record Number : Source Name : Time Generated : Time Written : Type : Information User Name : [vPodans]

как бы информации не сильно много. Давайте немного приведём вид в более оперативный:

[vPodans] gwmi win32_ntlogevent -filter "logfile='application'" | select recordnumber, timegenerated, sourcename, eventc ode, message -first 1 | ft -a recordnumber timegenerated sourcename eventcode message ------------ ------------- ---------- --------- ------- 1 20070710111520.000000-000 Microsoft-Windows-User Profiles Service 1531 The User Profile Service ha... [vPodans]

уже более читабельно, кроме вывода даты. Чтобы подвести вывод даты и времени в формат [datetime] нужно воспользоваться конвертером времени:

[System.Management.ManagementDateTimeconverter]::ToDateTime("20070710111520.000000-000")

Чтобы привести итоговый вывод времени в укороченный формат даты и времени к данному выражению достаточно применить метод ToString().

([System.Management.ManagementDateTimeconverter]::ToDateTime("20070710111520.000000-000")).ToString()

[vPodans] [System.Management.ManagementDateTimeconverter]::ToDateTime("20070710111520.000000-000")

otrdiena, 2007. gada 10. julija 14:15:20


[vPodans] ([System.Management.ManagementDateTimeconverter]::ToDateTime("20070710111520.000000-000")).ToString()
10.07.07. 14:15:20
[vPodans]

А теперь всё сделаем так (с использованием хэш-таблиц), чтобы это всё на лету преобразовывалось и мы получили сразу готовый и более опрятный вывод:

$a =  gwmi win32_ntlogevent -filter "logfile='application'" | select -first 1
$a | Select recordnumber, @{n="timegenerated";
e={([System.Management.ManagementDateTimeconverter]::ToDateTime($_.timegenerated)).tostring()}},
sourcename, eventcode, message | ft -AutoSize

[vPodans] $a =  gwmi win32_ntlogevent -filter "logfile='application'" | select -first 1
[vPodans] $a | Select recordnumber, @{n="timegenerated";
>> e={([System.Management.ManagementDateTimeconverter]::ToDateTime($_.timegenerated)).tostring()}},
>> sourcename, eventcode, message | ft -AutoSize
>>

recordnumber timegenerated      sourcename                              eventcode message
------------ -------------      ----------                              --------- -------
           1 10.07.07. 14:15:20 Microsoft-Windows-User Profiles Service      1531 The User Profile Service has start...


[vPodans]

вот так при помощи костылей мы привели вывод в нечто более божеское. В остальном WMI не представляет ничего интересного, что могло бы представиться полезным (за исключением возможности бэкапа журналов, которую я разобрал в предыдущем посте). Разобрать работу Win32_NTLogEventUser и Win32_NTLogEventComputer в принципе можно уже и самостоятельно.

Исходя из вышеизложенного можно понять, что WMI вариант управления эвентлогом не самый удобный и практичный. Но позволяет извлекать события из журналов Windows Vista/Windows Server 2008 в читабельном виде. При этом можно изменять различные параметры журналов событий которые описаны здесь: http://msdn.microsoft.com/en-us/library/aa394225(VS.85).aspx

Изменения делаются по одной общей схеме:

$EventLog = gwmi Win32_NTEventlogFile -Filter "logfilename = '$logfilename'"
$EventLog.Property = "New Property Value"
$EventLog.Put()

И в качестве последнего штриха приведу замеры скорости работы с эвентлогом с использованием .NET и WMI:

Windows Server 2003

[user name] (measure-command {gwmi win32_ntlogevent -filter "logfile='application' and eventcode=8194"}).totalseconds
13.0865344
[user name] (measure-command {(new-object diagnostics.eventlog("application")).Entries | ? {$_.EventID -eq 8194}}).totalseconds
20.7334336
[user name]

Windows Vista:

[vPodans] (measure-command {gwmi win32_ntlogevent -filter "logfile='application' and eventcode=8194"}).totalseconds
18,0120719
[vPodans] (measure-command {(new-object diagnostics.eventlog("application")).Entries | ? {$_.EventID -eq 8194}}).totalseconds
13,3134996
[vPodans]

Как видим, для Windows Server 2003 более предпочтительным по скорости является WMI (от которого там толку не сильно много), а в Windows Vista - наоборот, .NET работает шустрее. Но из-за проблем с отображением событий журнала Security его польза в Windows Vista весьма сомнительна.

PowerShell Powered - http://www.sysadmins.lv

Управление EventLog в PowerShell с использованием .NET

Camelot — Mon, 08 Dec 2008 21:58:03 GMT

В продолжении темы работы с журналом собитый (EventLog) хочу немного рассказать об удалённой работе с EventLog и основными задачами управления. При этом хочу отметить, что у нас есть 2 различных механизма управления:

.NET Framework
WMI

Но в зависимости от архитектуры ОС оба метода обладают различными характеристиками по времени работы, отображению событий и нагрузке системы. Забегая вперёд скажу, что использование чистого .NET в Windows Server 2003 занимает хоть и немного больше времени, но загрузка процессора ниже, чем у WMI. А вот в Windows Vista .NET работает быстрее по времени и с меньшей нагрузкой на процессор. Однако, учитывая нюансы, которые изложены здесь: Странности Get-Eventlog и тот факт, что командлет Get-Eventlog основан на .NET, то его применимость в условиях Windows Vista/2008 весьма сомнительна. Поэтому вариант с использованием .NET я буду писать применимо для Windows XP/2003.

Начнём с простого: управление журналом событий реализовано в классе System.Diagnostics.Eventlog. Для перечисления списка журналов можно воспользоваться статическим методом GetEventLogs. Как известно, в PowerShell статические методы указываются после двойного знака двоеточия - ::

[Administrator] [System.Diagnostics.EventLog]::GetEventLogs("dc1") Max(K) Retain OverflowAction Entries Name ------ ------ -------------- ------- ---- 16 384 0 OverwriteAsNeeded 289 Application 512 0 OverwriteAsNeeded 45 Directory Service 512 7 OverwriteOlder 10 DNS Server 512 0 OverwriteAsNeeded 52 File Replication Service 131 072 0 OverwriteAsNeeded 12 369 Security 16 384 0 OverwriteAsNeeded 498 System 15 360 0 OverwriteAsNeeded 625 Windows PowerShell [Administrator]

При этом обратите внимание на аргумент в скобках - в них можно указывать имена удалённых компьютеров для получения списка журналов с них. В данном случае я посмотрел список журналов на контроллере домена. Чтобы получить события из журнала нужно создать объект класса System.Diagnostics.Eventlog:

New-Object System.Diagnostics.Eventlog("Application","dc1")

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

[Administrator] $EventLog = new-Object System.Diagnostics.Eventlog("Application","dc1")
[Administrator] $EventLog | gm -MemberType property


   TypeName: System.Diagnostics.EventLog

Name                 MemberType Definition
----                 ---------- ----------
Container            Property   System.ComponentModel.IContainer Container {get;}
EnableRaisingEvents  Property   System.Boolean EnableRaisingEvents {get;set;}
Entries              Property   System.Diagnostics.EventLogEntryCollection Entries {get;}
Log                  Property   System.String Log {get;set;}
LogDisplayName       Property   System.String LogDisplayName {get;}
MachineName          Property   System.String MachineName {get;set;}
MaximumKilobytes     Property   System.Int64 MaximumKilobytes {get;set;}
MinimumRetentionDays Property   System.Int32 MinimumRetentionDays {get;}
OverflowAction       Property   System.Diagnostics.OverflowAction OverflowAction {get;}
Site                 Property   System.ComponentModel.ISite Site {get;set;}
Source               Property   System.String Source {get;set;}
SynchronizingObject  Property   System.ComponentModel.ISynchronizeInvoke SynchronizingObject {get;set;}


[Administrator]

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

[Administrator] $EventLog.Entries | select -last 5 Index Time Type Source EventID Message ----- ---- ---- ------ ------- ------- 285 Nov 29 21:05 Info SceCli 1704 Security policy in the Group policy objects has been applied ... 286 Nov 29 21:35 Info SceCli 1704 Security policy in the Group policy objects has been applied ... 287 Nov 29 21:40 Info SceCli 1704 Security policy in the Group policy objects has been applied ... 288 Nov 29 21:43 Info SceCli 1704 Security policy in the Group policy objects has been applied ... 289 Dec 08 20:19 Info SceCli 1704 Security policy in the Group policy objects has been applied ... [Administrator]

Кстати говоря, если посмотреть вывод команды Get-Eventlog, то он будет идентичный. Т.е. можно смело предположить, что командлет Get-Eventlog использует именно механизмы .NET. А теперь попробуем рассмотреть статические методы данного класса:

[Administrator] $EventLog | gm -MemberType methods -Static


   TypeName: System.Diagnostics.EventLog

Name                  MemberType Definition
----                  ---------- ----------
CreateEventSource     Method     static System.Void CreateEventSource(String source, String logName), static System....
Delete                Method     static System.Void Delete(String logName), static System.Void Delete(String logName...
DeleteEventSource     Method     static System.Void DeleteEventSource(String source), static System.Void DeleteEvent...
Equals                Method     static System.Boolean Equals(Object objA, Object objB)
Exists                Method     static System.Boolean Exists(String logName), static System.Boolean Exists(String l...
GetEventLogs          Method     static System.Diagnostics.EventLog[] GetEventLogs(), static System.Diagnostics.Even...
LogNameFromSourceName Method     static System.String LogNameFromSourceName(String source, String machineName)
ReferenceEquals       Method     static System.Boolean ReferenceEquals(Object objA, Object objB)
SourceExists          Method     static System.Boolean SourceExists(String source), static System.Boolean SourceExis...
WriteEntry            Method     static System.Void WriteEntry(String source, String message), static System.Void Wr...
WriteEvent            Method     static System.Void WriteEvent(String source, EventInstance instance, Params Object[...


[Administrator]

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

[Administrator] [System.Diagnostics.EventLog]::CreateEventSource("MySource", "PowerShell CustomLog", "dc1") [Administrator] [System.Diagnostics.EventLog]::GetEventLogs("dc1") Max(K) Retain OverflowAction Entries Name ------ ------ -------------- ------- ---- 16 384 0 OverwriteAsNeeded 289 Application 512 0 OverwriteAsNeeded 45 Directory Service 512 7 OverwriteOlder 10 DNS Server 512 0 OverwriteAsNeeded 52 File Replication Service 512 7 OverwriteOlder 0 PowerShell CustomLog 131 072 0 OverwriteAsNeeded 12 369 Security 16 384 0 OverwriteAsNeeded 498 System 15 360 0 OverwriteAsNeeded 625 Windows PowerShell [Administrator]

Вот так очень просто мы создали собственный источник событий (здесь не отображён) и свой собственный журнал событий! Причём, всё так же удалённо! Для удаления журнала и источника события необходимо использовать статические методы DeleteEventSource и Delete:

[System.Diagnostics.EventLog]::Delete("LogName")
[System.Diagnostics.EventLog]::DeleteEventSource("SourceName")

Чтобы управлять размером журнала нужно использовать свойство MaximumKilobytes. Увеличим размер журнала PowerShell CustomLog с 512 килобайт до 2-х мегабайт:

[Administrator] $EventLog = new-Object System.Diagnostics.Eventlog("PowerShell CustomLog","dc1") [Administrator] $EventLog.MaximumKilobytes = 2048 [Administrator] [System.Diagnostics.EventLog]::GetEventLogs("dc1") Max(K) Retain OverflowAction Entries Name ------ ------ -------------- ------- ---- 16 384 0 OverwriteAsNeeded 289 Application 512 0 OverwriteAsNeeded 45 Directory Service 512 7 OverwriteOlder 10 DNS Server 512 0 OverwriteAsNeeded 52 File Replication Service 2 048 7 OverwriteOlder 0 PowerShell CustomLog 131 072 0 OverwriteAsNeeded 12 369 Security 16 384 0 OverwriteAsNeeded 498 System 15 360 0 OverwriteAsNeeded 625 Windows PowerShell

Если сравнить 2 последних вывода, то заметим, что размер действительной изменился. Давайте запишем какое-нибудь событие в журнал. Для этого воспользуемся методом WriteEntry:

[Administrator] $EventLog.Source = "MySource"
[Administrator] $EventLog.WriteEntry("Hello World!", "Information")
[Administrator] $EventLog = new-Object System.Diagnostics.Eventlog("PowerShell CustomLog","dc1")
[Administrator] $EventLog.entries

Index Time          Type Source                EventID Message
----- ----          ---- ------                ------- -------
    1 Dec 08 22:55  Info MySource                    0 Hello World!


[Administrator]

Сперва мы указали источник события, потом применили метод WriteEntry, где ввели текст и тип события. Последней строкой мы убедились, что событие успешно записалось! Что касается типа события, то тут самому особо придумать ничего нельзя, потому что список типов жёстко регулируется:

[Administrator] [enum]::GetNames([System.Diagnostics.EventLogEntryType])
Error
Warning
Information
SuccessAudit
FailureAudit
[Administrator]

Чтобы очистить журнал от событий нужно использовать метод Clear:

$EventLog = New-Object System.Diagnostics.Eventlog("PowerShell CustomLog","dc1")
$EventLog.Clear()

И напоследок расскажу о действии при заполнении журнала. Для этого используется метод ModifyOverflowPolicy и метод может иметь следующие свойства:

MinimumRetentionDays (OverwriteOlder)
OverwriteAsNeeded
DoNotOverwrite

Эти свойства, думаю, в представлении не нуждаются, поэтому покажу примеры их использования:

$EventLog = New-Object System.Diagnostics.Eventlog("PowerShell CustomLog","dc1")
$EventLog.ModifyOverflowPolicy("OverwriteAsNeeded",$null)
$EventLog.ModifyOverflowPolicy("DoNotOverwrite",$null)
$EventLog.ModifyOverflowPolicy("OverwriteOlder",14)

К сожалению, средствами .NET невозможно архивировать журналы собитий, как это я описывал в предыдущей статье. Вот, вроде рассказал всё, что мне казалось интересным по этой теме. В следующий раз расскажу об управлении эвентлогом средствами WMI.

PowerShell Powered - http://www.sysadmins.lv

Архивирование и ротация журналов событий (EventLog) средствами PowerShell

Camelot — Thu, 04 Dec 2008 21:55:32 GMT

Снова навеяно темой на форуме TechNet-Ru. Уже не первый раз встречаю топики про архивирование журналов событий для последующего хранения в оффлайне. Безусловно не стоит пытаться скопировать .evt файл из папки Windows, поскольку файлы открыты и заблокированы (как и .pst файлы при запущенном MS Outlook). Для архивирования журнала скриптом нужно либо использовать Volume Shadow Copy либо использовать особые методы (например, вот так: http://support.microsoft.com/kb/312571). В качестве особых методов можно так же выделить использование WMI, которое позволяет решить поставленную задачу и добавит нам удалённой управляемости.

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

Задача: проводить с некоторой периодичностью архивацию журнала событий в файл. Убедиться, что бэкап сделан и после этого очистить журналы. В противном случае сделать что-нибудь другое.

За отправную точку возьмём класс Win32_NTEventlogFile. Давайте, вызовем его:

[vPodans] gwmi Win32_NTEventlogFile FileSize LogfileName Name -------- ----------- ---- 8458240 Application C:\Windows\System32\Winevt... 69632 DFS Replication C:\Windows\System32\Winevt... 69632 HardwareEvents C:\Windows\System32\Winevt... 69632 Internet Explorer C:\Windows\System32\Winevt... 69632 Key Management Service C:\Windows\System32\Winevt... 69632 ODiag C:\Windows\System32\Winevt... 1118208 OSession C:\Windows\System32\Winevt... 20975616 System C:\Windows\System32\Winevt... 11603968 Windows PowerShell C:\Windows\System32\Winevt... [vPodans]

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

[vPodans] gwmi Win32_NTEventlogFile | gm -MemberType method TypeName: System.Management.ManagementObject#root\cimv2\Win32_NTEventlogFile Name MemberType Definition ---- ---------- ---------- BackupEventlog Method System.Management.ManagementBaseObject BackupEventlog(System.String ArchiveFi... ChangeSecurityPermissions Method System.Management.ManagementBaseObject ChangeSecurityPermissions(System.Manag... ChangeSecurityPermissionsEx Method System.Management.ManagementBaseObject ChangeSecurityPermissionsEx(System.Man... ClearEventlog Method System.Management.ManagementBaseObject ClearEventlog(System.String ArchiveFil... Compress Method System.Management.ManagementBaseObject Compress() CompressEx Method System.Management.ManagementBaseObject CompressEx(System.String StartFileName... Copy Method System.Management.ManagementBaseObject Copy(System.String FileName) CopyEx Method System.Management.ManagementBaseObject CopyEx(System.String FileName, System.... DeleteEx Method System.Management.ManagementBaseObject DeleteEx(System.String StartFileName) GetEffectivePermission Method System.Management.ManagementBaseObject GetEffectivePermission(System.UInt32 P... Rename Method System.Management.ManagementBaseObject Rename(System.String FileName) TakeOwnerShip Method System.Management.ManagementBaseObject TakeOwnerShip() TakeOwnerShipEx Method System.Management.ManagementBaseObject TakeOwnerShipEx(System.String StartFil... Uncompress Method System.Management.ManagementBaseObject Uncompress() UncompressEx Method System.Management.ManagementBaseObject UncompressEx(System.String StartFileNa... [vPodans]

Здесь нас заинтересует 2 метода - BackupEventlog и ClearEventlog (там ещё есть ChangeSecurityPermissions - я бы не советовал с ним связываться ). В упрощённом варианте копирование и удаление будет сводиться к:

$LogName = "Application"
$Eventlog = gwmi Win32_NTEventlogFile -Filter "LogFileName = '$LogName'"
$Eventlog.BackupEventLog("F:\Eventlogs\$env:computername\$LogName" + "_" + "$(Get-Date -Format dd.MM.yyyy).evt")
$EventLog.Clear()

В данном случае с локальной машины заархивируем журнал Application в путь (после преобразований переменных) F:\Eventlogs\THOR\Application_04.12.2008.evt, после чего данный журнал будет очищен. Ничего сложного нету совсем. Разве что кроме одной детали. Такой фокус не получится с журналом Security, поскольку это жрунал аудита. И для очистки журнала потребуется право Manage auditing and security log привилегия SeAudit (в общем смысле это будет административная учётная запись). Поэтому перед использованием метода ClearEventlog нужно подключить эти самые привилегии:

$EventLog.PSBase.Scope.Options.EnablePrivileges = $true

вот и всё. Осталось только решить задачу ротации журналов (удалять все файлы, которые старше 365 дней или 1 года):

dir F:\Eventlogs\$env:computername -Recurse | ? {$_.lastwritetime -gt (Get-Date).AddDays(-365)} | del -Force

В качестве последнего штриха стоит оформить всё в красивый скрипт:

######################################################## # EventLog Backup Manager.ps1 # Version 1.0 # # Eventlog archiving script # # Vadims Podans (c) 2008 # http://www.sysadmins.lv/ ######################################################## function Backup-Eventlog { param ([string]$Computer) Begin { # разово получаем текущую дату в простом формате для пристыковки даты к имени файла $date = Get-Date -Format dd.MM.yyyy } Process { # получение списка всех журналов событий на текущем компьютере $Eventlog = gwmi Win32_NTEventlogFile -ComputerName $Computer $Eventlog | % { # косметическая переменная для вставки имени лога в текстовые сообщения $CurrentName = $_.LogFileName $CurrentLog = $_ # включение SeAudit привилегий $_.PSBase.Scope.Options.EnablePrivileges = $true # задаём путь, куда будут складываться архивы эвентлога $path = "\\BackupServer\Eventlogs\$computer\$CurrentName" + "_" + $date + ".evt" Write-Host "Processing $CurrentName log on $computer .." # непосредственно сам бэкап $Backup = $_.BackupEventLog($path) # проверка статуса бэкапа текущего журнала if ($Backup.ReturnValue -eq 0) { Write-Host "Success" # если бэкап прошёл успешно, то можно удалять записи в журнале и командлетом Out-Null
# подавляем ненужный вывод на экран $CurrentLog.ClearEventlog() | out-null } else { Write-Warning "Unexpected error occured. Operation aborted" } } } End { # эта часть обеспечивает удаление старых архивов и их ротацию после каждого запуска скрипта # стоит отметить, что данная секция выполняется только один раз и после проведения всей архивации Write-Host "Purging old archives .." dir \\BackupServer\Eventlogs\$computer -Recurse | ? {$_.lastwritetime -gt (Get-Date).AddDays(-365)} | del -Force } }

как бы и всё.

PowerShell Powered - http://www.sysadmins.lv

Пути к файлам и подстановочные знаки в PowerShell

Camelot — Tue, 02 Dec 2008 12:28:52 GMT

Из-за сильной занятости на работе в последнее время не получается уделять время блогу. Но сегодня выкроил немного времени и решил рассказать одну, на мой взгляд, интересную тему, которую каждый решает по-своему и не всегда очень удобным способом (о чём свидетельствует книга по PowerShell и ньюсгруппы). И на это есть весомые причины. А так же расскажу о весьма странном поведении ряда командлетов (на примере Get-Acl) при работе с файлами.

Давайте рассмотрим вопрос с начала и выйдем на нашу проблему. При поиске группы файлов PowerShell, как и многие другие командные оболочки, позволяет создавать маску поиска, как "*", "?". Безусловно с ними проблем быть не может, т.к. эти знаки в именах файлов встречаться не могут. Но если в имени файла используется символ открывающейся или закрывающейся квадратной скобки - "[" и "]", соответственно. Данные символы допустимы для именования файлов, но интерпретатор PowerShell их воспринимает как мета-символы подстановочного шаблона/маски, например:

[a-z]* - все объекты, которые начинаются с букв латинского алфавита
*[0-9] - все объекты, которые заканчиваются любой цифрой и т.д.

При этом встаёт вопрос, как сказать интерпретатору, что квадратная скобка в данном случае является литералом, а не мета-символ? Для начала я в папке создал 3 файла, 2 из которых содержат квадратные скобки:

[Folder] dir Directory: Microsoft.PowerShell.Core\FileSystem::D:\Users\_Shared Documents\Folder Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 02.12.08. 0:47 11 text.txt -a--- 02.12.08. 0:47 296 text[0].txt -a--- 02.12.08. 0:48 769 text[text.txt [Folder]

Давайте просмотрим содержимое файла text[text.txt:

[Folder] Get-Content text[text.txt
Get-Content : Cannot retrieve the dynamic parameters for the cmdlet. The specified wildcard pattern is not valid: text[
text.txt
At line:1 char:12
+ Get-Content  <<<< text[text.txt
[Folder]

занятно, не правда ли? Здесь мы столкнулись с проблемой, что интерпретатор PowerShell воспринял скобку в имени файла за мета-символ. Бороться с этим можно различными методами. Как вариант - использовать параметр -LiteralPath, что будет говорить интерпретатору о буквальном чтении пути. Проверим:

[Folder] Get-Content -LiteralPath text[text.txt Quest, Quest Software, the Quest Software logo, Aelita, Benchmark Factory, Big Brother, DataFactory, DeployDirector, ERDisk, Fastlane, Final, Foglight, Funnel Web, I/Watch, Imceda, InLook, InTrust, IT Dad, JClass, JProbe, LeccoTech, LiveReorg, NBSpool, NetBase, PerformaSure, PL/Vision, Quest Central, RAPS, SharePlex, Sitraka, SmartAlarm, Speed Change Manager, Speed Coefficient, Spotlight, SQL Firewall, SQL Impact, SQL LiteSpeed, SQL Navigator, SQLab, SQLab Tuner, SQLab Xpert, SQLGuardian, SQLProtector, SQL Watch, Stat, Stat!, Toad, T.O.A.D., Tag and Follow, Vintela, Virtual DBA, and XRT are trademarks and registered trademarks of Quest Software, Inc. Other trademarks and registered trademarks used in this guide are property of their respective owners. [Folder]

Как видите, мы получили содержимое файла (там отрывок из дисклаймера Quest Software). Однако, параметром -LiteralPath обладают далеко не все командлеты. Например, Get-Acl. У него нету такого параметра, поэтому получить ACL список такого файла будет очень проблематично. Посмотрим пример:

[Folder] Get-Item -LiteralPath text[text.txt


    Directory: Microsoft.PowerShell.Core\FileSystem::D:\Users\_Shared Documents\Folder


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         02.12.08.      0:59        769 text[text.txt


[Folder] Get-Item -LiteralPath text[text.txt | Get-Acl
Get-Acl : The specified wildcard pattern is not valid: text[text.txt
At line:1 char:45
+ Get-Item -LiteralPath text[text.txt | Get-Acl <<<<

Get-Item спокойно работает с LiteralPath, но при передаче его по конвейеру в командлет Get-Acl мы получаем ошибку. Хотя, по идее это должно было сработать. Кстати говоря, это первый обнаруженный недостаток. Вместо LiteralPath можно использовать 4 backtick (text````[text.txt), либо проще (что мне показалось более очевидным) - поместить литеральную скобку в подстановочный шаблон:

[Folder] Get-Item text````[text.txt Directory: Microsoft.PowerShell.Core\FileSystem::D:\Users\_Shared Documents\Folder Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 02.12.08. 0:59 769 text[text.txt [Folder] Get-Item text[[]text.txt Directory: Microsoft.PowerShell.Core\FileSystem::D:\Users\_Shared Documents\Folder Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 02.12.08. 0:59 769 text[text.txt [Folder]

В первом примере я использовал рецепт из книги Windows PowerShell In Action (страница 310), второй я додумал сам. Однако, оба эти приёма заменяют параметр -LiteralPath, но так же не решают проблемы командлетов, как Get-Acl. Если передавать эти объекты в Gat-Acl, то всё равно мы будем получать ошибки. Как вариант решения - использование промежуточной функции-фильтра (это рецепт решения Kiron из ньюсгрупп):

filter Escape-Bracket {
$_.psPath = $_.psPath -replace '\[|]','`$0'
$_
}

При использовании фильтра наш литеральный символ заменяем подстановочным знаком "?", пропускаем через фильтр и подаём на командлет Get-Acl:

[Folder] Get-Item text?text.txt | Escape-Bracket | Get-Acl | ft -a


    Directory: Microsoft.PowerShell.Core\FileSystem::D:\Users\_Shared Documents\Folder


Path          Owner        Access
----          -----        ------
text[text.txt Thor\vPodans Everyone Allow  FullControl...


[Folder]

Так оно работает. В качестве первого предположения я подумал на тип объектов:

[Folder] (Get-Item 'text[[]text.txt').GetType().fullname
System.IO.FileInfo
[Folder] (Get-Acl text.txt).GetType().fullname
System.Security.AccessControl.FileSecurity
[Folder]

Что при Get-Item мы получаем тип объектов FileInfo, который не содержит ACL, поэтому данный командлет передаёт в конвейер свойство PsPath, который уже Get-Acl использует для повторного извлечения уже ACL объекта.

Однако, я обратил внимание, что при использовании UNC путей вместо локальных промежуточная функция не требуется и вполне работает подстановочная маска заключённая в квадратные скобки:

[Folder] Get-Acl 'text[[]text.txt'
Get-Acl : The specified wildcard pattern is not valid: text[text.txt
At line:1 char:8
+ Get-Acl  <<<< 'text[[]text.txt'
[Folder] Get-Acl 'text[[]0[]].txt'
Get-Acl : Cannot find path 'D:\Users\_Shared Documents\Folder\text[0].txt' because it does not exist.
At line:1 char:8
+ Get-Acl  <<<< 'text[[]0[]].txt'
[Folder] Get-Acl '\\Thor\_Shared Documents\Folder\text[[]text.txt' | ft -a


    Directory: Microsoft.PowerShell.Core\FileSystem::\\Thor\_Shared Documents\Folder


Path          Owner        Access
----          -----        ------
text[text.txt Thor\vPodans Everyone Allow  FullControl...


[Folder] Get-Acl '\\Thor\_Shared Documents\Folder\text[[]0[]].txt' | ft -a


    Directory: Microsoft.PowerShell.Core\FileSystem::\\Thor\_Shared Documents\Folder


Path        Owner        Access
----        -----        ------
text[0].txt Thor\vPodans Everyone Allow  FullControl...


[Folder]

В первых двух командах я поместил квадратную скобку в подстановочный шаблон (заключил во внешние квадратные скобки) для локальных путей, а во втором - сделал то же самое, но для UNC пути. При этом, типы объектов не изменились:

[Folder] (Get-Item '\\thor\_Shared Documents\Folder\text[[]text.txt').gettype().fullname
System.IO.FileInfo
[Folder] (Get-Acl '\\thor\_Shared Documents\Folder\text[[]text.txt').gettype().fullname
System.Security.AccessControl.FileSecurity
[Folder]

Следовательно, моё предположение было неверным. Вполне возможно, что это баг командлетов, поэтому я на всякий случай запостил проблему на Connect'е:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=386138&SiteID=99

Желающие могут перейти по ссылке и подтвердить данную ошибку. Всем спасибо за участие :)

PowerShell Powered - http://www.sysadmins.lv

Управление принтерами в PowerShell (часть 3, заключительная)

Camelot — Sat, 22 Nov 2008 18:11:28 GMT

Вот и пришло время закрыть тему управления принтерами и их списками ACL в PowerShell с использованием WMI. Я в блоге уже расписывал решение частных задач по основным задачам управления принтеров и по управлению их ACL списками. В этом посте я сложу все наработки по этому вопросу в единый концептуальный скрипт, который будет называться PrinterUtils.ps1 с достаточно объёмным набором функций, которые нацелены на упрощение для администраторов автоматизации принтеров с использованием PowerShell. Если кто-то захочет разобраться в работе скрипта и понять используемые приёмы, то предлагаю ознакомиться с следующими ссылками:

В качестве основы я использовал свои предыдущие наработки с SecurityDescriptor в предыдущем блоге, когда разбирал вопрос управления SharePermissions из PowerShell:

Материала у меня на эту тему набралось достаточно много, чтобы проникнуться в идею работы классов WMI и SecurityDescriptor, который не раз пытался посадить меня в лужу :) Однако версия скрипта ShareUtils чётко говорит о том, что скрипт далеко не идеален и не оптимален, имеет свои недостатки, т.к. это был мой первый опыт работы с функциями. Сейчас я значительно переработал структуру работы скрипта (оставив только Core работы с SecurityDescriptor), добавив удалённое управление (в разумных пределах) и, главное (как мне кажется), реализовал работу функций в конвейере. Примеры использования скрипта распишу чуть ниже. Итак, представляю набор функций, которые реализованы в скрипте:

Подключение (маппинг) сетевого принтера к пользователю;
Отключение маппинга сетевого принтера от пользователя;
Получение сведений о принтерах;
Установка принтера по умолчанию;
Установка принтера для общего пользования (расшаривание принтера);
Отмена принтера для общего пользования;

Данная секция представляет собой базовые возможности по управлению принтерами и полностью работоспособна в среде Windows XP/Windows Server 2003. А вот секция управления ACL списками принтеров доступна только в среде Windows Vista/Windows Server 2008. Сюда входят следующие функции:

Получение сведений о правах доступа на конкретный принтер, конкретный принтсервер или по списку компьютеров;
Импорт сведений о правах доступа из внешнего источника. Это может быть и CSV и XML или другой формат;
Добавление пользователя или группы в ACL список принтера или всех принтеров, которые подключены к принтсерверу;
Удаление пользователя или группы из ACL списка принтера или всех принтеров, которые подключены к принтсерверу;
Установка пользователя или группы в ACL список принтера или всех принтеров, которые подключены к принтеру. При этом все имеющиеся права доступа будут удалены и заменены только одним ACE с правом ManagePrinters.

Для этих функций полностью реализована поддержка удалённой работы и работа в конвейере. Синтаксис команд используется примерно следующий:

New-NetworkPrinter -Computer <name> -name <name>
где Computer - имя компьютера, к которому подключён сетевой принтер
Name - сетевое имя принтера, который следует подключить к пользователю
Remove-NetworkPrinter -Name <name>
где Name - имя примапленного сетевого принтера (не обязательный параметр). Если параметр Name не указан, то будут отключены все примапленные сетевые принтеры.
Get-PrinterInfo -Computer <name> -Name <name>
где Computer - имя компьютера, к которому подключён принтер (не обязательный параметр. Если не указан, то будет использоваться локальная машина),
Name - имя принтера на удалённой или локальной машине, зависит от предыдущего параметра (не обязательный параметр. Если не указан, то будет выведена краткая справка о всех принтерах указанного компьютера. Если указан, то будет выведена подробная информация о принтере). Вывод данной команды не будет содержать сведений о правах доступа на принтер.
Set-DefaultPrinter -Name <name>
где Name - имя (или путь) принтера, который должен стать для пользователя принтером по умолчанию.
New-PrinterShare -Computer <name> -Name <name> -ShareName <name>
где Computer - имя компьютера, к которому подключён принтер (не обязательный параметр. Если не указан, будет использоваться локальная машина)
Name - имя принтера, который требуется предоставить для общего доступа
ShareName - сетевое имя принтера, т.е. имя, под которым принтер будет виден из сети
Remove-PrinterShare -Computer <name> -Name <name>
где Computer - имя компьютера, к которому подключён принтер (не обязательный параметр. Если не указан, будет использоваться локальная машина)
Name - имя принтера, для которого необходимо отключить общий доступ (не обязательный параметр. Если не указан, то общий доступ будет отменён для всех расшаренных принтеров на выбранном предыдущим параметром компьютере)
Get-Printer -Computer <name> -Name <name>
где Computer - имя компьютера, к которому подключён принтер (не обязательный параметр. Если не указан, будет использоваться локальная машина)
Name - имя принтера, для которого следует получить сведения о правах доступа (не обязательный параметр. Если не указан, то будут получены сведения об ACL всех принтеров на выбранном предыдущим параметром компьютере)
Генерирует на выходе массив объектов с необходимыми сведениями о каждом ACE. Данный массив можно использовать как для изменения прав доступа, так и просто для экспорта во внешний файл.
Set-Printer
не принимает никаких аргументов, а только получает данные по конвейеру. В качестве входных данных должны использоваться объекты, которые по свойствам соответствуют объектам, которые генерирует команда Get-Printer. Команда не может быть в начале строки, а только на выходе конвейера, с которого поступают объекты. Так же по конвейеру можно передавать объекты из внешних файлов (например, CSV, XML)
Add-PrinterPermission -User <name> -AceType <name> -AccessMask <name>
где User - имя пользователя/группы, которого следует добавить в ACL список принтера
AceType - тип доступа. Может быть Allow или Deny
AccessMask - маска доступа. Может иметь следующие значения: ManagePrinters, ManageDocuments, Print, TakeOwnership, ReadPermissions, ChangePermissions
Данная команда так же не может быть в начале строки, а должна находиться на выходе конвейера, с которого поступают объекты. В качестве входных данных должны использоваться объекты, которые по свойствам соответствуют объектам, которые генерирует команда Get-Printer. Команда не может быть в начале строки, а только на выходе конвейера, с которого поступают объекты. Так же по конвейеру можно передавать объекты из внешних файлов (например, CSV, XML)
Remove-PrinterPermission -User <name>
где User - имя пользователя/группы, которого следует удалить из списка ACL принтера
Данная команда так же не может быть в начале строки, а должна находиться на выходе конвейера, с которого поступают объекты. В качестве входных данных должны использоваться объекты, которые по свойствам соответствуют объектам, которые генерирует команда Get-Printer. Команда не может быть в начале строки, а только на выходе конвейера, с которого поступают объекты. Так же по конвейеру можно передавать объекты из внешних файлов (например, CSV, XML)
Set-PrinterPermission -User <name>
где User - имя пользователя/группы, для которого следует предоставить привилегированный доступ.
Важно: при использовании команды Set-PrinterPermission следует помнить, что указанный пользователь/группа будут иметь единственный доступ к принтеру с правом ManagePrinters. При этом вероятно, что вы после исполнения команды потеряете доступ к принтеру
Данная команда так же не может быть в начале строки, а должна находиться на выходе конвейера, с которого поступают объекты. В качестве входных данных должны использоваться объекты, которые по свойствам соответствуют объектам, которые генерирует команда Get-Printer.

Команда не может быть в начале строки, а только на выходе конвейера, с которого поступают объекты. Так же по конвейеру можно передавать объекты из внешних файлов (например, CSV, XML)

и несколько примеров использования:

Get-Printer PrintSrv "MyPrinter" | export-csv C:\LaserJet.csv - экспортирует ACL списки принтера MyPrinter в CSV файл

Get-Printer PrintSrv | Remove-PrinterPermission Everyone - удаляет группу Everyone из списков ACL всех принтеров сервера PrintSrv

Import-Clixml C:\Printers.xml | Set-Printer - восстанавливает права для принтеров на те, которые содержатся в XML файле. При этом текущие списки ACL указанных в файле принтеров будут полностью перезаписаны списком ACL из файла.

Get-Content C:\Computers.txt | %{Get-printer $_ | Add-Printerpermission NewPrinterWorkers Allow Print} - даёт право печати на всех принтерах, которые подключены к компьютерам из списка computers.txt

New-NetworkPrinter PrintSrv "HP LaserJet 2100" - подключает пользователю в контексте котрого исполняется скрипт сетевой принтер HP LaserJet 2100, который физически подключен к компьютеру PrintSrv

Это далеко не все варианты использования :) Вобщем, я старался создать достаточно широким функционалом, который обычно требуется в скриптах для принтменеджмента. Безусловно, он не охватывает все задачи и в нём реализованы только те функции, которые я посчитал актуальными. А вот, собственно и скрипт с небольшими комментариями по ходу дела:

########################################################
# PrinterUtils.ps1
# Version 0.1.0.0
#
# Functions for advanced printer management
#
# Vadims Podans (c) 2008
# http://www.sysadmins.lv/
########################################################
# внутренняя функция, которая преобразовывает числовой код возврата операции записи ACL
# в текстовое значение.
function _PrinterUtils_Get-Code ($Write) {
switch ($Write.ReturnValue) {
   "0" {"Success"}
   "2" {"Access Denied"}
   "8" {"Unknown Error"}
   "9" {"The user does not have adequate privileges to execute the method"}
   "21" {"A parameter specified in the method call is invalid"}
   default {"Unknown error $Write.ReturnValue"}
   }
}
# функция получения списка (списков) ACL принтера или всех принтеров
function Get-Printer ($Computer = ".", $name) {
# Если переменная $name пустая, то возвращается список всех локальных принтеров
if ($name) {
    $Printers = gwmi Win32_Printer -ComputerName $Computer -Filter "name = '$name'"
    } else {
        $Printers = gwmi Win32_Printer -ComputerName $Computer -Filter "local = '$True'"
    }
# объявление массива списков ACL
$PrinterInfo = @()
# извлечение списка ACL из каждого элемента массива списков ACL
foreach ($Printer in $Printers) {
    if ($printer) {
# в переменную $SD получаем дескриптор безопасности для каждого принтера и каждый элемент ACE (DACL)
# и добавляем в $PrinterInfo
        $SD = $Printer.GetSecurityDescriptor()
        $PrinterInfo += $SD.Descriptor.DACL | %{
            $_ | Select @{e = {$Printer.SystemName}; n = 'Computer'},
            @{e = {$Printer.name}; n = 'Name'},
            AccessMask,
            AceFlags,
            AceType,
            @{e = {$_.trustee.Name}; n = 'User'},
            @{e = {$_.trustee.Domain}; n = 'Domain'},
            @{e = {$_.trustee.SIDString}; n = 'SID'}
            }
        } else {
            Write-Warning "Specified printer not found!"
        }
    }
# выдача сведений об ACL на выход функции для последующей подачи на конвейер
$PrinterInfo
}
# функция записи в ACL принтера. Она не принимает никаких аргументов,
# а только принимает данные с конвейера
function Set-Printer {
# по конвейеру получаем массив ACE из внешнего источника
$PrinterInfo = @($input)
# расшиваем полученный массив по имени принтера и дальше по циклу подаём на
# обработку только ACL одного принтера
$PrinterInfo | Select -Unique Computer, Name | % {
    $Computer = $_.Computer
    $name = $_.name
# создаём новые объекты необходимых классов
    $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
      $ace = ([WMIClass] "Win32_Ace").CreateInstance()
      $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
# теперь расшиваем каждый ACE уже отфильтрованного списка ACL из PrinterInfo и
# заполняем форму SecurityDescriptor
    $PrinterInfo | ? {$_.Computer -eq $Computer -and $_.name -eq $name} | % {
        $SID = new-object security.principal.securityidentifier($_.SID)
        [byte[]] $SIDArray = ,0 * $SID.BinaryLength
        $SID.GetBinaryForm($SIDArray,0)
        $Trustee.Name = $_.user
        $Trustee.SID = $SIDArray
        $ace.AccessMask = $_.AccessMask
        $ace.AceType = $_.AceType
        $ace.AceFlags = $_.AceFlags
        $ace.trustee = $Trustee
# набор ACE поэтапно добавляем в DACL дескриптора безопасности
        $SD.DACL += @($ace.psobject.baseobject)
# устанавливаем флаг SE_DACL_PRESENT, что будет говорить о том, что мы изменяем
# только DACL и ничего более
        $SD.ControlFlags = 0x0004
        }
# когда полный список ACL для текущего принтера собран, выбираем имя текущего принтера
    $Printer = gwmi Win32_Printer -ComputerName $Computer -Filter "name = '$name'"
# проверяется, что принтер для записи ACL найден и производится запись.
# В противном случае запись ACL пропускается
    if ($Printer) {
        $Write = $Printer.SetSecurityDescriptor($SD)
        Write-Host "Processing current printer: $name"
        _PrinterUtils_Get-Code $Write
    } else {
        Write-Warning "Skipping non-present printer: $name"
        }
    }
}
# внутренняя функция, которая только формирует объект пользователя с набором прав
# и возвращает объект в вызывающую функцию для последующих преобразований
function _Create-SDObject ( $user, $AceType, $AccessMask) {
# преобразование текстового вида прав в числовые значения
$masks = @{ManagePrinters = 983052; ManageDocuments = 983088; Print = 131080;
TakeOwnership = 524288; ReadPermissions = 131072; ChangePermissions = 262144}
$types = @{Allow = 0; Deny = 1}
# создание необходимых свойств для объекта. Для поддержки удалённого управления
# было добавлено свойство Computer, которое будет принимать от Get-Printer аналогичное
# значение. Тем самым обеспечивается сквозная трансляция имени компьютера, где
# подключен принтер, по конвейеру для последующей записи
$AddInfo = New-Object System.Management.Automation.PSObject
$AddInfo | Add-Member NoteProperty Computer ([PSObject]$null)
$AddInfo | Add-Member NoteProperty Name ([PSObject]$null)
$AddInfo | Add-Member NoteProperty AccessMask ([uint32]$null)
$AddInfo | Add-Member NoteProperty AceFlags ([uint32]$null)
$AddInfo | Add-Member NoteProperty AceType ([uint32]$null)
$AddInfo | Add-Member NoteProperty User ([PSObject]$null)
$AddInfo | Add-Member NoteProperty Domain ([PSObject]$null)
$AddInfo | Add-Member NoteProperty SID ([PSObject]$null)
# заполнение объекта данными, которые были указаны в качестве аргументов вызова функции и возврат
# объекта в вызывающую функцию
$AddInfo.Name = $name
$AddInfo.User = $user
$AddInfo.SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
$AddInfo.AccessMask = $masks.$AccessMask
$AddInfo.AceType = $types.$AceType
$AddInfo
}
# функция для установки разрешений на принтер. При её использовании, текущий ACL очищается
# от всех записей и устанавливается только один ползователь/группа с правом ManagePrinters
function Set-PrinterPermission ($user) {
# принимаются данные с конвейера
$PrinterInfo = @($input)
$AddInfo = _Create-SDObject $user Allow ManagePrinters
# в этом цикле перебираются по именам все имена принтеров и для каждого из них
# записывается указанный в аргументах пользователь с удалением текущих ACE из ACL принтера
# это видно по тому, что никакая часть $PrinterInfo не передаётся по конвейеру на запись
foreach ($Printer in ($PrinterInfo | select -Unique Computer, Name)) {
$AddInfo.Computer = $Printer.Computer
$AddInfo.Name = $Printer.name
$AddInfo | Set-Printer
    }
}
# функция добавления пользователя/группу в имеющийся список ACL принтера. Основное отличие от
# предыдущего варианта, что для каждого принтера ACE не устанавливается, а добавляется
function Add-PrinterPermission ($user, $AceType, $AccessMask) {
$PrinterInfo = @($input)
$AddInfo = _Create-SDObject $user $AceType $AccessMask
foreach ($Printer in ($PrinterInfo | select -Unique Computer, Name)) {
$AddInfo.Name = $Printer.name
$AddInfo.Computer = $Printer.Computer
# вот этой строкой мы из списка всех принтеров итеративно перебираем каждый принтер
$PrinterInfoNew = $PrinterInfo | ?{$_.name -eq $Printer.name}
# и в хвост списка ACL добавляем новый ACE
$PrinterInfoNew += $AddInfo
# и подаём на запись
$PrinterInfoNew | Set-Printer
    }
}
# функция для удаления ACE пользователя/группы из ACL
function Remove-PrinterPermission ($user) {
$Printers = @($input)
# просто берём списки ACL, которые пришли по конвейеру и выкидываем оттуда все ACE,
# в которых фигурирует указанный в аргументах пользователь/группа и записывем ACE обратно в ACL
$printers | ? {$_.user -ne $user} | Set-Printer
}
function New-NetworkPrinter ($Computer, $name) {
([wmiclass]'Win32_Printer').AddPrinterConnection("\\$Computer\$name")
}
function Remove-NetworkPrinter ($name) {
if ($name) {
    (gwmi Win32_Printer -Filter "sharename='$name'").delete()
    } else {
        (gwmi Win32_Printer -Filter "local='$false'").delete()
    }
}
function Set-DefaultPrinter ($name) {
if (!$name) {
    Write-Warning "You must to specify printer name. Operation aborted!"
    } else {
        if (gwmi win32_Printer -Filter "name='$name'") {
            $SetDefault = (gwmi win32_Printer -Filter "name='$name'").SetDefaultPrinter()
            switch ($SetDefault.ReturnValue) {
                "0" {Write-Host "Now your default printer is $name"}
                default {Write-Warning "Some error occur"}
            }
        } else {
            Write-Warning "Specified printer not exist!"
            }
    }
}
function Get-PrinterInfo ($Computer = ".", $name) {
# здесь я предлагаю получить как полный набор свойств, так и упрощённый вывод сведений.
if ($name) {
    gwmi Win32_Printer -ComputerName $Computer -Filter "name='$name'" | select *
    } else {
        gwmi Win32_Printer -ComputerName $Computer
    }
}
function New-PrinterShare ($Computer = ".", $name, $ShareName) {
$Printer = gwmi win32_Printer -ComputerName $Computer -Filter "name='$name'"
if ($Printer) {
    $Printer.shared = $True
    $Printer.ShareName = $ShareName
    $Printer.put()
    } else {
        Write-Warning "Specified printer not exist!"
    }
}
function Remove-PrinterShare ($Computer = ".", $name) {
if ($name) {
    $filter = "name = '$name'"
    } else {
    $filter = "local = '$false'"
    }
gwmi Win32_Printer -ComputerName $Computer -Filter $filter | % {
    $_.shared = $false
    $_.put()
    }
}

многовато, конечно же, но ничего космически сложного для разбора я тут не вижу. Главное - чёткое понимание структуры SecurityDescriptor и хотя бы базовые навыки работы с ним.

Важно: если не указываете необязательные параметры, то указание последующих параметров в виде именованных (не позиционных) обязательна!

Даже не знаю, что ещё добавить сюда. Вроде все вопросы разобрал ранее, сейчас просто это всё собрал воедино. Вобщем, как обычно, если есть вопросы, замечания - кнопка Comments вам в помощь

PowerShell Powered - http://www.sysadmins.lv

Странности метода SetSecurityDescriptor класса Win32_Printer (часть 2)

Camelot — Wed, 19 Nov 2008 16:36:47 GMT

Итак, как я и обещал, я вернулся к вопросу изменения ACL принтеров в PowerShell. В первой части (Странности метода SetSecurityDescriptor класса Win32_Printer) я изложил проблематику вопроса. В конечном итоге я сегодня смог найти решение, которое оказалось не совсем понятным, но относительно предсказуемым.

Вернёмся снова к документации MSDN: SetSecurityDescriptor Method of the Win32_Printer Class

Это, конечно же, было моим попустительством, что не указал флаг управления SE_DACL_PRESENT и не включил привилегии SeSecurityPrivilege ("умение читать - первое умение системного администратора" (c) Peter.G). Понимание этого факта пришло после очередного прочтения поста о смене владельца папки (Смена владельца папки или файла в PowerShell (часть 2)). Что касается флагов управления, то выложу здесь значения флагов:

SE_OWNER_DEFAULTED = 0x0001
SE_GROUP_DEFAULTED = 0x0002
SE_DACL_PRESENT = 0x0004
SE_DACL_DEFAULTED = 0x0008
SE_SACL_PRESENT = 0x0010
SE_SACL_DEFAULTED = 0x0020
SE_DACL_AUTO_INHERIT_REQ = 0x0100
SE_SACL_AUTO_INHERIT_REQ =0x0200
SE_DACL_AUTO_INHERITED = 0x0400
SE_SACL_AUTO_INHERITED = 0x0800
SE_DACL_PROTECTED = 0x1000
SE_SACL_PROTECTED = 0x2000
SE_RM_CONTROL_VALID = 0x4000
SE_SELF_RELATIVE = 0x8000

Здесь я выделил жирным тот флаг, который нам нужен.

Добавим эту строчку к скрипту и добавим включение привилегий. И мы должны будем получить примерно такой скрипт:

$user = "everyone"
$SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
$ace = ([WMIClass] "Win32_Ace").CreateInstance()
$Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
$SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[byte[]] $SIDArray = ,0 * $SID.BinaryLength
$SID.GetBinaryForm($SIDArray,0)
$Trustee.Name = $user
$Trustee.SID = $SIDArray
$ace.AccessMask = 393224
$ace.AceType = 0
$ace.AceFlags = 0
$ace.Trustee = $Trustee
$SD.DACL = $ace
$SD.ControlFlags = 0x0004
$Printer = gwmi win32_printer -filter "name='CutePDF Writer'"
$Printer.psbase.Scope.Options.EnablePrivileges = $true
$inParams = $Printer.psbase.GetMethodParameters("SetSecurityDescriptor")
$inParams.Descriptor = $SD
$Printer.SetSecurityDescriptor($inParams)

Пробуем запустить его:


[System32] $user = "everyone"
[System32] $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
[System32] $ace = ([WMIClass] "Win32_Ace").CreateInstance()
[System32] $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
[System32] $SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[System32] [byte[]] $SIDArray = ,0 * $SID.BinaryLength
[System32] $SID.GetBinaryForm($SIDArray,0)
[System32] $Trustee.Name = $user
[System32] $Trustee.SID = $SIDArray
[System32] $ace.AccessMask = 393224
[System32] $ace.AceType = 0
[System32] $ace.AceFlags = 0
[System32] $ace.Trustee = $Trustee
[System32] $SD.DACL = $ace
[System32] $SD.ControlFlags = 0x0004
[System32] $Printer = gwmi win32_printer -filter "name='CutePDF Writer'"
[System32] $Printer.psbase.Scope.Options.EnablePrivileges = $true
[System32] $inParams = $Printer.psbase.GetMethodParameters("SetSecurityDescriptor")
[System32] $inParams.Descriptor = $SD
[System32] $Printer.SetSecurityDescriptor($inParams)


__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 1
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ReturnValue      : 2147749896



[System32]

И снова мы получаем ошибку, которая указывает, что какой-то параметр вызова неверный. Снова посмотрев предыдущую статью, я стал понимать в чём тут дело. А дело в том, что метод SetSecurityDescriptor в этом классе не принимает параметр Descriptor (хотя он есть в выдаче команды GetSecurityDescriptor) и в MSDN чётко указано:

uint32 SetSecurityDescriptor(
[in] Win32_SecurityDescriptor Descriptor

);

При этом, в методе SetShareInfo класса Win32_Share параметр Access я указывал и всё проходило на "ура". Здесь мы сталкиваемся с отсутствием единого формата использования метода SetSecurityDescriptor (отсутствие единого формата параметров я уже указывал в первой части) для различных WMI классов. И если один приём работает для одного класса, то, увы, далеко не гарантия, что этот же приём сработает для другого. Поэтому выкинем 2 предпоследние строчки из скрипта и в последней строке вместо аргумента $inParams заменим на $SD:

[System32] $user = "everyone"
[System32] $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
[System32] $ace = ([WMIClass] "Win32_Ace").CreateInstance()
[System32] $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
[System32] $SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[System32] [byte[]] $SIDArray = ,0 * $SID.BinaryLength
[System32] $SID.GetBinaryForm($SIDArray,0)
[System32] $Trustee.Name = $user
[System32] $Trustee.SID = $SIDArray
[System32] $ace.AccessMask = 393224
[System32] $ace.AceType = 0
[System32] $ace.AceFlags = 0
[System32] $ace.Trustee = $Trustee
[System32] $SD.DACL = $ace
[System32] $SD.ControlFlags = 0x0004
[System32] $Printer = gwmi win32_printer -filter "name='CutePDF Writer'"
[System32] $Printer.psbase.Scope.Options.EnablePrivileges = $true
[System32] $Printer.SetSecurityDescriptor($SD)


__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 1
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ReturnValue      : 0



[System32]

Вуаля! Мы получили ReturnValue=0, что означает успешное выполнение команды. Давайте убедимся, что группа Everyone имеет маску доступа 393224 (это ReadPermissions, ChangePermissions и Print). Для этого снова вызовем метод GetSecurityDescriptor для нового образца класса Win32_Printer:

[System32] $a = (gwmi win32_Printer -filter "name='cutepdf writer'").getsecuritydescriptor() [System32] $a.descriptor.dacl[0] __GENUS : 2 __CLASS : Win32_ACE __SUPERCLASS : __ACE __DYNASTY : __SecurityRelatedClass __RELPATH : __PROPERTY_COUNT : 7 __DERIVATION : {__ACE, __SecurityRelatedClass} __SERVER : __NAMESPACE : __PATH : AccessMask : 393224 AceFlags : 0 AceType : 0 GuidInheritedObjectType : GuidObjectType : TIME_CREATED : Trustee : System.Management.ManagementBaseObject [System32] $a.descriptor.dacl[0].trustee __GENUS : 2 __CLASS : Win32_Trustee __SUPERCLASS : __Trustee __DYNASTY : __SecurityRelatedClass __RELPATH : __PROPERTY_COUNT : 6 __DERIVATION : {__Trustee, __SecurityRelatedClass} __SERVER : __NAMESPACE : __PATH : Domain : Name : Everyone SID : {1, 1, 0, 0...} SidLength : 12 SIDString : S-1-1-0 TIME_CREATED : [System32]

Вот теперь мы видим нашу маску доступа (AccessMask=393224) в корне DACL и нашего уважаемого everyone в Trustee.

Примечание: данный скрипт удаляет все имеющиеся ACE из ACL принтера и записывает новый единственный ACE. Не забывайте об этом.

Теперь я закрываю этот вопрос. Что же дальше? А дальше будет вот что: я напишу готовый набор функций для управления ACL списками принтеров. Какой это будет набор - я пока в процессе разработки его структуры, но однозначно будут функции вида Get- Set- Add- Remove- PrinterPermission. Возможно будут добавлены функции для владельцев. Но об этом уже в следующий раз, так что продолжение следует однозначно

PowerShell Powered - http://www.sysadmins.lv

Смена владельца папки или файла в PowerShell (часть 2)

Camelot — Mon, 17 Nov 2008 00:19:53 GMT

Как-то давно Александр Станкевич просил у меня вариант скрипта, который бы менял владельца файла или папки из PowerShell. В своё время я занимался этим вопросом и результат моих исследований:

Что-то меня натолкнуло снова вернуться к этому вопросу. Учитывая проблематику, изложенных в предыдущих статьях, я перестал искать нативный способ изменения владельца в PowerShell через .NET и решил поискать его в WMI (что означает очередные мучения многострадального SecurityDescriptor ). Итак, у WMI есть несколько классов для работы с ACL (AccessControlList) файлов и папок. Например:

Я для решения данной задачи решил использовать класс Win32_LogicalFileSecuritySetting (хотя, можно и Win32_Directory использовать но после мелкой доработки. Но об этом я выскажусь в конце статьи).

Итак, класс Win32_LogicalFileSecuritySetting имеет те же методы, что и остальные классы, работающие со списками ACL - GetSecurityDescriptor и SetSecurityDescriptor. Я уже неоднократно поднимал вопрос работы с SecurityDescriptor в PowerShell, поэтому приступим сразу к решению задачи.

Как видно из картинки, нас будет интересовать объект Owner и ControlFlags. Объект DACL нас не будет интересовать совсем, поэтому работать с Win32_Ace нам не придётся, а только с Trustee:

$SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
$Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()

Далее следует стандартная процедура преобразования имени пользователя в SID и получение байтового массива из SID'а:

$SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[byte[]] $SIDArray = ,0 * $SID.BinaryLength
$SID.GetBinaryForm($SIDArray,0)

Теперь $SIDArray и имя пользователя запишем в Trustee и поместим этот объект в свойство Owner дескриптора безопасности:

$Trustee.Name = $user
$Trustee.SID = $SIDArray
$SD.Owner = $Trustee

Для того, чтобы заменить владельца папки нужно заполнить объект Control Flags, которые описаны здесь: http://msdn.microsoft.com/en-us/library/aa394402(VS.85).aspx. Не уверен, что стоит углубляться в этот момент (на практике очень редко приходится им пользоваться), поэтому скажу, что нас заинтересует флаг SE_SELF_RELATIVE. Заполняется он одной строчкой:

$SD.ControlFlags="0x8000"

Его можно записывать как десятичное число (32768), так и в HEX нотации. Я использую HEX. Вот и всё, дескриптор безопасности у нас готов. Теперь самое время получить ACL в формате SecurityDescriptor из имеющейся папки:

$wPrivilege = gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"

Вот теперь мы вплотную подошли к нашей проблеме. К слову говоря, если этот скрипт использовать в Windows Vista/Windows Server 2008 с повышенными привилегиями (запустив консоль в привилегированном режиме), то можно добавлять последнюю строчку с записью нового владельца в папку. В системах, где есть UAC нету такой проблемы, которая описана в ссылках, которые приведены в начале поста, поскольку при запуске консоли с повышенными привилегиями UAC включает для нас все необходимые привилегии (в частности SeRestorePrivilege и SeTakeOwnershipPrivilege, которые необходимы для этой операции). Но в более ранних ОС при запуске консоли PowerShell эти права не включаются и их нужно включать отдельно. Если в .NET нету нативного метода включения этих привилегий, то в WMI они есть и вот они:

$wPrivilege.psbase.Scope.Options.EnablePrivileges = $true

В Options помимо включения привилегий можно указывать имперсонализацию пользователя (Impersonate) и другие параметры. Чтобы посмотреть доступные свойства достаточно набрать в консоли:

$wPrivilege.psbase.scope.options | Get-Member

Когда привилегии включены, можно уже записывать дескриптор в папку при помощи метода SetSecurityDescriptor:

$wPrivilege.setsecuritydescriptor($SD)

Если имя папки указано верно, то в выводе ReturnValue должен вернуть значение 0, что означает, что владелец сменён! и мы небольшим (но для PowerShell'а это уже много, учитывая что многие вещи в нём делаются в одну строчку ) увеличением объёма кода можем полноценно изменять владельца файла или папки без установки дополнительных расширений, как PSCX или отдельных консольных утилит, как SubInAcl или SetAcl.

Теперь это всё окультурим в готовый скрипт:

function Set-Owner ($user, $Path) {
    if (!(Test-Path -LiteralPath $Path)) {Write-Warning "Указан неверный путь к папке"}
    else {
        # преобразовываем путь вида C:\Folder в C:\\Folder (к слешу пути добавляем ещё один
        # для корректной работы класса Win32_LogicalFileSecuritySetting и эскейпим другие символы
        $path = $path -replace "\\|'",'\$0'
        $Path = $Path -replace '\[', "$([char]91)"
        $Path = $Path -replace '\]', "$([char]93)"
        # т.к. DACL мы не записываем, то объявляем только классы SecurityDescriptor и Trustee
        $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
        $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
        # преобразовываем имя пользователя в SID и заполняем необходимые поля в Trustee
        $SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
        [byte[]] $SIDArray = ,0 * $SID.BinaryLength
        $SID.GetBinaryForm($SIDArray,0)
        $Trustee.Name = $user
        $Trustee.SID = $SIDArray
        $SD.Owner = $Trustee
        # здесь мы добавляем флаг управления
        $SD.ControlFlags="0x8000"
        # выбираем сведения о безопасности необходимой папки
        $wPrivilege = gwmi Win32_LogicalFileSecuritySetting -filter "path='$path'"
        # включаем привилегия для WMI. Для Windows Vista/Windows Server 2008,
        # при запуске скрипта с повышенными привилегиями данная строка не обязательна
        $wPrivilege.psbase.Scope.Options.EnablePrivileges = $true
        # записываем SecurityDescriptor с новым владельцем в папку
        $Return = $wPrivilege.setsecuritydescriptor($SD)
        # преобразовываем возвращаемый код в текстовое значение
        switch ($Return.ReturnValue) {
            "0" {"Успешно"}
            "2" {Write-Warning "Отказано в доступе"}
            "8" {Write-Warning "Неизвестная ошибка"}
            "9" {Write-Warning "Отсутствуют привилегии"}
            "21" {Write-Warning "Указан неправильный параметр"}
            "1307" {Write-Warning "Указанный пользователь не может быть владельцем данного объекта"}
            default {Write-Warning "Произошла неизвестная ошибка с кодом:" $Return.Value}
        }
    }
}

# эта часть совсем необязательна, я её включил лишь для наглядности 
# и полноты скрипта 
function Get-Owner ($path) {(Get-Acl $path).owner}

1 PS1 file
8,62 KB Download File.ps1

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

и немного о стандартности использования методов SetSecurityDescriptor для различных объектов. Мне не понятно, почему в различных классах WMI используются различные именования свойств дескриптора безопасности, когда в этом явных причин нету? Например:

Win32_Share для дескриптора использует свойство Access метода SetShareInfo
Win32_Printer использует свойство Descriptor метода SetSecurityDescriptor
Win32_Directory использует SecurityDescriptor метода SetSecurityDescriptor (и для SetSecurityDescrptorEx)
Win32_LogicalFileSecuritySetting использует Descriptor метода SetSecurityDescriptor

Вот 4 WMI класса управления ACL списками различных объектов, с которыми я недавно работал и имеем 3 различных именования свойства дескриптора безопасности и Win32_Share использует даже другое название метода (SetShareInfo), хотя этот метод использует тот же Win32_SecurityDescriptor. Но это уже оффтопик и личные размышления. Вот :)

PowerShell Powered - http://www.sysadmins.lv

Аудит доступа к файловым ресурсам в PowerShell

Camelot — Sat, 15 Nov 2008 22:17:15 GMT

Навеяно темой на форуме: http://forum.sysfaq.ru/index.php?showtopic=13274

Итак, есть задача отслеживать события удаления объектов (файлов и/или папок) с файлового сервера. Итак, для начала необходимо настроить аудит на файловом сервере. Приведу рекомендации коллеги WindowsNT:

Включить аудит успешных событий типа Object Access.
Отрегулировать размер журнала и параметры перезаписи.
В свойствах папки Shared Documents (и других папок общего доступа) включить Аудит на Успешные Everyone: Delete, Delete Subfolders and Files.

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

Итак, задача разбивается на 4 составные части:

получение всех эвентов с кодом EventID = 560;
из полученных эвентов получить массив с уникальным временем;
подсчитать количество эвентов для каждого уникального времени из массива, который был получен на втором этапе;
если кол-во эвентов больше или равно 5 (цифра может быть и немного другой), то записываем их в лог и отмечаем, как "возможно нелегальное".

Итак, давайте пробовать решить все этапы:

1) получение массива эвентов по коду 560:

$Events = Get-EventLog security | ?{$_.eventid -eq 560 -and
    $_.EntryType -eq "SuccessAudit" -and
    $_.message -like "*Object Name:`tD:\Shared Documents\*" -and
    $_.message -like "*Accesses:`t%delete*"
}

Итак, здесь я сделал 3 фильтра: код события - 560, Тип аудита Success Audit (т.к. под кодом 560 регистрируются и неуспешные аудиты), имя корневой папки, которая нас будет интересовать (только для случаев, если настроено несколько аудитов на различных папках) и явно будем интересоваться действием $Delete. Теперь из этого массива нужно получить массив уникального времени:

$UniqueTime = $Events | select -Unique TimeGenerated | %{($_.timegenerated).datetime}

Здесь я получил массив с набором уникального времени. Отмечу, что я взял свойство DateTime, которое даст нам точность до 1 секунды. Массив мы делаем затем, чтобы потом считать сколько событий удаления зафиксировано с этим временем (отличить легальное удаление от нелегального). Теперь при помощи полученной переменной соберём кол-во эвентов удаления на момент уникального времени. Иными словами мы берём отметку времени, когда зафиксирован лог удаления файла или папки и посмотрим, сколько ещё логов было зафиксировано за эту секунду:

[object[]]$SelectedEvents = $Events | ?{($_.timegenerated).datetime -eq UniqueTime}
$SelectedEvents.count

Переменная $SelectedEvents будет содержать все эвенты удаления в течении секунды. И их количество можно посчитать свойством Count. И дальше можно проводить сравнительный анализ по кол-ву эвентов. Если их за секунду зафиксировано больше 5 (вероятность нелегального удаления файлов), то продолжаем разбирать переменную $SelectedEvents. Разбирается скрипт по той же схеме, что и в упомянутой выше статье по аудиту доступа на терминальный сервер. В итоге мы получим такой скрипт:

########################################################
# FileServerDeleteAudit.ps1
# Version 1.0
#
# Windows Server 2003 eventlog parser
#
# Vadims Podans (c) 2008
# http://www.sysadmins.lv/
########################################################

$Data = New-Object System.Management.Automation.PSObject
$Data | Add-Member NoteProperty Time ($null)
$Data | Add-Member NoteProperty UserName ($null)
$Data | Add-Member NoteProperty FileName ($null)
$Data | Add-Member NoteProperty EventCount ($null)
$Events = Get-EventLog security | ?{$_.eventid -eq 560 -and
    $_.EntryType -eq "SuccessAudit" -and
    $_.message -like "*Object Name:`tD:\Shared Documents\*" -and
    $_.message -like "*Accesses:`t%delete*"
}
$UniqueTime = $Events | select -Unique TimeGenerated | %{($_.timegenerated).datetime}
foreach ($time in $UniqueTime) {[object[]]$SelectedEvents = $Events | ?{($_.timegenerated).datetime -eq $time}
    if ($SelectedEvents.count -ge 5) {
    $Data.EventCount = $SelectedEvents.Count
    $SelectedEvents | %{
    $message = $_.message.split("`n") |    %{$_.trim()}
    $Data.time = $_.TimeGenerated
    if ($message -like "Primary User Name:`t*$") {
        $Data.UserName = ($message | ?{$_ -like "Client User Name:*"} | %{$_ -replace "^.+`t *"})}
    else {
        $Data.UserName = ($message | ?{$_ -like "Primary User Name:*"} | %{$_ -replace "^.+`t *"})}
    $Data.FileName = ($message | ?{$_ -like "Object Name:*"} | %{$_ -replace "^.+`t *"})
    $Data
        }
    }
}

Что касается поля $Data.UserName, то здесь я сделал проверку поля Primary User Name. Если файл или папка были удалены с компьютера локально, то данное поле заполняется именем пользователя. Если же файл или папку удалили по сети, то в данном поле будет указано имя компьютера в формате ComputerName$, а имя пользователя будет отражено в поле Client User Name. Поэтому если в поле Primary User Name будет встречаться знак доллара ($), то мы в поле $Data.UserName записываем имя пользователя из поля эвентлога Client User Name. Жирным в скрипте я отметил те места, которые в зависимости от местных условий могут изменяться. В первом случае отмечена корневая папка, которая будет изучаться и кол-во инцидентов удаления в секунду описывает порог срабатывания скрипта. И результат работы скрипта:

Time UserName FileName EventCount ---- -------- -------- ---------- 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\AR 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\BG 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\DA 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140 2008.11.15. 23:33:44 Administrator C:\New Folder\dasblog\bin\... 140

Enjoy!

PowerShell Powered - http://www.sysadmins.lv

Странности метода SetSecurityDescriptor класса Win32_Printer (часть 1)

Camelot — Fri, 14 Nov 2008 19:21:45 GMT

В первой и второй части я рассказал про основные моменты управления принтерами в PowerShell и теперь хочу поговорить о правах на принтеры. Т.к. принтеры управляются с помощью классов WMI, то управление правами доступа к ним будет превращаться в очередную эпохальную эпопею, которую я исследовал при изучении безопасности Share Permissions (вот ссылка на эти статьи в моём прежнем блоге: http://vpodans.spaces.live.com/lists/cns!BB1419A2CFC1E008!178). Однако, с принтерами оказалось всё печальней Мне так и не удалось заставить работать метод SetSecurityDescriptor. Итак, я расскажу о своих кратких исследованиях и в чём же мы имеем проблему.

Для чтения прав доступа принтера потребуется метод GetSecurityDescriptor:

[System32] $a=(gwmi win32_printer -filter "name='cutepdf writer'").getsecuritydescriptor()
[System32] $a 

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 2
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
Descriptor       : System.Management.ManagementBaseObject
ReturnValue      : 0 


[System32] $a.Descriptor | fl [a-z]* 

ControlFlags     : 32780
DACL             : {System.Management.ManagementBaseObject, System.Management.ManagementBaseObject,System.Mana
gement.ManagementBaseObject, System.Management.ManagementBaseObject...}
Group            : System.Management.ManagementBaseObject
Owner            : System.Management.ManagementBaseObject
SACL             :
TIME_CREATED     : 

[System32] $a.descriptor.dacl[0] | fl [a-z]* 
AccessMask              : 983052
AceFlags                : 0
AceType                 : 0
GuidInheritedObjectType :
GuidObjectType          :
TIME_CREATED            :
Trustee                 : System.Management.ManagementBaseObject 


[System32] $a.descriptor.dacl[0].trustee | fl [a-z]* 

Domain       : Thor
Name         : Admin
SID          : {1, 5, 0, 0...}
SidLength    : 28
SIDString    : S-1-5-21-3020384060-3247076327-363933757-1000
TIME_CREATED : 
 
[System32]

Как видите, метод GetSecurityDescriptor вернул нам единственный параметр - Descriptor. Заглянув в Descriptor, нам нужно было найти параметр DACL, который уже содержит все пермишены. Подробнее материал изложен тут: WMI Security Descriptor Objects.

Примечание: методы GetSecurityDescriptor и SetSecurityDescriptor доступны только в ОС начиная от Windows Vista/Windows Server 2008 и выше.

Структура DACL содержит в себе как права доступа (AccessMask), так и сведения о пользователе, который имеет указаную AccessMask маску доступа (Trustee). Я попробовал создать идентичную структуру SecurityDescriptor (как описано в ссылке: WMI Security Descriptor Objects) и получил вот такой скрипт:

# задаём пользователя, которому хотим предоставить доступ
$user = "everyone"
# объявляем необходимые классы, которые описывают дескриптор безопасности
$SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
$ace = ([WMIClass] "Win32_Ace").CreateInstance()
$Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
# преобразовываем имя пользователя в строковый SID и массив байтов для Win32_Trustee
$SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[byte[]] $SIDArray = ,0 * $SID.BinaryLength
$SID.GetBinaryForm($SIDArray,0)
# заполняем необходимыми данными класс Win32_Trustee
$Trustee.Name = $user
$Trustee.SID = $SIDArray
# заполняем поля класса Win32_Ace, которые описывают права доступа и заворачиваем
# пользователя в лице класса Win32_Trustee
# AccessMask в контексте принтера может принимать значения:
# 524288 - Take ownership
# 131072 - read permissions
# 262144 - change permissions
# 983088 - manage documents
# 983052 - manage printers
# 131080 - print + read permissions
$ace.AccessMask = 983052
$ace.AceType = 0
$ace.AceFlags = 0
$ace.Trustee = $Trustee
# заворачиваем полученный объект Win32_Ace в параметр DACL класса Win32_SecurityDescriptor
$SD.DACL = $ace
# получаем объект принтера, с которым собираемся работать
$Printer = gwmi win32_printer -filter "name='CutePDF Writer'"
# получаем свойства метода SetSecurityDescriptor, чтобы в соответствии с ними
# завернуть туда SecurityDescriptor
$inParams = $Printer.psbase.GetMethodParameters("SetSecurityDescriptor")
# заворачиваем SecurityDescriptor в параметр Descriptor метода SetSecurityDescriptor
$inParams.Descriptor = $SD
# применяем метод SetSecurityDescriptor
$Printer.SetSecurityDescriptor($inParams)

И попробуем его запустить:

[System32] $user = "everyone"
[System32] $SD = ([WMIClass] "Win32_SecurityDescriptor").CreateInstance()
[System32] $ace = ([WMIClass] "Win32_Ace").CreateInstance()
[System32] $Trustee = ([WMIClass] "Win32_Trustee").CreateInstance()
[System32] $SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])
[System32] [byte[]] $SIDArray = ,0 * $SID.BinaryLength[System32] $SID.GetBinaryForm($SIDArray,0)
[System32] $Trustee.Name = $user
[System32] $Trustee.SID = $SIDArray
[System32] $ace.AccessMask = 983052
[System32] $ace.AceType = 0
[System32] $ace.AceFlags = 0
[System32] $ace.Trustee = $Trustee
[System32] $SD.DACL = $ace
[System32] $Printer = gwmi win32_printer -filter "name='CutePDF Writer'"
[System32] $inParams = $Printer.psbase.GetMethodParameters("SetSecurityDescriptor")
[System32] $inParams.Descriptor = $SD
[System32] $Printer.SetSecurityDescriptor($inParams)   

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT :
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ReturnValue      : 2147749896


[System32]

Как видно, ни одна строка не вернула ошибок, а последняя строка вернула значение 2147749896. Прогулявшись по MSDN нашёл описание этой ошибки: Win32SDToSDDL Method of the Win32_SecurityDescriptorHelper Class (практически везде данное значение в контексте SecurityDescriptor интерпретируются так):

One of the parameters to the call is not correct.

один из параметров вызова указан неверно. Давайте попробуем проанализировать, что мы сформировали и сравним с данными, которые получили методом GetSecurityDescriptor:

[System32] $inparams 

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 1
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
Descriptor       : System.Management.ManagementBaseObject


[System32] $inparams.Descriptor | fl [a-z]* ControlFlags :

DACL         : {System.Management.ManagementBaseObject}
Group        :
Owner        :
SACL         :
TIME_CREATED : 


[System32] $inparams.Descriptor.dacl[0] | fl [a-z]* 

AccessMask              : 983052
AceFlags                : 0
AceType                 : 0
GuidInheritedObjectType :
GuidObjectType          :
TIME_CREATED            :
Trustee                 : System.Management.ManagementBaseObject 


[System32] $inparams.Descriptor.dacl[0].trustee | fl [a-z]* 

Domain       :
Name         : everyone
SID          : {1, 1, 0, 0...}
SidLength    :
SIDString    :
TIME_CREATED : 
[System32]

Если сравнивать с первым листингом, где мы получали текущий SecurityDescriptor, то мы сохранили структуру SecurityDescriptor и в соответствующие поля записали нужные данные. При этом я также пытался для Trustee записать строковый SIDString и SIDLength:

$Trustee.SIDString = $SID.Value
$Trustee.SIDLength = $SID.BinaryLength

и получил уже такой Trustee:

[System32] $inparams.Descriptor.dacl[0].trustee | fl [a-z]* 

Domain       :
Name         : everyone
SID          : {1, 1, 0, 0...}
SidLength    : 12
SIDString    : S-1-1-0
TIME_CREATED : 


[System32]

От этого результат не изменился. Попробовал вызвать несколько иначе метод SetSecurityDescriptor:

$Printer.psbase.invokemethod("SetSecurityDescriptor", $inParams, $null)

и всё по старому. Я попытался нагуглить этот вопрос поисковой фразой "setsecuritydescriptor win32_printer powershell" (да-да, каюсь, я пользуюсь гуглем, как это ни прискорбно). И он мне выдал меньше одной страницы и 2 вменяемые ссылки, одна из которых ведёт на MSDN, а вторая на какой-то французский сайт (в котором я без переводчика плохо понимаю, а жаль) - http://powershell-scripting.com/index.php?option=com_joomlaboard&Itemid=76&func=view&id=2292&catid=6, но человек там творил что-то страшное и я понял, что там помощи не ждать.

Вобщем, этот вопрос пока остаётся открытым. Что ему не нравится, я пока не могу понять. Управление SecurityDescriptor в WMI - это не самая удачная модель управления безопасностью в WMI, но пока это почти единственный способ добиться результата - приходится с этим работать. Хотя, на первый взгляд может показаться, что там всё страшно и ужасно, но на самом деле, если разобрать предметно вопрос и поупражняться, всё оказывается вполне понятным, хоть и не совсем логичным и не всегда это хочет работать как положено :)

PowerShell Powered - http://www.sysadmins.lv

Управление принтерами в PowerShell (часть 2)

Camelot — Fri, 14 Nov 2008 01:31:03 GMT

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

New-NetworkPrinter - добавляет (мапит) сетевой принтер к пользователю
Remove-NetworkPrinter - удаляет сетевой принтер у пользователя (удаляет только маппинг принтера)
Set-DefaultPrinter - устанавливает выбранный принтер принтером по умолчанию
Get-Printer - получение сведений о выбранном принтере. Как полный набор сведений, так и краткий
New-PrinterShare - расшаривает локальный принтер для общего сетевого доступа
Remove-PrinterShare - отменяет сетевой доступ к принтеру

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

Сразу хочу оговориться, что для первых 3-х функций реализована только локальная поддержка (т.е. использовать функции по отношению к другим компьютерам нельзя). Сделано это почему: дело в том, что все WMI операции выполняются (даже на удалённых машинах) в контексте того пользователя, который запустил скрипт. Очень сомнительный смысл мапить для себя принтер на другой машине. Ко всему прочему в классе Win32_Printer не реализована даже поддержка удалённого маппинга принтера. Сейчас я это продемонстрирую:

В классе Win32_Printer есть замечательный метод AddPrinterConnection, который подключает сетевой принтер к пользователю. Если в MSDN написано, что он есть, значит таконо и есть. Посмотрим:

[vPodans] gwmi Win32_Printer | gm -membertype method


   TypeName: System.Management.ManagementObject#root\cimv2\Win32_Printer

Name                  MemberType Definition
----                  ---------- ----------
CancelAllJobs         Method     System.Management.ManagementBaseObject CancelAllJobs()
GetSecurityDescriptor Method     System.Management.ManagementBaseObject GetSecurityDescriptor()
Pause                 Method     System.Management.ManagementBaseObject Pause()
PrintTestPage         Method     System.Management.ManagementBaseObject PrintTestPage()
RenamePrinter         Method     System.Management.ManagementBaseObject RenamePrinter(System.String NewPrinterName)
Reset                 Method     System.Management.ManagementBaseObject Reset()
Resume                Method     System.Management.ManagementBaseObject Resume()
SetDefaultPrinter     Method     System.Management.ManagementBaseObject SetDefaultPrinter()
SetPowerState         Method     System.Management.ManagementBaseObject SetPowerState(System.UInt16 PowerState, Syst...
SetSecurityDescriptor Method     System.Management.ManagementBaseObject SetSecurityDescriptor(System.Management.Mana...


[vPodans]

Здесь я выбрал список методов объекта Win32_Printer. Но метода AddPrinterConnection мы там не наблюдаем! Почему? А всё потому, что ни один объект Win32_Printer не содержит данный метод! Метод AddPrinterConnection есть только внутри самого класса Win32_Printer и ни одним объектом не наследуется. Чтобы убедиться в этом, я вызову новый инстанс класса (не существующего объекта) и просмотрю его методы:

[vPodans] [wmiClass]'Win32_Printer' | gm -membertype method


   TypeName: System.Management.ManagementClass#ROOT\cimv2\Win32_Printer

Name                 MemberType Definition
----                 ---------- ----------
AddPrinterConnection Method     System.Management.ManagementBaseObject AddPrinterConnection(System.String Name)


[vPodans]

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

Что касается удаления примапленного принтера, то я рассказывал об этом в первой части. Чтобы не было вопросов, откуда взялся метод Delete, которого мы здесь не увидели (а так же не увидим на сайте MSDN), то сразу отвечу, что это не чистый метод, а скриптметод. Его можно найти, выполнив лишь команду:

gwmi Win32_Printer | gm -membertype scriptmethod

И там он будет. Поехали дальше. Что касается расшаривания принтера для предоставления общего доступа и его отмены. Мы не имеем ни единого метода или скриптметода, который бы это делал. Но если ещё раз и внимательно изучить класс Win32_Printer на MSDN (ещё раз даю ссылку), то можно заметить, что некоторые свойства объектов имеют Access Type: Read/Write. Именно этим мы и воспользуется:

[System32] (gwmi Win32_Printer -Filter "name='CutePDF Writer'").shared
False
[System32] $a = gwmi Win32_Printer -Filter "name='CutePDF Writer'"
[System32] $a.shared = $True
[System32] $a.put()


Path          : \\localhost\root\cimv2:Win32_Printer.DeviceID="CutePDF Writer"
RelativePath  : Win32_Printer.DeviceID="CutePDF Writer"
Server        : localhost
NamespacePath : root\cimv2
ClassName     : Win32_Printer
IsClass       : False
IsInstance    : True
IsSingleton   : False



[System32] (gwmi Win32_Printer -Filter "name='CutePDF Writer'").shared
True
[System32]

Итак, что же я сделал. Первой строкой я просмотрел свойство Shared для принтера CutePDF Writer и получил его значение - False. Это значит, что принтер просто локальный и не предоставлен в общий доступ. Далее, я изменил свойство Shared на True, предоставив его в общий доступ. Но это я только изменил свойство в переменной $a, но не в самом объекте. Чтобы записать изменения в объект я выполняю скриптметод put() и изменения уже записываются в сам объект принтера. Для верности я снова просмотрел свойство Shared и увидел мои изменения (вместо False получил True), т.е. принтер расшарился. Отмена предоставления принтера в общий доступ делается с точностью наоборот, а именно - свойство Shared выставляется обратно в False и изменения записываются командой put().

Примечание: при первом расшаривании принтера, кроме свойства Shared следует заполнить свойство ShareName, под которым он будет виден в сети. Так же выставив свойство Published в True мы можем опубликовать принтер в службе Active Directory.

На основе вышеизложенного материала напишем 6 несложных функций, которые обеспечивают базовый (это далеко не всё, что мы можем сделать с классом Win32_Printer) функционал по управлению принтерами:

########################################################
# BasicPrinterUtils.ps1
# Version 1.0
#
# Functions for basic printer management
#
# Vadims Podans (c) 2008
# http://www.sysadmins.lv/
########################################################
function New-NetworkPrinter ($computer, $name) {
([wmiclass]'Win32_Printer').AddPrinterConnection("\\$computer\$name")
}
function Remove-NetworkPrinter ($name) {
if ($name) {(gwmi Win32_Printer -Filter "sharename='$name'").delete()}
else {(gwmi Win32_Printer -Filter "local='$false'").delete()}
}
function Set-DefaultPrinter ($name) {
if (!$name) {Write-Host "Не указано имя принтера. Операция прервана"}
else {$internal = gwmi win32_Printer -Filter "name='$name'"
$internal.setdefaultprinter()}
}
function Get-Printer ($computer, $name, $full) {
$internal = gwmi Win32_Printer -ComputerName $computer -Filter "name='$name'"
# здесь я предлагаю получить как полный набор свойств, так и упрощённый вывод сведений.
if ($full) {$internal | select *} else {Write-Host $internal}
}
function New-PrinterShare ($computer, $name, $ShareName) {
$internal = gwmi win32_Printer -ComputerName $computer -Filter "name='$name'"
if ($internal) {$internal.shared = $true; $internal.ShareName = $ShareName; $internal.put()}
else {Write-Host "Указано неверное имя принтера"}
}
function Remove-PrinterShare ($computer, $name) {
if ($name) {$internal = gwmi Win32_Printer -Filter "name='$name'"; $internal.shared = $false; $internal.put()}
else {gwmi Win32_Printer -Filter "shared='$true'" | %{$_.shared = $false; $_.put()}}
}

Полагаю, что здесь комментировать особо нечего, т.к. тут всё очень просто и понятно. На этом пока всё. Продолжение, полагаю, следует. :)

BasicPrinterUtils.ps1 (1,6 KB)

PowerShell Powered - http://www.sysadmins.lv

Управление принтерами в PowerShell (часть 1)

Camelot — Mon, 10 Nov 2008 20:06:45 GMT

Ни для кого не секрет, что PowerShell умеет управлять принтерами. Для этого используются как WMI классы, так и COM объекты. При этом управление ими из PowerShell совсем не сложное. WMI представляет следующие классы:

Итак, самое простое - перечисление принтеров:

Write-Host "`tLocal Printers"
gwmi win32_printer -Filter "Local='$true'" | ft Name, Drivername -a
Write-Host "`tNetwork Printers"
gwmi win32_printer -Filter "Local='$false'" | ft Name, Drivername, ServerName -a

Здесь я вывожу 2 списка принтеров - которые подключены локально и сетевые принтеры. Фильтрация осуществляется по свойству Local, которое может быть или $true или $false. Так же можно посмотреть, какие принтеры расшарены для других пользователей:

Write-Host "`tShared Printers"
gwmi win32_printer -Filter "Shared='$true'" | ft Name, ShareName -a

Безусловно, как и остальные классы WMI, класс Win32_Printer позволяет удалённо подключаться к принтсерверу с использованием параметра -ComputerName.

Так же можно посмотреть текущие настройки принтера:

gwmi Win32_PrinterConfiguration | ft Caption, XResolution, YResolution, PaperSize -a

Этой командой я увижу основные параметры качества печати и текущий размер используемой бумаги. Дополнительные свойства описаны в классе Win32_PrinterConfiguration и описывать их тут смысла нету.

Классы Win32_PrinterDriver и Win32_PrinterDriverDll несут лишь справочную информацию о драйверах принтеров и реальное применение им я представляю слабо и рассматривать не буду.

Класс Win32_PrintJob показывает текущее состояние очереди печати принтера. Например, сейчас мой принтер печатает тестовую страницу:

[user name] gwmi Win32_Printjob | select *


Document         : Test Page
JobId            : 3
JobStatus        : Printing
Name             : Новая оргтехника, 3
PagesPrinted     : 0
Status           : OK
__GENUS          : 2
__CLASS          : Win32_PrintJob
__SUPERCLASS     : CIM_Job
__DYNASTY        : CIM_ManagedSystemElement
__RELPATH        : Win32_PrintJob.Name="Новая оргтехника, 3"
__PROPERTY_COUNT : 24
__DERIVATION     : {CIM_Job, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER         : CAMELOT
__NAMESPACE      : root\cimv2
__PATH           : \\CAMELOT\root\cimv2:Win32_PrintJob.Name="Новая оргтехника, 3"
Caption          : Новая оргтехника, 3
DataType         : NT EMF 1.008
Description      : Новая оргтехника, 3
DriverName       : HP Photosmart D6100 series
ElapsedTime      :
HostPrintQueue   : \\CAMELOT
InstallDate      :
Notify           : user name
Owner            : user name
Parameters       :
PrintProcessor   : hpzpp4pi
Priority         : 1
Size             : 114944
StartTime        :
StatusMask       : 16
TimeSubmitted    : 20081110195514.849000+120
TotalPages       : 1
UntilTime        :

Здесь видно, на какой принтер идёт печать, имя документа, статус печати, размер документа, имя пользователя, от которого производится печать и др. Кстати говоря, параметр JobId показывает количество отправленных заданий с момента последнего перезапуска спулера печати. Так же хочу заметить, что Win32_PrintJob возвращает информацию только при наличии заданий в спулере. Когда принтер простаивает, то данный класс ничего не возвращает.

Теперь настало время поговорить, как подключать новые принтеры и удалять текущие принтеры. Подключать принтеры можно как с помощью WMI, так и с помощью COM:

WMI

([wmiclass]'Win32_Printer').AddPrinterConnection("\\server\Printername")

COM

(New-Object -ComObject WScript.Network).AddWindowsPrinterConnection("\\Server\PrinterName")

При этом важно отметить, что при получении объекта Win32_Printer в нём метод AddPrinterConnection не содержится, т.к. данный метод содержится в самом классе Win32_Printer.

Удаление принтера производится при помощи метода Delete:

(gwmi Win32_Printer -Filter "name='PrinterName'").delete()

Таким образом удаляется только один принтер. Все принтеры удаляются без указания фильтра:

(gwmi Win32_Printer).delete()

Например, недавно на ньюсгруппах был вопрос, как для развёртывания нового принтсервера удалить со всех компьютеров домена. Задача решалась в несколько строк:

$filter = "(objectcategory=computer)"
$ds = New-object System.DirectoryServices.DirectorySearcher([ADSI]"",$filter)
$computers = $ds.Findall() | %{$_.properties.name}
foreach ($computer in $computers) {gwmi win32_printer -computername "$computer" | %{$_.delete()}

На сегодня, я думаю, это всё. Во второй части я планирую поговорить о чтении и установке пермишенов на принтеры с использованием PowerShell.

PowerShell Powered - http://www.sysadmins.lv