В этом посте я постарался собрать наиболее полезные или интересные ссылки на MS Knowledge Base (или просто KB) по теме Software Restriction Policies и AppLocker.

Article name	Article ID
How to stop an ActiveX control from running in Internet Explorer	KB240797
Description of the Software Restriction Policies in Windows XP	KB310791
RSoP Tool Incorrectly Displays Software Restriction Policies	KB312325
Software Restriction Policies Do Not Recognize 16-Bit Programs	KB319458
How To use Software Restriction Policies in Windows Server 2003	KB324036
"Software Restriction Policy Does Not Allow You to Start This Program" Error Message Even Though the Program Is Defined As "Allowed"	KB815471
Software Restriction Policies feature does not log events as expected	KB823726
Software Restriction Policies Do Not Persist After You Define Them	KB830678
"Windows cannot open this program because it has been prevented by a software restriction policy" error message when a user tries to open a file in Windows Server 2003	KB873419
You may receive a "RUNAS ERROR: Unable to run" error message in Windows XP with Service Pack 2	KB895196
The Digital Signatures tab may not appear in the properties dialog box of a digitally signed file that is larger than approximately 400 MB in Windows XP with Service Pack 2	KB922225
FIX: Error message when you try to install a large Windows Installer package or a large Windows Installer patch package in Windows Server 2003 or in Windows XP: "Error 1718. File was rejected by digital signature policy"	KB925336
Batch files for which you create a hash rules do not work on a Windows XP-based client computer	KB943854
Software Restriction Policy Enforcement set to “All Software Files” causes checks against paths/files that are invalid	KB959074
"HTTP Error 404 - File or Directory not found" error message when you request dll or exe files with IIS 6.0	KB970140
You cannot install a Windows Installer package under the Local System context on a Windows XP-based computer that has update KB956572 installed	KB971913
Error message when you try to install a large Windows Installer package or a large Windows Installer patch package in Windows Server 2003 Service Pack 2: "Error 1718 File was rejected by digital signature policy"	KB973825
The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7	KB976922
Error message occurs when you use GPMC to view a software restriction Group Policy setting in Windows 7 and in Windows Server 2008 R2: "An error has occurred while collecting data for Software Restriction Policies"	KB981750
AppLocker incorrectly calculates the hash of certain files at runtime in Windows 7 or in Windows Server 2008 R2	KB975449
Windows 7 or Windows Server 2008 R2 stops responding at the "Please wait" screen before you are requested to press Ctrl+ALT+DEL	KB983551
You cannot access allowed applications that are managed by AppLocker in Windows 7 or in Windows Server 2008 R2	KB2568041
You can circumvent AppLocker rules by using an Office macro on a computer that is running Windows 7 or Windows Server 2008 R2	KB2532445
AppLocker path condition does not work when a file name contains international characters in Windows 7 or in Windows Server 2008 R2	KB2659440

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

Давненько я ничего не писал про SRP, хотя давно пора было бы заполнить некоторые пробелы. В этой статье мы разберём 3 вопроса (проблемы):

• особенности применения SRP в системах x64;
• особенности конфигурирования политики на терминальном сервере;
• особенности создания правил в Vista-based системах и применения в XP-based системах.

Проблемы SRP в системах x64

Использование SRP в 64-разрядной системе иногда чревато проблемами. Давайте разберёмся с дефолтными правилами. Их у нас всего 2:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Это очень хорошие и полезные правила. Они позволяют нам запускать любые приложения из папки Windows и Program Files. Но в x64 системах у нас есть 2 класса приложений, родные x64 и унаследованные приложения x86, которые работают в режиме эмуляции. Такие приложения как правило устанавливаются в папку Program Files (x86). И если мы попробуем запустить любое приложение из папки Program Files (x86), мы получим ошибку:

Это происходит по вполне очевидным причинам. Наши правила по умолчанию не распространяются на папку Program Files (x86). Для этого мы должны создать ещё одно правило:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

После этого мы сможем запускать всё из папки Program Files (x86). Вроде бы всё хорошо и замечательно. Но природа работы SRP многогранна и необычна.

Представим ситуацию, у вас установлен 32-разрядный MS Outlook (ну или любая другая 32-разрядная почтовая программа) и вам пришло письмо с приаттаченным RAR архивом. А WinRAR у вас установлен x64. Вы пытаетесь открыть архив из письма, а не получается. На сколько я проверял, вообще ничего не происходит, но в журнале событий (напоминаю, что логи SRP пишутся в журнал Application) с EventID = 865 можно найти многозначащее:

