Update Azure Active Directoy, Azure AD, and AAD baseline references t…

…o Microsoft Entra ID equivalent (#1176)

* Update aad - entraid for unique IDs

* Updated azure ad references

* Rename aad.md to entraid.md

* Update defender.md azure -> entra

* updating azure ad references

* Update aad referneces in powerplatform

* Updated teams.md aad references

* Update entraid.md uinique ids

Microsoft documentation notes that "Acronym usage isn't encouraged, but if you must replace AAD with an acronym due to space limitations, use ME-ID."

* Update PowerShell/ScubaGear/baselines/entraid.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update PowerShell/ScubaGear/baselines/entraid.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update PowerShell/ScubaGear/baselines/defender.md

Co-authored-by: David Bui <[email protected]>

* Update PowerShell/ScubaGear/baselines/teams.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update PowerShell/ScubaGear/baselines/teams.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update PowerShell/ScubaGear/baselines/powerplatform.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Updated link in readme to new name for the markdown file

* Updated every instance of Microsoft Entra to Microsoft Entra ID for consistency.

* Updated every instance of Microsoft Entra to Microsoft Entra ID for consistency.

* Update entraid.md to revert update of unique ids

* Rename entraid.md back to aad.md

* Update aad.md 3.4v1 instruction

* Update README.md to adjust for the change back to aad.md

* Update PowerShell/ScubaGear/baselines/powerplatform.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update PowerShell/ScubaGear/baselines/powerplatform.md

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Add files via upload

* Updated 2.1v1 notes that reference azure ad

* removed repeated word

* formatting mistake for bolded word

* microsoft entra id consistency

---------

Co-authored-by: mitchelbaker-cisa <[email protected]>
Co-authored-by: David Bui <[email protected]>

PowerShell/ScubaGear/baselines/defender.md

@@ -847,7 +847,7 @@ Audit logs SHALL be maintained for at least the minimum duration dictated by OMB
 - _Last modified:_ June 2023
 - _Note_: Purview Audit (Premium) provides a default audit log retention policy,
           retaining Exchange Online, SharePoint Online, OneDrive for
-          Business, and Azure Active Directory audit records for one year.
+          Business, and Microsoft Entra ID audit records for one year.
           Additional record types require custom audit retention policies.
           Agencies may also consider alternate storage locations and services
           to meet audit log retention needs.

PowerShell/ScubaGear/baselines/powerbi.md

@@ -38,8 +38,8 @@ the types of users are defined as follows:
 2.  **External users**: Members of a different M365 tenant.
 3.  **Business to Business (B2B) guest users**: External users that are
   formally invited to view and/or edit Power BI workspace content and
-  are added to the agency's Azure Active Directory (Azure AD) as guest users. These users authenticate with their home organization/tenant and are granted access to Power BI
-  content by virtue of being listed as guest users in the tenant's Azure AD.
+  are added to the agency's Microsoft Entra ID as guest users. These users authenticate with their home organization/tenant and are granted access to Power BI
+  content by virtue of being listed as guest users in the tenant's Microsoft Entra ID.
 
 > Note:
 > These terms vary in use across Microsoft documentation.
@@ -50,7 +50,7 @@ the types of users are defined as follows:
 
 Power BI has a capability to publish reports and content to the web.
 This capability creates a publicly accessible web URL that does not
-require authentication or status as an Azure AD user to view it. While this
+require authentication or status as an Microsoft Entra ID user to view it. While this
 may be needed for a specific use case or collaboration scenario, it is a
 best practice to keep this setting off by default to prevent unintended
 and potentially sensitive data exposure.
@@ -133,7 +133,7 @@ To Disable Completely:
 
 3. Scroll to **Export and sharing settings**
 
-4. Click on **Allow Azure Active Directory guest users to edit and manage content in the organization** and set to **Disabled**
+4. Click on **Allow Microsoft Entra guest users to edit and manage content in the organization** and set to **Disabled**
 
 To Enable with Security Group(s):
 1. Navigate to the **PowerBI Admin Portal**
@@ -142,7 +142,7 @@ To Enable with Security Group(s):
 
 3. Scroll to **Export and sharing settings**
 
-4. Click on **Allow Azure Active Directory guest users to edit and manage content in the organization** and set to **Enabled**
+4. Click on **Allow Microsoft Entra guest users to edit and manage content in the organization** and set to **Enabled**
 
 5. Select the security group(s) you want to have access to the PowerBI tenant.
 > Note:
@@ -154,7 +154,7 @@ This section provides policies that help reduce guest user invitation risks rela
 The settings in this section control whether Power BI allows inviting external users to
 the agency's organization through Power BI's sharing workflows and
 experiences. After an external user accepts the invite, they become an
-Azure AD B2B guest user in the organization. They will then appear in user
+Microsoft Entra ID B2B guest user in the organization. They will then appear in user
 pickers throughout the Power BI user experience.
 
 ### Policies
@@ -179,7 +179,7 @@ The Invite external users to your organization feature SHOULD be disabled unless
 - [About Power BI Tenant settings \| Microsoft
   Docs](https://learn.microsoft.com/en-us/power-bi/admin/service-admin-portal-about-tenant-settings)
 
-- [Distribute Power BI content to external guest users with AAD B2B \|
+- [Distribute Power BI content to external guest users with Microsoft Entra B2B \|
   Microsoft
   Learn](https://learn.microsoft.com/en-us/power-bi/enterprise/service-admin-azure-ad-b2b)
 
@@ -217,7 +217,7 @@ To enable with security groups:
 
 ## 4. Power BI Service Principals
 
-Service principals are an authentication method that can be used to let an Azure AD application access Power BI service content and APIs. Power BI supports using service principals to manage application identities. Service principals use APIs to access tenant-level features, controlled by Power BI service administrators and enabled for the entire agency or for agency security groups. Accessing service principals can be controlled by creating dedicated security groups for them and using these groups in any Power BI tenant level-settings. If service principals are employed for Power BI, it is recommended that service principal credentials used for encrypting or accessing Power BI be stored in a key vault, with properly assigned access policies and regularly reviewed access permissions.
+Service principals are an authentication method that can be used to let an Microsoft Entra ID application access Power BI service content and APIs. Power BI supports using service principals to manage application identities. Service principals use APIs to access tenant-level features, controlled by Power BI service administrators and enabled for the entire agency or for agency security groups. Accessing service principals can be controlled by creating dedicated security groups for them and using these groups in any Power BI tenant level-settings. If service principals are employed for Power BI, it is recommended that service principal credentials used for encrypting or accessing Power BI be stored in a key vault, with properly assigned access policies and regularly reviewed access permissions.
 
 Several high-level use cases for service principals:
 
@@ -310,7 +310,7 @@ block using ResourceKey-based authentication." This baseline statement
 recommends, but does not mandate, setting ResourceKey-based
 authentication to the blocked state.
 
-For streaming datasets created using the Power BI service user interface, the dataset owner receives a URL including a resource key. This key authorizes the requestor to push data into the dataset without using an Azure AD OAuth bearer token, so please keep in mind the implications of having a secret key in the URL when working with this type of dataset and method.
+For streaming datasets created using the Power BI service user interface, the dataset owner receives a URL including a resource key. This key authorizes the requestor to push data into the dataset without using an Microsoft Entra ID OAuth bearer token, so please keep in mind the implications of having a secret key in the URL when working with this type of dataset and method.
 
 This setting applies to streaming and PUSH datasets. If ResourceKey-based authentication is blocked, users with a resource key will not be allowed to send data to stream and PUSH datasets using the API. However, if developers have an approved need to leverage this feature, an exception to the policy can be investigated.
 
@@ -320,7 +320,7 @@ This setting applies to streaming and PUSH datasets. If ResourceKey-based authen
 ResourceKey-based authentication SHOULD be blocked unless a specific use case (e.g., streaming and/or PUSH datasets) merits its use.
 
 <!--Policy: MS.POWERBI.5.1v1; Criticality: SHOULD -->
-- _Rationale:_ If resource keys are allowed, someone can move data without Azure AD OAuth bearer token, causing possibly malicious or junk data to be stored. Disabling resource keys reduces risk that an unauthorized individual will make changes.
+- _Rationale:_ If resource keys are allowed, someone can move data without Microsoft Entra ID OAuth bearer token, causing possibly malicious or junk data to be stored. Disabling resource keys reduces risk that an unauthorized individual will make changes.
 - _Last modified:_ June 2023
 - _MITRE ATT&CK TTP Mapping:_
   - [T1134: Access Token Manipulation](https://attack.mitre.org/techniques/T1134/)
@@ -443,12 +443,12 @@ Sensitivity labels SHOULD be enabled for Power BI and employed for sensitive dat
 
 ### License Requirements
 
-- Azure Information Protection Premium P1 or Premium P2 license is required to apply or view
-  Microsoft Information Protection sensitivity labels in Power BI. Azure Information Protection can be purchased either standalone or through one of the Microsoft licensing suites. See [Azure Information Protection
+- Microsoft Purview Information Protection Premium P1 or Premium P2 license is required to apply or view
+  Microsoft Information Protection sensitivity labels in Power BI. Azure Information Protection can be purchased either standalone or through one of the Microsoft licensing suites. See [Microsoft Purview Information Protection
   service description](https://azure.microsoft.com/services/information-protection/) for
   details.
 
-- Azure Information Protection sensitivity labels need to be migrated to
+- Microsoft Purview Information Protection sensitivity labels need to be migrated to
   the Microsoft Information Protection Unified Labeling platform to be
   used in Power BI.
 
@@ -481,7 +481,7 @@ Sensitivity labels SHOULD be enabled for Power BI and employed for sensitive dat
 Several best practices and approaches are available to protect sensitive
 data in Power BI:
 
-- Leverage sensitivity labels via Microsoft Information Protection.
+- Leverage sensitivity labels via Microsoft Purview Information Protection.
 
 - Power BI allows service users to bring their own key to protect data
   at rest.
@@ -526,15 +526,15 @@ the agency.
 
 **Information Protection Prerequisites Specific to Power BI**
 
-- An Azure Information Protection Premium P1 or Premium P2 license is
-  required to apply or view Microsoft Information Protection sensitivity
-  labels in Power BI. Azure Information Protection can be purchased
+- An Microsoft Purview Information Protection Premium P1 or Premium P2 license is
+  required to apply or view Microsoft Purview Information Protection sensitivity
+  labels in Power BI. Microsoft Purview Information Protection can be purchased
   either standalone or through one of the Microsoft licensing suites.
-  See [Azure Information Protection
+  See [Microsoft Purview Information Protection
   service](https://learn.microsoft.com/en-us/office365/servicedescriptions/azure-information-protection) description for
   details.
 
-- Azure Information Protection sensitivity labels need to be migrated to
+- Microsoft Purview Information Protection sensitivity labels need to be migrated to
   the Microsoft Information Protection Unified Labeling platform in
   order for them to be used in Power BI.
 

PowerShell/ScubaGear/baselines/powerplatform.md

@@ -72,7 +72,7 @@ Refer to [Power Platform Microsoft Learn documentation](https://learn.microsoft.
 
 ## 1. Creation of Power Platform Environments
 
-By default, any user in the Azure Active Directory (Azure AD) Tenant can create additional environments. Enabling these controls will restrict the creation of new environments to users with the following admin roles: Global admins, Dynamics 365 admins, and Power Platform admins.
+By default, any user in the Microsoft Entra ID Tenant can create additional environments. Enabling these controls will restrict the creation of new environments to users with the following admin roles: Global admins, Dynamics 365 admins, and Power Platform admins.
 
 ### Policies
 
@@ -151,10 +151,10 @@ connectors and configure them to fit agency needs and security
 requirements. The agency should then create a DLP policy to only allow
 those connectors to be used in Power Platform.
 
-When the Azure AD tenant is created, by default, a Power Platform
+When the Microsoft Entra ID tenant is created, by default, a Power Platform
 environment is created in Power Platform. This Power Platform
 environment will bear the name of the tenant. There is no way to
-restrict users in the Azure AD tenant from creating Power Apps in the
+restrict users in the Microsoft Entra ID tenant from creating Power Apps in the
 default Power Platform environment. Admins can restrict users from
 creating apps in all other created environments.
 
@@ -241,22 +241,22 @@ Non-default environments SHOULD have at least one DLP policy affecting them.
 
 ## 3. Power Platform Tenant Isolation
 
-Power Platform tenant isolation is different from Azure AD-wide tenant
-restriction. It does not impact Azure AD-based access outside of Power
+Power Platform tenant isolation is different from Microsoft Entra ID wide tenant
+restriction. It does not impact Microsoft Entra-based access outside of Power
 Platform. Power Platform tenant isolation only works for connectors
-using Azure AD-based authentication, such as Office 365 Outlook or
+using Microsoft Entra-based authentication, such as Office 365 Outlook or
 SharePoint. The default configuration in Power Platform has tenant
 isolation set to **Off**, allowing for cross-tenant connections to
 be established. A user from tenant A using a Power App with a connector
 can seamlessly establish a connection to tenant B if using appropriate
-Azure AD credentials.
+Microsoft Entra ID credentials.
 
 If admins want to allow only a select set of tenants to establish
 connections to or from their tenant, they can turn on tenant isolation.
 Once tenant isolation is turned on, inbound (connections to the tenant
 from external tenants) and outbound (connections from the tenant to
 external tenants) cross-tenant connections are blocked by Power Platform
-even if the user presents valid credentials to the Azure AD-secured data
+even if the user presents valid credentials to the Microsoft Entra-secured data
 source.
 
 ### Policies
@@ -265,7 +265,7 @@ source.
 Power Platform tenant isolation SHALL be enabled.
 
 <!--Policy: MS.POWERPLATFORM.3.1v1; Criticality: SHALL -->
-- _Rationale:_ Provides an additional tenant isolation control on top of Azure AD tenant isolation specifically for Power Platform applications to prevent accidental or malicious cross tenant information sharing.
+- _Rationale:_ Provides an additional tenant isolation control on top of Microsoft Entra ID tenant isolation specifically for Power Platform applications to prevent accidental or malicious cross tenant information sharing.
 - _Last modified:_ June 2023
 - _MITRE ATT&CK TTP Mapping:_
   - [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)

PowerShell/ScubaGear/baselines/teams.md

@@ -31,10 +31,10 @@ the types of users are defined as follows:
 
 3.  **Business to Business (B2B) guest users**: External users who are
     formally invited to collaborate with the team and added to the
-    agency's Azure Active Directory (Azure AD) as guest users. These users
+    agency's Microsoft Entra as guest users. These users
     authenticate with their home organization/tenant and are granted
     access to the team by virtue of being listed as guest users on the
-    tenant's Azure AD.
+    tenant's Microsoft Entra.
 
 4.  **Unmanaged users**: Users who are not members of any M365 tenant or
     organization (e.g., personal Microsoft accounts).