第25個冬天

  Q1. 先針對User1資訊來逐Group比對 Group1 → 條件：city 以 "m" 開頭，Montreal → 符合。 Group2 → 條件：department 不在 ["human resources"] User1 部門是 Human resources → 不符合 Group3 → 是 Assigned 群組，沒有動態規則。 但題目沒有說誰被指定 → 預設沒被指定，不加入。 結論:User1 只屬於 Group1 針對User2資訊來逐Group比對 Group1 → 條件：city 以 "m" 開頭，Melbourne →  符合 Group2 → 條件：部門 不是 human resources User2 部門是 Marketing →  符合 Group3 → 同上，Assigned 群組，沒說被指定 → 不加入 結論: User2 屬於 Group1 和 Group2 Q2.涉及混合部署的 Azure AD 關於能否從 Azure AD 修改用戶的 JobTitle 和 UsageLocation 屬性。 通常，只有純雲端用戶（來源為 Azure AD）能在 Azure AD 中修改屬性，而某些來自 Microsoft 帳戶的來賓用戶也可能能修改些許屬性。對於來自 Windows Server AD 的同步用戶，必須通過 Azure AD Connect，同步許多屬性，無法直接修改。 在混合部署中，某些屬性只能在本地環境修改並同步至 Azure AD。 例如，JobTitle 和 UsageLocation 屬性可能只在本地環境中可處理，而對於來賓用戶（來自 Microsoft 帳戶），它們可在 Azure AD 中修改，因為是外部屬性。 目前來賓使用者的 UsageLocation 是否被限制為必須設置進行許可指派還不確定，但 JobTitle 和 UsageLocation 應該可以為雲端用戶和來賓設定。 結論: JobTitle:User1 and User3 only 只有「雲端使用者 (Source = Azure AD)」與「來賓使用者 (Guest)」的 jobTitle 可以直接在 Azure AD 入口網站編輯。 User2屬於同步使用者 (Source ...

管理 Microsoft Entra 使用者和群組 建立使用者與群組 管理使用者與群組屬性 管理 Microsoft Entra ID 中的授權 管理外部使用者 設定自助式密碼重設 (SSPR) Microsoft Entra ID  前身為Azure Active Directory(Azure AD)。2023 年，Azure Active Directory (Azure AD) 已更名為 Microsoft Entra ID。 由 Microsoft 提供的雲端基礎身份認證、識別與存取權管理 (IAM) 服務， 允許組織管理使用者帳戶並存取本地的資源和雲端的資源。 提供了一個集中管理位置，用於跨多個應用程式、平台和設備管理使用者認證和授權。 使用如 OAuth 2、OpenID Connect、SAML 和 WS-Fed 等協定用於身分識別和授權。(非常適合透過網際網路運作，因為它們使用 HTTPS/TLS 加密。) 在 Entra ID 中，標準交流方式是透過 Microsoft Graph，用於與 Office 365、Entra ID 等許多服務進行互動，這些互動是基於 REST 的呼叫，同樣透過 HTTPS (連接埠 443) 進行。 與地端環境中常見的 Active Directory Domain Services (AD DS) 有顯著不同，AD DS 使用 Kerberos、NTLM，並透過 LDAP 進行互動。 AD DS 具有組織單位 (OU) 的結構，但 Entra ID 主要是扁平的，AD DS主要為私有網路結構設計。 Entra ID 中有兩種類型的群組 安全性 (Security)：最常見的類型，可以指派給角色 Microsoft 365：用於協作工具、行事曆、SharePoint 等 群組成員資格 指派的 (Assigned)：手動指定特定的使用者或裝置。 動態的 (Dynamic)：基於規則自動管理成員資格（適用於使用者或裝置），Entra ID 會定期檢查符合規則的身分識別並將其新增到群組中。 Entra ID 具有不同層級的授權，通常是按使用者授權。功能因授權層級(收費標準)而異： 免費 (Free)：提供基本功能 P1 (Premium P1)：增加了許多關鍵功能，例如 條件式存取 (Conditional Ac...