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/app-provisioning/on-premises-application-provisioning-architecture.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -144,7 +144,7 @@ This article lists the versions and features of Azure Active Directory Connect P
144
144
Microsoft provides direct support for the latest agent version and one version before.
145
145
146
146
### Download link
147
-
You can download the latest version of the agent using [this link](https://aka.ms/onpremprovisioningagent).
147
+
On-premises app provisioning has been rolled into the provisioning agent and is available from the portal. See [installing the provisioning agent](../cloud-sync/how-to-install.md).
Copy file name to clipboardExpand all lines: articles/active-directory/app-provisioning/plan-cloud-hr-provision.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.service: active-directory
8
8
ms.subservice: app-provisioning
9
9
ms.topic: conceptual
10
10
ms.workload: identity
11
-
ms.date: 04/17/2023
11
+
ms.date: 04/18/2023
12
12
ms.author: kenwith
13
13
ms.reviewer: arvinh
14
14
---
@@ -145,7 +145,7 @@ Run the initial configuration in a [pilot environment](../fundamentals/active-di
145
145
To facilitate Azure AD provisioning workflows between the cloud HR app and Active Directory, you can add multiple provisioning connector apps from the Azure AD app gallery:
146
146
147
147
-**Cloud HR app to Active Directory user provisioning**: This provisioning connector app facilitates user account provisioning from the cloud HR app to a single Active Directory domain. If you have multiple domains, you can add one instance of this app from the Azure AD app gallery for each Active Directory domain you need to provision to.
148
-
-**Cloud HR app to Azure AD user provisioning**: While Azure AD Connect is the tool that should be used to synchronize Active Directory users to Azure AD, this provisioning connector app can be used to facilitate the provisioning of cloud-only users from the cloud HR app to a single Azure AD tenant.
148
+
-**Cloud HR app to Azure AD user provisioning**: Azure AD Connect is the tool used to synchronize Active Directory on premises users to Azure Active Directory. The Cloud HR app to Azure AD user provisioning is a connector you use to provision cloud-only users from the cloud HR app to a single Azure AD tenant.
149
149
-**Cloud HR app write-back**: This provisioning connector app facilitates the write-back of the user's email addresses from Azure AD to the cloud HR app.
150
150
151
151
For example, the following image lists the Workday connector apps that are available in the Azure AD app gallery.
@@ -180,9 +180,9 @@ We recommend the following production configuration:
180
180
181
181
|Requirement|Recommendation|
182
182
|:-|:-|
183
-
|Number of Azure AD Connect provisioning agents to deploy|Two (for high availability and failover)
184
-
|Number of provisioning connector apps to configure|One app per child domain|
185
-
|Server host for Azure AD Connect provisioning agent|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers</br>Can coexist with Azure AD Connect service|
183
+
|Number of Azure AD Connect provisioning agents to deploy.|Two (for high availability and failover).
184
+
|Number of provisioning connector apps to configure.|One app per child domain.|
185
+
|Server host for Azure AD Connect provisioning agent.|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers. </br>Can coexist with Azure AD Connect service.|
186
186
187
187

188
188
@@ -194,15 +194,15 @@ We recommend the following production configuration:
194
194
195
195
|Requirement|Recommendation|
196
196
|:-|:-|
197
-
|Number of Azure AD Connect provisioning agents to deploy on-premises|Two per disjoint Active Directory forest|
198
-
|Number of provisioning connector apps to configure|One app per child domain|
199
-
|Server host for Azure AD Connect provisioning agent|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers</br>Can coexist with Azure AD Connect service|
197
+
|Number of Azure AD Connect provisioning agents to deploy on-premises|Two per disjoint Active Directory forest.|
198
+
|Number of provisioning connector apps to configure|One app per child domain.|
199
+
|Server host for Azure AD Connect provisioning agent.|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers. </br>Can coexist with Azure AD Connect service.|
200
200
201
201

202
202
203
203
### Azure AD Connect provisioning agent requirements
204
204
205
-
The cloud HR app to Active Directory user provisioning solution requires that you deploy one or more Azure AD Connect provisioning agents on servers that run Windows Server 2016 or greater. The servers must have a minimum of 4-GB RAM and .NET 4.7.1+ runtime. Ensure that the host server has network access to the target Active Directory domain.
205
+
The cloud HR app to Active Directory user provisioning solution requires the deployment of one or more Azure AD Connect provisioning agents. These agents must be deployed on servers that run Windows Server 2016 or greater. The servers must have a minimum of 4-GB RAM and .NET 4.7.1+ runtime. Ensure that the host server has network access to the target Active Directory domain.
206
206
207
207
To prepare the on-premises environment, the Azure AD Connect provisioning agent configuration wizard registers the agent with your Azure AD tenant, [opens ports](../app-proxy/application-proxy-add-on-premises-application.md#open-ports), [allows access to URLs](../app-proxy/application-proxy-add-on-premises-application.md#allow-access-to-urls), and supports [outbound HTTPS proxy configuration](../saas-apps/workday-inbound-tutorial.md#how-do-i-configure-the-provisioning-agent-to-use-a-proxy-server-for-outbound-http-communication).
208
208
@@ -227,7 +227,7 @@ This is the most common deployment topology. Use this topology, if you need to p
227
227
* Setup two provisioning agent nodes for high availability and failover.
228
228
* Use the [provisioning agent configuration wizard](../cloud-sync/how-to-install.md#install-the-agent) to register your AD domain with your Azure AD tenant.
229
229
* When configuring the provisioning app, select the AD domain from the dropdown of registered domains.
230
-
* If you are using scoping filters, configure [skip out of scope deletions flag](skip-out-of-scope-deletions.md) to prevent accidental account deactivations.
230
+
* If you're using scoping filters, configure [skip out of scope deletions flag](skip-out-of-scope-deletions.md) to prevent accidental account deactivations.
231
231
232
232
### Deployment topology 2: Separate apps to provision distinct user sets from Cloud HR to single on-premises Active Directory domain
233
233
@@ -247,7 +247,7 @@ This topology supports business requirements where attribute mapping and provisi
247
247
248
248
### Deployment topology 3: Separate apps to provision distinct user sets from Cloud HR to multiple on-premises Active Directory domains (no cross-domain visibility)
249
249
250
-
Use this topology to manage multiple independent child AD domains belonging to the same forest, if managers always exist in the same domain as the user and your unique ID generation rules for attributes like *userPrincipalName*, *samAccountName* and *mail*does not require a forest-wide lookup. It also offers the flexibility of delegating the administration of each provisioning job by domain boundary.
250
+
Use this topology to manage multiple independent child AD domains belonging to the same forest, if managers always exist in the same domain as the user and your unique ID generation rules for attributes like *userPrincipalName*, *samAccountName* and *mail*doesn't require a forest-wide lookup. It also offers the flexibility of delegating the administration of each provisioning job by domain boundary.
251
251
252
252
For example: In the diagram below, the provisioning apps are set up for each geographic region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). Depending on the location, users are provisioned to the respective AD domain. Delegated administration of the provisioning app is possible so that *EMEA administrators* can independently manage the provisioning configuration of users belonging to the EMEA region.
253
253
@@ -283,7 +283,7 @@ For example: In the diagram below, the provisioning apps are set up for each geo
283
283
284
284
### Deployment topology 5: Single app to provision all users from Cloud HR to multiple on-premises Active Directory domains (with cross-domain visibility)
285
285
286
-
Use this topology if you want to use a single provisioning app to manage users belonging to all your parent and child AD domains. This topology is recommended if provisioning rules are consistent across all domains and there is no requirement for delegated administration of provisioning jobs. This topology supports resolving cross-domain manager references and can perform forest-wide uniqueness check.
286
+
Use this topology if you want to use a single provisioning app to manage users belonging to all your parent and child AD domains. This topology is recommended if provisioning rules are consistent across all domains and there's no requirement for delegated administration of provisioning jobs. This topology supports resolving cross-domain manager references and can perform forest-wide uniqueness check.
287
287
288
288
For example: In the diagram below, a single provisioning app manages users present in three different child domains grouped by region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). The attribute mapping for *parentDistinguishedName* is used to dynamically create a user in the appropriate child domain. Cross-domain manager references and forest-wide lookup are handled by enabling referral chasing on the provisioning agent.
289
289
@@ -296,7 +296,7 @@ For example: In the diagram below, a single provisioning app manages users prese
296
296
* Create a single HR2AD provisioning app for the entire forest.
297
297
* When configuring the provisioning app, select the parent AD domain from the dropdown of available AD domains. This ensures forest-wide lookup while generating unique values for attributes like *userPrincipalName*, *samAccountName* and *mail*.
298
298
* Use *parentDistinguishedName* with expression mapping to dynamically create user in the correct child domain and [OU container](#configure-active-directory-ou-container-assignment).
299
-
* If you are using scoping filters, configure [skip out of scope deletions flag](skip-out-of-scope-deletions.md) to prevent accidental account deactivations.
299
+
* If you're using scoping filters, configure [skip out of scope deletions flag](skip-out-of-scope-deletions.md) to prevent accidental account deactivations.
300
300
301
301
### Deployment topology 6: Separate apps to provision distinct users from Cloud HR to disconnected on-premises Active Directory forests
302
302
@@ -314,7 +314,7 @@ Use this topology if your IT infrastructure has disconnected/disjoint AD forests
314
314
315
315
### Deployment topology 7: Separate apps to provision distinct users from multiple Cloud HR to disconnected on-premises Active Directory forests
316
316
317
-
In large organizations, it is not uncommon to have multiple HR systems. During business M&A (mergers and acquisitions) scenarios, you may come across a need to connect your on-premises Active Directory to multiple HR sources. We recommend the topology below if you have multiple HR sources and would like to channel the identity data from these HR sources to either the same or different on-premises Active Directory domains.
317
+
In large organizations, it isn't uncommon to have multiple HR systems. During business M&A (mergers and acquisitions) scenarios, you may come across a need to connect your on-premises Active Directory to multiple HR sources. We recommend the topology below if you have multiple HR sources and would like to channel the identity data from these HR sources to either the same or different on-premises Active Directory domains.
318
318
319
319
:::image type="content" source="media/plan-cloud-hr-provision/topology-7-separate-apps-from-multiple-hr-to-disconnected-ad-forests.png" alt-text="Screenshot of separate apps to provision users from multiple Cloud HR to disconnected AD forests" lightbox="media/plan-cloud-hr-provision/topology-7-separate-apps-from-multiple-hr-to-disconnected-ad-forests.png":::
Copy file name to clipboardExpand all lines: articles/active-directory/conditional-access/concept-conditional-access-conditions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -118,7 +118,7 @@ These browsers support device authentication, allowing the device to be identifi
118
118
> [!NOTE]
119
119
> Edge 85+ requires the user to be signed in to the browser to properly pass device identity. Otherwise, it behaves like Chrome without the accounts extension. This sign-in might not occur automatically in a Hybrid Azure AD Join scenario.
120
120
>
121
-
> Safari is supported for device-based Conditional Access, but it can not satisfy the **Require approved client app** or **Require app protection policy** conditions. A managed browser like Microsoft Edge will satisfy approved client app and app protection policy requirements.
121
+
> Safari is supported for device-based Conditional Access on a managed device, but it can not satisfy the **Require approved client app** or **Require app protection policy** conditions. A managed browser like Microsoft Edge will satisfy approved client app and app protection policy requirements.
122
122
> On iOS with 3rd party MDM solution only Microsoft Edge browser supports device policy.
123
123
>
124
124
> [Firefox 91+](https://support.mozilla.org/kb/windows-sso) is supported for device-based Conditional Access, but "Allow Windows single sign-on for Microsoft, work, and school accounts" needs to be enabled.
@@ -49,7 +49,7 @@ Register your web API in **App registrations** in the Azure portal.
49
49
1. Enter a **Name** for your application, for example `AppModelv2-NativeClient-DotNet-TodoListService`. Users of your app might see this name, and you can change it later.
50
50
1. For **Supported account types**, select **Accounts in any organizational directory**.
51
51
1. Select **Register** to create the application.
52
-
1. On the app **Overview** page, look for the **Application (client) ID** value, and then record it for later use. You'll need it to configure the Visual Studio configuration file for this project (that is, `ClientId` in the *TodoListService\Web.config* file).
52
+
1. On the app **Overview** page, look for the **Application (client) ID** value, and then record it for later use. You'll need it to configure the Visual Studio configuration file for this project (that is, `ClientId` in the *TodoListService\appsettings.json* file).
53
53
1. Under **Manage**, select **Expose an API** > **Add a scope**. Accept the proposed Application ID URI (`api://{clientId}`) by selecting **Save and continue**, and then enter the following information:
54
54
55
55
1. For **Scope name**, enter `access_as_user`.
@@ -65,9 +65,9 @@ Register your web API in **App registrations** in the Azure portal.
65
65
66
66
Configure the service project to match the registered web API.
67
67
68
-
1. Open the solution in Visual Studio, and then open the *Web.config* file under the root of the TodoListService project.
68
+
1. Open the solution in Visual Studio, and then open the *appsettings.json* file under the root of the TodoListService project.
69
69
70
-
1. Replace the value of the `ida:ClientId` parameter with the Client ID (Application ID) value from the application you registered in the **App registrations** portal.
70
+
1. Replace the value of the `Enter_the_Application_Id_here` by the Client ID (Application ID) value from the application you registered in the **App registrations** portal both in the `ClientID` and the `Audience` properties.
71
71
72
72
### Add the new scope to the app.config file
73
73
@@ -167,18 +167,7 @@ You can allow users from other directories to access your web API by pre-authori
167
167
168
168
By default, any personal accounts, such as *outlook.com* or *live.com* accounts, or work or school accounts from organizations that are integrated with Azure AD can request tokens and access your web API.
169
169
170
-
To specify who can sign in to your application, use one of the following options:
171
-
172
-
### Option 1: Limit access to a single organization (single tenant)
173
-
174
-
You can limit sign-in access to your application to user accounts that are in a single Azure AD tenant, including guest accounts of that tenant. This scenario is common for line-of-business applications.
175
-
176
-
1. Open the *App_Start\Startup.Auth* file, and then change the value of the metadata endpoint that's passed into the `OpenIdConnectSecurityTokenProvider` to `https://login.microsoftonline.com/{Tenant ID}/v2.0/.well-known/openid-configuration`. You can also use the tenant name, such as `contoso.onmicrosoft.com`.
177
-
1. In the same file, set the `ValidIssuer` property on the `TokenValidationParameters` to `https://sts.windows.net/{Tenant ID}/`, and set the `ValidateIssuer` argument to `true`.
178
-
179
-
### Option 2: Use a custom method to validate issuers
180
-
181
-
You can implement a custom method to validate issuers by using the `IssuerValidator` parameter. For more information about this parameter, see [TokenValidationParameters class](/dotnet/api/microsoft.identitymodel.tokens.tokenvalidationparameters).
170
+
To specify who can sign in to your application, by changing the `TenantId` property in the *appsettings.json* file.
182
171
183
172
[!INCLUDE [Help and support](../../../../../includes/active-directory-develop-help-support-include.md)]
Copy file name to clipboardExpand all lines: articles/active-directory/reports-monitoring/concept-audit-logs.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,7 +66,7 @@ With an application-centric view, you can get answers to questions such as:
66
66
67
67
## How do I access it?
68
68
69
-
The audit activity report is available in all editions of Azure AD. To access the audit logs, you need to have one of the following roles:
69
+
To access the audit log for a tenant, you must have one of the following roles:
70
70
71
71
- Reports Reader
72
72
- Security Reader
@@ -76,7 +76,7 @@ The audit activity report is available in all editions of Azure AD. To access th
76
76
77
77
Sign in to the Azure portal and go to **Azure AD** and select **Audit log** from the **Monitoring** section.
78
78
79
-
You can also access the audit log through the [Microsoft Graph API](/graph/api/resources/azure-ad-auditlog-overview).
79
+
The audit activity report is available in [all editions of Azure AD](reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data). If you have an Azure Active Directory P1 or P2 license, you can access the audit log through the [Microsoft Graph API](/graph/api/resources/azure-ad-auditlog-overview). See [Getting started with Azure Active Directory Premium](../fundamentals/active-directory-get-started-premium.md) to upgrade your Azure Active Directory edition. It will take a couple of days for the data to show up in Graph after you upgrade to a premium license with no data activities before the upgrade.
0 commit comments