Access to C:\Program Files\WinRAR\WinRAR.exe has been restricted by your Administrator by the default software restriction policy level.

Что хотите, то и делайте. Правила все есть, а не работают. Но я не зря говорил о многогранной и необычной природе SRP. При запуске одного приложения из второго (в нашем случае из аутлука запускаем WinRAR, чтобы открыть архив) контекст SRP наследуется из родительского приложения в дочернее (если так вообще можно сказать). Если говорить простым языком, если родительское приложение (в нашем случае MS Outlook) является 32-битным, то все запускаемые из него приложения проверяются так, будто они 32-битные. На практике это означает примерно следующее. Где фактически находится ветка реестра Software для x86 приложений? Кто-то скажет, что там же, где и всегда: HKLM\Software и будет не прав, потому что правильный ответ: HKLM\Software\Wow6432Node. И давайте посмотрим, что нам покажут вышеперечисленные пути (из правил SRP) в реестре:

А ведут оба этих пути в одну и ту же папку, т.е. Program Files (x86). Соответственно, в такой ситуации у нас нет ни одного правила для папки Program Files и вполне логично, что WinRAR запущен не был. В обратной ситуации (когда из 64-битного аутлука запустить 32-битный WinRAR) такой проблемы нет, потому что путь в значении ProgramFiles (x86) всегда ведёт в Program Files (x86). Для решения этой проблемы в Windows 7 было добавлено ещё одно значение: ProgramW6432Dir = C:\Program Files.

Этот ключ реестра во всех случаях ведёт в папку Program Files. Следовательно, нам нужно создать ещё одно правило, которое будет включать этот параметр реестра. В сухом остатке список правил по умолчанию для x64 систем у нас должен быть минимум такой:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%

Эти 4 правила обеспечивают полный эквивалент правил по умолчанию, которые используются в родных x86 системах. Однако, хочу отметить один факт. Параметр ProgramW6432Dir по указанному пути присутствует только в Windows 7 и Windows Server 2008 R2. В предыдущих системах (включая Windows Vista x64 и Windows Server 2008 x64) он отсутствует. Поэтому в них для решения этой проблемы придётся прописывать абсолютные пути (без использования переменных) к папкам C:\Program Files и C:\Program Files (x86).

Политики SRP на терминальных серверах

Достаточно часто (если исходить из общего количества внедрений SRP) администраторы наступают на одни и те же грабли. Поскольку природа терминальных серверов достаточно разнообразна, практически сложно создать какую-то одну политику SRP с правилами, которые удовлетворяли бы требованиям всех пользователей. Всегда будет так, что одному пользователю будет необходимо одно бизнес-приложение, а другому это приложение не нужно и должно быть запрещено. Адмнистраторы недолго думая пользуются тем фактом, что SRP можно настраивать и на уровне пользователя (секция User Configuration). Создают несколько политик SRP в этой секции, настраивают фильтрацию (чаще security filtering) так, чтобы каждой группе пользователей применялись нужные правила. Но сразу после применения политики могут начаться проблемы. Например, в пользовательской политике исключили расширение LNK, а на самом деле это расширение блокируется. Дело в том, что в определённых ситуациях (не скажу точно при каких условиях) SRP неявно создаёт копию политики по умолчанию в общекомпьютерной ветке реестра: HKLM\Software\Policies\Microsoft\Windows\Safer и получается конфликт, поскольку настройки компьютерной политики (кроме правил в Additional Rules) перекрывают соответствующие настройки в пользовательской политике.

Чтобы заранее избежать подобной ситуации следует придерживаться следующего правила: создать базовую (которая применима ко всем пользователям на машине) политику в секции Computer Configuration (в этой секции определить общие настройки и глобальные правила). Для расширения прав и/или назначения гранулированных прав запуска тех или иных приложений можно назначать правила в секции User Confgiration.

Создание политик в Vista-based системах и применения в XP-based системах

Ещё давным-давно (в декабре 2007) вышла в свет Windows Vista с некоторыми изменениями в SRP. В частности правила хешей теперь поддерживают алгоритм SHA256, который не поддерживается в Windows XP и Windows Server 2003 (включая R2). Но возникает вопрос interoperability с предыдущими системами. Например, что будет, если мы создадим правило в Windows Vista, а применим его на Windows XP (через GPMC.msc, который входит в состав RSAT)?

