Protect your business with identity and access management in the cloud
Get single sign-on to thousands of cloud apps and access to web apps that you run on-premises with Azure Active Directory Premium. Built for ease of use, Azure Active Directory management tools enable collaboration and deliver holistic identity protection and adaptive access control.
Benefits of Active Directory
Single sign-on to any cloud and on-premises web app
Azure Active Directory provides secure single sign-on to cloud and on-premises applications including Microsoft Office 365 and thousands of SaaS applications such as Salesforce, Workday, DocuSign, ServiceNow, and Box.
See more supported SaaS apps
Easily extend Active Directory to the cloud
Connect Active Directory and other on-premises directories to Azure Active Directory in just a few clicks and maintain a consistent set of users, groups, passwords, and devices across both environments.
Connect on-premises directories with Azure
Works with iOS, Mac OS X, Android and Windows devices
Users can launch applications from a personalized web-based access panel, mobile app, Office 365, or custom company portals using their existing work credentials—and have the same experience whether they’re working on iOS, Mac OS X, Android and Windows devices.
Protect sensitive data and applications
Enhance application access security with unique identity protection capabilities that provide a consolidated view into suspicious sign-in activities and potential vulnerabilities. Take advantage of advanced security reports, notifications, remediation recommendations and risk-based policies to protect your business from current and future threats.
Protect on-premises web applications with secure remote access
Access your on-premises web applications from everywhere and protect with multi-factor authentication, conditional access policies, and group-based access management. Users can access SaaS and on-premises web apps from the same portal.
Reduce costs and enhance security with self-service capabilities
Delegate important tasks such as resetting passwords and the creation and management of groups to your employees. Providing self-service application access and password management through verification steps can reduce helpdesk calls and enhance security.
Enterprise scale and SLA
Azure Active Directory Premium offers enterprise-grade scale and reliability. As the directory for Office 365, it already hosts hundreds of millions of users and handles billions of authentications every day. The high availability service is hosted in globally distributed datacenters in 17 regions, with worldwide technical support that provides a 99.9% SLA.
Azure Active Directory applications: New apps
Clockworks
FileCloud
Cezanne HR
Flat for Education
Insider Track
BGS Online
Nexonia
Proofpoint on Demand
Lifesize Cloud
Reward Gateway
Pacific Timesheet
Cisco Spark
Recognize
Yonyx Interactive Guides
Identity Panel
Hall Monitor
MediaValet
Origami Risk
Complion
Predictix
Mojo Helpdesk
SharpCloud Standard
Boost mobile productivity with secured access to applications
Using Azure Active Directory Premium, Bristow Group provided its helicopter pilots and support crews—a highly mobile workforce—easier access to critical enterprise applications, both on-premises and in the cloud.
Read the case study
Save time with simplified identity management
Royal Dutch Shell chose Azure Active Directory to simplify identity management for vendors and employees. Now the company provides fast, secured access to external vendors, cutting onboarding time from months to less than a week.
Read the case study
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
>
<channel>
<title>Azure Active Directory – Enterprise Mobility and Security Blog</title>
<atom:link href="https://blogs.technet.microsoft.com/enterprisemobility/feed/?product=azure-active-directory" rel="self" type="application/rss+xml" />
<link>https://blogs.technet.microsoft.com/enterprisemobility</link>
<description>The most recent news and updates about Microsoft’s Enterprise Mobility offerings and events for enterprise technology professionals and developers.</description>
<lastBuildDate>Wed, 20 Sep 2017 04:37:35 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<item>
<title>Fewer login prompts: The new “Keep me signed in” experience for Azure AD is in preview</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/19/fewer-login-prompts-the-new-keep-me-signed-in-experience-for-azure-ad-is-in-preview/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/19/fewer-login-prompts-the-new-keep-me-signed-in-experience-for-azure-ad-is-in-preview/#respond</comments>
<pubDate>Tue, 19 Sep 2017 16:00:16 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=55335</guid>
<description><![CDATA[Howdy folks, A common request we get from our customers is to reduce the number of times users are prompted to sign into Azure AD. One way to reduce the frequency of prompts is to check the “Keep me signed in” checkbox on the sign-in flow, but our telemetry shows that usage of that checkbox <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/19/fewer-login-prompts-the-new-keep-me-signed-in-experience-for-azure-ad-is-in-preview/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>A common request we get from our customers is to reduce the number of times users are prompted to sign into Azure AD. One way to reduce the frequency of prompts is to check the “Keep me signed in” checkbox on the sign-in flow, but our telemetry shows that usage of that checkbox is very low. But we know from talking to customers, that cutting down on the number of signin prompts is REALLY important. Nobody wants to have to signin to an app multiple times!</p> <p>So today I’m happy to share that we’re improving how “Keep me signed in” option is shown to users. We’re also adding intelligence to ensure users are prompted to remain signed in only when it’s safe to do so.</p> <p>First, as a quick refresher, here’s what the existing “Keep me signed in” experience is like. As you might guess, most users cruise right past the check box and never think twice.</p> <p><img width="1024" height="524" class="size-large wp-image-55397 aligncenter" alt="" src="https://msdnshared.blob.core.windows.net/media/2017/09/Old-KMSI-1024x524.jpg" /></p> <h3>What’s changing</h3> <p>We’re replacing the “Keep me signed in” checkbox with a prompt that displays after the user successfully signs in. This prompt asks the user if they’d like to remain signed in. If a user responds “Yes” to this prompt, the service gives them a persistent refresh token. This is the same behavior that currently occurs when a user checks the “Keep me signed in” checkbox. For federated tenants, this prompt will show after the user successfully authenticates with the federated identity service.</p> <p style="text-align: center"><img width="1024" height="501" class="alignnone size-large wp-image-55395" alt="" src="https://msdnshared.blob.core.windows.net/media/2017/09/New-KMSI-1024x501.jpg" /></p> <p>And for those of you who are security minded, you be happy to know that we’ve built a lot of smarts into this flow and the “Stay signed in?” option won’t display if our machine learning system detects a high risk signin or a signin from a shared device.</p> <h3>Some things to know</h3> <ul style="margin-left: 54pt"> <li>During the public preview period of the <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/02/the-new-azure-ad-signin-experience-is-now-in-public-preview/">new sign-in experience</a>, the updated “Keep me signed in” prompt will only show when users opt into the new sign-in experience. Users using the old experience will continue to see the checkbox and will not get the prompt.</li> <li>Admins can choose to hide this new prompt for users by using the “Show option to remain signed in” setting in <a href="https://docs.microsoft.com/en-us/azure/active-directory/customize-branding">company branding</a>. <p style="margin-left: 18pt"><em>(Note: Existing configurations of this setting will carry forward, so if you previously chose to hide the “Keep me signed in” checkbox in your tenant, we won’t show the new prompt to users in your tenant.)<br /> </em></p> </li> <li>This change won’t affect any token lifetime settings you have configured.</li> </ul> <h3>An additional note about security</h3> <p>Because “Keep me signed in” drops a persistent refresh token, some members of the IT community have asked if this might alter the security posture of their organization. We’ve done a significant amount of analysis on this topic and have concluded that increasing refresh token lifetime improves the user experience without reducing security posture. For more on that topic, please see our recent blog post on <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/">changes to default refresh token lifetimes</a>.</p> <h3>Let us know what you think!</h3> <p>Look for this new “Keep me signed in” prompt to start rolling out on the new sign-in experience in early October.</p> <p>Let us know if you have any questions, and head on over to the <a href="https://aka.ms/AzureActiveDirectoryCommunity">Azure Active Directory community</a> to share your feedback and suggestions with us we look forward to hearing from you!</p> <p>Best regards,</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/19/fewer-login-prompts-the-new-keep-me-signed-in-experience-for-azure-ad-is-in-preview/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Marching into the future of the Azure AD admin experience: retiring the Azure classic portal</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/#comments</comments>
<pubDate>Mon, 18 Sep 2017 16:00:57 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=55255</guid>
<description><![CDATA[Howdy folks, Since we announced General Availability of the new Azure AD admin center in May, it’s been used by over 800,000 users from 500,000 organizations in almost every country in the world. The new admin center is the future for administration of Azure AD. For over a year, we’ve been listening to your feedback <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>Since we <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/05/15/the-new-azure-ad-admin-console-is-ga/">announced General Availability</a> of the new <a href="https://aad.portal.azure.com/">Azure AD admin center</a> in May, it’s been used by over 800,000 users from 500,000 organizations in almost every country in the world. The new admin center is the future for administration of Azure AD.</p> <p>For over a year, we’ve been listening to your feedback and working to improve the new portal and the new experience. And we’ve heard you loud and clear that we have too many portals, that you want a single place where you can manage identity and access for your organization. So, on November 30, we’ll be retiring the Azure AD admin experience in the <a href="https://manage.windowsazure.com)">classic Azure portal</a>.</p> <p>Moving all admin capabilities to the new admin center and retiring our classic portal experience is a key milestone in our efforts to simplify the admin experience for Azure AD.</p> <h2>Azure AD admin center: the present and future for Azure AD administration</h2> <p>Now, the Azure AD admin center is where you can go to find admin experiences for the latest and greatest Azure AD capabilities. By focusing on the Azure AD admin center, we can make our admin experiences more consistent, and easier to use. And we can deliver them faster.</p> <p>At the moment, there are a few tasks that can still only be done in the classic Azure portal. Don’t worry, these capabilities will be added to our new admin experience in the next few weeks, well before November 30.</p> <h2>Azure Information Protection and Access Control Service</h2> <p>The Azure Information Protection (or AIP, formerly Rights Management Service) admin experiences will also be retired in the Azure classic portal on November 30, but can be found <a href="https://portal.azure.com/">here</a> in the new Azure portal.</p> <p>To learn more about Azure Information Protection, read our <a href="https://docs.microsoft.com/en-us/information-protection/">documentation</a>. To share feedback about Azure Information Protection, send <span style="color: #002060">an email to <a href="mailto:msipapp-feedback@microsoft.com">MSIPAppFeedback</a></span>.</p> <p>Additionally, after November 30, admin experiences for Access Control Services will be available at a different URL. We’ll communicate the details of that change soon.</p> <h2>Wrapping up</h2> <p>We hope you love using the Azure AD admin center! If you have questions about using or administering Azure AD, reach out to our engineering team and our community in our <a href="https://techcommunity.microsoft.com/t5/Azure-Active-Directory/bd-p/Azure-Active-Directory">forum</a>. And if you’ve got specific feedback on our admin portal experience, like bug reports or feature requests, post them in the ‘Admin portal’ section of our <a href="https://feedback.azure.com/forums/169401-azure-active-directory/category/162510-admin-portal">feedback forum</a>.</p> <p>Thanks for your continued feedback! It’s what guides us as we work to make the admin experience the best it can be for you. Keep sharing your thoughts we’re always listening.</p> <p>Best Regards,</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
</item>
<item>
<title>Managed Service Identities and Azure AD: Helping Azure developers keep their secrets secret!</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/14/managed-service-identities-and-azure-ad-helping-azure-developers-keep-their-secrets-secret/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/14/managed-service-identities-and-azure-ad-helping-azure-developers-keep-their-secrets-secret/#respond</comments>
<pubDate>Thu, 14 Sep 2017 18:05:37 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Apps]]></category>
<category><![CDATA[Authentication]]></category>
<category><![CDATA[Cloud]]></category>
<category><![CDATA[PKI]]></category>
<category><![CDATA[SaaS]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=55135</guid>
<description><![CDATA[Howdy folks, Just a quick note today! I am excited to announce a preview of a new integration between Azure and Azure Active Directory that is designed to make life easier for developers. It’s called Managed Service Identity, and it makes it simpler to build apps that call Azure services. Typically, to call a cloud <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/14/managed-service-identities-and-azure-ad-helping-azure-developers-keep-their-secrets-secret/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>Just a quick note today! I am excited to announce a preview of a new integration between Azure and Azure Active Directory that is designed to make life easier for developers. It’s called <a target="_blank" href="https://docs.microsoft.com/azure/active-directory/msi-overview" rel="noopener noreferrer">Managed Service Identity</a>, and it makes it simpler to build apps that call Azure services.</p> <p>Typically, to call a cloud service you need to send a credential (i.e. an API key or the like) to authenticate your app. Managing these credentials can be tricky. They are, by definition, secrets! You don’t want them to show up on dev/ops workstations or get checked into source control. But they must be available to your code when your code is running.</p> <p>So how do you get them there without anyone seeing them? Managed Service Identities!</p> <p>Managed Service Identities simplifies solves this problem by giving a computing resource like an Azure VM an automatically-managed, first class identity in Azure AD. You can use this identity to call Azure services without needing any credentials to appear in your code. If the service you are calling doesn’t support Azure AD authentication, you can still use Managed Service Identity to authenticate to Azure Key Vault and fetch the credentials you need at runtime. Presto, no credentials in code!</p> <p>You can read more about the <a target="_blank" href="https://azure.microsoft.com/blog/keep-credentials-out-of-code-introducing-azure-ad-managed-service-identity/" rel="noopener noreferrer">Managed Service Identity preview on the Azure blog</a>.</p> <p>Happy coding!</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/14/managed-service-identities-and-azure-ad-helping-azure-developers-keep-their-secrets-secret/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Azure AD B2B Collaboration in Microsoft Teams</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/11/azure-ad-b2b-collaboration-in-microsoft-teams/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/11/azure-ad-b2b-collaboration-in-microsoft-teams/#comments</comments>
<pubDate>Mon, 11 Sep 2017 13:00:52 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Announcements]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54985</guid>
<description><![CDATA[Howdy folks, Today I am excited to let you know that we’ve just enabled Guest Access in Microsoft Teams, built on the B2B collaboration features of Azure AD! You can now enable partner collaboration in Teams for interactions across chat, apps, and file sharing, all with the ease of use and enterprise-grade protection Azure Active <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/11/azure-ad-b2b-collaboration-in-microsoft-teams/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>Today I am excited to let you know that we’ve just enabled <a target="_blank" href="https://blogs.office.com/en-us/2017/09/11/expand-your-collaboration-with-guest-access-in-microsoft-teams/" rel="noopener noreferrer">Guest Access in Microsoft Teams</a>, built on the B2B collaboration features of Azure AD!</p> <p>You can now enable partner collaboration in Teams for interactions across chat, apps, and file sharing, all with the ease of use and enterprise-grade protection Azure Active Directory has long enabled for your employees.</p> <p><img width="900" height="650" class="size-full wp-image-55065 aligncenter" alt="" src="https://msdnshared.blob.core.windows.net/media/2017/09/Guest-Access-GIF_2.gif" /></p> <p>Now anyone with an Azure Active Directory account in any organization can be invited as a guest user in Microsoft Teams!</p> <p>Customers have already created more than 8 million guest users using the B2B features of Azure AD and we’re only getting started. Adding support for Microsoft Teams has been a top customer request, so we’re excited to turn on this new capability to keep the momentum going. I hope you’ll give it a try today!</p> <p>So, go ahead, <a target="_blank" href="http://teams.microsoft.com/start" rel="noopener noreferrer">log in to Teams</a> today and invite your partners to work with you.</p> <p>And as always, <a target="_blank" href="https://techcommunity.microsoft.com/t5/Azure-Active-Directory-B2B/bd-p/AzureAD_B2b" rel="noopener noreferrer">connect with us</a> for any feedback, discussions, and suggestions. You know were listening!</p> <p>Best Regards,</p> <p>Alex Simons (@Twitter:<a target="_blank" href="https://twitter.com/Alex_A_Simons" rel="noopener noreferrer">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> <p>P.S.: We are already working to add additional Azure AD capabilities in Teams, including support for external users with any corporate or consumer email account. Look for more news on that soon!</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/11/azure-ad-b2b-collaboration-in-microsoft-teams/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
</item>
<item>
<title>How we secure your data in Azure AD</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/05/how-we-secure-your-data-in-azure-ad/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/05/how-we-secure-your-data-in-azure-ad/#comments</comments>
<pubDate>Tue, 05 Sep 2017 16:00:31 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Datacenter]]></category>
<category><![CDATA[Security]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54956</guid>
<description><![CDATA[Howdy folks, With all the breaches of cloud identity services over the last few years, we get a lot of questions about how we secure customer data. So today’s blog is a dive into the details of how we protect customer data in Azure AD. Datacenter and Service Security Let’s start with our datacenters. First, <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/05/how-we-secure-your-data-in-azure-ad/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt"><span style="background-color: white">Howdy folks,</span><br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">With all the breaches of cloud identity services over the last few years, we get a lot of questions about how we secure customer data. So today’s blog is a dive into the details of how we protect customer data in Azure AD.<br /> </span></p> <h2><span style="background-color: white">Datacenter and Service Security<br /> </span></h2> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Let’s start with our datacenters. First, all of Microsoft’s datacenter personnel must pass a background check. All access to our datacenters is strictly regulated and every entry and exit are monitored. Within these datacenters, the critical Azure AD services that store customer data are located in special locked rackstheir physical access is highly restricted and camera-monitored 24 hours a day. Furthermore, if one of these servers is decommissioned, all disks are logically and physically destroyed to avoid data leakage.<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Next, we limit the number of people who can access the Azure AD services, and even those who do have access permissions operate without these privileges day-to-day when they sign in. When they do need privileges to access the service, they need to pass a multi-factor authentication challenge using a smartcard to confirm their identity and submit a request. Once the request is approved, the users privileges are provisioned “just-in-time”. These privileges are also automatically removed after a fixed period of time and anyone needing more time must go through the request and approval process again.<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Once these privileges are granted, all access is performed using a managed admin workstation (consistent with published <a href="https://gallery.technet.microsoft.com/Privileged-Access-3d072563">Privileged Access Workstation guidance</a>). This is required by policy, and compliance is closely monitored. These workstations use a fixed image and all software on the machine is fully managed. To minimize the surface area of risks, only selected activities are allowed, and users cannot accidentally circumvent the design of the admin workstation since they don’t have admin privileges on the box. To further protect the workstations, any access must be done with a smartcard and access to each one is limited to specific set of users.<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Finally we maintain a small number (fewer than five) of “break glass” accounts. These accounts are reserved for emergencies only and secured by multi-step “break glass” procedures. Any use of those accounts is monitored, and triggers alerts.<br /> </span></p> <h2><span style="background-color: white">Threat detection<br /> </span></h2> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">There are several automatic checks we do regularly, every few minutes to ensure things are operating as we expect, even as we are adding new functionality required by our customers:<br /> </span></p> <ul> <li><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white"><strong>Breach detection:</strong> We check for patterns that indicate breach. We keep adding to this set of detections regularly. We also use automated tests that trigger these patterns, so we are also checking if our breach detection logic is working correctly!<br /> </span></li> <li><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white"><strong>Penetration tests:</strong> These tests run all the time. These tests try to do all sorts of things to compromise our service, and we expect these tests to fail all the time. If they succeed, we know there is something wrong and can correct it immediately.<br /> </span></li> <li><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white"><strong>Audit:</strong> All administrative activity is logged. Any activity that is not anticipated (such as an admin creating accounts with privileges) causes alerts to be triggered that cause us to do deep inspection on that action to make sure it not abnormal.<br /> </span></li> </ul> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">And did we say we encrypt all your data in Azure AD? Yes, we do we use BitLocker to encrypt all Azure AD identity data at rest. What about on the wire? We do that as well! All Azure AD APIs are web-based using SSL through HTTPS to encrypt the data. Access to information is restricted through token-based authorization and each tenant’s data is only accessible to accounts permitted in that tenant. In addition, our internal APIs have the added requirement to use SSL client/server authentication on trusted certificates and issuance chains.<br /> </span></p> <h2><span style="background-color: white">A final note<br /> </span></h2> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Azure AD is delivered in two ways, and this post described security and encryption for the public service delivered and operated by Microsoft. For similar questions about our National Cloud instances operated by trusted partners, we welcome you to reach out to your account teams.<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">(Note: As a simple rule of thumb, if you manage or access your Microsoft Online services through URLs ending with .com, this post describes how we protect and encrypt your data.)<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">The security of your data is a top priority for us and we take it VERY seriously. I hope you found this overview of our data encryption and security protocol reassuring and useful.<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Best regards,<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Alex Simons (Twitter: @Alex_A_Simons)<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Director of Program Management<br /> </span></p> <p><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">Microsoft Identity Division</span></p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/05/how-we-secure-your-data-in-azure-ad/feed/</wfw:commentRss>
<slash:comments>10</slash:comments>
</item>
<item>
<title>Changes to the Token Lifetime Defaults in Azure AD</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/#comments</comments>
<pubDate>Thu, 31 Aug 2017 16:00:13 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Authentication]]></category>
<category><![CDATA[Conditional Access]]></category>
<category><![CDATA[Identity-driven Security]]></category>
<category><![CDATA[SSO]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54937</guid>
<description><![CDATA[Howdy folks, I’m happy to share that as part of our efforts to eliminate unnecessary signin prompts while maintaining high levels of security, we’re making some major improvements to how we manage refresh tokens lifetimes. This blog post goes into much greater technical detail than we usually discuss in this blog. But this is an <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>I’m happy to share that as part of our efforts to eliminate unnecessary signin prompts while maintaining high levels of security, we’re making some major improvements to how we manage refresh tokens lifetimes. This blog post goes into much greater technical detail than we usually discuss in this blog. But this is an important topic for many of you, so I think it’s warranted.</p> <p>Going forward the following defaults will now apply to all <span style="text-decoration: underline">new</span> Azure AD Tenants:</p> <ul> <li>Refresh Token Inactivity: 90 Days</li> <li>Single/Multi factor Refresh Token Max Age: until-revoked</li> <li>Refresh token Max Age for Confidential Clients: until-revoked</li> </ul> <p>It’s important to note that these new defaults will not apply to your tenant if you have customized these settings or if you are using federation. Additionally if you want to override these settings with your own custom setting, you can do that.</p> <h2>Why now?</h2> <p>We are keenly aware that unwanted authentication prompts degrade the user experience, result in user frustration, and often lead to so-called “shadow IT” where users end-run enterprise IT and use personally acquired SaaS apps to get their jobs done.</p> <p>As part of this effort to remove user friction, we analyzed the impact of our current default Refresh Token lifetime and found that nearly 20% of authentication prompts were caused by refresh token expiration. We also analyzed account compromise to see if there is correlation between refresh token lifetime and the likelihood of account compromise. We were pleased to find there was no statistically significant correlation between token lifetimes and compromised accounts.</p> <p>Using this and other data on usage patterns, we determined that extending refresh token lifetime will greatly improve the authentication experience while still maintaining high security standards.</p> <h2>What do these lifetimes control?</h2> <p>To understand the lifetimes and the changes we’ve made, it’s important to understand the <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-token-and-claims/">basics of tokens issued by Azure AD</a>.</p> <p>Although the refresh tokens now last longer, access tokens still expire on much shorter time frames. When the access token a client app is using to access a service or server expires, the client must request a new access token by sending the refresh token to Azure AD. As part of that request, Azure AD uses our conditional access system and identity protection system to assure the user and their device are in a secure and compliant state before issuing a new access token.</p> <p>Refresh tokens are also tied to the user credential originally provided by the user. This means that if a password was used to issue a refresh token, the refresh token and any additional refresh tokens derived from it are tied to that password. If the password is changed or expires, all derived refresh tokens become invalid and the user would be forced re-authenticate.</p> <p>Additionally, when a client gets an access token to access a protected resource, the client receives both a refresh token and a new access token. This allows Azure AD to constantly renewal of refresh tokens on a device that’s actively being used. On the other hand, if a user has not been active on her device for a certain period, her refresh token will become stale.</p> <h4>Refresh token inactivity</h4> <p>This policy controls how old a refresh token can be before it expires and can no longer be used to retrieve a new access/refresh token pair when attempting to access a resource. It forces users who haven’t been active on their client to re-authenticate to retrieve a new refresh token.</p> <p>This change won’t apply to your tenant if you configured Refresh Token Max Inactive Time to a custom value or if you configured federation with Azure AD and another authentication system</p> <h4>Single/multi-factor refresh token MaxAge</h4> <p>This policy controls how long a user can use a refresh token to get a new access/refresh token pair after they last successfully provided their credentials.</p> <p>After a user authenticates and receives a new refresh token, the refresh token can be used to obtain new access/refresh token pairs for the specified period called Refresh Token MaxAge. This is true if the current refresh token is not revoked or left unused for longer than the inactive time. (See above for Refresh Token Inactivity period). After Refresh Token MaxAge expires, the user must reauthenticate to receive a new refresh token, even if they’ve been actively refreshing the token.</p> <h4>Refresh token MaxAge for confidential clients</h4> <p>This policy controls how long a confidential client can use a refresh token to get a new access/refresh token pair after they last actively provided consent to access specific resources.</p> <p>After the client authenticates and receives a new refresh token, it can use the refresh token flow for the specified period. This is true if the current refresh token isn’t revoked, and isn’t left unused for longer than the inactive time. (See above for Refresh Token Inactivity period). After this period, the user must consent to the confidential client again for the client to continue receiving a new refresh token, even if they have been actively refreshing the token.</p> <p>Please note that MaxAge for confidential clients can’t be modified; it can, however, be revoked if needed, by using the steps in the <em>How can I revoke refresh tokens? </em>section<em><br /> </em>below.</p> <h2>Can I change/revert these settings?</h2> <p>You can use the <a href="https://docs.microsoft.com/azure/active-directory/active-directory-configurable-token-lifetimes">configurable token lifetimes</a> feature to control these lifetimes.</p> <p>To specifically revert the lifetimes in your tenant to their previous values, follow the guidelines below.</p> <h4>Set defaults in tenant to older values</h4> <p>If you are new to Azure AD, we recommend you learn <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-howto-tenant">how to get an Azure AD tenant</a> before you proceed.</p> <p>To get started:</p> <ol> <li>Download the latest <a href="https://www.powershellgallery.com/packages/AzureADPreview">Azure AD PowerShell Module Public Preview release</a>.</li> <li> <div>Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:</div> <p><em>Connect-AzureAD -Confirm<br /> </em></li> <li> <div>To create the policy, run the following command:</div> <p><em>New-AzureADPolicy -Definition @(‘{“TokenLifetimePolicy”:{“Version”:1,”MaxInactiveTime”:”14.00:00:00″,”MaxAgeSingleFactor”:”90.00:00:00″,”MaxAgeMultiFactor”:”90.00:00:00″,”MaxAgeSessionSingleFactor”:”until-revoked”,”MaxAgeSessionMultiFactor”:”until-revoked”}}’) -DisplayName “OrganizationDefaultPolicyScenario” -IsOrganizationDefault $true -Type “TokenLifetimePolicy”<br /> </em></li> </ol> <h2>How can I revoke refresh tokens?</h2> <p>Revoking a user’s active refresh tokens is simple and can be done on an ad-hoc basis. You do this by setting the <em>StsRefreshTokensValidFrom</em> on the user object, so any refresh tokens tied to a credential provided before the time this attribute was set will no longer be honored by Azure AD. The user will be forced to re-authenticate to receive a new refresh token.</p> <p>Follow these steps to revoke a user’s refresh tokens:</p> <ol> <li>Download the latest <a href="http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185">Azure AD PowerShell V1 release</a>.</li> <li> <div>Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:</div> <p><em>Connect-msolservice<br /> </em></li> <li> <div>Set the <em>StsRefreshTokensValidFrom </em>parameter using the following command:</div> <p><em>Set-MsolUser -UserPrincipalName <UPN of the User> -StsRefreshTokensValidFrom (“<current date>”)<br /> </em></li> </ol> <h2>Let us know what you think!</h2> <p>Once you’ve had a chance to experience these changes, let us know what you think! As always, we’d love to hear any feedback or suggestions you have.</p> <p>Best regards,</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> <p> </p> <p>[Updated 9/5/2017, 10:52 am Pacific to clarify that customers who have customized these settings or are using federation that these changes will not impact them]</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/feed/</wfw:commentRss>
<slash:comments>31</slash:comments>
</item>
<item>
<title>Today’s Identity News: Improvements to Azure AD Connect Health sync error reporting</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/30/todays-identity-news-improvements-to-azure-ad-connect-health-sync-error-reporting/</link>
<pubDate>Wed, 30 Aug 2017 16:00:22 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Hybrid]]></category>
<category><![CDATA[Hybrid Cloud]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54895</guid>
<description><![CDATA[Howdy folks, If you’re an Azure AD Connect Health user, this post is for you! We’ve made a few enhancements to sync error reports to help make information easier to digest and act on. I’ve invited Varun Karandikar, a Program Manager on the Azure AD Connect Health team, to tell you more about these updates. <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/30/todays-identity-news-improvements-to-azure-ad-connect-health-sync-error-reporting/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>If you’re an Azure AD Connect Health user, this post is for you! We’ve made a few enhancements to sync error reports to help make information easier to digest and act on.</p> <p>I’ve invited Varun Karandikar, a Program Manager on the Azure AD Connect Health team, to tell you more about these updates. His post is below. Please let us know what you think about the updated reports we’re always listening and look forward to hearing from you!</p> <p>Best regards,</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> <p>P.S.: Azure AD Connect Health is another on one of the “secret gem” features of Azure AD. If you aren’t using it today to monitor your ADFS and AAD Connect Sync Server, you are definitely missing out!</p> <p>—-</p> <p>Hello,</p> <p>Many of you may know about the <a href="https://docs.microsoft.com/en-us/active-directory/active-directory-aadconnect-health">Azure AD Connect Health</a> service, which allows you to monitor and gain insights into your hybrid identity infrastructure. (Check it out if you haven’t yet!) It also provides <a href="https://aka.ms/chsyncerrordoc02">reports about synchronization errors</a> that might occur while syncing data from on-premises AD to Azure AD using Azure AD Connect.</p> <h1>So, what’s new?</h1> <p>In this short post, we wanted to make three key announcements about sync error reports:</p> <ul> <li>Accessing the sync error report does NOT require Azure AD Premium.</li> </ul> <p style="text-align: center"><img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent1.jpg" /></p> <ul> <li>The sync error report now includes errors due to the <a href="https://aka.ms/dupattributeresdocs">Duplicate Attribute Resiliency feature</a>.</li> </ul> <p style="text-align: center"><img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent2.jpg" /></p> <ul> <li>We’ve added a dedicated category for the “FederatedDomainChange” errors.</li> </ul> <p style="text-align: center"><img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent3.jpg" /></p> <p>To view the report, upgrade to the latest version of AAD Connect (also works with version 1.1.281.0 or higher) and then simply navigate to the <a href="https://aka.ms/aadconnecthealth">Azure AD Connect Health Dashboard</a>.</p> <h1>That’s great! Tell me more…</h1> <p>Sync error reports are aimed at making it easy for admins to deal with errors that occur while syncing data from on-premises AD to Azure AD using Azure AD Connect. This capability is now available for <em>all</em> tenants and does not require Azure AD Premium.</p> <p>If you haven’t heard about the recent changes we made regarding how Azure AD handles duplicate attributes, please read more about the <a href="https://aka.ms/dupattributeresdocs">Duplicate Attribute Resiliency feature</a>. When errors are introduced, it is appropriate for an admin to get a report about all the errors in one place. Azure AD Connect Health sync error reports do exactly that they combine the errors reported on the Azure AD Connect server as well as errors introduced by the Duplicate Attribute Resiliency feature. This allows you to get all the relevant information you need about the object involved in the errors and instructions on how to fix the error.</p> <p>Last but not least, we’ve added a dedicated category for “FederatedDomainChange” error. If you change a user’s UserPrincipalName suffix from one federated domain to another (for example, <a href="mailto:user@linkedin.com">user@linkedin.com</a> is changed to <a href="mailto:user@microsoft.com">user@microsoft.com</a>), currently the user fails to sync due to a limitation in Azure AD and this is surfaced as a “FederatedDomainChange” Sync Error (error code = 105). With this dedicated category in the sync error report you can easily find all such users and take steps to fix these errors.</p> <p>We hope the sync error reports will help you easily navigate through errors and fix them quickly by providing all the relevant data in a few clicks.</p> <p>If you have any feedback or comments do reach out to us at <a href="mailto:askaadconnecthealth@microsoft.com">askaadconnecthealth@microsoft.com</a>.</p> <p>Thank you,</p> <p>The Azure AD Connect Health Team</p> ]]></content:encoded>
</item>
<item>
<title>New public preview: Azure AD Domain Services support for Azure Resource Manager virtual networks</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/29/new-public-preview-azure-ad-domain-services-support-for-azure-resource-manager-virtual-networks/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/29/new-public-preview-azure-ad-domain-services-support-for-azure-resource-manager-virtual-networks/#comments</comments>
<pubDate>Tue, 29 Aug 2017 16:00:50 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Cloud]]></category>
<category><![CDATA[Domain Controller]]></category>
<category><![CDATA[Hybrid]]></category>
<category><![CDATA[Hybrid Cloud]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54845</guid>
<description><![CDATA[Howdy folks, The #1 reason customers email (and tweet and in-message) me is to ask us to add support for Azure Resource Manager based virtual networks to Azure AD Domain Services. So I’m excited to announce the public preview of Azure AD Domain Services support for virtual networks created using the Azure Resource Manager deployment <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/29/new-public-preview-azure-ad-domain-services-support-for-azure-resource-manager-virtual-networks/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p style="text-align: justify">The #1 reason customers email (and tweet and in-message) me is to ask us to add support for Azure Resource Manager based virtual networks to Azure AD Domain Services.</p> <p style="text-align: justify">So I’m excited to announce the <strong>public preview of Azure AD Domain Services support for virtual networks created using the Azure Resource Manager deployment model</strong>. You can now create new managed AD domains in virtual networks that were provisioned using Azure Resource Manager. This public preview release makes deployment of Azure AD Domain Services much easier for you!</p> <p style="text-align: justify">If you follow the blog, you already know that Azure AD Domain Services is pretty cool. It provides managed AD domain services like domain join, group policy, LDAP, and Kerberos/NTLM authentication, and all those services are fully compatible with Windows Server Active Directory.</p> <p style="text-align: justify">Azure Resource Manager provides a consistent management layer for the tasks you perform through Azure PowerShell, Azure CLI, Azure portal, REST API, and development tools. <a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview">Learn more about Azure Resource Manager.</a> The resource manager deployment model is widely used across Azure and is now the preferred way to deploy new Azure workloads.</p> <p style="text-align: justify">This new public preview lets you create a managed AD domain in a resource manager virtual network from the Azure portal. To do this, you’ll use the brand-new wizard experience <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/07/11/new-public-preview-azure-ad-domain-services-admin-ux-in-the-new-azure-portal/">we previewed recently</a>.</p> <h2>Getting Started</h2> <p style="text-align: justify">Here’s how to get started with the preview:</p> <ol> <li> <div style="text-align: justify"><strong>If Azure AD Domain Services is not enabled for your Azure directory</strong> <a href="https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-getting-started">Create a new managed AD domain</a> using the Azure portal. Be sure to select ‘Resource Manager’ as the virtual network type.</div> <p style="text-align: justify"> </li> <li> <div style="text-align: justify"><strong>If you’ve already enabled Azure AD Domain Services for your Azure directory </strong> You have an existing managed AD domain enabled in a classic virtual network.</div> <ol> <li> <div style="text-align: justify">If the existing managed AD domain is a <strong>production instance</strong>, you won’t be able to use this preview. We are working on a migration feature that allows you to migrate your managed AD domain from the classic virtual network to a Resource Manager virtual network, without deleting the managed AD domain. We will make that available in public preview before the end of December 2017.</div> </li> <li> <div style="text-align: justify">If the existing managed AD domain is a <strong>test instance</strong>, you can disable Azure AD Domain services for the directory. You can then create a new instance and select a Resource Manager-based virtual network.</div> </li> </ol> </li> </ol> <p style="text-align: justify"><em>Note: If you are using Azure AD Domain Services in a classic virtual network for production purposes, do not disable Azure AD Domain Services. You will lose state within the managed AD domain, such as domain joined computers, any custom OUs you’ve created, and objects within them. We will be supporting the migration process of existing managed AD domains from classic virtual networks to resource manager virtual networks later this year.<br /> </em></p> <p style="text-align: center"><img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/082817_2047_Newpublicpr1.png" /></p> <h2>The Road to GA</h2> <p>We have quite a bit of work still to go before we can GA this feature. The two biggest remaining are:</p> <ol> <li> <div style="text-align: justify"><strong>We’re going all in on resource manager virtual networks:</strong> This public preview release defaults to using resource manager-type virtual networks when you create a new managed AD domain. During the public preview, you’ll be able to choose classic virtual networks while creating a new managed AD domain. But, when support for resource manager virtual networks becomes generally available, you won’t be able to create new managed AD domains in classic virtual networks anymore. Resource manager-based virtual networks will be the only supported deployment model for newly created managed AD domains.</div> <p style="text-align: justify"> </li> <li> <div style="text-align: justify"><strong>Migration process for existing managed AD domains:</strong> We do plan to support a migration process for existing managed AD domains, so you can easily switch from a classic virtual network to a resource manager-based virtual network. We’ll have more details on that process in the coming weeks.</div> </li> </ol> <h2>We want to hear from you!</h2> <p style="text-align: justify">As always, your feedback is very important to us! Please share your comments, questions, or concerns on our <a href="https://feedback.azure.com/forums/169401-azure-active-directory/category/160593-domain-services">discussion forum</a>, send us an email at <a href="mailto:aaddsfb@microsoft.com">aaddsfb@microsoft.com</a>, or comment below. We’re listening!</p> <p style="text-align: justify">Best regards,</p> <p style="text-align: justify">Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)</p> <p style="text-align: justify">Director of Program Management</p> <p style="text-align: justify">Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/29/new-public-preview-azure-ad-domain-services-support-for-azure-resource-manager-virtual-networks/feed/</wfw:commentRss>
<slash:comments>8</slash:comments>
</item>
<item>
<title>Azure AD and Intune now support macOS in conditional access!</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/#comments</comments>
<pubDate>Wed, 23 Aug 2017 16:00:07 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Authentication]]></category>
<category><![CDATA[Conditional Access]]></category>
<category><![CDATA[Mac OS]]></category>
<category><![CDATA[Office 365]]></category>
<category><![CDATA[SaaS]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54665</guid>
<description><![CDATA[Howdy folks, Conditional access is one of athe fastest growing services in EMS and we are constantly getting feedback from customers about new capabilities they would like us to add to it. One of the most frequently requested is support for macOS. Customers want to have one consistent system for securing user accessing to Office <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p style="text-align: justify">Howdy folks, </p> <p style="text-align: justify">Conditional access is one of athe fastest growing services in EMS and we are constantly getting feedback from customers about new capabilities they would like us to add to it. One of the most frequently requested is support for macOS. Customers want to have one consistent system for securing user accessing to Office 365 on all the platforms their employees are using. </p> <p style="text-align: justify">So I’m excited to share that Azure Active Directory and Intune now support macOS platform for device-based conditional access! Administrators can now restrict access to Intune-managed macOS devices using device-based conditional access according to their organization’s security guidelines. </p> <p style="text-align: justify">With the public preview of macOS device-based conditional access, you’ll be able to: </p> <ul> <li>Enroll and manage macOS devices using Intune </li> <li>Ensure macOS devices adhere to your organization’s compliance policies </li> <li>Restrict access to applications in Azure AD to only compliant macOS devices </li> </ul> <p>Get started with macOS conditional access public preview in two simple steps: </p> <h2>Configure compliance requirements for macOS devices in Intune<br /> </h2> <p>Use the Intune service in Azure Portal to create a device compliance policy for macOS devices in a few easy clicks: </p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI1.png" alt="" /> 	</p> <p>Configure compliance requirements for device health, properties, and system security per your organization’s requirements. </p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI2.png" alt="" /> 	</p> <p>For more details, go to <a href="https://aka.ms/macoscompliancepolicy">https://aka.ms/macoscompliancepolicy</a>. </p> <p><em>(Important Note: for Conditional Access on macOS to work, the device will need to have the Intune Company Portal app installed).<br /> </em></p> <h2>Restrict access to Azure AD applications for macOS devices<br /> </h2> <p>Create a targeted conditional access policy for macOS to protect the Azure AD Applications. Go to conditional access under Azure AD service in Azure portal to create a new policy for macOS platform. </p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI3.png" alt="" /> 	</p> <p>For more details on conditional access policies, go to <a href="https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access-azure-portal">Conditional Access in Azure Active Directory</a>. </p> <p>After you’ve taken these steps, macOS users covered in the policy will be able to access Azure AD connected applications only if their Mac conforms to your organization’s policies. </p> <h2>Supported OS versions, applications, and browsers<br /> </h2> <p>In the public preview, the following OS versions, applications, and browsers are supported on macOS: </p> <p><em>Operating Systems<br /> </em></p> <ul> <li>macOS 10.11+ </li> </ul> <p><em>Applications<br /> </em></p> <p>The following Office 2016 for macOS applications are supported: </p> <ul> <li>Outlook v15.34 and later </li> <li>Word v15.34 and later </li> <li>Excel v15.34 and later </li> <li>PowerPoint v15.34 and later </li> <li>OneNote v15.34 and later </li> </ul> <p><em>Browsers<br /> </em></p> <ul> <li>Safari </li> </ul> <p>Try it out today and let us know what you think! We look forward to hearing from you. </p> <p>Best regards, </p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>) </p> <p>Director of Program Management </p> <p>Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/feed/</wfw:commentRss>
<slash:comments>7</slash:comments>
</item>
<item>
<title>Cloud App Security new remediation feature</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/cloud-app-security-new-auto-remediation-feature/</link>
<pubDate>Wed, 09 Aug 2017 16:00:50 +0000</pubDate>
<dc:creator><![CDATA[Cloud App Security Team]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54115</guid>
<description><![CDATA[Require users to sign in again in case of suspicious behavior Real-time remediation for security threats is a key challenge for companies, where attackers can move quickly to access critical data. Cloud App Security team is excited to introduce a new feature for threat protection through integration with Azure Active Directory: when a suspicious user <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/cloud-app-security-new-auto-remediation-feature/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<h2>Require users to sign in again in case of suspicious behavior</h2> <p>Real-time remediation for security threats is a key challenge for companies, where attackers can move quickly to access critical data. <a href="https://www.microsoft.com/en-us/cloud-platform/cloud-app-security">Cloud App Security</a> team is excited to introduce a new feature for threat protection through integration with <a href="http://www.microsoft.com/identity">Azure Active Directory</a>: when a suspicious user activity is detected by Cloud App Security, you can now prevent access to corporate data accessed through apps that use Azure AD by requiring the user to sign in again.</p> <p>Lets explore two key reaction capabilities of this feature:</p> <h3 style="padding-left: 30px">Respond to anomalous behavior</h3> <p style="padding-left: 30px">External sharing of sensitive files, download of sensitive files from unrecognized locations, or any activity thats considered abnormal can trigger alerts in Cloud App Security portal. These alerts provide immediate notification of potential security incidents and assist admins with proactive investigation.</p> <p style="padding-left: 30px">In the event of suspicious user behavior, the new auto-remediation feature allows the security admin to take immediate action, and requiring the user to sign-in again to all apps.</p> <h3 style="padding-left: 30px">React to account takeover</h3> <p style="padding-left: 30px">When an attacker gains unauthorized access to an account, a common industry practice is to disable the account. But this is not enough! If the account is actively being used to exfiltrate data, gain elevated privileges in the organization, or any other method that keeps the attackers session active, they can still use the compromised account.</p> <p style="padding-left: 30px">The new Cloud App Security capability allows an admin to require the user to sign in again and mitigate the attack. Cloud App Security invalidates all the user’s refresh tokens issued to cloud apps.</p> <h3>How to implement this feature</h3> <p>Requiring the user to sign in again can be set during the policy creation phase, or initiated directly from an alert as part of the resolution options for a user. Initiating governance actions directly from the policy allow for automatic remediation. In this case, the admin needs only to select this option and it will be enforced.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/07/image541.png"><img width="445" height="268" title="image" class="aligncenter" style="float: none;padding-top: 0px;padding-left: 0px;margin-left: auto;padding-right: 0px;margin-right: auto;border: 0px" alt="image" src="https://msdnshared.blob.core.windows.net/media/2017/07/image_thumb443.png" border="0" /></a></p> <p style="text-align: center"><em>Policy setting: require user to sign-in again</em></p> <p align="left">Alternatively, an admin can select to require another sign in as part of the reactive investigation of an alert as seen below. In either case, to ensure secure productivity, the user is protected and can continue working with minimal interruption.</p> <p align="left"><a href="https://msdnshared.blob.core.windows.net/media/2017/07/image542.png"><img width="624" height="209" title="image" class="aligncenter" style="float: none;padding-top: 0px;padding-left: 0px;margin-left: auto;padding-right: 0px;margin-right: auto;border: 0px" alt="image" src="https://msdnshared.blob.core.windows.net/media/2017/07/image_thumb444.png" border="0" /></a></p> <p align="center"><em>Require user to sign in again during investigation of a specific alert</em></p> <h3>Better together</h3> <p>Our goal is to provide a holistic and innovative security approach with Enterprise Mobility + Security. Cloud App Security and Azure Active Directory together offer unique value that help you gain better control over your cloud, by identifying suspicious activities which may be indicative of a breach and then respond immediately.</p> <h2>Learn more and give us feedback</h2> <p>We know how important visibility, control and threat protection are for you, especially when it comes to cloud apps. Our goal is to continuously innovate to provide a top-notch user experience, visibility, data control and threat protection for your cloud apps. If you would like to learn more about our solution, please visit our technical <a href="https://docs.microsoft.com/en-us/cloud-app-security/governance-actions">documentation</a> page.</p> <p>Your feedback is key to our product development process. If you have questions, comments or feedback, please leave a comment below or visit our <a href="https://techcommunity.microsoft.com/t5/Microsoft-Cloud-App-Security/bd-p/MicrosoftCloudAppSecurity">Microsoft Cloud App Security Tech Community page</a>.</p> ]]></content:encoded>
</item>
</channel>
</rss>
