6.0 KiB
6.0 KiB
Password & Authenticator Policy (M365 + AD)
Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]
1) Purpose & Scope
This policy establishes mandatory requirements for password creation, management, and authentication across [Organization]’s Microsoft 365, Active Directory (AD), and integrated systems. It applies to all employees, contractors, vendors, and service accounts.
2) Policy Statements
2.1 Password Length
- Passwords must be at least 15 characters when used as a single factor of authentication.
- Passwords must be at least 8 characters when used in combination with MFA.
- Systems must allow passwords up to 64 characters and should support spaces, ASCII, and Unicode characters.
2.2 Complexity
- Passwords must not be subject to complexity rules requiring upper/lowercase, numbers, or symbols.
- Passwords shall be screened against a blocklist of weak, common, and compromised passwords using Azure AD Password Protection.
- Passwords must not match the user's current password or any of the last 5 passwords (where technically supported).
2.3 Expiration
- Passwords shall not expire on a scheduled basis.
- Passwords must be changed immediately upon indication or suspicion of compromise.
2.4 Usability
- Systems must permit copy/paste from password managers.
- Systems must provide a “show password” option.
- Password hints and security questions must not be used.
2.5 Multi-Factor Authentication (MFA)
- MFA must be enforced for:
- Microsoft 365 services
- VPN/remote access
- Privileged AD accounts
- Administrative access to SaaS and production systems
- MFA should use phishing-resistant methods (e.g., FIDO2, Microsoft Authenticator).
- SMS/voice shall only be used as fallback methods.
2.6 Account Lockout
- Failed logins must be throttled using Azure AD Smart Lockout.
- Accounts shall not be permanently locked out due to failed attempts; instead, time-based delays must be applied.
2.7 Storage & Transmission
- Passwords must only be transmitted over encrypted channels (TLS 1.2+).
- AD and M365 authentication must rely on Kerberos (AES) rather than NTLM where possible; the legacy NT hash used by NTLM is unsalted and vulnerable to pass-the-hash attacks, so NTLM use should be minimized even with NTLMv1/LM disabled.
- NTLMv1 and LAN Manager (LM) hashes must be disabled.
- Custom applications must use Argon2id, bcrypt, or PBKDF2 for password storage.
2.8 Resets & Recovery
- Password resets must require MFA verification (via Azure AD SSPR).
- Knowledge-based authentication (KBA/security questions) must not be used.
- After compromise, passwords must be reset and tokens revoked.
2.9 Administrative Accounts
- Administrative accounts must be separate from daily-use accounts.
- All administrative accounts must be protected with MFA.
- Administrative access must be provisioned through Privileged Identity Management (PIM) with just-in-time elevation.
- Shared administrative passwords must not be used. Break-glass accounts must be vaulted, monitored, and protected with MFA.
2.10 Service & Machine Accounts
- Service accounts must use Managed Service Accounts (MSA/gMSA) or Managed Identities where available.
- Service account passwords must be at least 30 characters, randomly generated, and stored securely (e. g. in Azure Key Vault).
- Service accounts must not allow interactive login.
- Secrets must be rotated regularly through automated processes.
2.11 Dormant Accounts
- User accounts inactive for 45 days must be disabled.
- Quarterly reviews of all accounts must be conducted by IT.
2.12 Application Integration
Applications authenticating against AD or Entra ID:
- Must support password length requirements and blocklist enforcement.
- Must allow paste/autofill and must not truncate passwords.
- Must store verifiers using modern password hashing methods if not federated.
2.13 Kill-Chain Credential Protection (Barbell Principle)
- Credentials gating existential systems — Enterprise Admin/Domain Admin break-glass credentials, AD FS/Entra Connect service account secrets, PKI/CA root passphrases (if operating internal PKI), Bitlocker/backup recovery key escrow master access — must receive protection disproportionate to ordinary accounts: split-knowledge / dual control, HSM or sealed-vault storage, and real-time alerting on access.
- Do not spread equivalent extra effort across low-value accounts — concentrate paranoia on this small kill-chain set; keep the AAL2 baseline (§2.1–§2.12) lean everywhere else.
- Full requirements and rotation cadence: see Secrets & Key Management Policy §2.5 — canonical source for this control.
3) Enforcement
- Violations of this policy may result in disciplinary action, up to and including termination of access or employment.
- System owners must remediate applications not compliant with this policy or document exceptions approved by the CISO.
4) Exceptions
- Exceptions must be documented, include compensating controls, and have CISO approval.
- Exceptions must have a review date not exceeding 12 months.