Disclaimer: Эта статья содержит сведения о правке реестра. Перед внесением изменений в системный реестр рекомендуется изучить процедуру его восстановления. Для получения дополнительных сведений о восстановлении реестра см. разделы «Восстановление реестра» или «Восстановление раздела реестра» справочной системы редактора реестра.

Ссылки на другие материалы из этой серии:

• Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов (ссылку будет по окончании написания этого цикла).

В предыдущей части мы поговорили о процессе аутентификации по сертификату (или смарт-картой), но не поговорили о том, как сертификат связывается (ассоциируется) с учётной записью пользователя в Active Directory. Процесс ассоциации сертификата с учётной записью называется certificate mapping. В мире Active Directory существует 2 вида маппинга:

• Implicit certificate mapping;
• Explicit certificate mapping.

Implicit certificate mapping

Implicit certificate mapping (в переводе звучит как «неявный» маппинг. В точности перевода могу ошибаться) является самым простым, шустрым и очевидным методом ассоциации сертификата с учётной записью пользователя. Для этого клиентский сертификат должен содержать расширение Subject Alternative Name и в нём должен быть прописан UPN (User Principal Name) пользователя:

Other Name:
     Principal Name=Administrator@contoso.com

Контроллер домена извлекает UPN пользователя из сертификата и пытается найти такой же UPN в глобальном каталоге. UPN хранится в атрибуте sAMAccountName. Если такой UPN найден, сертификат привязывается к учётной записи пользователя с указанным UPN. В противном случае считается, что учётная запись не найдена и аутентификация проваливается.

На заметку: некоторые пользователи (особенно, которым нужен доступ в 2 и более леса, которые не связаны доверительными отношениями) думают, что можно накидать несколько UPN'ов в расширение и получать профит — один универсальный сертификат для логона в 2 и более леса. Если в расширении SAN указано несколько различных UPN'ов, контроллер домена будет читать только первый из списка.

В 99% случаев вы будете использовать только implicit certificate mapping, который используется по умолчанию.

Explicit certificate mapping

В отдельных случаях у вас может и не быть возможности использовать implicit certificate mapping. Например, это сторонний (или коммерческий) CA, который по каким-то причинам не может или не хочет включать UPN пользователя в расширение SAN. Или у вас просто есть сертификат от чужого леса и вы его хотите использовать для двух лесов, которые друг о друге ничего не знают. И знать не хотят, видимо. С implicit certificate mapping вы можете использовать сертификат только в одном лесу или в нескольких лесах — но при условии, что UPN'ы в лесах совпадают.

Так же, существует ненулевая вероятность, что у вас будет сертификат с прописанным UPN в расширении SAN, но вы захотите использовать этот сертификат для другого UPN. Что делать? По умолчанию, контроллер домена при наличии UPN в SAN применяет *implicit mapping*, т.е. привязка по UPN и он даже не попытается попробовать explicit mapping. Хоть, такие случаи достаточно редки, но бывают нужны, вы можете отключить implicit mapping на уровне домена создав следующее значение в реестре (на контроллерах домена):

KEY =  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Type = DWORD
Value Name = UseSubjectAltName
Value Data = 0

Примечание: это возможно только для Windows Server 2008 и выше. Детали описаны в статье How to disable the Subject Alternative Name for UPN mapping. Но я ещё раз предупреждаю, что делать это следует только когда вы чётко понимаете, что вы делаете и какие последствия вас могут ожидать.

One-to-one mapping

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

Суть этого метода заключается в том, что определённые свойства сертификата должны быть описаны в атрибуте altSecurityIdentities (доступно через Attribute Editor) свойств учётной записи пользователя. Вот как можно создать маппинг one-to-one в консоли Active Directory Users and Computers:

1. Откройте оснастку Active Directory Users and Computers (dsa.msc);
2. В меню View установите флажок на Advanced Features;
3. Выберите учётную запись пользователя, с которой будут связываться сертификаты группы работников;
4. В контекстном меню выберите Name Mappings;
5. В открывшемся окне, кнопкой Add добавляете необходимые сертификаты.

