Windows Hello за бизнеса: Пълно ръководство за SSO и хардуерна сигурност

Windows Hello за бизнес Той се превърна в ключов компонент на стратегията на Microsoft за работа без пароли: комбинира ПИН кодове, биометрия и криптографски ключове, така че потребителите могат да влизат без да въвеждат пароли, но с много по-високо ниво на сигурност. Всичко това се поддържа от Хардуерна сигурност, TPM и съвременни модели на SSO както в облака, така и в хибридни и локални среди.

Далеч не е просто „ПИН кодът на Windows“, Windows Hello за бизнеса (WHfB) Това е разпределена система, която интегрира Microsoft Entra ID (преди Azure AD), Active Directory, PKI, Kerberos, FIDO2 и разширени политики за устройства и потребители. Ако сте администратор на Windows или самоличност, разбирането как всичко се вписва заедно – регистрация, осигуряване, синхронизиране на ключове, сертификати и удостоверяване – е от съществено значение за безпроблемното и ефективно внедряване. Надежден и устойчив на фишинг единичен вход.

Какво точно е Windows Hello за бизнеса и как променя удостоверяването?

Windows Hello за бизнес Това е корпоративната и управлявана версия на Windows Hello. Тя замества паролата с идентификационни данни с публичен ключ, свързани с устройството, защитени от TPM и отключени с ПИН или биометричен жест. Тези идентификационни данни позволяват удостоверяване срещу Идентификатор за вход в Microsoft, Active Directory или AD FSуслуги, които разчитат на тях.

Вместо да разчита на споделени тайни (пароли, еднократни пароли, SMS кодове), WHfB генерира двойка публичен/частен ключ за всеки потребител и устройство. Публичният ключ се регистрира при доставчика на самоличност (IdP), а частният ключ остава сигурно съхранен на устройството и не може да бъде експортиран. Потребителят предоставя само „ентропия“ със своя ПИН или биометрични данни, за да освободи този частен ключ, когато иска да се удостовери.

Резултатът е преживяване за удостоверяване устойчив на фишинг, кражба на идентификационни данни и атаки с груба силаПоддържане на SSO както в облака (Microsoft 365, съвременни приложения), така и в локални услуги (Kerberos, наследени приложения, VPN мрежи, базирани на сертификати и др.).

Вътрешни фази на Windows Hello за бизнеса: От нула до SSO

За да разберете напълно WHfB Препоръчително е работата му да се раздели на няколко хронологични фази: регистрация на устройството, осигуряване, синхронизиране на ключове (ако е приложимо), записване на сертификат (ако се използва) и накрая, ежедневно удостоверяване.

1. Регистрация на устройство

Първо, екипът трябва да премине през процес на регистрация на устройствоТази стъпка свързва устройството с конкретен IdP и му дава собствена идентичност:

• Облачни или хибридни внедряванияIdP е Microsoft Enter ID и устройството е регистрирано в услугата за регистрация на устройства.
• Чисто локални имплементацииIdP е AD FS и регистрацията се извършва спрямо услугата за регистрация на корпоративни устройства, предоставена от AD FS.

След регистрацията, устройството има доверена самоличност което му позволява да се удостовери с IdP, когато потребител влезе. Съществуват различни видове регистрация (присъединяване към домейн, присъединяване към Microsoft Login, лична регистрация и др.), известни като типове връзки или „типове съединения“, които определят последващото поведение на WHfB и SSO.

2. Фаза на обществените поръчки

По време на осигуряването, потребителят престава да бъде „потребител с парола“ и става потребител със собствена парола. Контейнер за Windows Hello на устройството. Този контейнер групира криптографския материал, свързан с вашите акаунти (корпоративни, образователни, лични), изолирано по доставчик на самоличност.

Типичният поток на доставки Следвай тези стъпки:

1. В асистента за потребителско изживяване (CXH), потребителят се удостоверява с IdP, използвайки МВнР (обикновено потребителско име/парола плюс втори фактор).
2. След преминаване на MFA, системата подканва потребителя да конфигурира PIN и, ако е наличен съвместим хардуер, един или повече биометрични жестове (лице, отпечатък).
3. Контейнерът Windows Hello е създаден на устройството.
4. Екипът генерира двойка публичен/частен ключ за удостоверяване, за предпочитане свързан с TPM; ако няма TPM, той е защитен чрез софтуерно криптиране.
5. Частният ключ се съхранява локално, запечатва се от TPM, когато има такъв, и се маркира като не може да се изнася.
6. Публичният ключ е регистриран в IdP, свързан с потребителския акаунт:
   • В облачни среди услугата за регистрация на устройства го записва в потребителския обект Microsoft Enter ID.
   • В локални сценарии AD FS съхранява ключа в Active Directory.

