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
title: View privileged role assignments in Azure AD Insights
3
+
description: How to view current privileged role assignments in the Azure AD Insights tab.
4
+
services: active-directory
5
+
author: jenniferf-skc
6
+
manager: amycolannino
7
+
ms.service: active-directory
8
+
ms.subservice: ciem
9
+
ms.workload: identity
10
+
ms.topic: how-to
11
+
ms.date: 03/31/2023
12
+
ms.author: jfields
13
+
---
14
+
15
+
# View privileged role assignments in your organization (Preview)
16
+
17
+
The **Azure AD Insights** tab shows you who is assigned to privileged roles in your organization. You can review a list of identities assigned to a privileged role and learn more about each identity.
18
+
19
+
> [!NOTE]
20
+
> Microsoft recommends that you keep two break glass accounts permanently assigned to the global administrator role. Make sure that these accounts don't require the same multi-factor authentication mechanism to sign in as other administrative accounts. This is described further in [Manage emergency access accounts in Microsoft Entra](../roles/security-emergency-access.md).
21
+
22
+
> [!NOTE]
23
+
> Keep role assignments permanent if a user has a an additional Microsoft account (for example, an account they use to sign in to Microsoft services like Skype, or Outlook.com). If you require multi-factor authentication to activate a role assignment, a user with an additional Microsoft account will be locked out.
24
+
25
+
## View information in the Azure AD Insights tab
26
+
27
+
1. From the Permissions Management home page, select the **Azure AD Insights** tab.
28
+
2. Select **Review global administrators** to review the list of Global administrator role assignments.
29
+
3. Select **Review highly privileged roles** or **Review service principals** to review information on principal role assignments for the following roles: *Application administrator*, *Cloud Application administrator*, *Exchange administrator*, *Intune administrator*, *Privileged role administrator*, *SharePoint administrator*, *Security administrator*, *User administrator*.
30
+
31
+
32
+
## Next steps
33
+
34
+
- For information about managing roles, policies and permissions requests in your organization, see [View roles/policies and requests for permission in the Remediation dashboard](ui-remediation.md).
Copy file name to clipboardExpand all lines: articles/active-directory/identity-protection/concept-workload-identity-risk.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ We detect risk on workload identities across sign-in behavior and offline indica
55
55
| --- | --- | --- |
56
56
| Azure AD threat intelligence | Offline | This risk detection indicates some activity that is consistent with known attack patterns based on Microsoft's internal and external threat intelligence sources. |
57
57
| Suspicious Sign-ins | Offline | This risk detection indicates sign-in properties or patterns that are unusual for this service principal. <br><br> The detection learns the baselines sign-in behavior for workload identities in your tenant in between 2 and 60 days, and fires if one or more of the following unfamiliar properties appear during a later sign-in: IP address / ASN, target resource, user agent, hosting/non-hosting IP change, IP country, credential type. <br><br> Because of the programmatic nature of workload identity sign-ins, we provide a timestamp for the suspicious activity instead of flagging a specific sign-in event. <br><br> Sign-ins that are initiated after an authorized configuration change may trigger this detection. |
58
-
| Admin confirmed account compromised | Offline | This detection indicates an admin has selected 'Confirm compromised' in the Risky Workload Identities UI or using riskyServicePrincipals API. To see which admin has confirmed this account compromised, check the account’s risk history (via UI or API). |
58
+
| Admin confirmed service principal compromised | Offline | This detection indicates an admin has selected 'Confirm compromised' in the Risky Workload Identities UI or using riskyServicePrincipals API. To see which admin has confirmed this account compromised, check the account’s risk history (via UI or API). |
59
59
| Leaked Credentials | Offline | This risk detection indicates that the account's valid credentials have been leaked. This leak can occur when someone checks in the credentials in public code artifact on GitHub, or when the credentials are leaked through a data breach. <br><br> When the Microsoft leaked credentials service acquires credentials from GitHub, the dark web, paste sites, or other sources, they're checked against current valid credentials in Azure AD to find valid matches. |
60
60
| Malicious application | Offline | This detection indicates that Microsoft has disabled an application for violating our terms of service. We recommend [conducting an investigation](https://go.microsoft.com/fwlink/?linkid=2208429) of the application. Note: These applications will show `DisabledDueToViolationOfServicesAgreement` on the `disabledByMicrosoftStatus` property on the related [application](/graph/api/resources/application) and [service principal](/graph/api/resources/serviceprincipal) resource types in Microsoft Graph. To prevent them from being instantiated in your organization again in the future, you cannot delete these objects. |
61
61
| Suspicious application | Offline | This detection indicates that Microsoft has identified an application that may be violating our terms of service, but hasn't disabled it. We recommend [conducting an investigation](https://go.microsoft.com/fwlink/?linkid=2208429) of the application.|
@@ -124,3 +124,4 @@ The [Azure AD Toolkit](https://github.com/microsoft/AzureADToolkit) is a PowerSh
Copy file name to clipboardExpand all lines: articles/active-directory/reports-monitoring/concept-provisioning-logs.md
+5-1Lines changed: 5 additions & 1 deletion
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.topic: conceptual
9
9
ms.workload: identity
10
10
ms.subservice: report-monitor
11
-
ms.date: 03/24/2023
11
+
ms.date: 03/31/2023
12
12
ms.author: sarahlipsey
13
13
ms.reviewer: arvinh
14
14
ms.collection: M365-identity-device-management
@@ -231,6 +231,7 @@ Use the following table to better understand how to resolve errors that you find
231
231
|SystemForCrossDomainIdentity<br>ManagementServiceIncompatible|The Azure AD provisioning service is unable to parse the response from the third party application. Work with the application developer to ensure that the SCIM server is compatible with the [Azure AD SCIM client](../app-provisioning/use-scim-to-provision-users-and-groups.md#understand-the-azure-ad-scim-implementation).|
232
232
|SchemaPropertyCanOnlyAcceptValue|The property in the target system can only accept one value, but the property in the source system has multiple. Ensure that you either map a single-valued attribute to the property that is throwing an error, update the value in the source to be single-valued, or remove the attribute from the mappings.|
233
233
234
+
234
235
## Error codes for cross-tenant synchronization
235
236
236
237
Use the following table to better understand how to resolve errors that you find in the provisioning logs for [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-configure.md). For any error codes that are missing, provide feedback by using the link at the bottom of this page.
@@ -243,6 +244,9 @@ Use the following table to better understand how to resolve errors that you find
243
244
> | AzureActiveDirectoryQuotaLimitExceeded | The number of objects in the tenant exceeds the directory limit.<br/><br/>Azure AD has limits for the number of objects that can be created in a tenant. | Check whether the quota can be increased. For information about the directory limits and steps to increase the quota, see [Azure AD service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md). |
244
245
> |InvitationCreationFailure| The Azure AD provisioning service attempted to invite the user in the target tenant. That invitation failed.| Navigate to the user settings page in Azure AD > external users > collaboration restrictions and ensure that collaboration with that tenant is enabled.|
245
246
> |AzureActiveDirectoryInsufficientRights|When a B2B user in the target tenant has a role other than User, Helpdesk Admin, or User Account Admin, they cannot be deleted.| Please remove the role(s) on the user in the target tenant in order to successfully delete the user in the target tenant.|
247
+
> |AzureActiveDirectoryForbidden|External collaboration settings have blocked invitations.|Navigate to user settings and ensure that [external collaboration settings](https://learn.microsoft.com/azure/active-directory/external-identities/external-collaboration-settings-configure) are permitted.|
248
+
> |InvitationCreationFailureInvalidPropertyValue|Potential causes: * The Primary SMTP Address is an invalid value. * UserType is neither guest nor member * Group email Address is not supported |* The Primary SMTP Address has an invalid value. Resolving this issue will likely require updating the mail property of the source user. aka.ms/DirectoryAttributeValidations * Please ensure that the userType property is provisioned as type guest or member. This can be fixed by checking your attribute mappings to understand how the userType attribute is mapped. *The email address address of the user matches with the email address of a group in the tenant. Please update the email address for one of the two objects.|
249
+
> |InvitationCreationFailureAmbiguousUser| The invited user has a proxy address that matches an internal user in the target tenant. The proxy address must be unique. | To resolve this error, delete the existing internal user in the target tenant or remove this user from sync scope.|
Copy file name to clipboardExpand all lines: articles/iot-edge/how-to-vs-code-develop-module.md
+50-6Lines changed: 50 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ zone_pivot_groups: iotedge-dev
17
17
18
18
This article shows you how to use Visual Studio Code to develop and debug IoT Edge modules in multiple languages and multiple architectures. On your development computer, you can use Visual Studio Code to attach and debug your module in a local or remote module container.
19
19
20
-
You can choose either the **Azure IoT Edge Dev Tool** CLI or the **Azure IoT Edge tools for Visual Studio Code** extension as your IoT Edge development tool. Use the tool selector button at the beginning to choose your tool option for this article.
20
+
You can choose either the **Azure IoT Edge Dev Tool**command-line tool (CLI) or the **Azure IoT Edge tools for Visual Studio Code** extension as your IoT Edge development tool. Use the tool selector button at the beginning to choose your tool option for this article.
21
21
22
22
Visual Studio Code supports writing IoT Edge modules in the following programming languages:
23
23
@@ -29,8 +29,8 @@ Visual Studio Code supports writing IoT Edge modules in the following programmin
29
29
30
30
Azure IoT Edge supports the following device architectures:
31
31
32
-
*X64
33
-
*ARM32
32
+
*AMD64
33
+
*ARM32v7
34
34
* ARM64
35
35
36
36
For more information about supported operating systems, languages, and architectures, see [Language and architecture support](module-development.md#language-and-architecture-support).
@@ -72,7 +72,7 @@ To build and deploy your module image, you need Docker to build the module image
72
72
73
73
::: zone pivot="iotedge-dev-cli"
74
74
75
-
- Install the Python-based [Azure IoT Edge Dev Tool](https://pypi.org/project/iotedgedev/) with the following command to enable you to debug, run, and test your IoT Edge solution. [Python (3.6/3.7)](https://www.python.org/downloads/) and [Pip3](https://pip.pypa.io/en/stable/installation/) are required.
75
+
- Install the Python-based [Azure IoT Edge Dev Tool](https://pypi.org/project/iotedgedev/) with the following command to enable you to debug, run, and test your IoT Edge solution. [Python (3.6 or 3.7)](https://www.python.org/downloads/) and [Pip3](https://pip.pypa.io/en/stable/installation/) are required.
76
76
77
77
```bash
78
78
pip3 install iotedgedev
@@ -260,6 +260,30 @@ For example:
260
260
261
261
::: zone-end
262
262
263
+
::: zone pivot="iotedge-dev-cli"
264
+
265
+
### Set IoT Edge runtime version
266
+
267
+
The latest stable IoT Edge system module version is 1.4. Set your system modules to version 1.4.
268
+
269
+
1. In Visual Studio Code, open *deployment.debug.template.json* deployment manifest file. The [deployment manifest](module-deployment-monitoring.md#deployment-manifest) is a JSON document that describes the modules to be configured on the targeted IoT Edge device.
270
+
1. Change the runtime version for the system runtime module images *edgeAgent* and *edgeHub*. For example, if you want to use the IoT Edge runtime version 1.4, change the following lines in the deployment manifest file:
You may receive a security warning recommending the use of `--password-stdin`. While that is a recommended best practice for production scenarios, it's outside the scope of this tutorial. For more information, see the [docker login](https://docs.docker.com/engine/reference/commandline/login/#provide-a-password-using-stdin) reference.
631
+
632
+
1. Sign in to the Azure Container Registry. You may need to [Install Azure CLI](/cli/azure/install-azure-cli) to use the `az` command. This command asks for your user name and password found in your container registry in **Settings** > **Access keys**.
633
+
634
+
```azurecli
635
+
az acr login -n <ACR registry name>
636
+
```
637
+
>[!TIP]
638
+
>If you get logged out at any point in this tutorial, repeat the Docker and Azure Container Registry sign in steps to continue.
639
+
596
640
#### Build module Docker image
597
641
598
642
Use the module's Dockerfile to [build](https://docs.docker.com/engine/reference/commandline/build/) the module Docker image.
Use the [IoT Edge Azure CLI set-modules](/cli/azure/iot/edge#az-iot-edge-set-modules) command to deploy the modules to the Azure IoT Hub. For example, to deploy the modules defined in the *deployment.debug.amd64.json* file to IoT Hub *my-iot-hub* for the IoT Edge device *my-device*, use the following command:
680
+
Use the [IoT Edge Azure CLI set-modules](/cli/azure/iot/edge#az-iot-edge-set-modules) command to deploy the modules to the Azure IoT Hub. For example, to deploy the modules defined in the *deployment.debug.template.json* file to IoT Hub *my-iot-hub*for the IoT Edge device *my-device*, use the following command:
> You can find your IoT Hub connection string in the Azure portal in your IoT Hub > **Security settings** > **Shared access policies** > **iothubowner**.
687
+
> You can find your IoT Hub shared access keyin the Azure portal in your IoT Hub >**Security settings**>**Shared access policies**>**iothubowner**.
0 commit comments