| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1339 - Authenticator Management | Protection Of Authenticators | ||
| Id | 367ae386-db7f-4167-b672-984ff86277c0 | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this Identification and Authentication control | ||
| Additional metadata |
Name/Id: ACF1339 / Microsoft Managed Control 1339 Category: Identification and Authentication Title: Authenticator Management | Protection Of Authenticators Ownership: Customer, Microsoft Description: The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access. Requirements: All passwords used to access the Microsoft corporate network or business information must be considered and handled as “information as per the InfoSec #2.0 Information Classification and Handling Standard.” Core Services Engineering and Operations (CSEO) is responsible for protecting Microsoft corporate network authenticators. Per corporate security policy, usernames and passwords are never stored or transmitted in the clear or any unencrypted format. Passwords must not be shared or revealed to anyone other than the authorized user. Additionally, passwords must be promptly changed if they are suspected of being known by unauthorized individuals. Per Azure policy, cryptographic protection is applied to passwords when transmitted and stored, and are never transmitted in any unencrypted format natively within the Azure environment. Cryptographic certificates are stored in an approved secret management store. Information stored in the approved secret management stores is encrypted, and access occurs over an encrypted channel. Authentication credentials, such as username/password pairs, are considered High Business Impact (HBI) data and are required to be protected based upon its classification. Encryption must be used when storing or transmitting passwords, username/password files, or authentication tokens, in accordance with Azure asset protection standard. Azure uses the following authentication protocols with commensurate encryption. Kerberos V5 Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. The Kerberos V5 protocol can use both symmetric and asymmetric encryption. Because most Kerberos encryption methods are based on keys that can be created only by the KDC and the client, or by the KDC and a network service, the Kerberos V5 protocol is said to use symmetric encryption. That is, the same key is used to encrypt and decrypt messages. Microsoft’s implementation of the Kerberos protocol can also make limited use of asymmetric encryption. A private/public key pair can be used to encrypt or decrypt initial authentication messages from a network client or a network service as in the case of public key certificates on smart cards. NTLMv2 NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a username, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials. Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept. Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server. The following steps present an outline of NTLM noninteractive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process. 1. (Interactive authentication only) A user accesses a client computer and provides a domain name, username, and password. The client computes a cryptographic hash of the password and discards the actual password. 2. The client sends the username to the server. 3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client. 4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response. 5. The server sends the following items to the domain controller - username; challenge sent to the client; response received from the client. 6. The domain controller uses the username to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge. 7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful. |
||
| Mode | Indexed | ||
| Type | Static | ||
| Preview | False | ||
| Deprecated | False | ||
| Effect | Fixed audit |
||
| RBAC role(s) | none | ||
| Rule aliases | none | ||
| Rule resource types | IF (2) Microsoft.Resources/subscriptions Microsoft.Resources/subscriptions/resourceGroups |
||
| Compliance | Not a Compliance control | ||
| Initiatives usage | none | ||
| History | none | ||
| JSON compare | n/a | ||
| JSON |
|