Смотрите, здесь уже используется (и не отключается) маппинг по Issuer DN Name и Subject DN Name. Т.е. если контроллеру предъявляют сертификат с такими же значениями полей Subject и Issuer, он привяжет этот сертификат к этой учётной записи, где настроен маппинг. Если снять чек-бокс «Use Subject for alternate security identity», любые сертификаты, выданные конкретным сервером CA будут мапиться к этой учётной записи и это будет many-to-one certificate mapping. Но не следует использовать маппинг только по издателю. О более гибких примерах маппинга мы поговорим ниже. Вот пример:

В данном случае любой сертификат с конкретным Subject DN, который выдан конкретным CA будет мапиться к рассматриваемой учётной записи.

Many-to-one mapping

Этот сценарий применяется очень редко, но для того, чтобы не оставлять пробелов, я решил написать несколько слов об этом в исключительно информативных целях. Суть этого метода заключается в том, что несколько разных сертификатов мапятся к одной учётной записи. Допустим, есть группа временных работников (или партнёры из другой компании), у которых нет индивидуальной учётной записи в Active Diectory, но им нужен доступ к веб-сайту, который использует аутентификацию клиентов по сертификатам. Как говорится, нет ножек — нет и мультиковнет учётной записи — нет доступа.

В случае с explicit certificate mapping, алгоритм поиска учётной записи с которой можно связать предъявленный сертификат усложняется. Контроллер домена будет искать в своей базе сертификаты и пытаться их забиндить по следующим признакам (именно в такой последовательности, как они здесь указаны):

1. Точное совпадение полей Subject и Issuer — X509:<I><S>
2. Только по полю Subject — X509:<S>
3. По полям Issuer и Serial Number — X509:<I><SR>
4. По расширению Subject Key Identifier — X509:<SKI>
5. По Thumbprint (хешу всего сертификата) — X509:<SHA1-PUKEY>
6. И, наконец, по полю RFC822 Name (он же адрес электронной почты) — X509:<RFC822>

Вот примерная таблица (зелёным отмечены правильные условия проверки, красным — неправильные):

Например, у пользователя есть сертификат на CN=Oleg Krylov, OU=Users, DC=contoso, DC=com и который выдан CN=Contoso Corporate CA, DC=contoso, DC=com. Из картинки видно, что мы можем применить следующий биндинг: X509:<I><S>. И вот как его следует использовать в altSecurityIdentities:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA

Во-первых, элементы DN размещаются в обратном порядке от представления в сертификате. Т.е. сначала RDN, а потом уже CN, потому что они так кодируются в сертификате. Вот, пример ASN1 структуры сертификата VeriSign:

И посмотрите на Subject этого сертификата в UI: http://EVSecure-aia.verisign.com/EVSecure2006.cer. Т.е. вам необходимо взять сертификат и переписывать поле Subject/Issuer снизу вверх. Во-вторых, каждый элемент DN разделяется запятой и вокруг запятых пробелов быть не должно.

У сертификата есть расширение Subject Key Identifier = c1 2f a9 f1 c0 22 d4 37 a2 20 07 1d b9 ab 4a 12 ef f2 f9 fa и вы хотите сделать маппинг по этому расширению. Для этого в свойство altSecurityIdentities необходимо прописать строку следующего содержания:

• X509:<SKI>c12fa9f1c022d437a220071db9ab4a12eff2f9fa

Если делаете маппиг по схеме X509:<I><SR> (по издателю и серийному номеру), следует учитывать, что байты серийного номера должны идти в обратном порядке. Т.е. если в сертификате мы видим вот такой серийный номер: 2e 33 87 4f 6f e2 d4 1e d3 ff ff 35 f6 a4 c9 18, в условии маппинга следует переписывать байты справа налево: 18 c9 a4 f6 35 ff ff d3 1e d4 e2 6f 4f 87 33 2e или вот так:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA<SR>18c9a4f635ffffd31ed4e26f4f87332e

Это связано с тем, что в структурах C серийный номер (CRYPT_INTEGER_BLOB) записывается в обратном порядке и KDC будет использовать серийный номер так, как он хранится в структуре.

