[ad_1]
Protecting sensitive data by putting the right security controls in place is of the utmost importance for every organization. This requires constantly evolving to satisfy standards and regulations that help protect data and combat threats. One of these standards is Transport Layer Security (TLS), which is an internet protocol to encrypt communications between your web browser and web server, as well as mobile applications communicating with any servers. We are recommending customers secure their infrastructure by using TLS 1.2 with Azure Active Directory. The older TLS versions (1.0 and 1.1) are being deprecated and removed to improve the security posture of your tenant and to be compliant with industry standards.
TLS is a widely adopted security protocol that facilitates privacy and data security for communications over the Internet. TLS is used when connecting to Azure AD, Office 365, and other cloud services owned by Microsoft or other cloud service providers. The first of three TLS components is encryption, which hides the data being transferred from third parties. The second component is authentication, which ensures that the parties exchanging information are who they claim to be. The third is Integrity that verifies that the data has not been forged or tampered with.
Since TLS 1.0, 1.1 protocols, and 3DES cipher are out of date, they do not support modern cryptographic algorithms. This results in security vulnerabilities that could be exploited by attackers. FedRamp and NIST SP 800-52r2 compliance requires legacy TLS (1.0, 1.1) protocols and cipher (3DES) to be deprecated.
Most Microsoft services, such as Microsoft 365, provide guidance on how to deprecate TLS 1.0 and 1.1. While many customers using Azure AD have already moved to TLS 1.2, we are sharing further guidance to accelerate this transition. Starting Jan. 31 2022, Azure AD will no longer support these deprecated TLS versions 1.0 and 1.1. Customers who have not moved to TLS 1.2 will be impacted since requests to Azure AD will fail.
Using Azure AD sign in logs to detect legacy TLS & plan transition
For complete guidance on supporting TLS 1.2 with Azure AD, refer to our documentation. Customers can use Azure AD sign-in logs to help identify clients or apps still using legacy TLS in their environment. For sign-ins performed over Legacy TLS, Azure AD will mark the Legacy TLS field in additional details with True. The Legacy TLS field appears only if the sign-in occurred over Legacy TLS, so if customers don’t see any Legacy TLS in their logs, they are ready for the switch to TLS 1.2.
There are multiple ways in which an administrator can use Legacy TLS protocols to review logs and find sign-in attempts.
- PowerShell: Customers can use PowerShell to filter and export sign-in log entries where Legacy TLS is being used. An Azure AD Premium license is needed to call MS Graph APIs through PowerShell. Learn more at Azure AD PowerShell cmdlets for reporting | Microsoft Docs
- UX: Customers can browse through more details of the legacy TLS-based sign-in log entry in the Azure Portal. For more details, refer to Sign-in logs in Azure Active Directory – preview | Microsoft Docs
- JSON: Customers can download the last seven days of sign-in logs in JSON format to see the Legacy TLS flag. This flag will show only if Legacy TLS is being used for the sign-in request. Downloading the sign-in logs in CSV format rather than JSON does not expose the Legacy TLS flag. For more information, refer to How to download logs in Azure Active Directory | Microsoft Docs
- Azure Monitor: Finally, customers can analyze logs in Azure Monitor and set up log export. For details, refer to Analyze activity logs using Azure Monitor logs | Microsoft Docs
As cryptographic protocols evolve, customers should review industry standards and best practices while monitoring for new vulnerabilities to existing protocols. We hope with these toolsets, customers can easily move to TLS 1.2 and improve their security posture.
Learn more about Microsoft identity:
Source link
