AZURE ACTIVE DIRECTORY TEAM BLOG
<?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>Sat, 07 Oct 2017 15:33:54 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<item>
<title>Improving access control with three new Azure AD public previews</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/10/05/improving-access-control-with-three-new-azure-ad-public-previews/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/10/05/improving-access-control-with-three-new-azure-ad-public-previews/#comments</comments>
<pubDate>Thu, 05 Oct 2017 18:26:42 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[Identity Governance]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=56275</guid>
<description><![CDATA[Howdy folks, It was great to get to meet so many of you at Ignite last week! Thanks a ton for stopping by the booth and making time to attend our sessions. If you were at Ignite or follow our blog, you know we announced a ton of new Azure AD capabilities last week. As <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/10/05/improving-access-control-with-three-new-azure-ad-public-previews/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p> <p>It was great to get to meet so many of you at Ignite last week! Thanks a ton for stopping by the booth and making time to attend our sessions. If you were at Ignite or follow our blog, you know we announced a ton of new Azure AD capabilities last week. As a follow-up, we’re going to do a few posts that cover the new capabilities we turned on in more detail. First up, let’s take a look at some of the new access control features we’ve just put into public preview.</p> <p>As customers increasingly adopt Azure AD, we’ve received a ton of request for features that help <span style="color: black">make sure the right people have access to the right resources, and that give enterprises control of and visibility into this access.</span> In response to that feedback, we’re pushing three new and exciting features in Azure AD to public preview:</p> <ol> <li>Extending Azure AD Privileged Identity Management to include Azure RBAC roles.</li> <li>Automated, periodic access reviews</li> <li>Automated Terms of Use administration and reporting</li> </ol> <p>Here’s a quick tour of each of these new public previews.</p> <p><strong>Privileged Identity Management – extended to managing in Azure<br /> </strong></p> <p>Azure AD Privileged Identity Management (PIM) is already generally available for managing <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-privileged-identity-management-configure">Azure AD roles</a>, which are used to administer Azure AD and other Microsoft online services. The top request we’ve seen in the <a href="https://feedback.azure.com/forums/169401-azure-active-directory/category/171225-privileged-identity-management">feedback forum</a> for Azure AD PIM is to bring just-in-time role activation, access reviews, and reports to Azure resources. We know these upgrades will help organizations address the challenges of large-scale IaaS administration, so we’ve added them and are now making them available in public preview.</p> <p>This new preview shows up in the Azure portal as part of the Azure AD PIM UI alongside the recent <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/05/24/azure-ad-privileged-identity-management-approval-workflows-are-now-in-public-preview/">approval workflows</a> preview.</p> <p>With this Azure AD PIM preview for Azure RBAC, you can now:</p> <ul> <li>Ensure the right users are assigned to Azure subscriptions, by starting an access review of any role in the subscription and asking a resource owner or the users themselves to confirm they still need access</li> <li>Control exposure of business-critical Azure assets by making users, either individually or via a group, eligible to activate a role to manage resources</li> <li>Limit how long a user can be activated in a role, and set an expiration date for a user’s or group’s role membership</li> <li>Get reports about users and groups with role assignments in Azure subscriptions, resource groups and resources, who activated their roles, and what users did in Azure while activated</li> <li>Let users take charge of their own role activity and requiring them to provide a justification or requiring that they authenticate with multi-factor authentication prior to when they need to activate a role</li> </ul> <p>For example, you can make a user, including a guest user, eligible for an Azure resource group’s role. Once you’ve done that, that user can activate the role when they need to make a change to the resource, and you can see a report of the changes the user made in Azure while they were activated.</p> <p>If you’re already using Azure AD PIM, you’ll see “Azure resources” in the Manage section.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac1.png" alt="" /></p> <p>If you’re not already using PIM, take a look at the instructions to <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-privileged-identity-management-configure">enable Privileged Identity Management for your directory</a> to get started. Read more about this exciting new preview at <a href="https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/azure-pim-resource-rbac">PIM for Azure resources (Preview)</a>.</p> <p><em>Note: Azure PIM is an Azure AD Premium 2 feature.<br /> </em></p> <p><strong>Access reviews for attestation<br /> </strong></p> <p>The second new feature in preview is access reviews of users in groups and assigned access to applications. We’ve already included access reviews for admins in directory roles in Azure AD PIM, and now we’re expanding how access reviews can be used for groups and application access.</p> <p>There are quite a few ways to control application access in Azure AD. A lot of organizations use groups in AD or Azure AD to control access. Users can also <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-self-service-application-access">request application access</a>. And now, the new Office 365 groups feature allows more users across your organization to create their own groups and pick who they want in those groups. (We’ve added a preview of <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/automated-expiration-for-office-365-groups-using-azure-ad-is-now-in-public-preview/">automatic expiration of Office 365 groups</a> to ensure the number of groups doesn’t get overwhelming).</p> <p>Of course, over time, group memberships and application access assignments can get stale people change jobs or no longer need access to a particular application. Maybe a guest who was given access isn’t affiliated with their original organization any longer. This staleness can cause a problem for protecting business-sensitive assets or applications subject to compliance. To avoid access getting out of hand, organizations can now schedule access reviews to make sure only the users they want to have access to their assets and applications are able to access those things.</p> <p>An access review asks users to recertify (or “attest”) to access rights to an app or membership in a group. You can ask users to review their own rights or select reviewers to review everyone in a group or everyone assigned access to an app. You can also ask the group owners to review. And finally, for those organizations that have other processes in place to manage employee access, you can scope the review to include only guest members or guests who have access.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac2.png" alt="" /></p> <p>Reviewers will receive an email so they can see the reviews in the access panel. Azure AD includes access highlights and recommendations that help reduce how long it takes for a review to be completed.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac3.png" alt="" /></p> <p>The results are aggregated and then, based on those results, the admin can choose when to make changes and remove the denied users’ access.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac4.png" alt="" /></p> <p>This particular preview includes access reviews for:</p> <ul> <li>Members of Office 365 groups</li> <li>Members of security groups and DLs, including groups originating from on-premises AD</li> <li>Users who have application access, including users who are members of groups assigned to enterprise applications</li> </ul> <p>And we’ll be adding more features and scenarios in the future!</p> <p>For even more information on access reviews, you can check out the <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-access-reviews-overview">access review overview</a> and turn on the preview for your tenant at <a href="https://aka.ms/azureadaccessreviews">https://aka.ms/azureadaccessreviews</a>.</p> <p><em>Note: Access reviews are an Azure AD Premium 2 feature<br /> </em></p> <p><strong>Terms of use<br /> </strong></p> <p>Our third preview being announced today is a terms of use access control we’ve added to Conditional Access.</p> <p>With terms of use, you can require a user to view and consent to your organization’s terms of use before they’re able access to an application. The terms can be any document relevant to your organization’s business or legal policies. Just start by uploading a PDF of that document to Azure AD, then, through conditional access policies, target the terms to be visible to groups of users or specific applications. If a user is in scope of this control, they’ll only receive access to the application if they’ve agreed to the terms presented.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac5.png" alt="" /></p> <p>You can see in the Azure AD audit reports who consented to each terms of use and when they consented.</p> <p>You can also configure multiple conditional access policies, using different policies for different applications or groups of users. For example, you might want to have everyone who access to a privacy-sensitive application use multi-factor authentication to sign in and to agree to the terms of use for that application.</p> <p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2017/10/100517_1818_Improvingac6.png" alt="" /><span style="background-color: yellow"><br /> </span></p> <p>Read more about this feature at <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-tou">Azure Active Directory Terms of Use (Preview)</a>.</p> <p><span style="color: #41424e"><em>Note: Terms of Use is an Azure AD Premium 1 feature<br /> </em></span></p> <p><span style="color: #41424e"><strong>Try them out!</strong></span></p> <p><span style="color: #41424e">I hope you’ll try out these new features and let us know what you think. </span>If you’re interested in taking these new features for a test drive and you don’t have EMS yet, <a href="https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security-trial">get a free trial of Enterprise Mobility + Security E5</a>.</p> <p><span style="color: #41424e">Please keep sharing your ideas on the <a href="https://feedback.azure.com/forums/169401-azure-active-directory">Azure AD feedback forum</a>. We want to hear from you!</span></p> <p>Best Regards,</p> <p>Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons"><span style="text-decoration: underline">@Alex_A_Simons</span></a>)</p> <p>Director of Program Management</p> <p>Microsoft Identity Division</p> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/10/05/improving-access-control-with-three-new-azure-ad-public-previews/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>What’s new with Azure Active Directory @ Ignite 2017</title>
<link>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/27/whats-new-with-azure-active-directory-ignite-2017/</link>
<comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/27/whats-new-with-azure-active-directory-ignite-2017/#respond</comments>
<pubDate>Wed, 27 Sep 2017 13:00:56 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Announcements]]></category>
<category><![CDATA[Authentication]]></category>
<category><![CDATA[Azure MFA]]></category>
<category><![CDATA[Cloud]]></category>
<category><![CDATA[Conditional Access]]></category>
<category><![CDATA[Hybrid]]></category>
<category><![CDATA[Identity Governance]]></category>
<category><![CDATA[Identity-driven Security]]></category>
<category><![CDATA[Multi-factor authentication]]></category>
<category><![CDATA[Public Preview]]></category>
<category><![CDATA[SaaS]]></category>
<category><![CDATA[Self Provisioning]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=55986</guid>
<description><![CDATA[Howdy folks! What an amazing week! Its the third day of Ignite and its been awesome getting to meet so many of you in person, especially when we have so much news to share! Leading up to the conference, the team worked hard to turn on important new Azure AD capabilities and Im excited to <p><a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/09/27/whats-new-with-azure-active-directory-ignite-2017/">Continue reading</a></p>]]></description>
<content:encoded><![CDATA[<p>Howdy folks!</p> <p>What an amazing week! Its the third day of Ignite and its been awesome getting to meet so many of you in person, especially when we have so much news to share!</p> <p>Leading up to the conference, the team worked hard to turn on important new Azure AD capabilities and Im excited to share a quick recap of everything we announced.</p> <h2>The next wave of conditional access starts now</h2> <p>In June we announced the <a target="_blank" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/06/08/the-new-intune-and-conditional-access-admin-consoles-are-ga/" rel="noopener noreferrer">general availability of the new conditional access admin experience</a> in the Azure portal. This powerful new experience makes it easy to manage policies that bring together services across EMS, including Azure Active Directory, Microsoft Intune. Conditional access also takes advantage of the Microsoft Intelligent Security Graph, which scans billions of signals to determine user risk levels.</p> <p>Now, were bringing to life a new wave of scenarios that expand our conditional access capabilities, including integration across EMS Azure Information Protection and Microsoft Cloud App Security services. Weve grouped the new features into three broad categories:</p> <ul> <li>Devices and apps</li> <li>Session control and information protection</li> <li>New conditions and custom controls</li> </ul> <p>Below are highlights from each feature category weve previewed at Ignite.</p> <h3>Devices and apps</h3> <p>We recently announced <a target="_blank" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/" rel="noopener noreferrer">device-based conditional access support for macOS</a>, and now were introducing new application-based conditional access capabilities. With this new level of control you can restrict access to services so that only client applications that support Intune app protection policies can use them. And you can combine app-based conditional access policies with device-based policies to protect data for both personal and corporate devices.</p> <p>Additionally, our conditional access policies now allow you to protect VPN connectivity in your Windows 10 device. So, any users with Windows 10 devices can connect automatically to your VPN only if they’re compliant with device policies.</p> <p>One more exciting feature were introducing is the ability to manage device identities in the Azure portal. With this new feature, you can manage device attributes, retrieve BitLocker keys for devices, see device authentication-related audit logs, and find support resources related to devices, all in the Azure portal.</p> <h3>Session control and information protection</h3> <p>The EMS team has also been making some incredible headway improving session control and data protection.</p> <p>Session controls allow you to limit access to resources. Weve had support for SharePoint restricted mode, one of our session control technologies, in public preview . Today, Im happy to let you know that were expanding our session controls in Azure AD Conditional Access to integrate with Microsoft Cloud App Security.</p> <p>Microsoft <a target="_blank" href="http://www.cloudappsecurity.com/" rel="noopener noreferrer">Cloud App Security</a> performs real-time monitoring and helps IT gain control over both authorized and unauthorized cloud application usage. This capability is currently in private preview. It will be available in public preview soon and will give you the ability to limit and control the actions your users take in SaaS applications using conditional access policy. For example, you will be able to let users access SaaS apps from an unfamiliar location or unmanaged device, but prevent them from downloading sensitive documents.</p> <p>And our new conditional access integration with Azure Information Protection (currently in public preview) allows you to apply access polices to protected files. Now, you can set a policy that prompts a user to complete a MFA challenge before accessing a protected document. You can even have the policy serve up a MFA challenge when users are off the corporate network or are flagged as an elevated risk by Identity Protection.</p> <h3>New Conditions & Custom Controls</h3> <p>Weve just turned on a public preview of country/region-defined IP range conditions. These new conditions make it easy to block access from specific countries and regions based on automatic IP address checks.</p> <p>Weve also unveiled custom <a target="_blank" href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-tou" rel="noopener noreferrer">Terms of Use</a> (ToU) as a control in conditional access. With ToU, you can require a user to consent to your organization’s terms of use before they get access to an application. The terms can be any document relevant to your organization’s business or legal policies. When you combine ToU with access reviews, you can collaborate across companies confidently, knowing the right level of information protection is in place.</p> <p>Finally, we’ve integrated two-step authentication solutions from Duo, RSA, and Trusona. So, if you’re using one of these providers to support two-step authentication, you can easily use them within the Azure AD conditional access engine.</p> <h2>Continuing to enable customers journey to the cloud</h2> <p>Weve heard stories from numerous customers that prove how important it is for their users passwords stay firmly within internal boundaries. So, we developed pass-through authentication! This authentication method allows you to use Azure AD for single sign-on without compromising any of your security requirements.</p> <p>Today, I’m happy to tell you pass-through authentication is now generally available!</p> <p>Pass-through authentication is an Azure AD sign-in options (along with password hash sync and federation). Its most appropriate for organizations who cant or dont want to permit users’ passwords, even in hashed form, to leave their internal boundaries. Pass-through authentication allows users to sign into both on-premises and cloud applications using the same passwords, and works by securely validating users passwords directly against on-premises Active Directory using a lightweight on-premises agent.</p> <p>To ensure a smooth user experience, were also extending seamless single sign-on to pass-through authentication and password hash sync. Hybrid customers will only need to sign into their device once. They will not be prompted again for another login, regardless of which authentication method they use, to access Azure AD-integrated applications on their AD-joined devices within their corporate network.</p> <p>For more details on this great functionality watch our <a target="_blank" href="https://youtu.be/PyeAC85Gm7w" rel="noopener noreferrer">Microsoft Mechanics show</a>, and visit the <a target="_blank" href="http://aka.ms/ptauth" rel="noopener noreferrer">pass-through authentication</a> and <a target="_blank" href="http://aka.ms/hybrid/sso" rel="noopener noreferrer">seamless single sign-on</a> documentation pages.</p> <h2>Casting a light on shadow IT</h2> <p><a target="_blank" href="http://www.computing.co.uk/ctg/news/2321750/more-than-80-per-cent-of-employees-use-non-approved-saas-apps-report" rel="noopener noreferrer">More than 80 percent of employees</a> admit to using non-approved SaaS applications for work, and discovering which apps theyre using is the first step to managing shadow IT. To that end, were upgrading the Cloud App Discovery tool to an enhanced experience powered by Microsoft Cloud App Security.</p> <p>With this upgrade, IT admins can now discover more than 15,000 apps without needing on-premises agents to do so. They can also receive detailed on-going risk analysis and alerts for new apps in use, get inbound and outbound traffic information, and uncover the top users of discovered apps all important pieces in gaining a greater understanding of cloud app usage across an organization.</p> <h2>More Governance and Compliance options for Azure AD customers</h2> <p>In addition to Sailpoint, were expanding our partnerships in advanced governance with the integration of Omada and Saviynt, two leaders in identity governance. Now you can seamlessly integrate their solutions with Azure Active Directory Premium which gives you rich governance capabilities like Access Requests, Policy based workflows and approvals, enhanced auditing and reporting and fine-grained lifcycle provisioning. If your looking for a great governance solution for Azure AD, you can’t go wrong with any of these partner solutions.</p> <p>Azure Active Directory is also adding more granular control functionality so enterprises can determine who has access to what across their hybrid deployments and cloud services. These new features, currently in public preview, enable customers to:</p> <ul> <li>ask group owners or group members to attest to their need for continued group membership, by starting an access review of that group.</li> <li>ask users with access to an enterprise application, or others in the organization, to recertify their need for continued application access.</li> </ul> <p>Weve made the Azure AD <a target="_blank" href="https://aka.ms/azureadaccessreviews" rel="noopener noreferrer">access review</a> experience more user-friendly by just showing access highlights, including whether the user being reviewed has signed into the application recently.</p> <p>Azure AD Privileged Identity Management (PIM) is also being extended to manage Azure subscriptions and resources, further governing who can manage resources in Azure. The new Azure AD PIM preview includes just in time and time-limited membership of Azure RBAC roles alongside its existing controls of Azure AD and Microsoft Online Services roles.</p> <h2>Wrapping Up</h2> <p>Theres so much to share, and in the weeks to come well be posting more detailed blog posts that get into the meat of many of these new features. Please continue to <a target="_blank" href="https://www.microsoft.com/en-us/ignite/default.aspx" rel="noopener noreferrer">watch us online</a> or visit us throughout the rest of Ignite, and keep an eye on this blog for more information. We want to hear from you and look forward to connecting!</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> ]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/09/27/whats-new-with-azure-active-directory-ignite-2017/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<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/#comments</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>10</slash:comments>
</item>
<item>
<title>Marching into the future of the Azure AD admin experience: retiring the Azure AD 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>4</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>
<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>
</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.</span><span style="color: black">All Azure AD servers are configured to use TLS 1.2. We allow inbound connections over TLS 1.1 and 1.0 to support external clients. We explicitly deny any connection over all legacy versions of SSL including SSL 3.0 and 2.0.</span><span style="color: #41424e;font-family: Segoe UI;font-size: 11pt;background-color: white">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> <p> </p> <p>[updated 10/3/2017 to add specificversion information about our use of TLS and SSL]</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> <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. 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.</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> <p>[Updated 10/3/2017 to clarify that this change will not effect customers who have customized these settings will not be impacted, but those using federation who have not changed these settingswill be effected.]</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>
</channel>
</rss>