Если на каком-то этапе удалось обнаружить однозначное сходство — дальнейшие попытки биндинга сертификата не производится, а сертификат привязывается к учётной записи и пользователь продолжает процесс аутентификации. Кстати, почему так сложно? Почему бы не взять и не просто сверить 1:1 предъявленный сертификат, с опубликованным в свойствах учётной записи? Ответ тут достаточно очевидный — вы можете использовать many-to-one (когда сравниваются только определённые атрибуты сертификатов). И если вам надо связать множество сертификатов с одной учётной записью, их всех придётся публиковать, а это может неприятно отразиться на репликации. И короткие строки сравнивать быстрее, чем бинарные массивы.

Примечание: many-to-one certificate mapping можно реализовать как средствами Active Directory (описано в статье), так и средствами IIS. При установки роли веб-сервера, у вас есть 2 похожих пункта:

С виду их не отличишь, но теперь вы знаете, что первый пункт (Client Certificate Mapping Authentication) использует маппинг настроенный в Active Directory, а IIS Client Certificate Mapping использует маппинг настроенный в IIS. Подробнее: Many-To-One Mappings <manyToOneMappings>.

Эпилог

Чувствую, что написал очень много и непонятно. Я не обещал, что будет легко. В принципе, вы можете читать только раздел Implicit certificate mapping, а остальное — только когда потребуется или просто ради лулзов . В следующей части перейдём немного от теории к практике.

Что бы почитать?

• Windows Vista Smart Card Infrastructure

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

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

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

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Логон смарт-картой или PKINIT

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT. PKINIT, в свою очередь, является лишь надстройкой над керберосом (или расширением протокола). Вот как он примерно работает:

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

1. Пользователь вводит PIN от смарт-карты и посылает запрос AS-REQ на контроллер домена (он же Key Distribution Center — KDC). Этот запрос содержит преаутентификационные данные PA_PK_AS_REQ, которые, в свою очередь, содержат логонный сертификат и подписанная временная метка и опциональные атрибуты. В качестве опциональных атрибутов, клиент посылает список поддерживаемых алгоритмов, корневых CA, параметры Diffie-Hellman и т.д. Более детально структуру запроса (а там есть достаточно занятных вещей) можно найти в RFC 4556  §3.2.1 (пункт 5 на странице 12). В связи с этим (например, передача списка доверенных корневых CA от клиента на сервер) время логона смарт-картой будет значительно медленней, чем при связке логин/пароль. Плюс расходы на криптографические операции.
2. Сервер KDC проверяет запрос и пробует ассоциировать полученный сертификат с учётной записью пользователя. Если сопоставление сертификата с учётной записью произошло успешно, KDC формирует ответ AS-REP, включая в него Ticket-Granting Ticket (TGT) и прочую необходимую информацию. Ответ подписывается сертификатом самого KDC (именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат (о нём мы поговорим в следующих статьях).
3. Клиент проверяет этот ответ и проверяет подпись (вместе с сертификатом KDC). Если с ответом и сертификатом всё хорошо, клиент, на основе имеющегося TGT, генерирует Ticket Granting Service запрос — TGS-REQ для доступа к конкретной службе и отправляет его на KDC.
4. KDC проверяет запрос TGS-REQ и в случае положительного вердикта формирует ответ Ticket-Granting Service (TGS-REP), включая в него всю необходимую информацию для интерактивного логона, включая все необходимые SID'ы и учётные данные для аутентификации при помощи NTLM.
5. Клиент генерирует специальный токен GSS-API (RFC 1964) и в него заворачивает полученный TGS-REP. На выходе получается запрос AP-REQ, который направляется уже к конкретной службе, куда нужен доступ.
6. Здесь, собственно, происходит уже обоюдная аутентификация сервера и клиента (уже с использованием Kerberos) и между ними уже начинается свой собственный диалог. Возможно, о бабах

В принципе, вот как примерно (на достаточно высоком уровне) происходит клиентская аутентификация по сертификату. Кое что я опустил (что нам не столь актуально в рамках рассматриваемой статьи), но кое что мы будем более плотно рассматривать в следующих статьях — например, маппинг сертификатов (ассоциация или сопоставление сертификата с учётной записью в Active Directory).

На последок, особо пытливым умам — увлекательное чтиво:

• MS-PKCA
• MS-PAC
• MS-KILE
• RFC 4556
• RFC 1964

Данная серия постов заказана и оплачена благотворительным фондом винниклОлега Крылова и всех-всех-всех.

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

Password-based authentication background

Почти всю свою историю человек использует аутентификацию на основе комбинации логин и пароль. Логин уникально идентфицирует пользователя, а пароль (или секретное слово) подтверждает, что я — это я, а не Вася, который выдаёт себя за меня. Но давайте посмотрим слабые места парольной аутентификации в IT:

• Пароли очень короткие (5-8 символов);

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

• Пароли забываются;

Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:

• Пароли записываются на бумажки и приклеиваются на монитор;

Я думаю, что многие администраторы с таким встречались. Поскольку наши пользователи очень современны, они часто обитают на различных интернет-ресурсах, форумах, чатах и прочих социальных сетях. Чтобы не сильно забивать себе голову паролями:

• Один и тот же пароль используется для множества сетевых ресурсов одновременно;

Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).

Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.