В интернетах ходят разные мифы на этот счёт, но в реальности всё гораздо проще. Когда Windows Vista (или выше) создаёт правило хеша, система генерирует 2 хеша — родной SHA256 и совместимый хеш MD5. Таким образом обеспечивается полная совместимость с системами XP/2003. Два хеша генерируются даже если это одиночная машина в рабочей группе и совместимость с предыдущими версиями систем не требуется. Вот как это выглядит в реестре:

Здесь мы видим стандартный хеш MD5 (AlgID = 8003 это MD5). ItemData содержит фактический хеш.

Под ключом правила (каждое правило здесь указано в виде GUID'а) добавляется ещё один ключ SHA256:

Вот здесь мы видим другой идентификатор алгоритма (800c это SHA256). ItemData так же содержит фактический хеш, но не MD5, а SHA256.

Примечание: полный список криптографических алгоритмов можнно найти по здесь: http://msdn.microsoft.com/en-us/library/aa375549(VS.85).aspx

Порядок проверки хешей для XP/2003 остался тот же — только MD5. В Windows Vista сначала проверяется хеш из ключа SHA256.

Update 20.03.2011: исправлен синтаксис для INF

---

В различных интернетах ходит достаточно много слухов о правильности использования флага EDITF_ATTRIBUTESUBJECTALTNAME2. В общем смысле, администраторы включают этот флаг для выпуска сертификатов с расширением Subject Alternative Name без разбора и ссылаются на этот документ: http://support.microsoft.com/kb/931351. Но, как оказывается, мало кто осилил документ полностью.

Как видно из названия (ATTRIBUTE), этот флаг разрешает сабмитить запрос сертификата с атрибутом, содержащим расширение SAN. Этот атрибут можно добавить следующими способами:

• при использовании Web Enrollment Pages (Windows 2000 и Windows Server 2003) вы можете указать дополнительный атрибут с использованием примерно такого формата: san:dns=dns.name[&dns=dns.name];
• при использовании certreq и INF файла, который содержит строку следующего формата: san:dns=dns.name[&dns=dns.name] (такой же, как и в Web Enrollment Pages);
• при использовании certreq и сабмита уже готового файла запроса: certreq –submit –attrib:"san:dns=dns.name[&dns=dns.name]"

С одной стороны, вроде, и удобно, но это сильно небезопасно. Дело в том, что если флаг EDITF_ATTRIBUTESUBJECTALTNAME2 включен, любой пользователь можешь добавить атрибут SAN к своему запросу и получить нужный сертификат, даже если шаблон не разрешает использовать расширение SAN. Данный флаг можно включать только если CA сконфгирурирован на ручное одобрение каждого запроса администратором CA, который будет следить, чтобы ни один пользователь не подсунул «левый» SAN. Но в условиях энтерпрайза это малореально. Следовательно вы НЕ ДОЛЖНЫ включать этот флаг на Enterprise CA, если он настроен на автоматическую выдачу сертификатов без премодерации!

Но мы ведь хотим SAN, но не хотим включать этот флаг. Как тогда быть? Для этого мы (и вы тоже) должны использовать один из следующих методов:

• Сжечь Web Enrollment Pages и научиться пользоваться оснасткой Certificates (в Windows Vista и выше) для получения сертификата: Web server certificate enrollment with SAN extension (ха-ха, у меня там раньше тоже была сноска на включение этого флага, потому что сам заблуждался).
• Использовать новые возможности INF файла. Начиная с Windows Vista вы можете в INF файле указать расширение SAN в Base64 кодировке с использованием примерно следующего формата:
  [Extensions] 
  2.5.29.17 = "{text}"
  _continue_ = "dns=www01.fabrikam.com&"
• настроить шаблон на премодерацию и использовать вот такой скриптик для добавления расширения SAN в запрос: How to add FQDN to HP iLO request

HTH

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

---

Решил я тут провести небольшое исследование на предмет работы интернет-браузеров с цифровыми сертификатами — как серверными, так и клиентскими и ещё по мелочам. Откровенно говоря, домашним пользователям подобные вещи не нужны совершенно, а вот корпоративному пользователю они могут потребоваться. Результаты исследования стали для меня небольшой неожиданностью. Но будем двигаться попорядку. Для начала список испытуемых (наиболее актуальные версии на момент постинга):

1. Microsoft Internet Explorer 8;
2. Mozilla Firefox 3.6.12;
3. Opera 10.63;
4. Google Chrome 7.0.517.44;
5. Apple Safari 5.33.19.4.

Все браузеры проверялись на Windows 7 Enterprise x64. Что проверялось? А проверялось следующее:

• Legacy cryptography support

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

• CNG Support

С выходом Windows Vista, Microsoft представил свою реализацию ассиметричных алгоритмов шифрования и генерации ключей под названием CNG (Cryptography Next Generation), в том числе с поддержкой ECC (Elliptic Curve Cryptography) и прочих стандартов. С момента выхода Windows Vista уже прошло ровно 3 года (конец 2007 года) и уже вышла следующая версия настольных Windows — Windows 7. Эти 2 системы всё шире и шире заполняют места в корпоративных сетях. Уже никого не удивишь сетью с системами под управлением только Windows Vista и выше. А, следовательно, уже приобретают актуальность SSL сертификаты с поддержкой CNG. Но все ли браузеры поддерживают их? Это тоже можно назвать баяном, но один браузер этот пункт провалил. Для меня было неожиданностью, что Opera ни в какую не хочет подключаться к сайтам с такими сертификатами.

• OCSP Support

Тоже стандарт де-факто 1999 года (RFC 2560). Ну за 11 лет браузеры как-то осилили 23-страничный RFC :-). Всё-таки, лучше потратить 2кб на запрос-ответ (а напомню, запрос весит примерно 70-100 байт, а ответ порядка 1,5кб), чем тратить мегабайты трафика (особенно на нешустрых мобильных каналах) на скачиваение CRL'ов. Вот один из таких пруфов:

http://SVRSecure-G2-crl.verisign.com/SVRSecureG2.crl

• Offline revocation detection

Довольно важный момент, который многие пытаются игнорировать. Потому что это не всем по зубам настроить правильно и практической пользы от этого они (они — кто не смог настроить доступность проверки отзыва) не видят. А это очень неправильно, ведь может быть так, что сертификат давно отозван (например, украли ключи от сертификата), а мы об этом ничего не знаем, т.к. списки отзыва недоступны. Как правило браузеры игнорируют эту ошибку, когда CRL'ы и OCSP недоступны, но опционально можно включить предупреждение, что сервер отзыва недоступен. В IE это сделано очень готично — выводит жёлтую полоску в адрес-баре: IE7 & SSL. Про другие браузеры не знаю, но похожих опций в настройках не нашёл.

• Native Windows/Integrated Authentication

Весьма актуальный пункт для корпоративного сектора. Поскольку внутренние порталы (особенно на SharePoint) используют учётные записи Active Directory для разграничения прав доступа на элементы и страницы корпоративного веб-сайта с использованием Windows (или Integrated) Authentication. Без него пользователю пришлось бы каждый раз вводить свои логин и пароль для входа на сайт, что весьма уныло и очень раздражает. А если есть вот такая сквозная аутентификация, система сама пересылает учётные данные (как правило, билет кербероса, а не логин и пароль в чистом виде, как некоторые могли бы подумать) на сервер. Безусловно, раздавать свои учётные данные (хоть и шифрованные) всем подряд — не самая лучшая затея в этой жизни. Поэтому существует некоторый дополнительный механизм, который определяет, кому можно их пересылать или нет. IE использует зоны интернета для разделения сайтов. По умолчанию Internet Explorer'у разрешено пересылать учётные данные только тем сайтам, которые находятся в зоне Local Intranet. Как правило корпоративные порталы добавляются в эту зону администраторами через GPO. На одиночных станциях это настраивается в апплете Internet Options панели управления.

Бытует мнение, что только IE может использовать сквозную аутентификацию на вебе. Но это всё неправда, потому что Google Chrome тоже использует зоны интернета для определения, кому можно пересылать учётные данные.

• Custom Windows/Integrated Authentication implementation

Далеко не обязательно (хотя и рекомендуется) использовать стандартное (можно даже сказать системное) разделение сайтов по зонам для определения разрешения на пересылку учётных данных для аутентификации и браузеры могут использовать свою реализацию сквозной аутентификации на вебе. И Mozilla FireFox в данном случае является примером такой реализации. Вот ссылка на настройку Windows Authentication в FireFox: Firefox and Integrated Windows Authentication. Opera и Safari никаким образом не поддерживают сквозную аутентификацию и не имеют собственных реализаций.

• Client Certificate Authentication