От този момент нататък, когато потребителят отключи устройството с ПИН или биометрични данни, той всъщност „задейства“ използването на този частен ключ на Hello да докажат самоличността си пред IdP.

3. Подробности за контейнера на Windows Hello и типове ключове

Контейнерът на Windows Hello не съхранява само един ключ: той може да съдържа различни видове криптографски материалиВсеки един има своя собствена функция и свой собствен „защитник“. Всеки защитник криптира своето копие на ключа за удостоверяване с различна техника (например, запечатване в TPM, използвайки ПИН като ентропия, или симетрично криптиране, получено от ПИН, ако няма TPM).

Вътре в контейнера можем да намерим:

• а основен ключ за удостоверяванеВинаги се създава асиметрична (публична/частна) двойка по време на регистрацията. Това е двойката, която трябва да се отключва всеки път с ПИН или биометрични данни. Ако потребителят нулира ПИН кода, a Нова парола и целият материал, който предишният е защитил, се криптира отново с новия.
• Един или повече ключове за идентификация на потребителя (Ключове за потребителски идентификатор): Те могат да бъдат симетрични или асиметрични в зависимост от IdP и модела на доверие. В имплементации, базирани на сертификати, тези ключове се използват за генериране на заявки към CA или за RDP, VPN и др.
• По желание, a административен ключ, предназначени за сценарии за нулиране (напр. възстановяване на ПИН) и данни, свързани с TPM на устройството.

Ключовете за идентификация на потребителя се използват за демонстриране на притежанието на частния ключ пред услугата (например подписване на nonce). Active Directory, Microsoft Entra ID и личните акаунти в Microsoft изискват асиметрични двойки ключове; устройството генерира двойката, записва публичната част и защитава частната част, която никога не напуска устройството.

Ако вашата организация има корпоративна PKI, можете да свържете ключове за идентификатор на потребителя към сертификати, издадени от вашия CAТова позволява на WHfB да се интегрира със сертификат-зависими приложения (класически VPN, RDP със смарт карти и др.). Ако не се нуждаете от PKI, IdP може самият да генерира и управлява този идентификационен материал, за да намали сложността.

4. Синхронизация на ключове в хибридни среди

В хибридни внедряванияКогато Microsoft Entra ID и Active Directory съществуват едновременно, е необходима допълнителна фаза: синхронизирайте публичния ключ Hello от облака към локалната директория, така че контролерите на домейни да могат да удостоверяват потребителите.

Публичният ключ се съхранява в атрибута msDS-KeyCredentialLink на потребителския обект в Active Directory, а синхронизацията се управлява от Синхронизиране на Microsoft ConnectБез тази репликация би било невъзможно за локален домейн да провери удостоверяване, базирано на WHfB, от устройство, присъединено към Microsoft Entra.

5. Регистрация на сертификат (при използване на Certificate Trust)

В модели, където WHfB разчита на сертификати за Kerberos удостоверяване или локални приложенияПоявява се допълнителен етап: регистрация на сертификати.

След като ключът е регистриран, клиентът генерира заявка за сертификат и я изпраща до орган за регистрация на сертификати (CRA)Сертификатният упълномощен орган (CA) обикновено се намира на AD FS сървъра и оркестрира заявката към корпоративната PKI. CA издава сертификата, който се съхранява в контейнера Hello на потребителя на устройството и се използва за удостоверяване към локални ресурси, които очакват сертификат за смарт карта или подобен.

Ежедневно удостоверяване, SSO и ролята на хардуерната сигурност

В ежедневиетоКогато потребителят включи или отключи компютъра, удостоверяването винаги се основава на поверителната част от идентификационните данни за Windows Hello (ключ или сертификат), плюс жеста на потребителя (ПИН или биометрични данни). Този жест никога не се изпраща до доставчика на идентификационни данни, нито се съхранява като такъв в системата.

Удостоверяването е, де факто, два фактора:

