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/develop/howto-restrict-your-app-to-a-set-of-users.md
+39-6Lines changed: 39 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,10 +8,11 @@ ms.service: active-directory
8
8
ms.subservice: develop
9
9
ms.workload: identity
10
10
ms.topic: how-to
11
-
ms.date: 12/19/2022
11
+
ms.date: 03/27/2023
12
12
ms.author: cwerner
13
13
ms.reviewer: jmprieur, kkrishna
14
14
ms.custom: aaddev, engagement-fy23
15
+
15
16
#Customer intent: As a tenant administrator, I want to restrict an application that I have registered in Azuren-e AD to a select set of users available in my Azure AD tenant
16
17
---
17
18
@@ -21,14 +22,14 @@ Applications registered in an Azure Active Directory (Azure AD) tenant are, by d
21
22
22
23
Similarly, in a [multi-tenant](howto-convert-app-to-be-multi-tenant.md) application, all users in the Azure AD tenant where the application is provisioned can access the application once they successfully authenticate in their respective tenant.
23
24
24
-
Tenant administrators and developers often have requirements where an application must be restricted to a certain set of users. There are two ways to restrict an application to a certain set of users or security groups:
25
+
Tenant administrators and developers often have requirements where an application must be restricted to a certain set of users or apps(services). There are two ways to restrict an application to a certain set of users, apps or security groups:
25
26
26
27
- Developers can use popular authorization patterns like [Azure role-based access control (Azure RBAC)](howto-implement-rbac-for-apps.md).
27
28
- Tenant administrators and developers can use built-in feature of Azure AD.
28
29
29
30
## Supported app configurations
30
31
31
-
The option to restrict an app to a specific set of users or security groups in a tenant works with the following types of applications:
32
+
The option to restrict an app to a specific set of users, apps or security groups in a tenant works with the following types of applications:
32
33
33
34
- Applications configured for federated single sign-on with SAML-based authentication.
34
35
- Application proxy applications that use Azure AD pre-authentication.
@@ -41,19 +42,19 @@ To update an application to require user assignment, you must be owner of the ap
41
42
1. Sign in to the [Azure portal](https://portal.azure.com/)
42
43
1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch the tenant in which you want to register an application.
43
44
1. Search for and select **Azure Active Directory**.
44
-
1. Under **Manage**, select **Enterprise Applications**>**All applications**.
45
+
1. Under **Manage**, select **Enterprise Applications**then select**All applications**.
45
46
1. Select the application you want to configure to require assignment. Use the filters at the top of the window to search for a specific application.
46
47
1. On the application's **Overview** page, under **Manage**, select **Properties**.
47
48
1. Locate the setting **Assignment required?** and set it to **Yes**. When this option is set to **Yes**, users and services attempting to access the application or services must first be assigned for this application, or they won't be able to sign-in or obtain an access token.
48
49
1. Select **Save** on the top bar.
49
50
50
51
When an application requires assignment, user consent for that application isn't allowed. This is true even if users consent for that app would have otherwise been allowed. Be sure to [grant tenant-wide admin consent](../manage-apps/grant-admin-consent.md) to apps that require assignment.
51
52
52
-
## Assign the app to users and groups
53
+
## Assign the app to users and groups to restrict access
53
54
54
55
Once you've configured your app to enable user assignment, you can go ahead and assign the app to users and groups.
55
56
56
-
1. Under **Manage**, select the **Users and groups**>**Add user/group** .
57
+
1. Under **Manage**, select the **Users and groups**then select**Add user/group** .
57
58
1. Select the **Users** selector.
58
59
59
60
A list of users and security groups will be shown along with a textbox to search and locate a certain user or group. This screen allows you to select multiple users and groups in one go.
@@ -63,6 +64,38 @@ Once you've configured your app to enable user assignment, you can go ahead and
63
64
1. Select **Assign** to complete the assignments of the app to the users and groups.
64
65
1. Confirm that the users and groups you added are showing up in the updated **Users and groups** list.
65
66
67
+
## Restrict access to an app (resource) by assigning other services (client apps)
68
+
69
+
Follow the steps in this section to secure app-to-app authentication access for your tenant.
70
+
71
+
1. Navigate to Service Principal sign-in logs in your tenant to find services authenticating to access resources in your tenant.
72
+
1. Check using app ID if a Service Principal exists for both resource and client apps in your tenant that you wish to manage access.
73
+
```powershell
74
+
Get-MgServicePrincipal `
75
+
-Filter "AppId eq '$appId'"
76
+
```
77
+
1. Create a Service Principal using app ID, if it does not exist:
78
+
```powershell
79
+
New-MgServicePrincipal `
80
+
-AppId $appId
81
+
```
82
+
1. Explicitly assign client apps to resource apps (this functionality is available only in API and not in the Azure AD Portal):
> If you don't want tokens to be issued for an application or if you want to block an application from being accessed by users or services in your tenant, create a service principal for the application and [disable user sign-in](../manage-apps/disable-user-sign-in-portal.md) for it.
98
+
66
99
## More information
67
100
68
101
For more information about roles and security groups, see:
Copy file name to clipboardExpand all lines: articles/active-directory/reports-monitoring/reports-faq.yml
+48-11Lines changed: 48 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ metadata:
9
9
ms.workload: identity
10
10
ms.topic: faq
11
11
ms.subservice: report-monitor
12
-
ms.date: 02/22/2023
12
+
ms.date: 03/27/2023
13
13
ms.author: sarahlipsey
14
14
ms.reviewer: besiler
15
15
ms.collection: M365-identity-device-management
@@ -111,6 +111,43 @@ sections:
111
111
answer: |
112
112
No, in general 90025 errors are resolved by an automatic retry without the user noticing the error. This error can occur when an internal Azure AD subservice hits its retry allowance and does not indicate your tenant is being throttled. These errors are usually resolved by Azure AD internally without any user impact. If the user is unable to sign in due to this error, manually trying again should resolve the issue.
113
113
114
+
- question: |
115
+
In Service Principal sign-in logs, what does it mean if I see “00000000-0000-0000-0000-000000000000” or “” for Service Principal ID or Resource Service Principal ID in my sign-in logs?
116
+
answer: |
117
+
If the Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there is no Service Principal for the client application in that instance of authentication (Azure AD no longer issues access tokens without a client Service Principal except for a small number of Microsoft and 3rd party applications).
118
+
119
+
If the Resource Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there is no Service Principal for the resource application in that instance of authentication.
120
+
121
+
> [!NOTE]
122
+
> Authentication without a client Service Principal is a deprecated behavior in Azure AD and is not commonly expected. This behavior is currently allowed only for a limited number of resource apps.
123
+
124
+
- question: |
125
+
In Service Principal sign-in logs, how can I query for instances of authentication without a client or resource Service Principal in my tenant? (That is, Service Principal ID or Resource Service Principal ID is “00000000-0000-0000-0000-000000000000” or “”)
126
+
answer: |
127
+
- To find instances of sign-in logs for your tenant where a client Service Principal is missing, use the following query:
128
+
```http
129
+
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and servicePrincipalId eq '00000000-0000-0000-0000-000000000000'
130
+
```
131
+
- To find instances of sign-in logs for your tenant where a resource Service Principal is missing, use the following query:
132
+
```http
133
+
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and resourceServicePrincipalId eq '00000000-0000-0000-0000-000000000000'
134
+
```
135
+
136
+
You can also find these sign-in logs in Azure AD Portal.
137
+
138
+
- Sign in to the [Azure portal](https://portal.azure.com) and go to **Azure Active Directory**.
139
+
- Navigate to Sign in Logs under **Monitoring**,
140
+
- Select the **Service Principal Sign ins**.
141
+
- Make sure you select an appropriate time frame in the Date field (last 24 hours, 7 days etc.).
142
+
- Add a filter and select **Service Principal ID** and provide the value ‘00000000-0000-0000-0000-000000000000' to get instances of authentication with no client Service Principal.
143
+
144
+
:::image type="content" source="media/reports-faq/service-principal-sign-ins.png" alt-text="Screenshot of service principal sign-in.":::
145
+
146
+
- question: |
147
+
How can I restrict sign-in (authentication) for various apps that I see in the Service Principal sign-in logs?
148
+
answer:
149
+
If you wish to control how authentication works in your tenant for specific client or resource apps, follow instructions in the [Restrict Azure AD app to a set of users](../develop/howto-restrict-your-app-to-a-set-of-users.md) article.
150
+
114
151
- name: Conditional Access
115
152
questions:
116
153
- question: |
@@ -120,29 +157,29 @@ sections:
120
157
121
158
To get started:
122
159
123
-
* Sign in to the [Azure portal](https://portal.azure.com) and got to **Azure AD** > **Sign-ins log**.
124
-
* Select the sign-in that you want to troubleshoot.
125
-
* Navigate to the **Conditional Access** tab.
160
+
- Sign in to the [Azure portal](https://portal.azure.com) and go to **Azure Active Directory** then select **Sign-ins log**.
161
+
- Select the sign-in that you want to troubleshoot.
162
+
- Navigate to the **Conditional Access** tab.
126
163
Here, you can view all the policies that impacted the sign-in and the result for each policy.
127
164
128
165
- question: |
129
166
What are all possible values for the Conditional Access status?
130
167
answer: |
131
168
Conditional Access status can have the following values:
132
169
133
-
* **Not Applied**: There was no CA policy with the user and app in scope.
134
-
* **Success**: There was a CA policy with the user and app in scope and CA policies were successfully satisfied.
135
-
* **Failure**: The sign-in satisfied the user and application condition of at least one CA policy and grant controls are either not satisfied or set to block access.
170
+
- **Not Applied**: There was no CA policy with the user and app in scope.
171
+
- **Success**: There was a CA policy with the user and app in scope and CA policies were successfully satisfied.
172
+
- **Failure**: The sign-in satisfied the user and application condition of at least one CA policy and grant controls are either not satisfied or set to block access.
136
173
137
174
- question: |
138
175
What are all possible values for the Conditional Access policy result?
139
176
answer: |
140
177
A CA policy can have the following results:
141
178
142
-
* **Success**: The policy was successfully satisfied.
143
-
* **Failure**: The policy wasn't satisfied.
144
-
* **Not applied**: The policy conditions may not have been met.
145
-
* **Not enabled**: The policy may be in a disabled state.
179
+
- **Success**: The policy was successfully satisfied.
180
+
- **Failure**: The policy wasn't satisfied.
181
+
- **Not applied**: The policy conditions may not have been met.
182
+
- **Not enabled**: The policy may be in a disabled state.
146
183
147
184
- question: |
148
185
The policy name in the sign-ins log doesn't match the policy name in Conditional Access. Why?
0 commit comments