Пора переходить на 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). 

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