Бывают в этой жизни такие ситуации, когда использование логина и пароля для доступа к веб-сайту очень небезопасно (особенно если на сайте хранится очень конфиденциальная информация). Для усиления аутентификации можно использовать пользовательские сертификаты. Пользователь просто предъявляет его и тем самым аутентифицируется на веб-сервере. Опять же, по умолчанию для поиска пользовательских сертификатов используется системное пользовательское хранилище сертификатов (certmgr.msc). Но это тоже не обязательно (хотя и рекомендуется) и можно сделать свою реализацию.

В принципе, эту функцию поддерживают (тем или иным образом) все браузеры. Однако, в Opera она не работает. Никак. Кнопки нужные есть, но они выдают ошибки и всё. Поэтому для Opera здесь ставим красный крестик.

• Windows Certificate Store support

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

Internet Explorer (удивительно, да?), Google Chrome и Apple Safai используют стандартное хранилище сертификатов. Mozilla FireFox и Opera не поддерживают его никоим образом.

Примечание: однако, это вовсе не значит, что Chrome и Safari будут показывать зелёные полоски на вашем Extended Validation SSL сертификате. Т.е. если система доверяет вашему корневому сертификату (он установлен в контейнере Trusted Root CAs), Chrome и Safari будут ему доверять тоже. Но зелёнку (если она настроена для Internet Explorer) показывать не будут.

• Custom Certificate Store support

Т.к. использование стандартного хранилища сертификатов не обязательно для браузеров, Mozilla FireFox и Opera используют свои собственные хранилища для проверки доверия SSL сертификатам, а так же и для использования клиентских сертификатов для аутентификации на вебе. Поэтому если у вас используются внутренние сертификаты (выданые вашим собственным CA), скорее всего они не будут работать в этих браузерах и вам придётся их отдельно настраивать, чтобы эти браузеры доверяли вашим сертификатам. Что касается пользовательских сертификатов, то здесь придётся экспортировать сертификат из хранилища в PFX и импортировать в браузер. Это неудобно и вообще плохо.

Что касается Opera, этот браузер вообще как-то по-своему относится к сертификатам. Например, даже не показывает зелёнки (Extended Validation SSL) на тех сайтах, где остальные браузеры её показывают. Например, Opera до сих пор не показывает зелёнку на https://startssl.org.

• Native smart card support

Бывают в этой жизни и более тяжёлые случаи, когда пользователи не имеют логина и пароля для входа в систему и вообще для аутентификации в Active Directory. У них есть сертификат, но он не просто лежит в хранилище, а находится на защищённом криптоустройстве, называемом смарт-картой. Это уже из разряда многофакторной аутентификации, о которой я здесь рассказывать не буду, но этот вид аутентификации значительно надёжней комбинации логина и пароля, т.к. тут нужно знать не только PIN код от смарт-карты (а его можно и узнать при большом желании), но и иметь при себе саму смарт-карту. Для работы со смарт-картой в систему устанавливается её драйвер и криптопровайдер (Cryptographic Service Provider, CSP). Этот CSP так же встраивает себя в LSA (Local Security Authority), что позволяет приложениям легко обнаруживать смарт-карты для аутентификации, даже если приложение не обучено специально работать со смарт-картами. Для этого, разумеется, необходимо использовать системные API.

Вот эти самые системные API используют следующие браузеры: Internet Explorer (ну куда же без него :-)), Chrome и Safari. Как только вы установили драйвер для смарт-карты, эти браузеры уже готовы с ней работать. Просто, удобно и со вкусом.

• Custom smart card support

Mozilla FireFox и Opera не используют системные API для получения сведений о смарт-картах и в этих браузерах эту поддержку нужно включать вручную. Вот пример, как это делается в Mozilla FireFox на примере Aladdin eToken: eToken Settings for Mozilla-Firefox 3.5 (по ссылке документ PDF). Opera, к сожалению, смарт-карты не поддерживает ни в каком виде.

---

А теперь соберём это всё в аккуратненькую табличку:

	Internet Explorer	Mozilla FireFox	Opera	Google Chrome	Apple Safari
Legacy cryptography support	:yes:	:yes:	:yes:	:yes:	:yes:
CNG Support	:yes:	:yes:	:no:	:yes:	:yes:
OCSP Support	:yes:	:yes:	:yes:	:yes:	:yes:
Offline revocation detection	:no:	:no:	:no:	:no:	:no:
Native Windows/Integrated Authentication	:yes:	:no:	:no:	:yes:	:no:
Custom Windows/Integrated Authentication implementation	Not required	:yes:	:no:	Not required	:no:
Client Certificate Authentication	:yes:	:yes:	:no:	:yes:	:yes:
Windows Certificate Store support	:yes:	:no:	:no:	:yes:	:yes:
Custom Certificate Store support	Not required	:yes:	:yes:	Not required	Not required
Native smart card support	:yes:	:no:	:no:	:yes:	:yes:
Custom smart card support	Not required	:yes:	:no:	Not required	Not required