• Нещо, което потребителят притежава: ключът или сертификатът, свързан с устройството.
• Нещо, което потребителят знае или е: локален ПИН код или биометрични данни.

Когато потребителят въведе ПИН кода или използва разпознаване на пръстови отпечатъци/лице, Windows освобождава ключа за удостоверяване от контейнера му и го използва за криптографски подписва данни, изпратени до IdPДоставчикът на самоличност проверява този подпис спрямо съхранения публичен ключ и, ако всичко съвпада, издава маркерите, необходими за достъп до ресурси (Microsoft 365, SaaS приложения, локални ресурси и др.).

Нито ПИН кодът, нито биометричният шаблон излезте от устройствотоПИН кодът дори не се съхранява като текст: той служи като ентропия за криптографски операции и за отключване на защитени от TPM материали. IdP вижда само криптографско доказателство, че потребителят контролира регистрирания частен ключ.

Главен токен за обновяване (PRT) и модерно единично влизане (SSO)

El единичен вход В съвременния свят на Microsoft има ключов токен: Основен токен за обновяване (PRT)Това е JSON уеб токен, който включва потребителски и устройствани твърдения и позволява SSO за приложения, защитени от Microsoft Entra ID или AD FS.

PRT се получава при влезте или отключете устройството с надеждни идентификационни данни (WHfB или традиционни идентификационни данни), по начин, аналогичен на начина, по който Kerberos TGT беше получен преди това в локална среда. На устройства:

• Присъединете се към Microsoft. или хибриди, свързани с Microsoft Enter: PRT се издава при самото влизане в системата.
• Регистрирани лични устройства (BYOD): PRT се генерира, когато към устройството се добави служебен или образователен акаунт.

Без PRT, потребителите ще трябва непрекъснато да въвеждат идентификационни данни и правила за условен достъп въз основа на състоянието на устройството. не можеше да бъде оцененоС WHfB и валиден PRT се постига плавен SSO, който е обусловен и от състоянието на оборудването, съответствието, риска и др.

Ключови настройки на правилата: SSO и хардуерна сигурност

WHfB предлага широка гама от настройки на правилата както чрез CSP (за MDM като Intune), така и чрез GPO. Много от тях са фокусирани върху укрепване на SSO и гарантиране, че наличният хардуер за сигурност на устройството винаги се използва.

Задължително използване на хардуерни устройства за сигурност (TPM)

Една от най-важните политики изисква предоставянето на Windows Hello за бизнеса да се извършва само в устройства с използваем TPM (1.2 или 2.0)TPM осигурява допълнителна защита, защото частният ключ е свързан с този физически компонент; дори ако атакуващ копира диска, той няма да може да използва ключа на друг компютър.

Чрез CSP, тази конфигурация Контролира се от:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
• И, по избор, изключване на някои TPM 1.2 с:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12

Освен това има еквивалент на GPO в административните шаблони на Windows Hello за бизнес на ниво екип. Ако е активирано, Осигуряването на WHfB няма да е достъпно за оборудване без валиден TPM., като по този начин драстично се засилва безопасността на околната среда.

Конфигуриране на локално SSO: сертификат срещу доверие в облака

За SSO към локални ресурси (домейн контролери, локални приложения), WHfB може да използва три основни модела на довериебазирани на сертификати, базирани на ключове (Key Trust) и, по-скоро, Доверие към облачния Kerberos (доверие в облака).

Има две основни политики:

• Използване на сертификат за локално удостоверяване:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
  Ако е активирано, WHfB регистрира сертификат за вход в контейнера и го използва за локално удостоверяване.
• Използване на облачно доверие за локално удостоверяване:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
  Ако е активирано, WHfB използва Kerberos билет, получен от удостоверяване в Microsoft Entra ID, за удостоверяване спрямо локални ресурси, без да е необходимо издаване на допълнителни сертификати.

Деактивирането или неконфигурирането на тези правила кара системата да се върне към ключ или сертификатВ зависимост от другите активни опции. В GPO тези опции се намират в разделите „Компютър“ и „Потребител“ под „Компоненти на Windows“ > „Windows Hello for Business“.

Главен контрол: Активиране или деактивиране на Windows Hello за бизнеса

Съществува глобална директива, която определя дали дадено устройство използвайте WHfB или не И ако съветникът за осигуряване се стартира след влизане в системата:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

С тях можете:

