Skip to content

Commit 13defa8

Browse files
iainfouldsiainfoulds
committed
[AzureAD-Passwordless] Pulling over JFlo hybrid updates
1 parent fc8a99d commit 13defa8

6 files changed

+244
-37
lines changed

‎.openpublishing.redirection.json

Lines changed: 0 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -36711,11 +36711,6 @@
3671136711
"redirect_url": "/azure/active-directory/user-help/myprofile-portal-overview",
3671236712
"redirect_document_id": false
3671336713
},
36714-
{
36715-
"source_path": "articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md",
36716-
"redirect_url": "/azure/active-directory/authentication/howto-authentication-passwordless-security-key-windows",
36717-
"redirect_document_id": false
36718-
},
3671936714
{
3672036715
"source_path": "articles/application-gateway/application-gateway-ssl-portal.md",
3672136716
"redirect_url": "/azure/application-gateway/create-ssl-portal",

‎articles/active-directory/authentication/concept-authentication-passwordless.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ The Authenticator App turns any iOS or Android phone into a strong, passwordless
4949

5050
FIDO2 security keys are an unphishable standards-based passwordless authentication method that can come in any form factor. Fast Identity Online (FIDO) is an open standard for passwordless authentication. FIDO allows users and organizations to leverage the standard to sign in to their resources without a username or password using an external security key or a platform key built into a device.
5151

52-
For public preview, employees can use security keys to sign in to their Azure AD-joined Windows 10 devices and get single-sign on to their cloud and on-premises resources. Users can also sign in to supported browsers. FIDO2 security keys are a great option for enterprises who are very security sensitive or have scenarios or employees who aren't willing or able to use their phone as a second factor.
52+
For public preview, employees can use security keys to sign in to their Azure AD or hybrid Azure AD joined Windows 10 devices and get single-sign on to their cloud and on-premises resources. Users can also sign in to supported browsers. FIDO2 security keys are a great option for enterprises who are very security sensitive or have scenarios or employees who aren't willing or able to use their phone as a second factor.
5353

5454
![Sign in to Microsoft Edge with a security key](./media/concept-authentication-passwordless/concept-web-sign-in-security-key.png)
5555

‎articles/active-directory/authentication/howto-authentication-passwordless-deployment.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -107,6 +107,15 @@ Enabling Windows 10 sign in using FIDO2 security keys requires enabling the cred
107107
- If Intune deployment isn't possible, administrators must deploy a package on each machine to enable the credential provider functionality. The package installation can be carried out by one of the following options:
108108
- Group Policy or Configuration Manager
109109
- Local installation on a Windows 10 machine
110+
- [Enable credential provider with Group Policy](howto-authentication-passwordless-security-key-windows.md#enable-with-group-policy)
111+
- Only supported for hybrid Azure AD joined devices.
112+
113+
#### Enable on-premises integration
114+
115+
Follow the steps in the article [Enable passwordless security key sign in to on-premises resources (preview)](howto-authentication-passwordless-security-key-on-premises.md) to enable access to on-premises resources.
116+
117+
> [!IMPORTANT]
118+
> These steps must also be completed for any hybrid Azure AD joined devices to utilize FIDO2 security keys for Windows 10 sign in.
110119
111120
### Register security keys
112121

‎articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md

Lines changed: 198 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,198 @@
1+
---
2+
title: Passwordless security key sign in to on-premises resources (preview) - Azure Active Directory
3+
description: Enable passwordless security key sign-in to on-premises resources (preview)
4+
5+
services: active-directory
6+
ms.service: active-directory
7+
ms.subservice: authentication
8+
ms.topic: conceptual
9+
ms.date: 01/30/2020
10+
11+
ms.author: iainfou
12+
author: iainfoulds
13+
manager: daveba
14+
ms.reviewer: librown, aakapo
15+
16+
ms.collection: M365-identity-device-management
17+
---
18+
# Enable passwordless security key sign-in to on-premises resources (preview)
19+
20+
This document focuses on enabling passwordless authentication to on-premises resources for environments with both **Azure AD joined** and **hybrid Azure AD joined** Windows 10 devices. This functionality provides seamless single sign-on (SSO) to on-premises resources using Microsoft-compatible security keys.
21+
22+
| |
23+
| --- |
24+
| FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)|
25+
| |
26+
27+
## SSO to on-premises resources using FIDO2 keys
28+
29+
Azure Active Directory (AD) can issue Kerberos Ticket Granting Tickets (TGTs) for one or more of your Active Directory domains. This functionality allows users to sign into Windows with modern credentials like FIDO2 security keys and access traditional Active Directory based resources. Kerberos Service Tickets and authorization will continue to be controlled by your on-premises Active Directory domain controllers.
30+
31+
An Azure AD Kerberos Server object will be created in your on-premises Active Directory and then be securely published to Azure Active Directory. The object is not associated with any physical servers. It is simply a resource that can be used by Azure Active Directory to generate Kerberos Ticket Granting Tickets (TGTs) for your Active Directory Domain.
32+
33+
![Getting a TGT and PRT from Azure AD and AD DS](./media/howto-authentication-passwordless-on-premises/fido2-tgt-exchange-process.png)
34+
35+
1. User signs in to their Windows 10 device with a FIDO2 security key and authenticates to Azure AD.
36+
1. Azure AD checks the directory for a Kerberos server key matching the user's on-premises AD domain.
37+
1. Azure AD generates a Kerberos TGT for the user's on-premises AD domain. The TGT only includes the user's SID. No authorization data is included in the TGT.
38+
1. The TGT is returned to the client along with their Azure AD Primary Refresh Token (PRT).
39+
1. The client machine contacts an on-premises AD domain controller and trades the partial TGT for a fully formed TGT.
40+
1. The client machine now has an Azure AD PRT and a full Active Directory TGT and can access both cloud and on-premises resources.
41+
42+
## Requirements
43+
44+
Organizations must complete the steps in the article [Enable passwordless security key sign to Windows 10 devices (preview)](howto-authentication-passwordless-security-key.md) before completing the steps in this article.
45+
46+
Organizations must meet the following software requirements.
47+
48+
- Devices must be running Windows 10 Insider Build 18945 or newer
49+
- Upgrade to the latest version of [Azure AD Connect](../hybrid/how-to-connect-install-roadmap.md#install-azure-ad-connect)
50+
- Fully patched Windows Server 2016/2019 Domain Controllers to handle the on-premises authentication request load.
51+
52+
### Supported scenarios
53+
54+
- The scenario supports single sign-on (SSO) to both:
55+
- Cloud resources like Office 365 and other SAML enabled applications.
56+
- On-premises resources, and Windows-Integrated authentication to web sites, including web sites and SharePoint sites that require IIS Authentication, and/or resources that use NTLM authentication.
57+
58+
### Unsupported scenarios
59+
60+
The following scenarios are not supported:
61+
62+
- Windows Server Active Directory Domain Services (AD DS) domain joined (on-premises only devices) deployment **not supported**.
63+
- RDP, VDI, and Citrix scenarios are **not supported** using security key.
64+
- S/MIME is **not supported** using security key.
65+
- "Run as" is **not supported** using security key.
66+
- Log in to a server using security key is **not supported**.
67+
68+
## Create Kerberos server object
69+
70+
Administrators will use PowerShell tools from their Azure AD Connect server to create an Azure AD Kerberos Server object in their on-premises directory.
71+
You will need to run these steps in each domain and forest in your organization that contain Azure AD users.
72+
73+
1. Upgrade to the latest version of Azure AD Connect. The instructions assume you have already configured Azure AD Connect to support your hybrid environment.
74+
1. On the Azure AD Connect Server, open an elevated PowerShell prompt, and navigate to `C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\`
75+
1. Run the following PowerShell commands to create a new Azure AD Kerberos server object in both your on-premises Active Directory domain and Azure Active Directory tenant.
76+
77+
> [!NOTE]
78+
> Replace `contoso.corp.com` in the following example with your on-premises Active Directory domain name.
79+
80+
```powerShell
81+
Import-Module ".\AzureAdKerberos.psd1"
82+
83+
# Specify the on-premises Active Directory domain. A new Azure AD
84+
# Kerberos Server object will be created in this Active Directory domain.
85+
$domain = "contoso.corp.com"
86+
87+
# Enter an Azure Active Directory global administrator username and password.
88+
$cloudCred = Get-Credential
89+
90+
# Enter a domain administrator username and password.
91+
$domainCred = Get-Credential
92+
93+
# Create the new Azure AD Kerberos Server object in Active Directory
94+
# and then publish it to Azure Active Directory.
95+
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
96+
```
97+
98+
### Viewing and verifying the Azure AD Kerberos Server
99+
100+
You can view and verify the newly created Azure AD Kerberos Server using the following command:
101+
102+
```powerShell
103+
Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
104+
```
105+
106+
This command will output the properties of the Azure AD Kerberos Server. You can review the properties to verify that everything is in good order.
107+
108+
| Property | Description |
109+
| --- | --- |
110+
| ID | The unique ID of the AD Domain Controller object. This ID is sometimes referred to as it’s "slot" or it’s "branch ID". |
111+
| DomainDnsName | The DNS domain name of the Active Directory Domain. |
112+
| ComputerAccount | The computer account object of the Azure AD Kerberos Server object (The DC). |
113+
| UserAccount | The disabled user account object that holds the Azure AD Kerberos Server TGT encryption key. The DN of this account will be: <br> `CN=krbtgt_AzureAD,CN=Users,<Domain-DN>` |
114+
| KeyVersion | The key version of the Azure AD Kerberos Server TGT encryption key. The version is assigned when the key is created. The version is then incremented every time the key is rotated. The increments are based on replication meta-data and will likely be greater than one. For example, the initial KeyVersion could be *192272*. The first time the key is rotated, the version could advance to *212621*. The important thing to verify is that the KeyVersion for the on-premises object and the CloudKeyVersion for the cloud object are the same. |
115+
| KeyUpdatedOn | The date and time that the Azure AD Kerberos Server TGT encryption key was updated/created. |
116+
| KeyUpdatedFrom | The Domain Controller where the Azure AD Kerberos Server TGT encryption key was last updated. |
117+
| CloudId | The ID from the Azure AD Object. Must match the ID above. |
118+
| CloudDomainDnsName | The DomainDnsName from the Azure AD Object. Must match the DomainDnsName above. |
119+
| CloudKeyVersion | The KeyVersion from the Azure AD Object. Must match the KeyVersion above. |
120+
| CloudKeyUpdatedOn | The KeyUpdatedOn from the Azure AD Object. Must match the KeyUpdatedOn above. |
121+
122+
### Rotating the Azure AD Kerberos Server key
123+
124+
The Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis. It’s recommended you follow the same schedule you use to rotate all other Active Directory Domain Controller krbtgt keys.
125+
126+
> [!WARNING]
127+
> There are other tools that could rotate the krbtgt keys, however, you must use the tools mentioned in this document to rotate the krbtgt keys of your Azure AD Kerberos Server. This ensures the keys are updated in both on-premises AD and Azure AD.
128+
129+
```powerShell
130+
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey
131+
```
132+
133+
### Removing the Azure AD Kerberos Server
134+
135+
If you would like to revert the scenario and remove the Azure AD Kerberos Server from both on-premises Active Directory and Azure Active Directory, run the following command.
136+
137+
```powerShell
138+
Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
139+
```
140+
141+
### Multi-forest and multi-domain scenarios
142+
143+
The Azure AD Kerberos server object is represented in Azure AD as a *KerberosDomain* object. Each on-premises Active Directory domain is represented as a single *KerberosDomain* object in Azure AD.
144+
145+
For example, your organization has an Active Directory forest with two domains, `contoso.com` and `fabrikam.com`. If you choose to allow Azure AD to issue Kerberos Ticket Granting Tickets (TGT) for the entire forest, there will be two *KerberosDomain* objects in Azure AD. One *KerberosDomain* object for `contoso.com` and one for `fabrikam.com`. If you have multiple Active Directory forests, you will have one *KerberosDomain* object for each domain in each forest.
146+
147+
You will need to run the steps in [Create Kerberos server object](#create-kerberos-server-object) in each domain and forest in your organization that contain Azure AD users.
148+
149+
## Known behavior
150+
151+
Logon with FIDO will be blocked if your password has expired. The expectation is for user to reset their password before being able to log in using FIDO.
152+
153+
## Troubleshooting and feedback
154+
155+
If you would like to share feedback or encounter issues while previewing this feature, please share via the Windows Feedback Hub app.
156+
157+
1. Launch **Feedback Hub** and make sure you're signed in.
158+
1. Submit feedback under the following categorization:
159+
1. Category: Security and Privacy
160+
1. Subcategory: FIDO
161+
1. To capture logs, use the option: **Recreate my Problem**
162+
163+
## Frequently asked questions
164+
165+
### Does this work in my on-premises environment?
166+
167+
This feature does not work for a pure on-premises Active Directory Domain Services (AD DS) environment.
168+
169+
### My organization requires two factor authentication to access resources, what can I do to support this requirement?
170+
171+
Security keys come in a variety of form factors. Contact the device manufacturer of interest to discuss how their devices can be enabled with a PIN or biometric as a second factor.
172+
173+
### Can admins set up security keys?
174+
175+
We are working on this capability for general availability (GA) of this feature.
176+
177+
### Where can I go to find compliant Security Keys?
178+
179+
[FIDO2 security keys](concept-authentication-passwordless.md#fido2-security-keys)
180+
181+
### What do I do if I lose my Security Key?
182+
183+
You can remove keys from the Azure portal, by navigating to the security info page and removing the security key.
184+
185+
### I’m not able to use FIDO immediately after I create a hybrid Azure AD joined machine
186+
187+
If clean installing a hybrid Azure AD joined machine, post domain join and restart you must sign in with a password and wait for policy to sync before being able to use FIDO to sign in.
188+
189+
- Check your current status by typing `dsregcmd /status` into a command window and check that both *AzureAdJoined* and *DomainJoined* are showing *YES*.
190+
- This delay is a known limitation for domain joined devices and not FIDO specific.
191+
192+
### I’m unable to get SSO to my NTLM network resource after signing in with FIDO and get a credential prompt
193+
194+
Make sure enough domain controllers are patched to respond in time to service your resource request. To check if you can see a domain controller that is running the feature, check the output of `nltest /dsgetdc:contoso /keylist /kdc`.
195+
196+
## Next steps
197+
198+
[Learn more about passwordless](concept-authentication-passwordless.md)

0 commit comments

Comments
 (0)