Introduction to certificate-based authentication

Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.

Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.

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

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

Сертификат не подвержен ни одной из проблем, которым подвержены пароли.  Надёжность сертификата главным образом обеспечивается его сложностью и надёжностью хранения. В современных системах закрытые ключи хранятся на жёстких дисках компьютеров. Следовательно, получив полный доступ к диску, можно получить и доступ к закрытому ключу и сертификаты на этой машине (а представьте, это сервер CA?) становятся скомпрометированными. Для укрепления физической защиты ключей необходимо иметь надёжное хранилище для них, которым и выступает смарт-карта.

Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number). Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.

Где можно применять аутентификацию пользователей по сертификатам?

В Microsoft Windows мы можем применять пользовательские сертификаты для:

• Интерактивного логона в домен (требуется смарт-карта);
• Логона на сервер терминалов при помощи Remote Desktop (требуется смарт-карта);
• Аутентификации на веб-странице;
• Аутентификации в VPN;
• Аутентификации в 802.11х сетях (они же wireless).
• Аутентификации в ActiveSync;
• и ещё по мелочам.

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

Сегодня хочу поговорить про использование алиасов в скриптах и дать несколько практических советов при сборке текстов из фрагментов.

Алиасы

Семантика языка PowerShell подразумевает использование унифицированного синтаксиса, где название каждой команды явно говорит о том, что она делает. Например, Get-Process. Совершенно очевидно, что эта команда должна делать. Но, порой, эти команды бывают очень длинными и набирать их постоянно в консоли бывает не очень удобно. Например, самый топовый — Get-ChildItem. Это даже не самая длинная команда, просто наиболее часто используемая. Или Foreach-Object. Даже автозавершение команд не всегда спасает ситуацию. Для этого были придуманы алиасы (короткие ссылки на команды), которые очень выгодно использовать в консоли. Так же у команд есть и очень длинные параметры. Например, всякие –InputObject, –Include, –ErrorAction и т.д. PowerShell позволяет сокращать параметры первыми буквами до тех пор, пока эти буквы не будут явно указывать на конкретное название. Например, у команды Get-ChildItem параметр –Include может быть сокращён до –I, а –Exclude до –Ex. Но многие скриптописатели пишут скрипты (и выкладывают их даже где-то) с использованием этих самых алиасов и коротких обозначений параметров.

Хорошо это или плохо? Ответ очевидный — за такое надо бить больно сапогами и по лицу. Использование алиасов приводит нас обратно к одной из проблем оболочки cmd — сразу не скажешь, что делает та или иная команда. Пользователь без соответствующей подготовки вряд ли сходу скажет, что делает команда regsvr32 или что делает ключ /i этой команды. Или вот 2 примера:

gps iex* | spps -f
ls .\ -r -fo | %{cp $_.fullname -des e:\ -ea 0}

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

Get-Process iex* | Stop-Process -Force
Get-ChildItem .\ -Recurse -Force | ForEach-Object {Copy-Item $_.fullname -Destination e:\ -ErrorAction SilentlyContinue}

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

