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

I'm alive, @skorotkov

@skorotkov - привет =)
Скоро я здесь что-нибудь начну писать

Обновление до Windows 10, ошибки на файлы lnk в папке Recent

Пока обновляли тестовую группу машин Window 7 до Windows 10, на паре машин столкнулся с проблемой: до первого ребута на машине валится таск, машина ребутится, делает откат, создается профиль username.000, даже если машину потом заапгрейдить еще раз, то часть приложений будет ссылаться на username000\*, часть на username\*, например, локальные pst в Outlook.

В логе %systemdrive%\$WINDOWS.~BT\Panther\setupact.log видим следующую ошибку:

Operation failed: First boot apply. Error: 0x8007042B[gle=0x000000b7]

Operation execution failed: 13. hr = 0x8007042B

ExecuteOperations: Failed execution phase Post First Boot. Error: 0x8007042B

Operation execution failed.

CSetupPlatformPrivate::Execute: Failed to deserialize/execute post-FirstBoot operations. Error: 0x8007042B

Persisting diagnostics data to C:\$WINDOWS.~BT\Sources\Diagnostics\diagnostics.dat

Diagnostics data saved successfully

SETUPPLATFORMCOMM: Progress message received: Phase: First Boot, Operation: Migrate data, Percentage: 58%

WINDEPLOY error code is 0x80004005. Will not attempt uninstall

В логе %systemdrive%\$WINDOWS.~BT\Panther\setuperr.log видим следующую ошибку:

Error 183 while applying object C:\Users\username\AppData\Roaming\Microsoft\Windows\Recent [022019.pdf.lnk]. Shell application requested abort[gle=0x00000002]

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

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

В каталоге Recent хранятся ссылки-ярлыки на недавно открытые документы. Это то самое, что можно увидеть в Пуск-Недавние документы или при правом клике на ярлык Word, закрепленного на панели задач - быстро открыть последние документы, открытые в приложении.

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

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

 cd $env:systemdrive\  
 $a=dir users  
 $a.fullname | %{remove-item ($_+"\appdata\roaming\microsoft\windows\recent\*") -Confirm:$false -Recurse}  

Скрипт пробегается рекурсивно по всем профилям в папке Users на системном диске, заглядывает в Recent и удаляет все оттуда.

После этого собираем пакет, указываем source folder с нашим скриптом, программы не создаем. Не забываем сделать Distribute Content на DP.

Далее создаем в TS для обновления ОС шаг - Run powershell script повыше Upgrade operating system и указываем пакет и имя нашего скрипта, Execution policy ставим в bypass:

После этого запускаем TS повторно, радуемся результату.