aws-ds-can-authorize-application

id: aws-ds-can-authorize-application
emits: CanModifyTrust
applies_to:
- aws
match_effective_permission:
  action: ds:AuthorizeApplication
  resource_type: AWS::DirectoryService::MicrosoftAD
emit:
  source_type: Identity
  target_type: TrustPolicy
  source: <principal>
  target: <TrustPolicy node (or federation-config node) for the directory>
  api_source: iam:SimulatePrincipalPolicy | policy evaluation
  permissions:
  - ds:AuthorizeApplication
  evidence_field: effective ds:AuthorizeApplication on directory ARN
  narrative: '{principal.name} can authorize a third-party application to authenticate against directory
    {directory.name} (ds:AuthorizeApplication), granting it LDAP/Kerberos access as a domain identity.'
  note: "ds:AuthorizeApplication grants a named application (identified by a service principal or OAuth\
    \ client) the right to act as a Kerberos/LDAP client against the directory. An attacker who authorizes\
    \ a malicious application becomes a trust anchor for that app; the app can then authenticate to any\
    \ domain-joined resource using the directory's credentials. This is a Phase-2 identity-entry primitive\
    \ (introduce a new external identity that the directory will trust). Classified as CanModifyTrust\
    \ because it expands the set of principals trusted to authenticate against the directory. IMPORTANT\
    \ LIMITATION: the authorized application receives LDAP/Kerberos client credentials only, not the ability\
    \ to assume or impersonate the directory's internal identities. Do NOT conflate this with CanAssume\
    \ or CanImpersonate \u2014 downstream consumers should note that path traversal stops at Kerberos-ticket\
    \ authentication, not Windows-domain escalation or IAM role assumption."