---

Какие выводы следуют из этого?

• Internet Explorer показал вполне очевидные результаты по обсуждаемым моментам.
• Mozilla FireFox показал себя жутким независимым индивидуалистом. Абсолютно все указанные функции реализованы внутри браузера, иногда даже в виде костылей. С одной стороны это делает его платформонезависимым, но с другой стороны значительно усложняет администрирование, поскольку придётся настраивать систему и отдельно браузер. Вобщем, вариант не очень подходящий.
• Opera — достаточно популярный браузер среди домашних пользователей, но совершенно не пригоден как корпоративный браузер. Вобщем, в recycle bin.
• Google Chrome. Что удивильно (всё же, приятно), что Google Chrome показал точно такие же результаты, как и Internet Explorer. А это значит, что в Google хорошо подготовились к возможному внедрению своего детища в корпоративный сектор. Этот браузер предельно максимально использует системные возможности Windows, чтобы не доставлять дополнительного головняка администраторам, которым, возможно, придётся его настраивать. Правда, это делает браузер платформозависимым, но это в данном случае соверешенно некритично. Вобщем годная альтернативна для замена IE (в разрезе обсуждаемых моментов).
• Apple Safari, вроде, всё выглядит очень прилично, но отсутствие какой-либо реализации Windows Authentication, портит всё впечатление. А ведь сквозная аутентификация — немаловажная фича для корпоративного браузера. Вобщем, можно оставить на перспективу после Chrome.

Вот, собственно говоря, и всё :-)

На днях столкнулся с весьма интересным случаем:

На сервере Hyper-V работает виртуалка с ролью Enterprise CA и тут понадобилось перезагрузить физический хост. Всё прошло нормально, но утром посыпались жалобы, что люди не могут с токенами войти в систему и пользователи, подключающиеся к терминальному серверу по протоколу RDP-TLS получали одну и ту же ошибку: A revocation check could not be performed for the certificate. Начав расследование инцидента выяснилось, что CA по каким-то причинам отказался публиковать CRL'ы. Причём в эвентлоге ничего подозрительного обнаружено не было. Посмотрев последний CRL обнаружил, что время в Next Publish совпало с тем временем, когда хост Hyper-V ребутился (это было видно по эвентлогу загрузки системы). Как известно, по умолчанию Hyper-V при выключении сохраняет состояние виртуальных машин (как бы отправляет их в режим "sleep") и при включении обратно, восстанавливает их из этого режима. Вобщем, у CA был забит триггер обновления CRL'ов на определённое время и виртуалка его проспала. После этого CA даже не делал попыток переопубликовать CRL в течении 8 (или около того) часов, пока я их вручуню не опубликовал. 2-часовой overlap по очевидным причинам не спас ситуацию. Как выяснилось, CA не будет обновлять такие CRL'ы пока:

• кто-то опубликует их вручную;
• кто-то перезапустит службу certsvc.

Пораскинув мозгами я проверил ещё один момент — работу Key Archival, т.к. сертификат CA Exchange обновляется по такому же приципу. Т.е. если физический хост временно недоступен (выключен, перезагружается, ковыряется в носу) и в этот период истекает сертификат CA Exchange, то после возвращения виртуалки из сна этот сертификат не обновляется и архивирование ключей перестаёт работать. Может, я один такой счастилвчик, кто нарвался на такую несложную, но противную проблему, но факт остаётся фактом. И здесь, CA не будет предпринимать попыток обновить CA Exchange пока:

• кто-то запустит оснастку PKIView.msc (да-да, PKIView.msc может запустить триггер обновления CA Exchange);
• кто-то запустит команду: certutul –cainfo xchg;
• кто-то перезапустит службу certsvc.

Чтобы предотвратить подобное в дальнейшем, я выбрал следующий воркэраунд для Hyper-V:

1. Запустите оснастку Hyper-V Management;
2. Выберите виртуалку, на которой работает Enterprise CA и нажмите Settings;
3. Проскрольте список вниз до секции Management и разверните её;
4. В Automatic start action выберите Always start;
5. В Automatic stop action выберите Shutdown.
6. Повторите эти шаги для всех виртуальных машин, на которых работает Enterprise CA.

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