Włącz logowanie bez hasła przy użyciu klucza zabezpieczeń do zasobów lokalnych przy użyciu Microsoft Entra ID.
W tym temacie przedstawiono sposób włączania uwierzytelniania bez hasła do zasobów lokalnych dla środowisk z urządzeniami z systemem Windows 10 w wersji 2004 lub nowszej. Urządzenia mogą być połączone z usługą Microsoft Entra lub połączone hybrydowo z usługą Microsoft Entra. Ta funkcja uwierzytelniania bez hasła zapewnia bezproblemowe logowanie jednokrotne (SSO) do zasobów lokalnych w przypadku korzystania z kluczy zabezpieczeń zgodnych z firmą Microsoft lub zaufania Windows Hello dla firm Cloud.
Użyj SSO, aby zalogować się do zasobów lokalnych przy użyciu kluczy FIDO2
Identyfikator Entra firmy Microsoft może wystawiać bilety przyznawania biletów protokołu Kerberos dla co najmniej jednej domeny usługi Active Directory. Dzięki tej funkcji użytkownicy mogą logować się do systemu Windows przy użyciu nowoczesnych poświadczeń, takich jak klucze zabezpieczeń FIDO2, a następnie uzyskiwać dostęp do tradycyjnych zasobów opartych na usłudze Active Directory. Bilety usług Kerberos i autoryzacja nadal są kontrolowane przez lokalnych kontrolerów domeny Active Directory.
Obiekt serwera Kerberos Microsoft Entra jest tworzony w lokalnym wystąpieniu Active Directory, a następnie bezpiecznie opublikowany w Microsoft Entra ID. Obiekt nie jest skojarzony z żadnymi serwerami fizycznymi. To po prostu zasób, który może być używany przez Microsoft Entra ID do generowania biletów TGT Kerberos dla domeny Active Directory.
Użytkownik loguje się do urządzenia z systemem Windows 10 przy użyciu klucza zabezpieczeń FIDO2 i uwierzytelnia się w usłudze Microsoft Entra ID.
Microsoft Entra ID sprawdza katalog w poszukiwaniu klucza serwera Kerberos, który pasuje do domeny lokalnej usługi Active Directory użytkownika.
Microsoft Entra ID generuje TGT protokołu Kerberos dla lokalnej domeny Active Directory użytkownika. TGT zawiera tylko identyfikator SID użytkownika i brak danych autoryzacji.
Bilet TGT jest zwracany klientowi wraz z podstawowym tokenem odświeżania (PRT) użytkownika Microsoft Entra.
Komputer kliencki kontaktuje się z lokalnym kontrolerem domeny Active Directory i wymienia częściową TGT na w pełni sformułowany bilet TGT.
Maszyna kliencka ma teraz protokół PRT firmy Microsoft i pełny bilet TGT usługi Active Directory oraz może uzyskiwać dostęp do zasobów w chmurze i lokalnych.
Wymagania wstępne
Przed rozpoczęciem procedur opisanych w tym artykule organizacja musi wykonać instrukcje opisane w temacie Włączanie kluczy dostępu (FIDO2) dla organizacji.
Należy również spełnić następujące wymagania systemowe:
Urządzenia muszą mieć system Windows 10 w wersji 2004 lub nowszej.
Kontrolery domeny systemu Windows Server muszą działać w systemie Windows Server 2016 lub nowszym i mieć zainstalowane poprawki dla następujących serwerów:
AES256_HMAC_SHA1 należy włączyć, gdy polityka zabezpieczeń sieciowych: konfiguracja dozwolonych typów szyfrowania dla Kerberos jest konfigurowana na kontrolerach domeny.
Aby wykonać kroki w scenariuszu, należy posiadać wymagane poświadczenia.
- Użytkownik usługi Active Directory, który jest członkiem grupy Administratorzy domeny dla domeny i członkiem grupy Administratorzy przedsiębiorstwa dla lasu. Określany jako $domainCred.
- Użytkownik Microsoft Entra z rolą Administratora tożsamości hybrydowej. Określany jako $cloudCred.
Użytkownicy muszą mieć następujące atrybuty entra firmy Microsoft wypełnione za pośrednictwem programu Microsoft Entra Connect:
-
onPremisesSamAccountName
(accountName
w programie Microsoft Entra Connect) -
onPremisesDomainName
(domainFQDN
w programie Microsoft Entra Connect) -
onPremisesSecurityIdentifier
(objectSID
w programie Microsoft Entra Connect)
Program Microsoft Entra Connect domyślnie synchronizuje te atrybuty. Jeśli zmienisz atrybuty do synchronizacji, upewnij się, że wybrano pozycję
accountName
,domainFQDN
iobjectSID
w celu synchronizacji.-
Obsługiwane scenariusze
Scenariusz w tym artykule obsługuje SSO w obu następujących przypadkach:
- Zasoby w chmurze, takie jak platforma Microsoft 365 i inne aplikacje obsługujące język SAML (Security Assertion Markup Language).
- Zasoby lokalne i zintegrowane uwierzytelnianie systemu Windows z witrynami internetowymi. Zasoby mogą obejmować witryny internetowe i witryny programu SharePoint, które wymagają uwierzytelniania usług IIS i/lub zasobów korzystających z uwierzytelniania NTLM.
Nieobsługiwane scenariusze
Następujące scenariusze nie są obsługiwane:
- Wdrożenie usługi Windows Server Active Directory Domain Services (AD DS) połączonej z domeną (tylko urządzenia lokalne).
- Protokół RDP (Remote Desktop Protocol), infrastruktura pulpitu wirtualnego (VDI) i scenariusze Citrix przy użyciu klucza zabezpieczeń.
- Protokół S/MIME przy użyciu klucza zabezpieczeń.
- Uruchom jako przy użyciu klucza zabezpieczeń.
- Zaloguj się do serwera przy użyciu klucza zabezpieczeń.
Instalowanie modułu AzureADHybridAuthenticationManagement
AzureADHybridAuthenticationManagement
Moduł zapewnia funkcje zarządzania FIDO2 dla administratorów.
Otwórz wiersz polecenia programu PowerShell przy użyciu opcji Uruchom jako administrator.
AzureADHybridAuthenticationManagement
Zainstaluj moduł:# First, ensure TLS 1.2 for PowerShell gallery access. [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 # Install the AzureADHybridAuthenticationManagement PowerShell module. Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Uwaga
- Od wersji update 2.3.331.0 moduł AzureADHybridAuthenticationManagement nie instaluje modułu AzureADPreview.
- Można zainstalować moduł
AzureADHybridAuthenticationManagement
na dowolnym komputerze, z którego można uzyskać dostęp do lokalnego kontrolera domeny usługi Active Directory, bez zależności od rozwiązania Microsoft Entra Connect. - Moduł
AzureADHybridAuthenticationManagement
jest dystrybuowany za pośrednictwem Galeria programu PowerShell. Galeria programu PowerShell to centralne repozytorium zawartości programu PowerShell. W nim można znaleźć przydatne moduły programu PowerShell zawierające polecenia programu PowerShell i zasoby usługi Desired State Configuration (DSC).
Tworzenie obiektu serwera Kerberos
Administratorzy używają modułu AzureADHybridAuthenticationManagement
do tworzenia obiektu serwera Kerberos firmy Microsoft w katalogu lokalnym. Obiekt musi zostać utworzony na serwerze Microsoft Entra Connect lub na serwerze, na którym zainstalowano zależność Microsoft.Online.PasswordSynchronization.Rpc.dll.
Uruchom następujące kroki w każdej domenie i lesie w organizacji, które zawierają użytkowników firmy Microsoft Entra:
- Otwórz wiersz polecenia programu PowerShell przy użyciu opcji Uruchom jako administrator.
- Uruchom następujące polecenia programu PowerShell, aby utworzyć nowy obiekt serwera Microsoft Entra Kerberos zarówno w lokalnej domenie Active Directory, jak i w dzierżawie Microsoft Entra.
Wybierz Chmurę platformy Azure (domyślnie Azure Commercial)
Domyślnie polecenie Set-AzureADKerberosSever
cmdlet będzie używać punktów końcowych chmury komercyjnej. Jeśli konfigurujesz protokół Kerberos w innym środowisku chmury, musisz ustawić polecenie cmdlet tak, aby używało określonej chmury.
Aby uzyskać listę dostępnych chmur i wartość liczbową wymaganą do zmiany, uruchom następujące polecenie:
Get-AzureADKerberosServerEndpoint
Przykładowe dane wyjściowe:
Current Endpoint = 0(Public)
Supported Endpoints:
0 :Public
1 :China
2 :Us Government
Zanotuj wartość liczbową obok żądanego środowiska chmury.
Aby następnie ustawić żądane środowisko chmury, uruchom następujące polecenie:
(Przykład: w przypadku chmury dla instytucji rządowych USA)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2
Wskazówka
Aby uzyskać dodatkowe informacje dotyczące porównywania chmur komercyjnych i suwerennych platformy Azure, zobacz: Różnice między chmurami komercyjnymi i suwerennych platformy Azure.
Przykład 1 monitu o wszystkie poświadczenia
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Hybrid Identity Administrators group for Microsoft Entra ID.'
# Enter a Domain Administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
Przykład 2 monitu o podanie poświadczeń w chmurze
Uwaga
Jeśli pracujesz na maszynie przyłączonej do domeny przy użyciu konta z uprawnieniami administratora domeny, możesz pominąć parametr "-DomainCredential". Jeśli parametr "-DomainCredential" nie jest podany, bieżące poświadczenia logowania do systemu Windows są używane do uzyskiwania dostępu do lokalnego kontrolera domeny Active Directory.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Use the current windows login credential to access the on-premises AD.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred
Przykład 3 monituj o wszystkie poświadczenia przy użyciu nowoczesnego uwierzytelniania
Uwaga
Jeśli Organizacja chroni logowanie oparte na hasłach i wymusza nowoczesne metody uwierzytelniania, takie jak uwierzytelnianie wieloskładnikowe, fiDO2 lub technologia karty inteligentnej, należy użyć parametru -UserPrincipalName
z główną nazwą użytkownika (UPN) administratora tożsamości hybrydowej.
- Zastąp
contoso.corp.com
w poniższym przykładzie nazwą domeny lokalnej usługi Active Directory. - Zastąp
administrator@contoso.onmicrosoft.com
w poniższym przykładzie UPN administratora tożsamości hybrydowej.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Enter a Domain Administrator username and password.
$domainCred = Get-Credential
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred
Przykład 4 żądanie poświadczeń w chmurze z użyciem nowoczesnej metody uwierzytelniania
Uwaga
Jeśli pracujesz na maszynie przyłączonej do domeny z kontem z uprawnieniami administratora domeny, a organizacja chroni logowanie oparte na hasłach i wymusza nowoczesne metody uwierzytelniania, takie jak uwierzytelnianie wieloskładnikowe, FIDO2 lub technologia karty inteligentnej, należy użyć parametru -UserPrincipalName
z główną nazwą użytkownika (UPN) administratora tożsamości hybrydowej. Możesz pominąć parametr "-DomainCredential".
> — Zastąp administrator@contoso.onmicrosoft.com
w poniższym przykładzie nazwą UPN administratora tożsamości hybrydowej.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName
Wyświetlanie i weryfikowanie serwera Microsoft Entra Kerberos
Możesz wyświetlić i zweryfikować nowo utworzony serwer Microsoft Entra Kerberos przy użyciu następującego polecenia:
# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)
To polecenie zwraca właściwości serwera Microsoft Entra Kerberos. Możesz przejrzeć właściwości, aby sprawdzić, czy wszystko jest w porządku.
Uwaga
Próba połączenia z inną domeną przez podanie poświadczeń w formacie domena\nazwa użytkownika połączy się za pośrednictwem NTLM, ale zakończy się niepowodzeniem. Jednak użycie formatu userprincipalname dla administratora domeny zapewni, że połączenie RPC z kontrolerem domeny zostanie podjęte prawidłowo przy użyciu Kerberos. Jeśli użytkownicy znajdują się w grupie zabezpieczeń "Chronieni użytkownicy" w usłudze Active Directory, wykonaj następujące kroki, aby rozwiązać ten problem: Zaloguj się jako inny użytkownik domeny w ADConnect i nie podaj parametru "-domainCredential". Używany jest bilet użytkownika w systemie Kerberos, który jest aktualnie zalogowany. Możesz potwierdzić, wykonując whoami /groups
polecenie , aby sprawdzić, czy użytkownik ma wymagane uprawnienia w usłudze Active Directory, aby wykonać poprzednie polecenie.
Nieruchomość | opis |
---|---|
ID | Unikatowy identyfikator obiektu kontrolera domeny AD DS. Ten identyfikator jest czasami określany jako jego slot lub identyfikator gałęzi. |
DomainDnsName | Nazwa domeny DNS domeny usługi Active Directory. |
ComputerAccount | Obiekt konta komputera obiektu serwera Kerberos firmy Microsoft (DC). |
Konto Użytkownika | Wyłączony obiekt konta użytkownika, który zawiera klucz szyfrowania TGT serwera Microsoft Entra Kerberos. Nazwa domeny tego konta to CN=krbtgt_AzureAD,CN=Users,<Domain-DN> . |
KluczowaWersja | Wersja klucza szyfrowania TGT serwera Microsoft Entra Kerberos. Wersja jest przypisywana podczas tworzenia klucza. Wersja jest następnie zwiększana za każdym razem, gdy klucz jest obracany. Przyrosty są oparte na metadanych replikacji i najprawdopodobniej większe niż jeden. Na przykład początkowa wersja keyversion może być 192272. Przy pierwszym obróceniu klucza wersja może przejść do 212621. Ważne jest, aby sprawdzić, czy KeyVersion dla obiektu lokalnego i CloudKeyVersion dla obiektu w chmurze są takie same. |
KluczZaktualizowanyDnia | Data i godzina zaktualizowania lub utworzenia klucza szyfrowania TGT serwera Microsoft Entra Kerberos. |
KluczZaktualizowanyZ | Kontroler domeny, na którym ostatnio zaktualizowano klucz szyfrowania TGT serwera Microsoft Entra Kerberos. |
Identyfikator chmury | Identyfikator obiektu Microsoft Entra. Musi być zgodny z identyfikatorem z pierwszego wiersza tabeli. |
CloudDomainDnsName | Z obiektu Microsoft Entra pochodzi DomainDnsName. Musi być zgodna z wartością DomainDnsName z drugiego wiersza tabeli. |
CloudKeyVersion | KeyVersion z obiektu Microsoft Entra. Musi być zgodna z parametrem KeyVersion z piątego wiersza tabeli. |
AktualizacjaKluczaChmury | KeyUpdatedOn pochodzący z obiektu Microsoft Entra. Musi odpowiadać wartości KeyUpdatedOn z szóstego wiersza tabeli. |
Obróć klucz serwera Microsoft Entra Kerberos
Klucze serwera Microsoft Entra Kerberos krbtgt powinny być regularnie rotowane. Zalecamy, aby postępować zgodnie z tym samym harmonogramem, jaki stosujesz do rotacji wszystkich innych kluczy usługi Active Directory DC krbtgt.
Ostrzeżenie
Istnieją inne narzędzia, które mogą obracać klucze krbtgt . Należy jednak użyć narzędzi wymienionych w tym dokumencie, aby obrócić klucze krbtgt serwera Microsoft Entra Kerberos. Dzięki temu klucze są aktualizowane zarówno w lokalnej usłudze Active Directory, jak i w Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey
Usuwanie serwera Microsoft Entra Kerberos
Jeśli chcesz przywrócić scenariusz i usunąć serwer Microsoft Entra Kerberos zarówno z lokalnej usługi Active Directory, jak i Microsoft Entra ID, uruchom następujące polecenie:
Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
Scenariusze wieloforestowe i wielodomenowe
Obiekt serwera Microsoft Entra Kerberos jest reprezentowany w elemencie Microsoft Entra ID jako obiekt KerberosDomain . Każda lokalna domena Active Directory jest reprezentowana jako pojedynczy obiekt KerberosDomain w Microsoft Entra ID.
Załóżmy na przykład, że organizacja ma las usługi Active Directory z dwiema domenami contoso.com
i fabrikam.com
. Jeśli zdecydujesz się zezwolić Microsoft Entra ID na wystawianie TGT protokołu Kerberos dla całego lasu, w Microsoft Entra ID istnieją dwa obiekty KerberosDomain, jeden obiekt KerberosDomain dla contoso.com
i drugi dla fabrikam.com
. Jeśli masz wiele lasów usługi Active Directory, istnieje jeden obiekt KerberosDomain dla każdej domeny w każdym lesie.
Postępuj zgodnie z instrukcjami dotyczącymi tworzenia obiektu serwera Kerberos w każdej domenie i lesie w organizacji, które zawierają użytkowników Microsoft Entra.
Znane zachowanie
Jeśli hasło wygasło, logowanie przy użyciu funkcji FIDO jest zablokowane. Oczekuje się, że użytkownicy zresetują swoje hasła, zanim będą mogli się zalogować przy użyciu funkcji FIDO. To zachowanie dotyczy również logowania użytkowników zsynchronizowanych hybrydowo lokalnie z relacją zaufania protokołu Kerberos w chmurze Windows Hello dla firm.
Rozwiązywanie problemów i opinie
Jeśli wystąpią problemy lub chcesz podzielić się opinią na temat tej funkcji logowania za pomocą klucza zabezpieczeń bez hasła, udostępnij je za pośrednictwem aplikacji Centrum opinii o systemie Windows, wykonując następujące czynności:
- Otwórz centrum opinii i upewnij się, że zalogowałeś się.
- Prześlij opinię, wybierając następujące kategorie:
- Kategoria: Bezpieczeństwo i prywatność
- Podkategoria: FIDO
- Aby przechwycić dzienniki, użyj opcji Odtwórz mój problem.
Logowanie przy użyciu klucza zabezpieczeń bez hasła — często zadawane pytania
Poniżej przedstawiono odpowiedzi na często zadawane pytania dotyczące logowania bez hasła:
Czy logowanie za pomocą klucza zabezpieczeń bez hasła działa w moim środowisku lokalnym?
Ta funkcja nie działa w czystym lokalnym środowisku usług AD DS.
Moja organizacja wymaga uwierzytelniania dwuskładnikowego w celu uzyskania dostępu do zasobów. Co mogę zrobić, aby spełnić to wymaganie?
Klucze zabezpieczeń występują w różnych formach. Skontaktuj się z producentem urządzenia, aby omówić sposób włączania ich urządzeń przy użyciu numeru PIN lub biometrii jako drugiego czynnika.
Czy administratorzy mogą skonfigurować klucze zabezpieczeń?
Pracujemy nad tą funkcją dla ogólnie dostępnej wersji tej funkcji.
Gdzie mogę znaleźć zgodne klucze zabezpieczeń?
Aby uzyskać informacje o zgodnych kluczach zabezpieczeń, zobacz FIDO2 security keys (Klucze zabezpieczeń FIDO2).
Co mogę zrobić, jeśli utracę klucz zabezpieczeń?
Aby usunąć zarejestrowany klucz zabezpieczeń, zaloguj się do myaccount.microsoft.com, a następnie przejdź do strony Informacje o zabezpieczeniach.
Co mogę zrobić, jeśli nie mogę użyć klucza zabezpieczeń FIDO natychmiast po utworzeniu komputera dołączonego do hybrydowego środowiska Microsoft Entra?
Jeśli przeprowadzasz czystą instalację maszyny hybrydowej Microsoft Entra, po zakończeniu procesu przyłączania do domeny i ponownego uruchomienia musisz zalogować się przy użyciu hasła i poczekać na synchronizację zasad, zanim będzie można użyć klucza zabezpieczeń FIDO do zalogowania się.
- Sprawdź bieżący stan, uruchamiając
dsregcmd /status
polecenie w oknie wiersza polecenia i sprawdź, czy stan AzureAdJoined i DomainJoined są wyświetlane jako TAK. - To opóźnienie synchronizacji jest znanym ograniczeniem urządzeń przyłączonych do domeny i nie jest specyficzne dla fiDO.
Co zrobić, jeśli nie mogę uzyskać logowania jednokrotnego do zasobu sieciowego NTLM po zalogowaniu się przy użyciu funkcji FIDO i wyświetleniu monitu o podanie poświadczeń?
Upewnij się, że wystarczająca liczba kontrolerów domeny jest załatana, aby reagować na czas i zrealizować Twoje żądanie zasobów. Aby sprawdzić, czy kontroler domeny uruchamia funkcję, uruchom polecenie nltest /dsgetdc:contoso /keylist /kdc
, a następnie zapoznaj się z wynikami.
Uwaga
Przełącznik /keylist
w poleceniu nltest
jest dostępny w kliencie z systemem Windows 10 v2004 lub nowszym.
Czy klucze zabezpieczeń FIDO2 są zgodne z logowaniem do systemu Windows przy użyciu kontrolera RODC obecnego w środowisku hybrydowym?
Logowanie FIDO2 systemu Windows szuka zapisywalnego kontrolera domeny w celu wymiany użytkownika TGT. Jeśli masz co najmniej jeden zapisywalny kontroler domeny na każdą lokalizację, logowanie działa prawidłowo.