Пользователи PowerGUI Script Editor могут воспользовться адд-оном, написанным одним пошикмвп Шейем Леви (Shay Levy) — Expand Alias, который автоматически разворачивает алиасы в их полное значение.

Кавычки и here strings

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

На этой неделе мне прислали скрипт, который на выходе делает красивую HTML'ку с красивыми стилями и всё такое. И вот какое чудо (не единственное) я увидел:

$a = "<title>Телефонный справочник ООО `"Имя компании`"</title>"

# стили и заголовок окна
$a = $a + "<style>"
$a = $a + "BODY{background-color:#FFF;color:#000;font-family: tahoma; font-size: 8pt; }"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: #BFBFBF;border-collapse: collapse; width: 100%}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#4E7DD1; color: #FFF}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#FFF}"
$a = $a + "col#c1 { width: 10%;} col#c2{ width: 10%; }col#c3 {width: 10%;}col#c4 { width: 3%;}"
$a = $a + "col#c5 { width: 10%;} col#c6{ width: 11%; }col#c7 {width: 10%;}col#c8 { width: 25%;}"
$a = $a + "</style>"

Ах, какая красота. Уже в первой строке человек использует бэктик (`) для эскейпа двойных кавычек внутри текстовой строки. Зачем? Я не знаю. Ведь достаточно было заменить наружные кавычки на одинарные и всё стало бы прекрасно:

$a = '<title>Телефонный справочник ООО "Имя компании"</title>'

А какую функцию несёт переменная $a? Мы уже говорили, что название переменной должно отражать её сущность. Это сейчас понятно, что там, а чуть ниже в коде, где она будет использоваться — мы уже забудем, что там было.

Ок, идём дальше. А дальше он добавляет к этой строке другой код HTML (естественно, в виде текста). Я давно замечал, что люди или не знают или не хотят использовать here strings. Ведь можно сделать вот так:

