Differences

This shows you the differences between two versions of the page.

--- azure:az-500:alt:identity_and_access_management [2023/01/31 17:15] – [Related] mmuze
+++ azure:az-500:alt:identity_and_access_management [2023/02/11 21:02] (current) – [Identity and Access Management] mmuze
@@ Line 1: / Line 1: @@
 ====== Identity and Access Management ======
+  * [[https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles]]
   * [[azure:az-500:alt:role_based_access_control|Role Based Access Control/RBAC]]
   * [[azure:az-500:alt:hybrid_identity|Hybrid Identity]]
@@ Line 7: / Line 8: @@
   * Because Azure AD is HTTP/HTTPS based, it does not use Kerberos authentication. Instead, it uses HTTP and HTTPS protocols such as SAML, WS-Federation, and OpenID Connect for authentication (and OAuth for authorization).
   * MFA is supported for free tier AAD by way of //Security Defaults//.
-      * //Security Defaults// is a a built-in set of protections against identity based attacks.
+      * //Security Defaults// is a built-in set of protections against identity-based attacks.
+  * **//[[https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/directory-delegated-administration-primer|delegated administration]]//** is the term for how a //CSP (Cloud Solution Provider)// can be given roles that allow them to administer services on behalf of the customer.
+==== Security Principle ====
+> Security principal: An Azure security principal is a security identity that user-created apps, services, and automation tools use to access specific Azure resources. Think of it as a "user identity" (username and password or certificate) with a specific role, and tightly controlled permissions. A security principal should only need to do specific things, unlike a general user identity. It improves security if you grant it only the minimum permission level that it needs to perform its management tasks. A security principal used with an application or service is called a service principal.
 ===== Authentication Methods =====
@@ Line 20: / Line 27: @@
 >The simplest way to enable authentication for on-premises directory objects in Azure AD. Users can use the same username and password that they use on-premises without having to deploy any additional infrastructure. Some premium features of Azure AD, like Identity Protection and Azure AD Domain Services, require password hash synchronization, no matter which authentication method you choose.
 ====== AAD Roles ======
+  * AAD Roles are generally assigned to individual users, but some groups are given a special designation that allows roles to be assigned to them.
+    * These must be cloud groups created directly in AAD, **not** synced security groups from Windows AD.
+    * The members must be directly assigned to the group—not dynamic groups.
+  * AAD does not have organizational units (OUs)—it has a flat structure. But it does have **Administrative Units** that certain roles can be assigned to.
 > The **Account Administrator** is the user that initially signed up for the Azure subscription, and is responsible as the billing owner of the subscription.
@@ Line 90: / Line 101: @@
   * Requires a P2 license
+====== Microsoft Entra Verified ID ======
+====== Passwordless authentication ======
+====== User Management ======
+  * Deleted users and M365 groups can be restored (undeleted) for up to 30 days.
+  * Deleted Security Groups cannot be restored.
+====== Guest Access ======
+  * The default user/guest collaboration settings allow any user (including B2B guest uers) to invite guest users.
+  * When inviting guests is limited to certain admin roles those roles include Global Administrator, User Administrator, and Guest Inviter.
 ====== Related ======
   * [[azure:az-500:alt:hybrid_identity|Hybrid Identity]]