• Изисквайте всички потребители да осигурят WHfB на устройството.
• Напълно предотвратявайте употребата на WHfB.
• Позволете на всеки потребител да реши дали иска да конфигурира Hello.
• Предотвратете автоматичното стартиране на съветника след първото влизане в системата, което е полезно, когато Използвате решение на трета страна да се осигури WHfB.

Политики за ПИН код, възстановяване и контрол на сложността

ПИН кодът за Windows Hello Това е един от стълбовете на решението. Въпреки че много хора го бъркат с „кратка“ парола, всъщност това е локален фактор, свързан с устройството, защитен от TPM и много по-малко използваем от традиционната парола.

Изтичане, история и продължителност на ПИН кода

Политиките за ПИН ви позволяват да коригирате жизнен цикъл и сложност подобен начин — макар и по-детайлно — на традиционните пароли:

• ИзтичанеМожете да настроите ПИН кода да изтича между 1 и 730 дни. Ако стойността е 0, ПИН кодът никога не изтича (стойност по подразбиране).
• рекорд: определя колко предишни ПИН кода не могат да бъдат използвани повторно, между 0 и 50. Стойност 0 означава, че не се съхранява история.
• Минимална и максимална дължина: конфигурируем минимум от 4 знака; максимум до 127, като винаги се спазва изискването минималното значение да е по-малко от максималното и че по подразбиране, ако не е конфигурирано, се изисква минимум 6 знака.

Ако тези правила не са зададени, поведението по подразбиране позволява до 127 знака и изисква ПИН от поне 6, без допълнителни изисквания освен правилата за сложност, които дефинирате.

Изисквания за съставяне на ПИН код

можеш да решиш Какви типове знаци се приемат и кои са задължителни в ПИН кода за Windows Hello?