$html = @'
<title>Телефонный справочник ООО "Имя компании"</title>
<style>
BODY{background-color:#FFF;color:#000;font-family: tahoma; font-size: 8pt; }
TABLE{border-width: 1px;border-style: solid;border-color: #BFBFBF;border-collapse: collapse; width: 100%}
TH{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#4E7DD1; color: #FFF}
TD{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#FFF}
col#c1 { width: 10%;} col#c2{ width: 10%; }col#c3 {width: 10%;}col#c4 { width: 3%;}
col#c5 { width: 10%;} col#c6{ width: 11%; }col#c7 {width: 10%;}col#c8 { width: 25%;}
</style>
'@

Если вам надо в коде разместить набор строк, заключайте их в here strings (с двойными кавычками, если внутри надо экспандить переменные или с одинарными, если это не надо).

Так же, в этом скрипте увидел ещё вот такую прелесть:

$menu = $menu + "<a href=`"#"+$head+"`">"+$head+"</a><br>"

А если мы снова упакуем это в here strings?

$menu += @"
<a href="#$head">$head</a><br>
"@

и мы снова избавились от груды бесполезных кавычек и необходимости их эскейпить.

Вот ещё прелесть:

$PatternTo = "<col id=""c1""/><col id=""c2""/><col id=""c3""/><col id=""c4""/><col id=""c5""/><col id=""c6""/><col id=""c7""/><col id=""c8""/>"

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

$PatternTo = '<col id="c1"/><col id="c2"/><col id="c3"/><col id="c4"/><col id="c5"/><col id="c6"/><col id="c7"/><col id="c8"/>'

эффект тот же самый и минус 16 кавычек.

Отсюда следует вот такое правило: учитесь правильно использовать кавычки. Избегайте эскейпинг кавычек — в 99% случаев это не нужно совсем. Вместо этого надо предусмотреть использование одинарных кавычек или применять here strings, если выхода нет.

$menu= "</style>" + "<TABLE Style=`"border-color:#FFF; border-collapse: separate`"><tr><td Style=`"border-color:#FFF`">" +$menu + "</td></tr></TABLE>"

Например, здесь мы не можем обойтись просто одинарными кавычками, потому что внутри строки надо вставить значение переменной. Значит, нам поможет here strings:

$menu= @"
</style><TABLE Style="border-color:#FFF; border-collapse: separate"><tr><td Style="border-color:#FFF">$menu</td></tr></TABLE>
"@

Работа с большим объёмом текста

В PowerShell при работе с большим объёмом текста (уже начиная от мегабайта) наблюдается ощутимая деградация производительности. Например, ваш код на выходе генерирует большой XML или HTML код, следует избегать операторы конкатенации ($a = $a + "some text" или $a += "some text"). Вместо этого следует использовать StringBuilder:

# создаём объект StringBuilder
$SB = New-Object Text.StringBuilder
# добавляем фрагменты текста в коде
<...>
[void]$SB.Append("some string")
<...>
# выгружаем итоговый текст в файл:
Set-Content -Path $path -Value $SB.ToString()

В качестве примера можете посмотреть мой код в PSFCIV, который заворачивает объекты с конвейера в XML:

function _toxml_ {
# в Begin создаём заголовок XML и открывающийся тег <FCIV>
    Begin {
        $xmlstring = New-Object System.Text.StringBuilder
        [void]$xmlstring.Append('<?xml version="1.0" ?><FCIV>')
    }
# в Process будут по одному поступать объекты, которые описывают файл.
    Process {
# для каждого файла у нас будет один тег <FILE_ENTRY>
        [void]$xmlstring.Append(" <FILE_ENTRY>`n")
# чтобы вручную не создавать и не заполнять вложенные теги мы простым foreach
# перечисляем теги, какие у нас будут в XML и за счёт переменных автоматом
# создаём их в XML и заполняем их данными. Для этого свойства объектов должны
# называться так же, как и теги.
        foreach ($child in ("name", "Size", "TimeStamp", "SHA1", "MD5")) {
            [void]$xmlstring.Append(" <$child>$($_.$child)</$child>`n")
        }
# когда текущий объект обработан, закрываем тег и ждём следующий объект файла
        [void]$xmlstring.Append(" </FILE_ENTRY>`n")
    }
# когда объекты закончились, закрываем первый тег <FCIV> и подаём полученный XML дальше
    End {
        [void]$xmlstring.Append("</FCIV>`n")
        [string]$xmlstring.ToString()
    }
}

В этом случае деградация производительности будет минимальной.

Наконец-то я смог выкроить время на то, чтобы написать что-нибудь ещё полезного в бложек. В последнее время я занимался весьма интересными вопросами, результатами которых я, может, как-нибудь поделюсь здесь. А может быть и не поделюсь

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

Форматирование

Неотформатированный код можно смело кидать в ресуклер, даже не вникая в него. Можете соглашаться, а можете и нет, но суть от этого не меняется. В принципе, PowerShell не имеет своих стандартов форматирования кода, но их можно унаследовать из IDE, как Visual Stidio. В основном это относится к разбивке сложных выражений на несколько строк и отступе от левого края. Разбивка сложных выражений проводится по таким символам, как: круглая скобка — (, квадратная скобка — [ (хотя, чаще она используется как метасимвол регулярных выражений) или фигурная скобка — {. Любые открывющиеся скобки в PowerShell являются признаком начала какой-то вложенной конструкции. И эти конструкции, если они достаточно длинные, следует располагать на новой строке. Открывающаяся скобка должна быть последним символом в текущей строке (или быть единственным символом в строке), а закрывающая скобка должна быть на отдельной строке. При этом весь код внутри конструкции должен быть отбит дополнительным табом от основного кода (т.е. не быть на одном уровне).

Заметка: олдфаги наверняка помнять 80 column rule, которое означает, что любая строка кода не должна быть длиннее 80 символов (классический размер консоли — 80 столбцов на 25 строк), а если она пытается быть длиннее — её надо разбивать на несколько строк. Плюс, это добавляет читабельности коду, потому что читать по вертикали проще, чем по горизонтали. Но это не значит, что надо строго придерживаться этого правила. Лично я считаю, что это правило можно расширить, но без фанатизма. Скажем, мне 100-110 символов кажется вполне разумным пределом.

Чувствую, что написал чушь, но ничего лучше не придумал, поэтому предлагаю пример, как делать не следует:

param ([Parameter(Mandatory = $true, Position = 0)][string]$Path,[Parameter(Mandatory = $true, Position = 1)][string]$XML)

Вот так — тоже плохо:

param ([Parameter(Mandatory = $true, Position = 0)][string]$Path,
[Parameter(Mandatory = $true, Position = 1)][string]$XML)

А хорошо будет вот так:

param (
    [Parameter(Mandatory = $true, Position = 0)]
    [string]$Path,
    [Parameter(Mandatory = $true, Position = 1)]
    [string]$XML
)

или вот так:

param 
(
    [Parameter(Mandatory = $true, Position = 0)]
    [string]$Path,
    [Parameter(Mandatory = $true, Position = 1)]
    [string]$XML
)

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

param 
(
    [ValidateSet("Bad", "Locked", "Missed", "New", "Ok", "Total", "Unknown")]
    [ValidateCount(1,7)]
    [String[]]$Show
)

Это значительно улучшает читабельность кода. Это несложное правило форматирования относится и к остальным подобным конструкциям. Например, вот кусочек кода, который что-то проверяет по условию IF и что-то делает:

if (Test-Path -LiteralPath $path) {Set-Location -LiteralPath $path
if ($pwd.Provider.Name -ne "FileSystem") {Set-Location $oldpath; throw "Specified path is not filesystem path. Try again!"}}
else {throw "Specified path not found. Try again!"}

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

if (Test-Path -LiteralPath $path) {
    Set-Location -LiteralPath $path
    if ($pwd.Provider.Name -ne "FileSystem") {
        Set-Location $oldpath
        throw "Specified path is not filesystem path. Try again!"
    }
} else {
    throw "Specified path not found. Try again!"
}

или Visual Studio-стайл:

if (Test-Path -LiteralPath $path) 
{
    Set-Location -LiteralPath $path
    if ($pwd.Provider.Name -ne "FileSystem") 
    {
        Set-Location $oldpath
        throw "Specified path is not filesystem path. Try again!"
    }
} 
else
{
    throw "Specified path not found. Try again!"
}

В обоих последних примерах можно уже точно сказать что к чему относится. Или вызов методов .NET:

[Security.Cryptography.X509Certificates.X509Certificate2UI]::SelectFromCollection(
    $certs,
    "Select a certificate",
    "Select a certificate or certificates from the list",
    "MultiSelection"
)

красиво и понятно. В отдельных случаях можно и не разбивать простые конструкции на несколько строк:

if ($a % 2) {$true} else {$false}

Для пользователей PowerShell Plus, в редакторе доступна встроенный автоформат кода. Т.е. набираете код так, как вам нравится, а потом автоформат форматирует как нужно.

Если у вас есть ещё какие-то соображения относительно форматирования, я не прочь их прочитать в комментариях. Так же, можете помочь с какими-то формулировками, потому что мои мне кажутся не самыми лучшими.

Именование переменных

Через мои руки прошло не мало сторонних скриптов и заметил несколько особенностей в именовании переменных. Если быть точнее, то всего 2.

• Префиксы

Очень много скриптов было портировано с VBS и переменные тоже унаследовали вбсную аттрибутику — префикс, означающий тип данных. Например, $strPath или $colServers или что-то типа $objWMI. Я не говорю, что так делать плохо, но с другой стороны я не рекомендую так делать, ибо незачем. В PowerShell переменные могут хранить любой тип данных. Причём, типы в переменной могут меняться. Если вы хотите ограничить переменную каким-то определённым типом — ограничивайте так:

[string]$Path, [String[]]$Servers, [int]$Numbers

никаких префиксов не надо и вы видите, какой тип данных хранится в переменных.

• Однобуквенные переменные

Начинающие и/или просто малоопытные администраторы начинают с самых простых скриптов и зачастую экономят на названиях перменных. Например:

$a = C:\
$b = dir $a\*.mp3
$c = d:\
copy $b -D $c

Названия переменных должны отражать свою суть, т.е. что в переменной хранится. Не бойтесь использовать даже длинные переменные (в пределах разумного, естественно). Например, переменная, содержащая файлы, которые надо куда-то добавить, может называться $FilesToBeAdded. Всё очень просто