Управление драйверами. Импорт дубликатов.

Процесс импорта драйверов и сборка Driver Packages - обычная задача, но нужно понимать, как происходит этот процесс:

• Driver Source Path - сетевой путь, откуда мы будем импортировать драйверы
• Driver Package Source - источник драйверов для Driver Package. Сюда будут скопированы драйверы после импорта
• Driver Package - сам пакет драйверов, который мы распространяем на Distribution Points

Важный момент - когда мы делаем Import Driver, если такой драйвер уже существует, импортирован повторно он не будет, не смотря на то, что у нас по умолчанию установлена опция 

Specify the option for duplicate drivers - Import the driver and append a new category to the existing categories

При этом, когда мы начинаем собирать Driver Package, все драйверы, входящие в его состав, будут скопированы в Driver Package Source Path. 

Для наглядности процесса импорта драйверов и работы с дубликатами, создадим в Driver Source Path два каталога с драйверами:

1. HP Envy - уникальный драйвер Intel Discrete LAN, общий драйвер Realtek Audio
2. Lenovo P360 - уникальный драйвер Broadcom Discrete LAN, общий драйвер Realtek Audio 

Начинаем импортировать драйверы для HP Envy, задаем категорию по названию модели оборудования и сразу же создаем Driver Package:

Процесс импорта драйверов можно посмотреть в логе DriverCatalog.log. Посмотрим в него, когда начнем импортировать дубликаты драйверов.

Начинаем импортировать драйверы для Lenovo P360, используя опцию Import the driver and append a new category to the existing categories. Зададим для импортируемых драйверов категорию по модели.

Первые 3 драйвера у нас совпадают с теми, что мы уже импортировали для HP Envy. Посмотрим в лог DriverCatalog.log:

Мы видим, что часть драйверов уже содержится в каталоге. Давайте посмотрим в Driver Package Source:

Здесь мы видим дубликаты, видим, что размер совпадает. Теперь давайте посмотрим, что у нас в Driver Catalog со стороны Configuration Manager:

Здесь мы не видим дубликатов, видим только, что к дубликатам просто добавилась новая категория, а вот Driver Source Path у нас ссылается на HP Envy.

Давайте посмотрим в Driver Package:

Здесь мы видим ту же самую картину - Driver Source Path разный, хотя Driver Package Source у нас дубликаты содержит.

Откуда взялась идея всего этого разбора и дальнейших действий по импорту дубликатов? Так вышло, что на некоторых томах файлового сервера была включена Дедупликация, которая не поддерживается для Source в Configuration Manager. Исключения были сделаны некорректно, потому что для их добавления, сначала нужно было полностью отключить дедупликацию, дождаться обработки, сделать исключения и только потом включать дедупликацию обратно.

Так вышло, что часть драйверов находились "в дедупликации", а часть были полноценными. Собирался "кривой" пакет и на выходе мы получали не очень работоспособную ОС.

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

Для большого количества нового оборудования нужно было разместить новые драйверы в Driver Source Path на томе без дедупликации, Driver Package Source так же разместить на томе без дедупликации, а так как драйверы имели дубликаты, необходимы было принудительно импортировать их в Driver Catalog.

Здесь важно понимать, как Configuration Manager определяет, что драйвер является дубликатом: Configuration Manager считает "master hash" для каждого каталога, если такой же уже есть - это дубликат. Все, что нам нужно сделать - это, например, добавить в каждый каталог драйверов пустой/файл с одним символом и мы получим уникальный "master hash":

Импортируем из нового Driver Source Path те же самые драйверы:

Все импортируемые драйверы уже есть в Driver Catalog, но для Configuration Manager дубликатами они теперь не являются.

BAT-скрипт для создания файлов в подкаталогах с точкой внутри:

@ECHO OFF

for /f "tokens=*" %%G IN ('dir /ad /b /s') DO (

echo . > "%%G\%~n0.txt"

)

Файл будет создаваться по имени BAT-скрипта.

