You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/partner-arkose-labs.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ Arkose Labs products integration includes the following components:
37
37
- Custom HTML, JavaScript, and API connectors integrate with the Arkose platform
38
38
-**Azure Functions** - Your hosted API endpoint that works with the API connectors feature
39
39
- This API validates the server-side of the Arkose Labs session token
40
-
- Learn more in the [Azure Functions Overview](/azure/azure-functions/functions-overview)
40
+
- Learn more in the [Azure Functions Overview](../azure-functions/functions-overview.md)
41
41
42
42
The following diagram illustrates how the Arkose Labs platform integrates with Azure AD B2C.
43
43
@@ -179,7 +179,7 @@ Username and password are stored as environment variables, not part of the repos
179
179
180
180
#### Deploy the application to the web
181
181
182
-
1. Deploy your Azure Function to the cloud. Learn more with [Azure Functions documentation](/azure/azure-functions/).
182
+
1. Deploy your Azure Function to the cloud. Learn more with [Azure Functions documentation](../azure-functions/index.yml).
183
183
2. Copy the endpoint web URL of your Azure Function.
184
184
3. After deployment, select the **Upload settings** option.
185
185
4. Your environment variables are uploaded to the Application settings of the app service. Learn more on [Application settings in Azure](../azure-functions/functions-develop-vs-code.md?tabs=csharp#application-settings-in-azure).
@@ -224,4 +224,4 @@ Username and password are stored as environment variables, not part of the repos
Copy file name to clipboardExpand all lines: articles/active-directory/authentication/concept-authentication-authenticator-app.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,6 +72,15 @@ Authenticator leverages the native Apple cryptography to achieve FIPS 140, Secur
72
72
73
73
FIPS 140 compliance for Microsoft Authenticator on Android is in progress and will follow soon.
74
74
75
+
## Determining Microsoft Authenticator registration type in My Security-Info
76
+
Managining and adding additional Microsoft Authenticator registrations can be performed by users by accessing https://aka.ms/mysecurityinfo or by selecting Security info from from My Account. Specific icons are used to differentiate whether the Microsoft Authenticator registration is capable of passwordless phone sign-in or MFA.
Microsoft Authenticator: MFA capable | <imgwidth="43"alt="Microsoft Authenticator MFA Capable"src="https://user-images.githubusercontent.com/50213291/211921054-d11983ad-4e0d-4612-9a14-0fef625a9a2a.png">
82
+
83
+
75
84
## Next steps
76
85
77
86
- To get started with passwordless sign-in, see [Enable passwordless sign-in with the Microsoft Authenticator](howto-authentication-passwordless-phone.md).
Copy file name to clipboardExpand all lines: articles/active-directory/authentication/concept-authentication-strengths.md
+3-10Lines changed: 3 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -201,17 +201,9 @@ An authentication strength Conditional Access policy works together with [MFA tr
201
201
202
202
-**Users who signed in by using certificate-based authentication aren't prompted to reauthenticate** - If a user first authenticated by using certificate-based authentication and the authentication strength requires another method, such as a FIDO2 security key, the user isn't prompted to use a FIDO2 security key and authentication fails. The user must restart their session to sign-in with a FIDO2 security key.
203
203
204
-
-**Authentication methods that are currently not supported by authentication strength** - The Email one-time pass (Guest) authentication method is not included in the available combinations.
205
-
206
204
-**Using 'Require one of the selected controls' with 'require authentication strength' control** - After you select authentication strengths grant control and additional controls, all the selected controls must be satisfied in order to gain access to the resource. Using **Require one of the selected controls** isn't applicable, and will default to requiring all the controls in the policy.
207
205
208
-
-**Multiple Conditional Access policies may be created when using "Require authentication strength" grant control**. These are two different policies and you can safely delete one of them.
209
-
210
-
-**Windows Hello for Business** – If the user has used Windows Hello for Business as their primary authentication method it can be used to satisfy an authentication strength requirement that includes Windows Hello for Business. However, if the user has used another method as their primary authenticating method (for example, password) and the authentication strength requires them to use Windows Hello for Business they will not be prompted to use not register for Windows Hello for Business.
211
-
212
-
-**Authentication loop** can happen in one of the following scenarios:
213
-
1.**Microsoft Authenticator (Phone Sign-in)** - When the user is required to use Microsoft Authenticator (Phone Sign-in) but the user is not registered for this method, they will be given instructions on how to set up the Microsoft Authenticator, that does not include how to enable Passwordless sign-in. As a result, the user can get into an authentication loop. To avoid this issue, make sure the user is registered for the method before the Conditional Access policy is enforced. Phone Sign-in can be registered using the steps outlined here: [Add your work or school account to the Microsoft Authenticator app ("Sign in with your credentials")](https://support.microsoft.com/en-us/account-billing/add-your-work-or-school-account-to-the-microsoft-authenticator-app-43a73ab5-b4e8-446d-9e54-2a4cb8e4e93c)
214
-
2.**Conditional Access Policy is targeting all apps** - When the Conditional Access policy is targeting "All apps" but the user is not registered for any of the methods required by the authentication strength, the user will get into an authentication loop. To avoid this issue, target specific applications in the Conditional Access policy or make sure the user is registered for at least one of the authentication methods required by the authentication strength Conditional Access policy.
206
+
-**Authentication loop** - When the user is required to use Microsoft Authenticator (Phone Sign-in) but the user is not registered for this method, they will be given instructions on how to set up the Microsoft Authenticator, that does not include how to enable Passwordless sign-in. As a result, the user can get into an authentication loop. To avoid this issue, make sure the user is registered for the method before the Conditional Access policy is enforced. Phone Sign-in can be registered using the steps outlined here: [Add your work or school account to the Microsoft Authenticator app ("Sign in with your credentials")](https://support.microsoft.com/en-us/account-billing/add-your-work-or-school-account-to-the-microsoft-authenticator-app-43a73ab5-b4e8-446d-9e54-2a4cb8e4e93c)
215
207
216
208
217
209
## Limitations
@@ -220,8 +212,9 @@ An authentication strength Conditional Access policy works together with [MFA tr
220
212
221
213
-**Require multifactor authentication and Require authentication strength can't be used together in the same Conditional Access policy** - These two Conditional Access grant controls can't be used together because the built-in authentication strength **Multifactor authentication** is equivalent to the **Require multifactor authentication** grant control.
222
214
215
+
-**Authentication methods that are currently not supported by authentication strength** - The Email one-time pass (Guest) authentication method is not included in the available combinations.
223
216
224
-
<!---place holder: Auth Strength with CCS - will be documented in resilience-defaults doc-->
217
+
-**Windows Hello for Business** – If the user has used Windows Hello for Business as their primary authentication method it can be used to satisfy an authentication strength requirement that includes Windows Hello for Business. However, if the user has used another method as their primary authenticating method (for example, password) and the authentication strength requires them to use Windows Hello for Business they will not be prompted to use not register for Windows Hello for Business.
@@ -35,6 +35,8 @@ To verify if a method can be used:
35
35
36
36
If the user is registered for an enabled method that meets the authentication strength, they might need to use another method that isn't available after primary authentication, such as Windows Hello for Business or certificate-based authentication. For more information, see [How each authentication method works](concept-authentication-methods.md#how-each-authentication-method-works). The user will need to restart the session and choose **Sign-in options** and select a method required by the authentication strength.
37
37
38
+
:::image type="content" border="true" source="./media/troubleshoot-authentication-strengths/choose-another-method.png" alt-text="Screenshot of how to choose another sign-in method.":::
39
+
38
40
## A user can't access a resource
39
41
40
42
If an authentication strength requires a method that a user can’t use, the user is blocked from sign-in. To check which method is required by an authentication strength, and which method the user is registered and enabled to use, follow the steps in the [previous section](#a-user-is-asked-to-sign-in-with-another-method-but-they-dont-see-a-method-they-expect).
Cloud sync is built on top of the Azure AD services and has 2 key components:
24
24
25
25
-**Provisioning agent**: The Azure AD Connect cloud provisioning agent is the same agent as Workday inbound and built on the same server-side technology as app proxy and Pass Through Authentication. It requires an outbound connection only and agents are auto-updated.
26
-
-**Provisioning service**: Same provisioning service as outbound provisioning and Workday inbound provisioning which uses a scheduler-based model. In case of cloud sync, the changes are provisioned every 2 mins.
26
+
-**Provisioning service**: Same provisioning service as outbound provisioning and Workday inbound provisioning, which uses a scheduler-based model. Cloud sync provisions change every 2 mins.
27
27
28
28
29
29
## Initial setup
30
-
During initial setup, a few things are done that makes cloud sync happen. These are:
30
+
During initial setup, a few things are done that makes cloud sync happen.
31
31
32
32
-**During agent installation**: You configure the agent for the AD domains you want to provision from. This configuration registers the domains in the hybrid identity service and establishes an outbound connection to the service bus listening for requests.
33
-
-**When you enable provisioning**: You select the AD domain and enable provisioning which runs every 2 mins. Optionally you may deselect password hash sync and define notification email. You can also manage attribute transformation using Microsoft Graph APIs.
33
+
-**When you enable provisioning**: You select the AD domain and enable provisioning, which runs every 2 mins. Optionally you may deselect password hash sync and define notification email. You can also manage attribute transformation using Microsoft Graph APIs.
34
34
35
35
36
36
## Agent installation
37
-
The following is a walk-through of what occurs when the cloud provisioning agent is installed.
37
+
The following items occur when the cloud provisioning agent is installed.
38
38
39
-
- First, the Installer installs the Agent binaries and the Agent Service running under the Virtual Service Account (NETWORK SERVICE\AADProvisioningAgent). A virtual service account is a special type of account that does not have a password and is managed by Windows.
39
+
- First, the Installer installs the Agent binaries and the Agent Service running under the Virtual Service Account (NETWORK SERVICE\AADProvisioningAgent). A virtual service account is a special type of account that doesn't have a password and is managed by Windows.
40
40
- The Installer then starts the Wizard.
41
41
- The Wizard will prompt for Azure AD credentials, will then authenticate, and retrieve a token.
42
42
- The wizard then asks for the current machine Domain Administrators credentials.
43
43
- Using these credentials, the agent general managed service account (GMSA) for this domain is either created or located and reused if it already exists.
44
44
- The agent service is now reconfigured to run under the GMSA.
45
45
- The wizard now asks for domain configuration along with the Enterprise Admin (EA)/Domain Admin(DA) Account for each domain you want the agent to service.
46
-
- The GMSA account is then updated with permissions that enable it access to each domain entered above.
46
+
- The GMSA account is then updated with permissions that enable it access to each domain entered during setup.
47
47
- Next, the wizard triggers agent registration
48
48
- The agent creates a certificate and using the Azure AD token, registers itself and the certificate with the Hybrid Identity Service(HIS) Registration Service
49
49
- The Wizard triggers an AgentResourceGrouping call. This call to HIS Admin Service is to assign the agent to one or more AD Domains in the HIS configuration.
50
50
- The wizard now restarts the agent service.
51
-
- The agent calls a Bootstrap Service on restart (and every 10 mins afterwards) to check for configuration updates. The bootstrap service validates the agent identity. It also updates the last bootstrap time. This is important because if agents don't bootstrap, they are not getting updated Service Bus endpoints and may not be able to receive requests.
51
+
- The agent calls a Bootstrap Service on restart (and every 10 mins afterwards) to check for configuration updates. The bootstrap service validates the agent identity. It also updates the last bootstrap time. This is important because if agents don't bootstrap, they aren't getting updated Service Bus endpoints and may not be able to receive requests.
52
52
53
53
54
54
## What is System for Cross-domain Identity Management (SCIM)?
55
55
56
-
The [SCIM specification](https://tools.ietf.org/html/draft-scim-core-schema-01) is a standard that is used to automate the exchanging of user or group identity information between identity domains such as Azure AD. SCIM is becoming the de facto standard for provisioning and, when used in conjunction with federation standards like SAML or OpenID Connect, provides administrators an end-to-end standards-based solution for access management.
56
+
The [SCIM specification](https://tools.ietf.org/html/draft-scim-core-schema-01) is a standard that is used to automate the exchanging of user or group identity information between identity domains such as Azure AD. SCIM is becoming the de facto standard for provisioning and, when used with federation standards like SAML or OpenID Connect, provides administrators an end-to-end standards-based solution for access management.
57
57
58
58
The Azure AD Connect cloud provisioning agent uses SCIM with Azure AD to provision and deprovision users and groups.
Once you have installed the agent and enabled provisioning, the following flow occurs.
62
+
Once you've installed the agent and enabled provisioning, the following flow occurs.
63
63
64
64
1. Once configured, the Azure AD Provisioning service calls the Azure AD hybrid service to add a request to the Service bus. The agent constantly maintains an outbound connection to the Service Bus listening for requests and picks up the System for Cross-domain Identity Management (SCIM) request immediately.
65
65
2. The agent breaks up the request into separate queries based on object type.
66
66
3. AD returns the result to the agent and the agent filters this data before sending it to Azure AD.
67
67
4. Agent returns the SCIM response to Azure AD. These responses are based on the filtering that happened within the agent. The agent uses scoping to filter the results.
68
68
5. The provisioning service writes the changes to Azure AD.
69
-
6. If this is a delta Sync as opposed to a full sync, then cookie/watermark is used. New queries will get changes from that cookie/watermark onwards.
69
+
6.If a delta Sync occurs, as opposed to a full sync, then the cookie/watermark is used. New queries will get changes from that cookie/watermark onwards.
70
70
71
71
## Supported scenarios:
72
72
The following scenarios are supported for cloud sync.
73
73
74
74
75
-
-**Existing hybrid customer with a new forest**: Azure AD Connect sync is used for primary forests. Cloud sync is used for provisioning from an AD forest (including disconnected). For more information see the tutorial [here](tutorial-existing-forest.md).
75
+
-**Existing hybrid customer with a new forest**: Azure AD Connect sync is used for primary forests. Cloud sync is used for provisioning from an AD forest (including disconnected). For more information, see the tutorial [here](tutorial-existing-forest.md).
-**New hybrid customer**: Azure AD Connect sync is not used. Cloud sync is used for provisioning from an AD forest. For more information see the tutorial [here](tutorial-single-forest.md).
78
+
-**New hybrid customer**: Azure AD Connect sync isn't used. Cloud sync is used for provisioning from an AD forest. For more information, see the tutorial [here](tutorial-single-forest.md).
0 commit comments