NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1 requires organizations to uniquely identify and authenticate users and devices — including service accounts — so that actions on Controlled Unclassified Information (CUI) are attributable; this post explains how to configure on-premises Active Directory (AD) and Azure AD (Microsoft Entra ID) to meet that requirement with practical implementation steps, PowerShell/CLI examples, small-business scenarios, and compliance best practices.
\n\nFor Compliance Framework implementation you must ensure every human actor and non-human actor (service account, managed identity, service principal) has a unique, auditable identity; that identities are labeled or grouped to indicate purpose and ownership; that authentication methods are controlled and logged; and that account lifecycle (creation, change, decommission) is tracked and periodically reviewed. Achieve this by enforcing naming conventions and OU/group/attribute usage in AD, by using managed accounts and minimum-privilege service principals in Azure AD, and by centralizing logs and periodic inventories.
\n\nStart by creating a clear OU and account-type taxonomy (for example: OU=Users, OU=ServiceAccounts, OU=ManagedServiceAccounts). Use a naming convention such as \"svc-
Implement technical controls: prefer Group Managed Service Accounts (gMSA) or Managed Service Accounts for services running on domain-joined hosts instead of traditional domain user accounts. Example commands (run from a domain controller with AD PowerShell module):
\nNew-ADServiceAccount -Name \"gMSA-Web01\" -DNSHostName \"web01.contoso.local\" -PrincipalsAllowedToRetrieveManagedPassword \"WebServersGroup\"\nInstall-ADServiceAccount -Identity gMSA-Web01 # on the target web server\n# Inventory accounts with suspicious settings\nGet-ADUser -Filter * -Properties PasswordNeverExpires,Description,ServicePrincipalName | \n Where-Object { $_.PasswordNeverExpires -eq $true -or $_.ServicePrincipalName } | Select Name,PasswordNeverExpires,ServicePrincipalName,DescriptionIn Azure use service principals and managed identities rather than long-lived service user credentials. For platform-hosted services prefer system- or user-assigned Managed Identities (which cannot be used interactively and have no password to rotate). For cross-tenant apps use service principals with certificate-based credentials stored in Key Vault and with least-privilege role assignments. Example CLI commands:
\n# Create a service principal (Azure CLI)\naz ad sp create-for-rbac --name \"svc-api-prod\" --skip-assignment\n\n# Create a user-assigned managed identity\naz identity create -g MyRG -n svc-managedidentity\n\n# List service principals with owner info\naz ad sp list --display-name \"svc-*\" --query \"[].{appId:appId,displayName:displayName,owners:owners}\"Ensure Azure AD Connect maps a stable source anchor (onPremisesImmutableId/sourceAnchor) and synchronize key attributes (employeeId, extensionAttribute1, onPremisesSamAccountName) so you can correlate on-prem AD accounts to Azure AD objects in logs and inventory.
\n\nIdentification is only useful if tied to an auditable log stream and a documented lifecycle. Enable and forward AD logs: turn on \"Audit account management\", \"Audit logon events\", and \"Audit directory service access\" via Group Policy and send events (Event IDs such as 4720, 4726, 4768/4769) to a central SIEM or Log Analytics workspace. In Azure, enable Sign-in and Audit logs, and configure diagnostic settings to forward to Log Analytics, Storage, or Sentinel for retention and review. Maintain an \"account inventory\" (CSV or CMDB) updated monthly that contains account name, type (user/service/gMSA/managed identity), owner, purpose, authentication method, creation date, last use, and expiration/rotation date.
\n\nA small defense subcontractor with 25 employees hosts an internal intranet (IIS) and one Azure-hosted API. They create OU=ServiceAccounts in AD and implement a gMSA \"gMSA-intranet\" for the IIS pool, assign principalsAllowedToRetrieveManagedPassword to the WebServersGroup, and document the owner and purpose in managedBy and extensionAttribute1. For the Azure API they provision a user-assigned managed identity and assign it a Key Vault access policy and a Reader role scoped to the resource group. They configure Azure AD Connect to sync employeeId and extensionAttribute1 so they can map on-prem persons to cloud principals, and they forward logs to a low-cost Log Analytics workspace for 90-day retention to meet contract requirements.
\n\nBest practices: enforce unique human accounts — never share user accounts; prefer gMSA/managed identities over passwords; require MFA for privileged and any interactive access; use Privileged Identity Management (PIM) or just-in-time elevation for admin roles; document any \"password never expires\" accounts and rotate credentials where possible; use Key Vault for secrets and prefer certificate-based credentials for service principals. Automate inventory via scripts and schedule quarterly reviews to disable orphaned accounts.
\n\nRisks of not implementing these controls include untraceable or shared credentials leading to improper attribution, lateral movement in a breach, exposed long-lived secrets, audit failures during assessments, loss of CUI, contract penalties, and reputational damage. For small businesses, an attacker using an untracked service account can maintain persistent access without detection — implementing the steps above materially reduces that risk.
\n\nSummary: To meet IA.L2-3.5.1 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, establish unique, auditable identities for users and service accounts in both AD and Azure AD; adopt gMSA and managed identities; enforce naming, ownership attributes, centralized logging, and periodic inventory/review; and apply least privilege and MFA for interactive access. These concrete steps — OU and naming conventions, PowerShell/CLI commands shown above, Azure AD Connect attribute mapping, and log forwarding — give you an actionable path to compliance while reducing security and operational risk.
", "plain_text": "NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1 requires organizations to uniquely identify and authenticate users and devices — including service accounts — so that actions on Controlled Unclassified Information (CUI) are attributable; this post explains how to configure on-premises Active Directory (AD) and Azure AD (Microsoft Entra ID) to meet that requirement with practical implementation steps, PowerShell/CLI examples, small-business scenarios, and compliance best practices.\n\nImplementation overview — what to achieve for IA.L2-3.5.1\nFor Compliance Framework implementation you must ensure every human actor and non-human actor (service account, managed identity, service principal) has a unique, auditable identity; that identities are labeled or grouped to indicate purpose and ownership; that authentication methods are controlled and logged; and that account lifecycle (creation, change, decommission) is tracked and periodically reviewed. Achieve this by enforcing naming conventions and OU/group/attribute usage in AD, by using managed accounts and minimum-privilege service principals in Azure AD, and by centralizing logs and periodic inventories.\n\nActive Directory (on-prem) — practical configuration steps\nStart by creating a clear OU and account-type taxonomy (for example: OU=Users, OU=ServiceAccounts, OU=ManagedServiceAccounts). Use a naming convention such as \"svc--\" for service accounts and \"u-\" for user accounts. Create AD attributes and conventions to store ownership and purpose: use managedBy (AD GUI) or extensionAttribute1 for owner/team, description for purpose and expiration date, and servicePrincipalName (SPN) where appropriate.\n\nImplement technical controls: prefer Group Managed Service Accounts (gMSA) or Managed Service Accounts for services running on domain-joined hosts instead of traditional domain user accounts. Example commands (run from a domain controller with AD PowerShell module):\nNew-ADServiceAccount -Name \"gMSA-Web01\" -DNSHostName \"web01.contoso.local\" -PrincipalsAllowedToRetrieveManagedPassword \"WebServersGroup\"\nInstall-ADServiceAccount -Identity gMSA-Web01 # on the target web server\n# Inventory accounts with suspicious settings\nGet-ADUser -Filter * -Properties PasswordNeverExpires,Description,ServicePrincipalName | \n Where-Object { $_.PasswordNeverExpires -eq $true -or $_.ServicePrincipalName } | Select Name,PasswordNeverExpires,ServicePrincipalName,Description\n\nAzure AD (Microsoft Entra) — practical configuration steps\nIn Azure use service principals and managed identities rather than long-lived service user credentials. For platform-hosted services prefer system- or user-assigned Managed Identities (which cannot be used interactively and have no password to rotate). For cross-tenant apps use service principals with certificate-based credentials stored in Key Vault and with least-privilege role assignments. Example CLI commands:\n# Create a service principal (Azure CLI)\naz ad sp create-for-rbac --name \"svc-api-prod\" --skip-assignment\n\n# Create a user-assigned managed identity\naz identity create -g MyRG -n svc-managedidentity\n\n# List service principals with owner info\naz ad sp list --display-name \"svc-*\" --query \"[].{appId:appId,displayName:displayName,owners:owners}\"\n\nEnsure Azure AD Connect maps a stable source anchor (onPremisesImmutableId/sourceAnchor) and synchronize key attributes (employeeId, extensionAttribute1, onPremisesSamAccountName) so you can correlate on-prem AD accounts to Azure AD objects in logs and inventory.\n\nLogging, inventory, and lifecycle controls\nIdentification is only useful if tied to an auditable log stream and a documented lifecycle. Enable and forward AD logs: turn on \"Audit account management\", \"Audit logon events\", and \"Audit directory service access\" via Group Policy and send events (Event IDs such as 4720, 4726, 4768/4769) to a central SIEM or Log Analytics workspace. In Azure, enable Sign-in and Audit logs, and configure diagnostic settings to forward to Log Analytics, Storage, or Sentinel for retention and review. Maintain an \"account inventory\" (CSV or CMDB) updated monthly that contains account name, type (user/service/gMSA/managed identity), owner, purpose, authentication method, creation date, last use, and expiration/rotation date.\n\nSmall business example and scenario\nA small defense subcontractor with 25 employees hosts an internal intranet (IIS) and one Azure-hosted API. They create OU=ServiceAccounts in AD and implement a gMSA \"gMSA-intranet\" for the IIS pool, assign principalsAllowedToRetrieveManagedPassword to the WebServersGroup, and document the owner and purpose in managedBy and extensionAttribute1. For the Azure API they provision a user-assigned managed identity and assign it a Key Vault access policy and a Reader role scoped to the resource group. They configure Azure AD Connect to sync employeeId and extensionAttribute1 so they can map on-prem persons to cloud principals, and they forward logs to a low-cost Log Analytics workspace for 90-day retention to meet contract requirements.\n\nCompliance tips, technical best practices, and risks\nBest practices: enforce unique human accounts — never share user accounts; prefer gMSA/managed identities over passwords; require MFA for privileged and any interactive access; use Privileged Identity Management (PIM) or just-in-time elevation for admin roles; document any \"password never expires\" accounts and rotate credentials where possible; use Key Vault for secrets and prefer certificate-based credentials for service principals. Automate inventory via scripts and schedule quarterly reviews to disable orphaned accounts.\n\nRisks of not implementing these controls include untraceable or shared credentials leading to improper attribution, lateral movement in a breach, exposed long-lived secrets, audit failures during assessments, loss of CUI, contract penalties, and reputational damage. For small businesses, an attacker using an untracked service account can maintain persistent access without detection — implementing the steps above materially reduces that risk.\n\nSummary: To meet IA.L2-3.5.1 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, establish unique, auditable identities for users and service accounts in both AD and Azure AD; adopt gMSA and managed identities; enforce naming, ownership attributes, centralized logging, and periodic inventory/review; and apply least privilege and MFA for interactive access. These concrete steps — OU and naming conventions, PowerShell/CLI commands shown above, Azure AD Connect attribute mapping, and log forwarding — give you an actionable path to compliance while reducing security and operational risk." }, "metadata": { "description": "Practical, step-by-step guidance to configure Active Directory and Azure AD so users and service accounts are uniquely identified, tracked, and auditable for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 compliance.", "permalink": "/how-to-configure-active-directory-and-azure-ad-to-identify-users-and-service-accounts-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-ial2-351.json", "categories": [], "tags": [] } }