• ЦифриАко активирате правилото да изисква цифри, ПИН кодът трябва да съдържа поне една цифра. Ако го деактивирате, цифрите са забранени. Без тази настройка цифрите са разрешени, но не са задължителни.
• Малки букви: позволява ви да изисквате поне един, да ги забраните напълно или да ги оставите по избор.
• Letras mayúsculas: същата схема като при малките букви.
• Специални символи: поне един може да е задължителен, може да е забранен или може да е разрешен. Счита се за широк набор от символи (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Тези правила ви позволяват да регулирате баланса между използваемост и здравинаАко обаче сложността се прекали, рискът от забравяне на ПИН кодове и заявки за поддръжка се увеличава, нещо, което много организации се опитват да избегнат именно когато внедряват WHfB.

Възстановяване на ПИН код

La Възстановяване на ПИН код Това позволява на потребителя да нулира забравен ПИН код, без да губи свързани идентификационни данни или сертификати (включително ключове, свързани с лични акаунти на този компютър). За да направи това, Windows Hello криптира тайна за възстановяване, която се съхранява локално, така че само услугата за възстановяване и самото устройство могат да я дешифрират.

Тази функционалност изисква от потребителя да изпълни Многофакторно удостоверяване спрямо Microsoft Enter ID За да възстановите ПИН кода, ако активирате съответната политика (чрез CSP или GPO), Windows ще генерира и съхрани тази тайна за възстановяване; ако я деактивирате или я оставите неконфигурирана, устройството То нито ще създаде, нито ще запази Тайната и, в случай на забравяне на ПИН кода, потребителят ще трябва да го изтрие напълно и да си осигури нов, като се регистрира отново за услугите, до които предишният ПИН е давал достъп.

Биометрия, защита срещу измама и ESS

Биометрични данни в WHfB (Лице, пръстов отпечатък, ирис) е допълнение към ПИН кода, а не негов пълен заместител. Винаги има резервен ПИН код, когато сензорът се повреди или контекстът не позволява използването му.

Подобрена защита срещу спуфинг

Има специфична политика, която се изисква подобрена защита от спуфинг (подобрена защита от подправяне) при разпознаване на лица. Когато е активирана, Windows ще позволи удостоверяване на лице само ако сензорът и стекът отговарят на тези разширени изисквания за откриване на атаки (например, предотвратяване на влизане със снимки, видеоклипове или прости deepfakes).

Ако е деактивирано или не е конфигурирано, Windows няма да изисква тази засилена защита и лицевото удостоверяване ще бъде по-малко ограничаващо. Свързаният CSP маршрут е ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofing, а еквивалентът може да се намери и в GPO под опциите за биометрични данни на Windows Hello for Business.

ESS: Подобрена сигурност при влизане с периферни устройства

La Подобрена сигурност при влизане (ESS) Това е допълнителен слой, който комбинира VBS (Виртуализиране, базирано на сигурност), TPM 2.0 и специфични компоненти за изолиране на биометрични шаблони и операции за сравнение чрез хардуер.

С ESS се извършват биометрични данни (лице, пръстов отпечатък) и сравнения в изолирани и защитени области на паметтаТова са точки от данни, до които останалата част от операционната система няма директен достъп. Каналът между сензорите и алгоритъма също е защитен, така че злонамерен софтуер или атакуващи не могат да инжектират или възпроизвеждат фалшиви биометрични данни, за да симулират влизания или да блокират потребителите.

политика EnableESSwithSupportedPeripherals позволява две основни ценности:

• 0ESS е активиран дори ако има периферни или интегрирани сензори, които не поддържат ESS. Операциите за удостоверяване са разрешени с тези устройства, с определени ограничения. Това не е най-препоръчителната опция.
• 1ESS е активиран грях Приема периферни или интегрирани сензори, които не поддържат ESS. С други думи, биометричните операции от всяко устройство, което не поддържа ESS, са блокирани за Windows Hello. Това е конфигурацията с по-голяма сигурност.

Ако е деактивирано или неконфигурирано, на ESS устройствата ще Те блокират сензорите. които не са съвместими с ESS, като се поддържа консервативен подход към безопасността.

Използване на биометрия като цяло

политика UseBiometrics Контролира дали Windows Hello за бизнеса позволява използването на биометрични жестове или се поддържат само ПИН кодове. Ако е активирано или неконфигурирано, биометричните данни са разрешени; ако е деактивирано, използването им е забранено и потребителите винаги ще трябва да се удостоверяват с ПИН код. ПИН или други фактори.

Във всеки случай, биометрични данни:

• Те се съхраняват само на локалното устройство (база данни в C:\Windows\System32\WinBioDatabase).
• Всеки сензор има собствен файл и уникален, произволно генериран ключ, криптиран с AES в CBC режим и SHA-256 хеш.
• Те не се изпращат до външни сървъри или не се синхронизират между компютрите, което предотвратява създаването на единични точки за събиране от нападателите.

Интеграция със смарт карти и стари приложения

Много организации все още разчитат на смарт карти и приложения, които чакат сертификати от тип „смарт карта“WHfB включва опции за емулиране или интегриране с тези среди, без да губи предимствата на съвременното удостоверяване.

Емулация и изброяване на смарт карти

по подразбиранеWindows не позволява на потребителите на една и съща машина да виждат идентификационните данни за Windows Hello, предоставени за други потребители. Политика ви позволява да се откажете в сценарии, при които:

• Един и същ потребител може да има акаунти със и без привилегии на един и същ компютър.
• Той иска да влезе с „нормалния“ акаунт, но да повиши привилегиите си, преди да излезе, използвайки собствените си идентификационни данни за Hello.

Има и опция за Деактивиране на емулацията на смарт картаАко е активирано, WHfB идентификационните данни вече няма да са съвместими с приложения, които очакват смарт карта. Ако остане деактивирано или не е конфигурирано, Windows ще продължи да предоставя тази емулация автоматично.

Използвайте Hello сертификати като сертификати за смарт карти

Друга важна политика es UseHelloCertificatesAsSmartCardCertificatesАко е активирано, приложенията могат да обработват Сертификати за Windows Hello за фирми, като например сертификати за смарт карти.В този контекст обаче, биометричните фактори Не са налични когато се изисква оторизация за използване на частния ключ на сертификата.

Ако не е конфигурирано или е деактивираноПриложенията не използват Hello сертификати по този начин и биометричните данни остават достъпни за потребителя. Не е възможно тази опция да е активна едновременно с политиката, която деактивира емулацията на смарт карти.

Изисквания за PKI, CRL и сертификат за домейн контролер

В внедрявания, където WHfB трябва да осигури SSO за локални ресурси, използвайки сертификати и KerberosPKI инфраструктурата за сертификати трябва да бъдат правилно конфигурирани, особено ако има устройства, свързани само с Microsoft. Въведете който ще се удостовери в Active Directory.

Точка за разпространение на CRL, достъпна за устройства, свързани към Entra

Един от критичните моменти е списък с анулирани сертификати (CRL)Когато CA отмени сертификат, той добавя информация към този списък и Windows го проверява, за да провери дали сертификатът е все още валиден.

В много локални среди CDP (Точка за разпространение на CRL) се публикува като маршрут LDAP в Active DirectoryТова работи добре за машини, присъединени към домейн, но не и за устройства, присъединени само към Microsoft Entra, които не могат да четат Active Directory преди удостоверяване. Това създава кръгова зависимост: за да валидирате сертификата на домейн контролера, трябва да прочетете Active Directory, но не можете да четете Active Directory без първо да се удостоверите.

Решението е да се публикува CDP в уеб сървър, достъпен чрез HTTP (не HTTPS)което не изисква предварително удостоверяване. Типичната процедура включва:

• Инсталирайте IIS или друг уеб сървър на вътрешен сървър.
• Създайте виртуална директория (например, cdp), която сочи към споделена папка, където CA може да публикува CRL.
• Настройте разрешенията за NTFS и споделяне, така че CA да може да записва в тази папка.
• Създайте DNS запис (например, crl.midominio.com) сочещ към този сървър.
• Конфигурирайте климатика за излъчване, за да включите CDP HTTP в разширенията на издадените сертификати и да публикува CRL и delta CRL на това място.

след това Трябва да принудите публикуването на нов CRL и да проверите дали той е достъпен от браузър. http://crl.tudominio.com/cdp и прегледайте файловете .crl генерирани.

Преиздаване на сертификат за домейн контролер и стриктно KDC валидиране

Вече издадените сертификати не се актуализират автоматично с новия CDP; подновяват гиПо-конкретно, сертификатите на домейн контролер, използвани за удостоверяване чрез Kerberos. WHfB налага тази функция. „Стриктна проверка на KDC“ Когато устройство, присъединено към Microsoft Entra, се удостоверява срещу локален домейн, сертификатът за контролер на домена трябва да отговаря на няколко изисквания:

• Доменният контролер трябва да притежава частния ключ на представения сертификат.
• Коренният CA, издал сертификата за домейн, трябва да е в корени на доверието на устройството.
• Трябва да използвате Шаблон за сертификат за удостоверяване с Kerberosне стари шаблони.
• Сертификатът трябва да съдържа EKU на KDC удостоверяване.
• Алтернативното име на субекта трябва да съдържа DNS име, което съответства на името на домейна.
• Алгоритъмът за подпис трябва да бъде поне SHA256.
• Публичният ключ трябва да бъде 2048 бита RSA.

След конфигуриране на CA и подновяване на сертификатите на домейна, трябва да проверите в раздела с подробности за всеки сертификат дали е наличен правилният HTTP CDP. Това е жизненоважно за Устройства, свързани само с доверителни домейн контролери на Entra при удостоверяване с WHfB.

Внедряване на коренния сертификат на CA на устройства, присъединени към Entra

Накрая, устройства, свързани към Microsoft Entra Те трябва да се доверяват на коренния CA (централния CA) на компанията. Това се постига чрез експортиране на коренния сертификат от веригата на доверие на сертификата на контролера на доменното им име и разпространението му до компютрите, например чрез:

• Политика на сертификат за доверие в оборудването в Microsoft Intune, сочейки към довереното коренно хранилище на екипа.
• Или еквивалентни методи в други MDM/управлявани решения.

Ако тази стъпка бъде пропусната, дори ако всички останали елементи са правилно конфигурирани, устройствата няма да се доверяват на домейновите контролери и удостоверяванията с WHfB. Те ще се провалят на TLS/сертификатния слой.

Windows Hello за бизнеса носи значителен скок напред в сигурността и процеса на влизанеТой замества паролите с идентификационни данни, свързани с устройството, защитени от хардуер и управлявани централизирано, предлагайки модерно, устойчиво на фишинг единично влизане (SSO) както в облачна, така и в локална среда. За да работи наистина добре обаче, подготовката на инфраструктурата за идентичност и PKI трябва да се вземе сериозно, трябва да се дефинират подходящи политики за ПИН кодове, биометрия и задължително използване на TPM, и това трябва да бъде съпроводено с поетапно внедряване с ясна комуникация с потребителите, така че промяната да се възприема като подобрение, а не като поредно ИТ усложнение.