Вы еще не общаетесь по HTTPS? Тогда мы идем к вам. Часть 1.

Всем привет. Вчера в очередной раз переводил инфраструктуру на HTTPS и подумал, что мой step by step guide может оказаться полезным для сообщества, пообещал в telegram чате выложить.

Про публикацию CRL и обработку IIS знака + есть по ССЫЛКЕ

Во второй части расскажу про закручивание гаек и переходу на TLS 1.2 only.

Корректировать текст не буду, оставлю все, как есть. Писал по заказу.

Если у вас имеются устаревшие ОС – Windows 7/2008/2008r2, а задачи отключить все протоколы, кроме TLS 1.2 нет, вам необходимо удостовериться, что со стороны серверов SCCM присутствует поддержка устаревших протоколов ssl 3.0/tls 1.0/tls 1.1

Если вы не добавите поддержку TLS 1.2 (не обязательно делать протоколом по умолчанию), то потеряете устаревшие ОС из управления.

Рекомендации по включению/переходу на TLS 1.2 будут позже.

Включить/отключить устаревшие протоколы можно, например, через IISCrypto (https://www.nartac.com/Products/IISCrypto/Download)

Для перехода на https на корпоративном PKI создать 3 шаблона и 2 AD группы:

1. IIS Servers template (+ad группа (sccm_iis_servers), в которую будут включаться все серверы с ролью IIS (dp, mp, sup,…). Шаблон создается как Duplicate Web Server template. Убедиться, что Compatibility Settings Certification Authority – Windows Server 2003, Certificate Recipient – Windows XP / Server 2003, на вкладке General задать имя шаблона, срок действия сертификата и Renewal период. Убедиться, что на вкладке Request Handling не установлена опция Allow private key to be exported. На вкладке Subject Name выбрать Supply in request. На вкладке Security добавить созданную AD группу sccm_iis_servers, добавить права enroll. В целях безопасности, можно забрать/наделить правами другие группы.
   
   
2. DP/OSD template (+ad группа (sccm_dp_servers), в которую будут включаться все серверы с ролью Distribution Point. Шаблон создается как Duplicate Workstation Authentication template. Убедиться, что Compatibility Settings Certification Authority – Windows Server 2003, Certificate Recipient – Windows XP / Server 2003, на вкладке General задать имя шаблона, срок действия сертификата и Renewal период. Убедиться, что на вкладке Request Handling установлена опция Allow private key to be exported. На вкладке Subject Name выбрать Supply in request. На вкладке Security добавить созданную AD группу sccm_dp_servers, добавить права enroll. В целях безопасности, можно забрать/наделить правами другие группы, в частности надо убрать права у Domain Computers.
   
   
3. Client certificate template. Шаблон создается как Duplicate Workstation Authentication template. Убедиться, что Compatibility Settings Certification Authority – Windows Server 2003, Certificate Recipient – Windows XP / Server 2003, на вкладке General задать имя шаблона, срок действия сертификата и Renewal период. Убедиться, что на вкладке Request Handling не установлена опция Allow private key to be exported. На вкладке Subject Name выбрать Build from this Active Directory information и выбрать только опцию DNS name. На вкладке Security для группы Domain Computers установить разрешающие права Read, Enroll, Autoenroll

После создания шаблонов, их нужно активировать: нажать правой кнопкой мыши на Certificate Templates – New – Certificate Template to Issue – выбрать 3 созданных шаблона и нажать Ok.
После добавления серверов в AD группы их необходимо перезагрузить, что бы обновить членство в группах.


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


Создаем новую групповую политику и делаем ей Link на необходимые OU:


Computer configuration – Windows Settings – Security Settings – Public Key Policies – Certificate Services Client – Auto-Enrollment


• выбрать Configuration model – Enabled
• выбрать Renew expired certificates, update pending certificates, and remove revoked certificates
• выбрать Update certificates that use certificate templates

Далее необходимо выпустить сертификаты для серверов, с ролью IIS/DP. Для DP можно выпустить только один сертификат и использовать его везде, так как он используется только во время для OSD, при чем клиентом. Можно избежать пункта 1.b. (DP/OSD template), но для порядка можно везде свои сертификаты.

1. Открываем на сервере оснастку Certificates
2. Кликаем правой кнопкой мышки на Personal – Certificates – All tasks – Request new certificate
3. Выбираем шаблон сертификата для IIS серверов и для DP, если сервер так же является DP
4. Кликаем на шаблоне для IIS серверов More information is required to enroll for this certificate. Click here to configure settings.
5. На вкладке Subject выбираем Alternative name – type DNS и добавляем 2 значения для сервера – netbios name, fqdn (например sccm01, sccm01.test.lab)
6. На вкладке General можно так же указать friendly name для сертификата
7. Выпускаем сертификаты
8. Экспортируем сертификат, выпущенный по шаблону DP/OSD Template вместе с закрытым ключом. Это необходимо проделать либо для каждой DP, либо для какой-то одной.

Далее необходимо сделать bind выпущенных сертификатов на серверы с ролью IIS:

1. Открыть оснастку Internet Information Services (IIS) Manager
2. Кликнуть правой кнопкой мыши на Default Web Site – Edit Bindings
3. Выбрать https/443 – SSL certificate
4. Указать сертификат, выпущенный по шаблону IIS Servers template

На серверах с ролью Software Update Point дополнительно нужно сделать bind сертификата на сайт WSUS Administation:

1. Открыть оснастку Internet Information Services (IIS) Manager
2. Кликнуть правой кнопкой мыши на WSUS Administation:– Edit Bindings
3. Выбрать https/8531 – SSL certificate
4. Указать сертификат, выпущенный по шаблону IIS Servers template
5. Для виртуальных директорий APIRemoting30, ClientWebService, DSSAuthWebService, ServerSyncWebService, SimpleAuthWebService выбрать SSL Settings, установить опцию Require SSL и Client Certificate – Ignore, после каждого действия нажимать Apply

Далее на всех серверах с ролью Software Update Point необходимо конфигурирование через wsusutil.

C:\program files\update services\tools\wsusutil.exe configuressl fqdn-sup-server

Результатом должно быть URL: https://fqdn-sup.server:8531

Далее переключаем SCCM на HTTPS:

1. В свойствах сайта Client Computer Communication выбираем HTTPS only
2. Если у вас корректно сконфигурирована публикация CRL, то отметить опцию Clients check the certificate revocation list (CRL) for site systems
3. Trusted Root Certification Authorities – добавить открытые ключи всех CA, которые выпускают сертификаты для SCCM (Root, Issuing, …)

На каждой Distribution Point:

1. Заходим в свойства – General и выбираем HTTPS
2. Выбираем Import Certificate и указываем экспортированный сертификат по шаблону DP/OSD Template. Можно использовать один и тот же сертификат для всех DP. Иногда при импорте с удаленной консоли возникает ошибка импорта, поэтому сертификат лучше импортировать с консоли на сайт-сервере.

• В свойствах каждой Management Point указываем Client Connection – HTTPS (логи mpsetup.log, mpcontrol.log)
  
  
• В свойствах каждой Software Update Point выставляем опцию Require SSL communication to the WSUS server

Так как у вас в цепочке сертификата имеется Root CA и Intermediate CA, то на Management Points необходима настройка Schannel provider trust mode:

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL] - "ClientAuthTrustMode"=dword:00000002

Подробности по ссылке - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831771(v=ws.11)?redirectedfrom=MSDN

На этом переключение на HTTPS закончено.

Пора переходить на HTTPS. WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED

В марте 2021 года был первый официальный анонс, что HTTP client communication теперь в статусе deprecated, а первый релиз после 1 ноября 2022 года выйдет без данного функционала.

Посмотреть список всех Deprecated features можно по ссылке

Выхода два: использовать Enhanced HTTP, либо использовать существующий/разворачивать новый корпоративный PKI. Более защищенный вариант - использовать корпоративный PKI. 

В случае с корпоративным PKI - необходимо создать шаблоны для серверов с IIS, для DP (на самом деле этот сертификат нужен клиенту во время OSD, закрытый ключ - экспортируемый), для клиентов, а если используете 3rd party update - сертификат для WSUS Code Sign (если хочется использовать от корпоративного PKI, а не самоподписанный). WSUS Code Sign сертификат устанавливается через SCUP.

После этого настроить Autoenroll сертификатов для клиентов - указать в шаблоне, что по нему можно делать Autoenroll, в групповой политике включить этот самый Autoenroll, переключить Communication со стороны сайта в HTTPS Only, Management Point Communication автоматически переключится в HTTPS, подкинуть сертификаты на DP, сделать везде биндинг сертификатов на IIS, переключить WSUS Communication в HTTPS, подправить ssl через wsusutil и радоваться жизни.

Но тут я развернул лабу в HTTP и решил переключить ее в HTTPS, никакого PKI не было, поднял его, сделал выгрузку CRL в папку, создал виртуальную директорию на IIS на эту папку, указал путь в сертификатах до CRL, ткнул на CA опубликовать CRL, они появились, по http доступны, со стороны ConfigMgr все переключил в HTTPS, а клиенты не хотят общаться с Management Point, в CCMMessaging.log видим WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED

И оно вроде бы как намекает, что что-то не так с Certificate Revocation List (CRL), но отовсюду доступно. 

И вот одна маленькая настройка в IIS выпила много моей крови... Решением проблемы было выбрать виртуальную директорию с CRL, перейти в Configuration Editor, выбрать секцию system.webServer/security/requestFiltering, установить allowDoubleEscaping в значение True, нажать Apply и радоваться жизни. 

Виной всему наличие знака + в названии Delta CRL файла.

"BSOD" до ввода Bitlocker PIN

Просто из заметок и опыта.

Никогда такого не происходило на подготовленном корпоративном образе/wim, но частично левые 1607/1809 (LTSC) при загрузке, если OS Drive зашифровали битлокером, выдают просто синий экран и только. По факту, если набрать PIN и нажать enter - все хорошо, продолжаем загрузку, но мы видим просто синий экран.

Как итог - проблема со шрифтами. Лечится одной командой в cmd от имени Администратора:

bfsvc.exe %windir%\boot /v

По итогу:

Именно из cmd, из pwsh придется пострадать.

 

Pre-provision Bitlocker во время OSD

Если вам захотелось сделать Pre-provision Bitlocker во время OSD и получить, например, зашифрованный OS Drive на выходе со стандартным ПИН-кодом, у меня для вас кое-что есть.

Мы имеем очень просто тестовый Task Sequence, SCCM 2107

Нас интересуют два шага:

1. Pre-provision Bitlocker
2. Enable Bitlocker

В документации (два пункта выше - кликабельны в офф документацию) есть описание этих двух шагов, но нет одной маленькой детали.

На шаге Enable Bitlocker имеем вот такую картину, ПИН-код установлен 9753 (менее 4х символов ПИН-код не принимается и подсвечивает красным:

Начинаем установку тестовой ВМ и получаем ошибку на шаге Enable Bitlocker

Идем смотреть в smsts.log и видим там немного подробностей

Ошибка в явном виде мало о чем говорит, но методом проб и ошибок выясняется, что на шаге Enable Bitlocker минимальная длина ПИН-кода все таки 6 символов, а не 4, после которых он начинает его принимать, так же визард спокойно примет ПИН-код 1234, но дальше вас тоже будет ждать разочарование.

В документации нигде не описана минимальная длина ПИН-кода для шага Enable Bitlocker, потому что в политике можно указать минимульную длину 4 символа и спокойно зашифровать раздел с ПИН-кодом 9753, визард так же не проводит никаких проверок, кроме минимальной длины в 4 символа.

Ради интереса я попробовал задеплоить политику Bitlocker, где явно указано, что длина ПИН-кода должна быть минимум 4 символа на коллекцию All unknown computers. Результата так же не дало.

Циклы установки обновлений на рабочие станции

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

• 1 часа в обеденный перерыв может быть недостаточно для установки обновлений
• Пользователь выключает ПК после рабочего дня (особенно ноуты)
• Пользователь выключает ПК на выходные

Как итог - имеем никогда не устанавливающиеся обновления, потому что доступного окна никогда нет. Если мы используем дедлайны и указываем, что при наступлении дедлайна принудительно устанавливать обновления - это опять таки немного выбивается из "не затрагивать пользователя в рабочее время".

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

Итак, как мы знаем, Patch Thuesday происходит во второй вторник месяца. Мы запускаем ADR для рабочих станций каждое 15е число месяца в 06-00. 

Почему 15е число? Потому что 2й вторник бывает максимум 14го числа. У нас есть как минимум один день, что бы узнать, что какие-то обновления вызывают какие-то проблемы и притормозить цикл даже для первой волны.

Мы используем 3 волны обновлений:

1. Тестовые виртуальные машины + несколько некритичных машин (это можеть быть моя вторая машина, например). На данном этапе мы проверяем только то, что обновление устанавливается, машина не падает в BSOD, возможны какие-то мелкие проверки. Я рекомендую НИКОГДА не использовать для первой волны тестирования машины технической поддержки. Это очень распространенная практика, но при таком раскладе можно получить ситуацию, что вся ТП останется без своих рабочих станций. Буквально недавно был случай с 1607 LTSB, которая после установки CU падала в BSOD.
2. Вторая волна обновлений включает в себя около 10-15% рабочих станций организации. В идеале туда должны входить рабочие станции с ПО, которое необходимо проверять после установки обновлений, в случае неудачного обновления, что бы этим ПО можно было воспользоваться где-то еще в отделе, но это утопия. Вторая волна обновлений формировалась по принципу лояльности пользователей - мы выкатили патчи с available периодом в 1 неделю и посмотрели, кто ставит патчи вручную, среди этих пользователей и была сформирована вторая волна обновлений.
3. Массовый деплой обновлений на все рабочие станции.

Сами циклы обновлений по расписанию (даты могут быть изменены, суть в количестве дней - 1, 7, 5 на добровольную установку):

Волна 1. 15 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 16 числа 06:00, далее дедлайн.

Выдерживаем паузу в 3 дня, что бы опять же почитать новости/community/посмотреть на машины первой волны.

Волна 2. 18 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 25 числа 06:00, далее дедлайн.

Волна 3. 25 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 30 числа 06:00, далее дедлайн.

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

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

После установки обновлений мы не подавляем перезагрузку, а даем 12 часов на ребут (в политике агента Computer Restart). 

Бывает не очень удобно, когда цикл выпадает на выходные дни. Тут бы, конечно, могли помочь окна, но есть свои но. Всегда найдется кто-то, кто вышел поработать специально в выходной день, а мы тут со своим ребутом и патчами.

Кастомизация пользовательского окружения Windows. Startmenulayout.

Давно обещал сообществу написать стать/несколько статей по кастомизации пользовательского окружения. Сразу оговорюсь, что я буду описывать большую часть настроек, которые делаются локально/в default профиль. Почему? Потому что очень часто бывает диалог:

- А как сделать вот эту штуку юзеру?

- Через GPO

- У меня нет прав в GPO

От части, я тоже в свое время столкнулся с подобным и костылил все настройки локально, но в будущем большая часть настроек была все же перенесена в GPO, когда такие права появились.

Из полезного, можно почитать про mandatory profile (ссылка), default profile (реестр, файлы - об этом позже), lgpo (ссылка)

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

Bitlocker+Legacy-MBR

Сегодня ТП пришла с проблемой - налили ноут HP, включили Bitlocker, задали ПАРОЛЬ 12345678, при каждой перезагрузке просит recovery key. 

Такое уже проходили и сразу на ум пришло, что:

1. TPM либо нет, либо отключен, но у нас разрешен пароль, если нет TPM

2. Раз падает в recovery - 146% налили ноут в legacy

Пункт два подтвердился. Заходим в Панель управления, настройки Bitlocker и делаем Приостановить защиту. Далее в cmd от Администратора

 mbr2gpt /convert /allowfullos

Перезагружаемся, выставляем в BIOS грузиться в UEFI. Система грузится в UEFI, отлично.

Идем обратно в Панель управления, настройки Bitlocker и нажимаем Возобновить Bitlocker и получаем ошибку. Подумалось, что проблема из-за того, что был установлен пароль с последовательностью, а TPM не позволяет использовать последовательность из 3х цифр для PIN кода. Жму изменить PIN и тоже получаю ошибку.

Идем в mmc - управление TPM и видим, что TPM не готов к работе. Жмем подготовить, получаем сообщение, что TPM готов к работе, но с ограничениями. Жму сбросить, ребут - без изменений, не готов к работе.

Идем в настройки BIOS (а так как я пока что работаю из дома, попросил показать по видео, что там происходит). А там конечно же не стоит галка TPM State, включаем галку и TPM говорит, что готов к работе.

Идем обратно в панель управления, нажимаем Возобновить Bitlocker и получаем ошибку "Системе на удалось найти указанный файл". Хмммм. Пробуем через cmd от Администратора

 manage-bde -status c:

Говорит, что полностью зашифровано, но приостановлено.

 manage-bde -resume c:

Что-то вроде до автоматического включения осталась одна перезагрузка. Ребутаемся - опять говорит, что осталась одна перезагрузка.

1. Идем в c:\windows\system32\recovery

2. Переименовываем файл ReAgent.xml, во что-то вроде _ReAgent.xml

3. Идем в панель управления, настройки Bitlocker, Возобновить

4. Радуемся

Проблема - в файле остались GUID'ы старого раздела, когда он был еще в MBR. Новый ReAgent.xml будет создан автоматически.

MBAM и Enhanced HTTP, лайфхак

Как известно, для использования MBAM в SCCM необходимо, что бы Management Point был настроен по HTTPS. 

Во время разворачивания лабы надо было быстро проверить MBAM на 2002, а PKI разворачивать не очень хотелось.

Enhanced HTTP - released feature начиная с версии 1810, позволяющая следующее:

• You can secure sensitive client communication without the need for PKI server authentication certificates.
• Clients can securely access content from distribution points without the need for a network access account, client PKI certificate, and Windows authentication.

Более подробно - в документации

В одном из сценариев указано, что можно использовать для связи клиента с Management Point.

Идем в свойства сайта, переходим на вкладку Communication Security и выставляем галку 

Use Configuration Manager-generated certificates for HTTP site systems:

При этом в свойствах Management Point у нас остается Client Connection HTTP:

Идем в IIS и смотрим Bindings Default Web Site, видимо, что на 443 порту установлен сертификат SMS Role SSL Certificate:

Нажимаем View, переходим на вкладку Details, Copy to file и сохраняем сертификат.

Вешаем политику MBAM с шифрованием системного диска на коллекцию, запускаем цикл Machine Policy и смотрим в лог BitlockerManagementHandler.log, где видим, что агент MBAM успешно установлен, но на шаге Checking for recovery service at https://lab-sccm.lab.local/SMS_MP_MBAM/CoreService.svc получаем ошибку:

Идем на клиента, берем сохраненный SMS Role SSL Certificate и импортируем его в Доверенные корневые центры сертификации

Запускаем на клиенте Панель управления - Configuration Manager - Конфигурации наш Bitlocker Compliance, смотрим в BitlockerManagementHandler.log еще раз:

Порталы так же устанавливаются и работают:

А вот с IBCM у меня не взлетает, ругается:"Unable to find suitable Recovery Service MP".

Будем посмотреть.

PKI, SHA-256 и вот это все

Пришло время написать что-нибудь, т.к. 4 месяца не видел в глаза SCCM, а потом 4 месяца внедрял SCCM и времени писать особо не было. Было много интересного, постараюсь время от времени делиться.

Очень я своевременно про Windows 7, но просто полезно для понимания.

Имели SCCM 1906, в новогодние праздники по традиции решили обновиться до 1910, т.к. сильно хочется MBAM. Обновились, заодно переехали на HTTPS, задеплоили нового агента на препрод, погоняли и поставили галку автообновления агента в течение 2х недель.

Проходит 2 недели и я вижу, что очень много клиентов не обновилось. Начинаю разбираться в чем дело и понимаю, что проблема на 99% Windows 7, на остальных системах проблемы нет. Стучусь с клиента на Win10 на DP по https и вижу, что сертификат подменяется Касперским. Ну, думаю, дело в шляпе, буду просить ИБ удалить Каспера. Стучусь с Win7 и вижу, что сертификат подменяется DLP. Радости нет предела. Выясняем, что на Win7 стоит версия Каспера, которая не умеет подменять сертификат, но все равно удаляем Каспера и DLP. Результата никакого.

Шаблон сертификата на всех машинах одинаковый, выпускающий CA один и тот же, на клиенте сертификат присутствует, в логах агента SCCM сертификат проходит все проверки, но во время скачивания контента видим в логе DataTransferService.log на клиенте следующие ошибки:

 Failed in WinHttpSendRequest API, ErrorCode = 0x2efe  
 Successfully queued event on HTTP/HTTPS failure for server 'sccm-dp01.domain.local'.     DataTransferService     21.01.2020 13:08:59     3788 (0x0ECC)  
 Error sending DAV request. HTTP code 0, status ''     DataTransferService     21.01.2020 13:08:59     3788 (0x0ECC)  
 GetDirectoryList_HTTP mapping original error 0x80072efe to 0x800704cf.     DataTransferService     21.01.2020 13:08:59     3788 (0x0ECC)  
 GetDirectoryList_HTTP('https://sccm-dp01.domain.local:443/SMS_DP_SMSPKG$/Content_89021bf8-df78-4d5e-9ae1-c02fce8317fb.1') failed with code 0x800704cf.     DataTransferService     21.01.2020 13:08:59     3788 (0x0ECC)  

Со стороны IIS на DP было видно:
403 7 5 1390 2, что говорит нам 403.7 Forbidden: Client Certificate Required 

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

При этом я вижу около 10 машин на Win7, на которых проблемы нет, агент успешно обновился, любой софт ставится.

Отмечу сразу, что 7ки с проблемами не обновлялись от слова совсем. Прикатил туда все патчи - без результата, т.к. подозрение пало на отсутствие поддержки SHA-256. Развернул чистую 7ку без софта от ИБ, пропатчил и тоже без результата.

Добрый PFE из MS говорит, что надо брать в руки Wireshark и смотреть, что происходит, но сразу я его конечно же не послушал и проводил бесконечные эксперименты. В итоге беру Wireshark и вижу, что в момент согласования я получают от DP - RESET. Начинаю смотреть внимательно и вижу, что в списке допустимых алгоритмов почему-то не наблюдаю SHA-256, перепроверяю наличие патчей - установлены:

Приглядевшись еще внимательнее я вижу, что согласование пытается пройти по SSL3 и TLS 1.0 , и тут коллективный разум в лице @skorotkov спрашивает, какая ОС у меня на DP, на что я сообщаю, что Win 2019. Он просит показать вывод IISCrypto - скачать можно по ссылке https://www.nartac.com/Products/IISCrypto/Download

Вывод, собственно, таков:

Думаю, теперь всем всё понятно. На Win 2019 по умолчанию включен только TLS 1.2, а на Win 7 у меня было две проблемы - отсутствовала поддержка SHA-256, т.к. не были установлены обновления и не был включен TLS 1.2

Про включение TLS 1.2 тут https://docs.microsoft.com/en-us/configmgr/core/plan-design/security/enable-tls-1-2-client

Выражаю огромную благодарность Community по SCCM, в частности @skorotkov и @quantum_yupiter