вторник, 28 апреля 2020 г.

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".
Будем посмотреть.

среда, 22 января 2020 г.

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