Identity and Security

This domain explains how the environment is trusted, governed, and secured.

It covers both local security posture and the Azure-side governance or identity relationships that directly describe the Azure Local deployment.

What Ranger Collects

The identity-and-security domain should document:

• Active Directory or workgroup identity posture
• local identity with Azure Key Vault signals when that variant is present
• cluster identity and Arc-related identity context
• certificates, TLS posture, and secret-backup dependencies
• BitLocker, secured-core, WDAC, Defender, and audit-policy posture
• local-administrator and drift-control signals
• Azure RBAC or policy context that directly affects the Azure Local deployment

Manifest Sub-Domains

The v1 collector writes to these named sections of the identitySecurity manifest domain:

Sub-domain	Content
activeDirectory	Domain name, forest, domain-functional level, OU placement, CNO/VCO context, and AD health signals
certificates	Certificate inventory, expiry posture, TLS bindings, and secret-backup dependency signals
keyVault	Key Vault name, secret-backup extension state, required role assignments, and managed identity binding for local-identity deployments
bitLocker	Volume encryption state, recovery key backup posture, and compliance signal
defender	Defender AV status, real-time protection, signature currency, and exclusion posture
auditPolicy	Relevant audit categories enabled or disabled at the host level

In AD-backed deployments the activeDirectory section is populated from the domain collector. In local-identity deployments where no AD is present, activeDirectory records a not-applicable reason and the keyVault section carries the primary secret and trust signals.

Current Collector Depth

Current v1 collection also covers:

• BitLocker enablement and protector-type signals where they can be discovered safely.
• WDAC posture, enforcement hints, and broader secured-core indicators.
• Defender and endpoint-security detail used to describe host protection posture.
• Domain auto-detection and workgroup handling so collection behaves correctly outside classic AD joins.

Why It Matters

Security and trust posture are part of both operational understanding and handoff-quality documentation. This domain should explain not only what is enabled, but also what identity model the environment actually relies on.

Connectivity and Credentials

Requirement	Purpose
WinRM / PowerShell remoting	Host security, certificate, and local-policy discovery
Cluster credential	Required for host-side collection
Domain credential	Required when AD-specific discovery is in scope
Azure credential	Required for Azure RBAC, policy, Key Vault, and Arc-side relationships

Default Behavior

Run this domain when cluster credentials are available.

AD-specific subcollection should become skipped or not-applicable in local-identity deployments instead of being reported as missing or broken.

Variant Behavior

AD-Backed

Ranger should document domain membership, OU placement, CNO or VCO context where relevant, and other directory-backed trust signals.

Local Identity with Azure Key Vault

Ranger should document:

• ADAware posture
• workgroup status
• Key Vault secret-backup extension state
• required Key Vault role assignments
• local-identity tool compatibility boundaries

Disconnected Operations

Ranger should distinguish Azure public-cloud RBAC and policy from local disconnected control-plane policy and access surfaces.

Multi-Rack Preview

Security posture still matters, but the environment may rely more heavily on preview-specific Azure-managed infrastructure layers that should be documented clearly.

Example Manifest Data

A successful collect produces entries like this:

{
  "id": "identitySecurity",
  "status": "success",
  "domains": {
    "identitySecurity": {
      "activeDirectory": {
        "domain": "contoso.com",
        "domainFunctionalLevel": "Windows2016Domain",
        "ouPath": "OU=AzureLocal,DC=contoso,DC=com"
      },
      "bitLocker": {
        "volumes": [
          { "node": "tplabs-01-n01", "driveLetter": "C:", "encryptionMethod": "XtsAes256",
            "protectionStatus": "On", "keyBackedToAD": true }
        ]
      },
      "defender": {
        "nodes": [
          { "host": "tplabs-01-n01", "amRunning": true, "rtpEnabled": true,
            "signatureAge": 0, "exclusionCount": 4 }
        ]
      }
    }
  }
}

Common Findings

Finding	Severity	What it means
BitLocker not enabled on one or more nodes	Warning	Host volume is unencrypted; relevant for security posture and compliance
BitLocker recovery key not backed up to AD	Warning	Recovery key may be lost if the node fails before a manual backup
Defender real-time protection disabled	Warning	Host is not actively protected; investigate before documenting as intentional
Defender signatures out of date	Warning	AV signatures are stale; update path may be blocked or delayed
Certificate expiring within 30 days	Warning	One or more certificates are near expiry; plan renewal to avoid service disruption

Partial Status

status: partial on the identity-security collector means:

• AD queries failed (domain unreachable or permissions missing) while host security facts (BitLocker, Defender) succeeded
• Azure RBAC or policy queries failed while local identity data succeeded
• Key Vault extension checks failed in a local-identity deployment

Local security posture (BitLocker, Defender, WDAC) is collected independently of AD queries. AD absence does not prevent host security data from being collected.

Domain Dependencies

No hard dependency on other collectors. Azure RBAC and policy sections benefit from the azure-integration domain context but collect independently.

Evidence Boundaries

• Direct discovery: host security and identity posture from the nodes
• Azure-side discovery: RBAC, policy, Key Vault, and Arc-related governance context
• Manual/imported evidence: operator-supplied trust-boundary notes or governance overlays when needed

v1 and Future Boundaries

v1 should focus on host and deployment-level identity and security posture.

It should not imply a full enterprise IAM review or deep in-guest workload security assessment for every hosted workload type.