Server Man
Well-Known Member
- May 17, 2015
- Android 4.3 Jelly Bean
- Android browser 4.0
Howdy folks,
Today I’m excited to announce the Public Preview of Azure AD Conditional Access support for blocking legacy authentication. In the past you needed to use ADFS to do this, but using conditional access to do this is SO much simpler/better. Now you to can manage legacy authentication blocking as one part of your overall conditional access strategy, all from right in the Azure AD admin console. And for many of you, this will also give you the option to move away from ADFS to an cloud centered authentication model enabled by pass-through authentication.
First things first, let’s define legacy authentication. Legacy authentication is a term that refers to authentication protocols used by apps like:
Attackers strongly prefer these protocols in fact, nearly 100% of password spray attacks use legacy authentication protocols! This is because legacy authentication protocols don’t support interactive sign-in, which is required for additional security challenges like multi-factor authentication and device authentication.
Before we get into the details, I want to be super duper clear – I strongly recommend you block use of legacy authentication protocols in your tenant. There are VERY few things you can do which are as easy to deploy and can improve your security posture as much.
It should be one of the top items on your To-Do list for next week!
Get started!
Ready to try this new feature out? You’ll find it under the “Client apps” condition in Azure AD Conditional access.
To create a test policy:
To test the policy, we recommend installing an older version of the Office client, like Office 2010, and signing in with a user from the pilot group.
If you’d like to test with basic authentication clients that use SMTP, POP, IMAP, etc., first run this PowerShell commandlet for the test user and then sign-in with the test user after an hour. The PowerShell commandlet ensures that the policy will take effect for the user within an hour of when it’s run. Typically, it takes up to 24 hours for the policy to take affect for basic authentication clients.
Don’t forget to review the FAQ section to learn more about this new feature. And if you’re not familiar with conditional access yet, go ahead and read through our Azure AD conditional access documentation.
Tell us what you think
As always, we’d love to hear any feedback or suggestions you have. We’ve even created a short survey for you to participate in. Please let us know what you think!
Best regards,
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Division
Continue reading...
Today I’m excited to announce the Public Preview of Azure AD Conditional Access support for blocking legacy authentication. In the past you needed to use ADFS to do this, but using conditional access to do this is SO much simpler/better. Now you to can manage legacy authentication blocking as one part of your overall conditional access strategy, all from right in the Azure AD admin console. And for many of you, this will also give you the option to move away from ADFS to an cloud centered authentication model enabled by pass-through authentication.
First things first, let’s define legacy authentication. Legacy authentication is a term that refers to authentication protocols used by apps like:
- Older Office clients that do not use modern authentication (e.g., Office 2010 client)
- Clients that use mail protocols such as IMAP/SMTP/POP
Attackers strongly prefer these protocols in fact, nearly 100% of password spray attacks use legacy authentication protocols! This is because legacy authentication protocols don’t support interactive sign-in, which is required for additional security challenges like multi-factor authentication and device authentication.
Before we get into the details, I want to be super duper clear – I strongly recommend you block use of legacy authentication protocols in your tenant. There are VERY few things you can do which are as easy to deploy and can improve your security posture as much.
It should be one of the top items on your To-Do list for next week!
Get started!
Ready to try this new feature out? You’ll find it under the “Client apps” condition in Azure AD Conditional access.
To create a test policy:
- In the Azure AD portal, go to “Conditional access” and create a new policy.
- Select the users for your pilot group. As with all conditional access policies, we recommend starting with a small set of users to be sure you understand the support and end user experience impact.
- Select “All cloud apps”.
- Under the “Client apps” conditions, you should now see the “Other clients” checkbox. The “Other clients” checkbox includes older Office clients that do not support modern authentication, as well as clients that use mail protocols like POP, IMAP, SMTP, etc.
- Select the “Block access” control.
- Save the policy.
To test the policy, we recommend installing an older version of the Office client, like Office 2010, and signing in with a user from the pilot group.
If you’d like to test with basic authentication clients that use SMTP, POP, IMAP, etc., first run this PowerShell commandlet for the test user and then sign-in with the test user after an hour. The PowerShell commandlet ensures that the policy will take effect for the user within an hour of when it’s run. Typically, it takes up to 24 hours for the policy to take affect for basic authentication clients.
Don’t forget to review the FAQ section to learn more about this new feature. And if you’re not familiar with conditional access yet, go ahead and read through our Azure AD conditional access documentation.
Tell us what you think
As always, we’d love to hear any feedback or suggestions you have. We’ve even created a short survey for you to participate in. Please let us know what you think!
Best regards,
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Division
Continue reading...