<?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>Active Directory Team Blog</title>
<atom:link href="https://blogs.technet.microsoft.com/ad/feed/" rel="self" type="application/rss+xml" />
<link>https://blogs.technet.microsoft.com/ad</link>
<description></description>
<lastBuildDate>Sat, 04 Jun 2016 16:42:22 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<generator>http://wordpress.org/?v=4.2.7</generator>
<item>
<title>#AzureAD Identity Protection adds support for federated identities!</title>
<link>https://blogs.technet.microsoft.com/ad/2016/06/02/azuread-identity-protection-adds-support-for-federated-identities/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/06/02/azuread-identity-protection-adds-support-for-federated-identities/#comments</comments>
<pubDate>Thu, 02 Jun 2016 14:35:41 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10565</guid>
<description><![CDATA[Howdy folks, Azure AD Identity Protection has been generating a TON of customer interest, especially with recent news about hackers selling huge lists of leaked user credentials. So today I’m excited to let you know that Azure AD Identity Protection has just turned on support for federated identities. This means that our largest customers, most... <a href="https://blogs.technet.microsoft.com/ad/2016/06/02/azuread-identity-protection-adds-support-for-federated-identities/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>Azure AD Identity Protection has been generating a TON of customer interest, especially with recent news about hackers selling huge lists of leaked user credentials. So today I’m excited to let you know that Azure AD Identity Protection has just turned on support for federated identities. This means that our largest customers, most of who use Active Directory Federation Server with Azure AD, can now get the benefit of this powerful security service.</p>
<p>To give you a quick walk through of how to get this set up and working, I’ve asked Salah Ahmed one of the PM’s in our Identity Security and Protection team to write up a blog post. You’ll find it below.</p>
<p>I hope you’ll try out it today. Azure AD Identity Protection is undoubtedly the fastest and easiest way available to substantially improve your company’s security posture. If your company is using Azure AD, you’d have to be crazy to give it a try!</p>
<p>And as always, we’d love to receive 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>Hi all!</p>
<p>My name is Salah Ahmed and I am a Program Manager in the Identity Security and Protection team in Microsoft’s Identity Division. Today we are pleased to announce an update to the public preview of Azure Active Directory Identity Protection that extends risk based conditional access to federated identities. For the benefit of those who missed the <a href="https://blogs.technet.microsoft.com/ad/2016/03/02/azure-ad-identity-protection-is-in-public-preview-whoop-whoop/">original public preview announcement</a>, you can think of Identity Protection as a gatekeeper to the cloud, analyzing and securing sign-ins to all of the applications Azure AD manage, including Office 365, and Azure, third party applications like ServiceNow, Salesforce.com, Google Apps, and DropBox and on-premises apps connected using the Azure AD App Proxy.</p>
<h2>Detection</h2>
<p>Identity Protection detects risk events involving identities in an Azure Active Directory that indicate that the identities may have been compromised. For details on risk detection, see <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection-risk-events-types/">Types of risk events detected by Azure Active Directory Identity Protection</a>.</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/06/060216_1437_AzureADIden1.png" alt="" /></p>
<p><strong>What’s new:</strong> Starting today, all of Identity Protection’s risk event types will be covered for federated identities! Now you can tell if botnet infections, TOR networks, or location anomalies are present in your federated sign-ins. [Note that leaked credentials detection requires that you have enabled <a href="http://social.technet.microsoft.com/wiki/contents/articles/18096.dirsync-password-sync-frequently-asked-questions.aspx">password hash sync</a> in your federated tenant.]</p>
<h2>Risk based Conditional Access</h2>
<p>Identity Protection allows admins to respond to risky sign-ins by</p>
<ul>
<li>Enforcing multi factor authentication (MFA)</li>
<li>Blocking them completely</li>
</ul>
<p>The great thing about Identity Protection sign-in risk policy is that it interrupts only bad sessions. As a result, if a bad actor is trying to sign-in to an account, only the bad actor would be interrupted, without the actual user being impacted in any way.</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/06/060216_1437_AzureADIden2.png" alt="" /></p>
<p><strong>What’s new: </strong>Starting today, blocking or enforcing MFA on risky sessions is available for federated identities. What this means it that your federated identities have an extra layer of protection when they try to access cloud services such as Office 365, Azure, or *any* apps configured for Single Sign-On with Azure Active Directory!</p>
<p>If the administrator has configured a policy to enforce MFA on sign-in risks, the next time a risky sign-in is detected, the user is informed that something unusual was detected about their sign-in.</p>
<p style="text-align: center;margin-left: 36pt"><img src="https://msdnshared.blob.core.windows.net/media/2016/06/060216_1437_AzureADIden3.png" alt="" /></p>
<p>The user is then required to prove their identity by solving a security challenge.</p>
<p style="text-align: center;margin-left: 36pt"><img src="https://msdnshared.blob.core.windows.net/media/2016/06/060216_1437_AzureADIden4.png" alt="" /></p>
<p>Alternatively, if the administrator has configured a policy to block risky sign-ins, the next time a risky sign-in is detected, it is blocked. Self-recovering by solving multi-factor authentication is not an option in this case.</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/06/060216_1437_AzureADIden5.png" alt="" /></p>
<p>Note on Multifactor authentication:<strong><br />
</strong>For federated tenants, multi-factor authentication (MFA) may be performed by Azure Active Directory or by the on-premises AD FS server.</p>
<p>By default, MFA will occur at a page hosted by Azure Active Directory. In order to configure MFA on-premises, the –SupportsMFA property must be set to true in Azure Active Directory, by using the Azure AD module for Windows PowerShell.</p>
<p>The following example shows how to enable on-premises MFA by using the <a href="https://msdn.microsoft.com/library/azure/dn194088.aspx">Set-MsolDomainFederationSettings cmdlet</a> on the contoso.com tenant:</p>
<p style="background: #eeeeee"><span style="color: #2b91af;font-family: Consolas;font-size: 10pt">Set<span style="color: black">–<span style="color: #2b91af">MsolDomainFederationSettings<span style="color: black"> –<span style="color: #2b91af">DomainName<span style="color: black"> contoso.com –<span style="color: #2b91af">SupportsMFA<span style="color: black"> $true<span style="color: #505050"><br />
</span></span></span></span></span></span></span></span></span></p>
<p>In addition to setting this flag, the federated tenant AD FS instance must be configured to perform multi-factor authentication. You can revisit the <a href="https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server/">instructions for deploying Azure Multi-Factor Authentication on-premises</a>.</p>
<h1>Try it out!</h1>
<p>So what are you waiting for? Identity Protection’s capabilities are a must-have in today’s world of persistent bad actors and frequent security breaches. <a href="http://aka.ms/aadipgetstarted">Setting up</a> Identity Protection <em>takes less than a minute</em>! You need an Azure AD Premium license to try out the full capabilities in this public preview.<strong><br />
</strong>If you would like to see Identity Protection’s detection capabilities in action and would like to test its detection, mitigation and remediation capabilities, check out our <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection-playbook/">Playbook</a> for step-by-step instructions.</p>
<p>I hope you’ll find this new capability useful!</p>
<p>Regards,</p>
<p>Salah Ahmed</p>
<p>Program Manager</p>
<p>Microsoft Identity Division</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/06/02/azuread-identity-protection-adds-support-for-federated-identities/feed/</wfw:commentRss>
<slash:comments>5</slash:comments>
</item>
<item>
<title>Using #AzureAD Dynamic Groups with SharePoint Online</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/26/using-azuread-dynamic-groups-with-sharepoint-online/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/26/using-azuread-dynamic-groups-with-sharepoint-online/#comments</comments>
<pubDate>Thu, 26 May 2016 15:22:24 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[How To]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10495</guid>
<description><![CDATA[Howdy folks, Today’s we’re trying something new – a quick “how-to” post. Rob De Jong is the PM who owns our self-service group and dynamic group features. Here he’s going to walk you through using Dynamic Groups with SharePoint online. I hope you’ll find this useful. Let us know what you think! Best Regards, Alex... <a href="https://blogs.technet.microsoft.com/ad/2016/05/26/using-azuread-dynamic-groups-with-sharepoint-online/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>Today’s we’re trying something new – a quick “how-to” post. Rob De Jong is the PM who owns our self-service group and dynamic group features. Here he’s going to walk you through using Dynamic Groups with SharePoint online.</p>
<p>I hope you’ll find this useful. Let us know what you think!</p>
<p>Best Regards,</p>
<p>Alex Simons (Twitter: @Alex_A_Simons)</p>
<p>Director of Program Management</p>
<p>Microsoft Identity Division</p>
<p>————</p>
<p>Hello,</p>
<p>Rob De Jong here. Today I want to tell you about a very powerful feature in Azure Active Directory is the ability to manage access to SharePoint Online through a dynamic group. Often, directory administrators need to provide access based on a user’s department, location or job title, or maybe some other attribute or combination of attributes. And usually this information is available, perhaps in an HR system or in a local directory. If these attributes are synced to Azure AD then it is easy to use them in a dynamic group to manage access. This is sometimes also referred to as “Attribute Based Access Control”, or ABAC.</p>
<p>In this video I’m showing how to configure a group in your directory to provide dynamic, attribute-based access to a SharePoint site. You could use the same approach to manage SaaS applications, assign licenses or even manage access to on premises resources.</p>
<p><iframe src="https://channel9.msdn.com/Series/Azure-Active-Directory-Videos-Demos/Using-Azure-Active-Directory-dynamic-group-membership-to-manage-access-to-Sharepoint-sites/player" width="640" height="360" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>
<p>Note that, since the dynamic group feature supports standard user attributes as well as extension attributes and custom attributes, you can use virtually all attributes in your on premises AD to sync to Azure AD and drive a dynamic group to provide access to resources in your directory.</p>
<p><a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-accessmanagement-manage-groups/">Here</a> you can read more about dynamic groups in Azure AD. Please note that dynamic groups require an Azure AD Premium license assigned to all members of the dynamic group.</p>
<p>Best Regards,</p>
<p>Rob</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/26/using-azuread-dynamic-groups-with-sharepoint-online/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Adobe Acrobat DC now supports #AzureAD and OneDrive!</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/25/adobe-acrobat-dc-now-supports-azuread-and-onedrive/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/25/adobe-acrobat-dc-now-supports-azuread-and-onedrive/#comments</comments>
<pubDate>Wed, 25 May 2016 14:55:31 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Announcements]]></category>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10485</guid>
<description><![CDATA[Howdy folks, I am excited to announce that Adobe Acrobat DC is now integrated with O365 through OneDrive and Azure Active Directory (Azure AD). Acrobat connects with OneDrive so PDFs can be opened, edited, and saved directly from OneDrive. This keeps the file in OneDrive, avoiding the need for users to download and upload files... <a href="https://blogs.technet.microsoft.com/ad/2016/05/25/adobe-acrobat-dc-now-supports-azuread-and-onedrive/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>I am excited to announce that Adobe Acrobat DC is now integrated with O365 through OneDrive and Azure Active Directory (Azure AD). Acrobat connects with OneDrive so PDFs can be opened, edited, and saved directly from OneDrive. This keeps the file in OneDrive, avoiding the need for users to download and upload files just to use them with Acrobat. Using Acrobat with OneDrive streamlines your experience and enables the power of Office 365 on your PDF files.</p>
<p>In the first week alone we saw more than 800 enterprises connect Acrobat with their Office 365 accounts through Azure AD!</p>
<p>Adobe Acrobat is one of the most popular client apps for desktop, browser and tablet users to fill, sign and send forms easily and fast. The Acrobat federation uses industry standard <a href="https://msdn.microsoft.com/library/azure/dn645545.aspx">OAuth 2.0</a> protocol in Azure AD to enable authorization to customer’s Azure AD tenant and Office 365 data. The Azure AD implementation is extended to protect third-party web APIs and customer data.</p>
<p>If you have an Azure AD Account, the easy SSO experience with Adobe Acrobat will give you transparent access to the Acrobat features without any sign-in process and yet your access is secure and protected by Azure AD.</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052516_1455_AdobeAcroba1.png" alt="" /></p>
<p>On the Home screen in Acrobat or Acrobat Reader, select <strong>Add Account</strong> in the left-hand pane, and then click <strong>Add </strong>under the OneDrive account, enter your cloud service credentials then <strong>Sign in</strong>.</p>
<p>Please let us know if you have any questions for configuring SSO with Adobe Acrobat.</p>
<p>I hope you’ll give it a try today!</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/ad/2016/05/25/adobe-acrobat-dc-now-supports-azuread-and-onedrive/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>117M leaked creds (from LinkedIn?). New best practices + #AzureAD and MSA can help</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/#comments</comments>
<pubDate>Tue, 24 May 2016 15:57:57 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[How To]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10295</guid>
<description><![CDATA[Howdy folks, You probably saw the news last week that a hacker was selling a list with 117M usernames and passwords purportedly leaked from LinkedIn. With these kinds of leaks happening almost weekly now, what can a person do to protect themselves? Or if you are an IT admin, what can you do to protect... <a href="https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>You probably saw the news last week that a hacker was selling a list with 117M usernames and passwords purportedly leaked from LinkedIn. With these kinds of leaks happening almost weekly now, what can a person do to protect themselves? Or if you are an IT admin, what can you do to protect your users accounts?</p>
<p>Based on the latest research, there are some straight forward, concrete steps you can take as a user or as an administrator to help protect your accounts. And we’ve got some great features in #AzureAD and the Microsoft Account service that can help you as well.</p>
<p>I’ve asked Robyn Hicock and Alex Weinert from our Identity Protection team to walk you through these steps. Robyn has done a really great white paper reviewing the latest best practices in password security and Alex has written up a nice blog post showing you how Azure AD and the Microsoft Account service can help. You’ll find Alex’s blog post and links to Robyn’s whitepaper below.</p>
<p>I hope you’ll take the time to read them both. They are both interesting and some of Robyn’s findings will probably surprise 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>
<p>Hello everyone!</p>
<p>Alex Weinert, Group Program Manager of Azure AD Identity Protection team here again. Hot on the heels of my <a href="https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/">blog</a> explaining our approach to lists of compromised credentials and sharing the results data, last week we had another <a href="http://www.bing.com/search?q=117+million+credentials">another big list in the news</a>, this time a set of 117M purportedly leaked from LinkedIn.</p>
<p>With all these lists leaking, what can you do to stay safe?</p>
<p>To start with, I’d recommend you read this <a href="http://aka.ms/passwordguidance">great whitepaper</a> that Robyn Hicock, a Program Manager on our team just published online. It highlights a bunch of very cool research and gives some great guidance on improving the security of passwords.</p>
<p>The paper draws on some great work done by the folks in Microsoft Research, our data and learnings from 10+ years of defending the Microsoft Account service from attacks and information across the industry.</p>
<p>I think it will change the way you think about your password policies. For example, did you know that in the real world all of these common approaches:<strong><em><br />
</em></strong></p>
<ul>
<li><em>Password length requirements</em></li>
<li><em>Password “complexity” requirements</em></li>
<li><em>Regular, periodic password expiration </em></li>
</ul>
<p>actually make passwords easier to crack? Why you might ask? Because humans act in pretty predictable ways when faced with these kinds of requirements. You can learn all about it in <a href="http://aka.ms/passwordguidance">Robyn’s paper</a>.</p>
<p>In addition to Robyn’s paper, I want to share a few insights into how Azure AD and the Microsoft Account system work to protect you and your passwords. We do this in two innovative ways based on the best practice outlined in Robyn’s paper:</p>
<ul style="margin-left: 41pt">
<li>Dynamically banning common passwords</li>
<li>Smart password lockout</li>
</ul>
<p>Read on to learn more about these approaches and how we use them in Azure AD and the Microsoft Account System.</p>
<p><strong>Dynamically Banned Passwords<br />
</strong></p>
<p>As Robyn’s paper explains, the most important thing to keep in mind when selecting a password is to choose one that is unique, and therefore hard to guess. We help you do this in the Microsoft Account and Azure AD system by <strong><em>dynamically banning commonly used passwords</em></strong>.</p>
<p>When it comes to big breach lists, cybercriminals and the Azure AD Identity Protection team have something in common – we both analyze the passwords that are being used most commonly. Bad guys use this data to inform their attacks – whether building a <a href="http://www.bing.com/search?q=rainbow+table">rainbow table</a> or trying to brute force accounts by trying popular passwords against them. What *we* do with the data is prevent you from having a password anywhere near the current attack list, so those attacks won’t work.</p>
<p>As I mentioned in my last blog and the latest Microsoft <a href="http://www.microsoft.com/sir">Security Incident Report,</a> we see more than 10M accounts attacked daily, so we have a lot of data about which passwords are in play in those attacks. We use this data to maintain a dynamically updated banned password list.</p>
<p>We then use that list to prevent you from selecting a commonly used password or one that is similar. This service is already live in the Microsoft Account Service and in private preview in Azure AD. Over the next few months we will roll it out across all 10m+ Azure AD tenants.</p>
<p>Here’s what it looks like to an end user in Azure AD (currently in private preview – coming soon!):</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052416_2003_117Mleakedc1.jpg" alt="" /></p>
<p>And here’s what it looks like on your Microsoft account (Outlook, Xbox, OneDrive…):</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052416_2003_117Mleakedc2.jpg" alt="" /></p>
<p><strong>Smart Password Lockout</strong></p>
<p>Of course, you already know that when our security system detects a bad guy trying to guess your password online, we will lock out the account. What you probably don’t know is that we do lots of work to make sure that they only lock themselves out!</p>
<p>Our systems are designed for determining the risk associated with a specific login session. Using this, we can apply lockout semantics only to the folks who aren’t you. The only way *you* get locked out is if someone is guessing your passwords on your own machine or network.</p>
<p>If you are locked out in Azure AD, it looks like this:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052416_2003_117Mleakedc3.png" alt="" /></p>
<p>And in Microsoft account, it looks like this:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052416_2003_117Mleakedc4.png" alt="" /></p>
<p>To see how effective this is at saving good users from disruption, check this out – more than half the time, we keep hackers from disrupting you or your users:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/052416_2003_117Mleakedc5.jpg" alt="" /></p>
<p>Those are just a few of the things we do on behalf of Azure AD Admins.</p>
<p>If you are an Azure AD Admin, the most important thing you can do – as Robyn points out in the doc – is to make sure your users are all configured correctly for Azure MFA or better yet, start using something like Windows Passport, which is inherently multi-factor and will soon help get us (and you!) out of the password business altogether!</p>
<p>Enjoy our <a href="http://aka.ms/passwordguidance">password guidance</a> – and be sure to let Robyn (<a href="https://twitter.com/RobynHicock">@robynhicock</a>) know what you think!</p>
<p>Until next time – be safe!</p>
<p>-Alex <a href="https://twitter.com/Alex_T_Weinert">(@alex_t_weinert</a>)</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/feed/</wfw:commentRss>
<slash:comments>21</slash:comments>
</item>
<item>
<title>#AzureAD: Postponing our planned certificate roll</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/21/azuread-postponing-our-planned-certificate-roll/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/21/azuread-postponing-our-planned-certificate-roll/#comments</comments>
<pubDate>Sat, 21 May 2016 22:31:59 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<category><![CDATA[Updates]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10255</guid>
<description><![CDATA[Howdy folks, Quick update for you on the certificate rolling we told you about this week in this blog post. We received feedback from some of you that you need more time to get ready and ensure there is no service interruption for customers. Given this input and our strong desire to avoid any down time for... <a href="https://blogs.technet.microsoft.com/ad/2016/05/21/azuread-postponing-our-planned-certificate-roll/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p style="background: white"><span style="color: #212121;font-size: 11pt">Howdy folks,<br />
</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">Quick update for you on the certificate rolling we told you about this week in <a href="https://blogs.technet.microsoft.com/ad/2016/05/12/hey-azuread-app-devs-were-going-to-roll-our-certs-on-523/">this</a> blog post.</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">We received feedback from some of you that you need more time to get ready and ensure there is no service interruption for customers. Given this input and our strong desire to avoid any down time for customer <strong>we are going to delay the rollover by a few weeks</strong> in order to lower the risk of customer impact.<br />
</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">We’ll get you updated info next week with additional details!<br />
</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">Best Regards,<br />
</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">Alex Simons (Twitter: @Alex_A_Simons)<br />
</span></p>
<p style="background: white"><span style="color: #212121;font-size: 11pt">Director of Program Management<br />
</span></p>
<p style="background: white"><span style="color: #212121"><span style="font-size: 11pt">Microsoft Identity Division</span><span style="color: black"><br />
</span></span></p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/21/azuread-postponing-our-planned-certificate-roll/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>ADAL .NET v3 reaches GA!</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/18/adal-net-v3-reaches-ga/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/18/adal-net-v3-reaches-ga/#comments</comments>
<pubDate>Wed, 18 May 2016 17:03:40 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Announcements]]></category>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10205</guid>
<description><![CDATA[Hi folks, today I am happy to announce that the version 3 of our authentication library ADAL .NET v3 is generally available. ADAL .NET v3 introduces important new features, such as cross platform development via Xamarin, which will help you to easily harness the power of Azure AD and the Microsoft cloud API – no... <a href="https://blogs.technet.microsoft.com/ad/2016/05/18/adal-net-v3-reaches-ga/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Hi folks, today I am happy to announce that the version 3 of our authentication library ADAL .NET v3 is generally available. ADAL .NET v3 introduces important new features, such as cross platform development via Xamarin, which will help you to easily harness the power of Azure AD and the Microsoft cloud API – no matter what OS you are targeting.</p>
<p>To walk us through the salient features of this release I invited back Vittorio, a Program Manager from the developer experience team.</p>
<p>As always, we welcome your feedback.</p>
<p>John Justice</p>
<p>Director of Program Management</p>
<p>Microsoft Identity Developer Platform</p>
<p> </p>
<p>——</p>
<p>Hello everybody,</p>
<p><a href="https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/">ADAL .NET v3</a> is finally ready to power your apps in production! Thanks to the new Xamarin integration features you can now write your application once, and run it on iOS, Android and Windows – ADAL v3 helps you to address your authentication needs in a single place and reuse it across all platforms.</p>
<p>In this post I will list the most salient news and features.</p>
<h1>What’s new in ADAL .NET v3</h1>
<p>ADAL .NET v3 has been refactored to extend the range of platforms it can reach. Namely, with v3 you can target:</p>
<ul>
<li>.NET 4.5+ applications: WPF apps, console apps, code behind of ASP.NET 4.6 web apps and API, etc etc</li>
<li>UWP apps (Windows 10 and Windows 10 Mobile)</li>
<li>Windows Store apps</li>
<li>Xamarin iOS and Android apps</li>
<li>Xamarin Forms apps</li>
<li>[still preview] .NET Core apps</li>
</ul>
<p>(note, Windows Phone is no longer supported in ADAL v3. If you need WP8.1 support, please keep using ADAL v2.x).</p>
<p>That’s a pretty large collection! We were able to achieve this by pivoting from Windows Runtime Components, the component technology we used in v2, and .NET portable classes. If you peek inside ADAL .NET v3 NuGet, you’ll see the following:</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2016/05/145.png"><img class="alignnone size-full wp-image-10215" src="https://msdnshared.blob.core.windows.net/media/2016/05/145.png" alt="1" width="433" height="122" /></a></p>
<p>The idea is that when you add a NuGet reference to ADAL, the NuGet system will pull in specific assemblies depending on your project type. For example, if you are building a portable class, you’ll get netcode45 or dnxcore50. If you are building a Xamarin iOS project, however, you’ll end up with both the netcore45 assembly and the platform-specific Xamarin.iOS10 assembly.</p>
<p>The primitives you use for working ADAL are largely unchanged – they are the familiar <em>AuthenticationContext</em>, <em>AcquireToken</em>*, <em>AuthenticationResult</em> and the like. However the surface has been adjusted to accommodate the fact that your code might now be running on widely different platforms – with different ways of prompting the user, different storage technology for token caches, and so on. Here there’s how we achieve adaptive behavior across platforms.</p>
<p>AcquireToken* now accepts a new parameter, an interface named <em>IPlatformParameters</em>. That interface has a concrete implementation, <em>PlatformParameter</em>, for all the supported platforms. The main purpose of <em>PlatformParameters</em> is to carry a reference of the parent UX element from which you want to trigger the authentication experience: that helps ADAL to determine at runtime whether it should prompt the user using iOS, Android, Windows Store or Windows desktop experiences. The subdivision in interface and concrete classes allows you to maximize code reuse: you can put most of your authentication logic in a portable class, where you use the <em>IPlatformParameter</em> – and all you need to do for leveraging that from platform specific projects is to pass in the corresponding <em>PlatformParameters</em> platform specific implementation. Let me give you a practical example.</p>
<p>The main ADAL sample demonstrating how to work with Xamarin can be found <a href="https://github.com/Azure-Samples/active-directory-dotnet-native-multitarget">here</a>. It is a simple application, which allows you to query the directory to find basic information about a user.</p>
<p>The solution structure follows the pattern introduced earlier: there is a portable class project containing the bulk of the authentication logic, and platform specific projects (in this case for desktop, UWP, iOS, Android) implementing the experience (note, Xamarin Forms is also supported. See <a href="http://www.cloudidentity.com/blog/2015/07/22/using-adal-3-x-with-xamarin-forms/">here</a> for hints on how to use it).</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2016/05/246.png"><img class="alignnone size-full wp-image-10235" src="https://msdnshared.blob.core.windows.net/media/2016/05/246.png" alt="2" width="336" height="132" /></a></p>
<p>If you expand the references folder for the portable class library and any of the platform specific projects, you’ll observe the assemblies distribution typical of the pattern.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2016/05/326.png"><img class="alignnone size-full wp-image-10245" src="https://msdnshared.blob.core.windows.net/media/2016/05/326.png" alt="3" width="388" height="417" /></a></p>
<p>The portable library refers to the portable ADAL assembly; the platform specific project refers to the portable library, and the ADAL PCL & the platform specific assembly.</p>
<p>The portable class library project contains some basic token acquisition logic. The interesting parts are highlighted below.</p>
<p><em>public static async Task<List<User>> SearchByAlias(string alias, IPlatformParameters parent)</em></p>
<p><em>{</em></p>
<p><em>// …</em></p>
<p><em>authResult = await authContext.AcquireTokenAsync(graphResourceUri,</em></p>
<p><em>clientId, returnUri, parent);</em></p>
<p><em>// …</em></p>
<p>The call to AcquireTokenAsync looks like the good ol’ AcquireTokenAsync in ADAL 2.x, except for the new parameter passing in the IPlatformParameters.</p>
<p>Let’s once again pick the Android project as the representative of what happens in platform specific project. The directory searching functionality is implemented in MainActivity.cs. Here there’s the code used to trigger the search.</p>
<p><em>List<User> results = await DirectorySearcher.SearchByAlias(searchTermText.Text, new PlatformParameters(this));</em></p>
<p>The <em>PlatformParameters</em> instance passed here is the Android specific implementation of <em>IPlatformParameters</em>, taking in input the current activity. This allows ADAL to dynamically determine what logic to invoke for displaying prompts and access storage in platform specific fashion. iOS has similar code in its viewcontroller, Windows in its XAML page, and so on.</p>
<h1>Samples</h1>
<p>The Nuget refactoring and the IPlatformParameters are the main structural differences in respect to ADAL 2.x. There are many more news, of course! You can find a list of the differences in the changelog reported in the <a href="https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/releases">releases section</a> of <a href="https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/releases">ADAL .NET’s github repo</a> – however you’ll likely have more fun by experimenting with the <a href="https://azure.microsoft.com/en-us/documentation/samples/?service=active-directory&platform=dotnet">samples</a>!</p>
<p>Danny Strockis from our PM team worked hard to port most of the <a href="https://azure.microsoft.com/en-us/documentation/samples/?service=active-directory&platform=dotnet">.NET samples</a> (a staggering 35 of them, at the moment) to use ADAL v3. Among those you’ll find a number of samples showing off the brand new features ADAL v3 introduces, such as the aforementioned Xamarin sample and the <a href="https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-deviceprofile/">device profile sample</a> (introduced <a href="http://www.cloudidentity.com/blog/2015/12/02/new-adal-3-x-previewdevice-profile-linux-and-os-x-sample/">here</a> – and which happens to also run on Linux and Mac!).</p>
<p>Note: if for some reason you need to stick with ADAL v2.x for a little longer, and you need to access the version of the samples using ADAL v2.x, you can go to the releases section of the sample repo and select the release labeled ADAL v2. For example for the desktop apps sample in <a href="https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/">https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/</a> you can access the ADAL v2.x version by navigating to <a href="https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/releases/tag/v2.X">https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/releases/tag/v2.X</a>.</p>
<h1>ADAL v3 and .NET Core RC2 support</h1>
<p>Earlier this week the ASP.NET and .NET teams released the RC2 of .NET Core and ASP.NET Core.</p>
<p>ADAL v3 is now GA, hence its NuGet is in the stable nuget.org feed – it would be odd to reference to prerelease bits, hence the stable ADAL v3 package does NOT work with .NET Core. We’ll be releasing a version of ADAL working .NET Core RC2 in the coming weeks.</p>
<h1>ADAL v3 and MSAL</h1>
<p>You will recall that few weeks ago, during //build/, we announced the preview of MSAL – a new authentication library that works with the v2 authentication endpoint of Azure AD (supporting both work & school accounts and Microsoft Accounts, or MSAs) and with Azure B2C. MSAL works exclusively with those new endpoints, and cannot be used for obtaining tokens from the current organizations-only Azure AD v1 endpoints. Furthermore, MSAL does not work with ADFS – while ADAL v3 does (and in fact, we expanded support for the scenarios offered by ADFS in Windows Server 2016).</p>
<p>Hence, choosing what library to use in your project is easy. If you need to talk with services that only accept tokens issued by organizations-only Azure AD v1 endpoints, such as the Azure management API; if you need to implement topologies not yet supported by the new endpoints (such as exposing your own API to other developers, consuming 3<sup>rd</sup> party API, etc); if you need to connect with ADFS directly, use ADAL v3. If you want to experiment with the Microsoft graph, work on scenarios where business and consumer identities seamlessly blend, or try new features (such as incremental consent), the MSAL will be the right fit for the job.</p>
<p> </p>
<p>Well, there you have it. ADAL v3 unlocks scenarios and use cases that weren’t possible with ADAL v2, unlocking the full potential of cross platform development without compromising on the ease of use you’ve come to know and love. We want to thank you for the tons of useful feedback you gave us during the preview period. Please keep your feedback coming, and thank you for using our services!</p>
<p>Best,</p>
<p>Vittorio Bertocci (Twitter: <a href="https://twitter.com/vibronet">@vibronet</a> – Blog: <a href="http://www.cloudidentity.com/">http://www.cloudidentity.com/</a>)</p>
<p>Principal Program Manager</p>
<p>Microsoft Identity Division</p>
<p> </p>
<p> </p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/18/adal-net-v3-reaches-ga/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>#AzureAD now supports custom unique IDs in SAML tokens for gallery apps</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/#comments</comments>
<pubDate>Fri, 13 May 2016 16:38:56 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Best Practices]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10187</guid>
<description><![CDATA[Howdy folks, Here’s one of the most common pieces of feedback we get from customers using Azure AD: “My users are already using the app, and their username isn’t their email address or user principal name. It’s a custom ID that we defined, and I need to get Azure Active Directory to send that value.”... <a href="https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p><span style="font-family: Segoe UI">Here’s one of the most common pieces of feedback we get from customers using Azure AD:<br />
</span></p>
<p style="margin-left: 36pt"><span style="font-family: Segoe UI"><em>“My users are already using the app, and their username isn’t their email address or user principal name. It’s a custom ID that we defined, and I need to get Azure Active Directory to send that value.”<br />
</em></span></p>
<p><span style="font-family: Segoe UI">Sound familiar?<br />
</span></p>
<p><span style="font-family: Segoe UI">If so, I’m happy to announce that our claims editor for gallery apps has been enhanced to allow the selection of extension attributes as the unique user ID.<br />
</span></p>
<p><span style="font-family: Segoe UI"><strong>What is the claims editor?<br />
</strong></span></p>
<p><span style="font-family: Segoe UI">The claims editor is a user interface in the <a href="https://manage.windowsazure.com/">Azure classic portal</a> that allows you to edit all of the user information (or claims) sent in the SAML tokens to specific apps. This includes the “nameidentifier” claim, which is the one that uniquely identifies the user.<br />
</span></p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051316_1639_AzureADnows1.png" alt="" /><span style="font-family: Segoe UI"><br />
</span></p>
<p><span style="font-family: Segoe UI">This editor is available for all <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-appssoaccess-whatis/">pre-integrated</a> and<span style="color: #505050"> <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-saas-custom-apps/">custom</a> </span>apps added from the Azure AD application gallery, and can be found under the Attributes tab. The claims editor is described here:<br />
</span></p>
<p><a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-saml-claims-customization/"><span style="font-family: Segoe UI">https://azure.microsoft.com/en-us/documentation/articles/active-directory-saml-claims-customization/</span></a><span style="color: #505050;font-family: Segoe UI"><br />
</span></p>
<p><span style="font-family: Segoe UI"><strong>What are extension attributes?<br />
</strong></span></p>
<p><span style="font-family: Segoe UI">Extension attributes are user attributes in Azure Active Directory that can be populated using <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/">Azure AD Connect</a><span style="color: #505050">. </span>Any attributes stored in on-premises Active Directory can be mapped to these extension attributes, and commonly these can include custom identifiers like the Employee ID mastered in the organization’s HR system.<span style="color: #505050"><br />
</span></span></p>
<p><span style="font-family: Segoe UI">These extension attributes appear in Azure Active Directory as <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-attributes-synchronized/">ExtensionAttribute1 though ExtensionAttribute15</a>. Once synced to Azure AD, you can see and select these extension attributes as the “nameidentifier” claim in the claims editor:<br />
</span></p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051316_1639_AzureADnows2.png" alt="" /><span style="font-family: Segoe UI"><br />
</span></p>
<p><span style="font-family: Segoe UI">Storing the HR Employee ID in an extension attribute is a very common use case, and virtually any user ID value required by an application can be created in on-premises Active Directory and mapped to an extension attribute using AAD Connect.<br />
</span></p>
<p><span style="font-family: Segoe UI">I hope you’ll find this new capability useful! And as always, we would love to hear any feedback or suggestions you have!<br />
</span></p>
<p><span style="font-family: Segoe UI">Best Regards,<br />
</span></p>
<p><span style="font-family: Segoe UI">Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)<br />
</span></p>
<p><span style="font-family: Segoe UI">Director of Program Management<br />
</span></p>
<p><span style="font-family: Segoe UI">Microsoft Identity Division<br />
</span></p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>Hey #AzureAD App Devs! We’re going to roll our certs on 5/23</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/12/hey-azuread-app-devs-were-going-to-roll-our-certs-on-523/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/12/hey-azuread-app-devs-were-going-to-roll-our-certs-on-523/#comments</comments>
<pubDate>Thu, 12 May 2016 16:00:21 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Best Practices]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=10175</guid>
<description><![CDATA[Howdy folks, As part of our commitment to protecting customer data, we periodically roll the certificates in Azure AD. Our next certificate rollover is coming 5/23/2016. If you followed our development best practices, this should have no impact on your app. But it’s always best to be sure! So Brandon Werner, one of the PM’s... <a href="https://blogs.technet.microsoft.com/ad/2016/05/12/hey-azuread-app-devs-were-going-to-roll-our-certs-on-523/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>As part of our commitment to protecting customer data, we periodically roll the certificates in Azure AD. Our next certificate rollover is coming 5/23/2016. If you followed our development best practices, this should have no impact on your app.</p>
<p>But it’s always best to be sure! So Brandon Werner, one of the PM’s on our developer platform team has written a quick blog post below to help you make sure your app with keep working.</p>
<p>Best Regards,</p>
<p>Alex Simons (@Alex_A_Simons)</p>
<p>Director of Program Management</p>
<p>Microsoft Identity Division</p>
<p>——————————</p>
<p style="background: white"><span style="color: #212121;font-family: Segoe UI">Howdy everyone,<br />
</span></p>
<p style="background: white"><span style="color: #212121"><span style="font-family: Segoe UI">It’s me, Brandon Werner, back with you again!.As part of our best practice of protecting customers data world wide, Azure Active Directory periodically </span><span style="color: black"><span style="font-size: 11pt">rolls the certificates of the service.</span><span style="color: #212121;font-family: Segoe UI"> <span style="font-size: 11pt">The Azure Active Directory authentication service will be performing a certificate rollover on 5/23. </span>If you followed the development guidelines outlined below, you should experience no impact. We’ve included <span style="font-size: 11pt">information</span> below so you can review your applications and ensure they are following these best practices.</span><br />
</span></span></p>
<p style="background: white"><span style="color: black"><strong>We do not expect any impact for:</strong></span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol"></span><span style="font-size: 7pt"> </span>Any application which follows the best practices outlined here: <a href="https://msdn.microsoft.com/en-us/library/azure/dn641920.aspx" target="_blank"><span style="color: #0563c1">https://msdn.microsoft.com/en-us/library/azure/dn641920.aspx</span></a></span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol"></span><span style="font-size: 7pt"> </span>Any application added from the <a href="https://azure.microsoft.com/en-us/marketplace/active-directory/all/" target="_blank"><strong>Azure AD application gallery</strong></a> that has been configured to use SAML or WS-Federation. These applications follow separate rollover cycles and provide separate notifications.</span></p>
<p style="background: white"><span style="color: black"><strong>There might be an impact to applications if:</strong></span></p>
<p style="background: white"><span style="color: black">The application takes a dependency on any of the endpoints listed below, but is not configured to automatically update the certificate from the metadata. Best practices on how to automatically update the certificate are outlined here: <a href="https://msdn.microsoft.com/en-us/library/azure/dn641920.aspx" target="_blank"><span style="color: #0563c1">https://msdn.microsoft.com/en-us/library/azure/dn641920.aspx</span></a></span></p>
<p style="background: white"><span style="color: black"><strong>Metadata Endpoints Updated</strong></span></p>
<p style="background: white"><span style="color: black">The following metadata endpoints have been updated to publish the new certificate:</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/FederationMetadata/2007-06/FederationMetadata.xml</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/discovery/keys</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/FederationMetadata/2007-06/FederationMetadata.xml</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/discovery/keys</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/.well-known/openid-configuration</span><br />
</span></p>
<p style="background: white"><span style="color: black"><strong>Token Issuance Endpoints Affected</strong></span></p>
<p style="background: white"><span style="color: black">Tokens issued over the following endpoint will switch to using the new certificate only on 5/23:</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/oauth2/authorize</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/oauth2/token</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/wsfed</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.microsoftonline.com/{tenant}/saml2</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/oauth2/authorize</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/oauth2/token</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/wsfed</span><br />
</span></p>
<p style="background: white"><span style="color: black"><span style="font-family: Symbol;font-size: 10pt"></span><span style="font-size: 7pt"> </span><span style="color: #0563c1">https://login.windows.net/{tenant}/saml2</span><br />
</span></p>
<p style="background: white"><span style="color: black"> If you experience unusual behaviors, visit <a href="http://azure.microsoft.com/en-us/support/options/" target="_blank"><span style="color: #0563c1">http://azure.microsoft.com/en-us/support/options/</span></a></span></p>
<p style="background: white"><span style="color: black"> Thanks,</span></p>
<p style="background: white"><span style="color: black">Brandon</span></p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/12/hey-azuread-app-devs-were-going-to-roll-our-certs-on-523/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>How we protect #AzureAD and Microsoft Account from lists of leaked usernames and passwords</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/#comments</comments>
<pubDate>Tue, 10 May 2016 15:09:24 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<category><![CDATA[Thought Leadership]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=9935</guid>
<description><![CDATA[Howdy folks, Last week there was a lot of news coverage about a list of 272 million stolen username and passwords that were available from a Russian hacker named “The Collector”. Given all the attention this list received, I thought you might be interested in how we protect user accounts from being hacked when something... <a href="https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>Last week there was a lot of news coverage about a list of 272 million stolen username and passwords that were available from a Russian hacker named “The Collector”. Given all the attention this list received, I thought you might be interested in how we protect user accounts from being hacked when something like this happens. This kind of thing happens with alarming frequency, so we’ve developed a standard set of processes and an automated system to protect user accounts from this kind of threat.</p>
<p>To share the details on how this works and what we learned from this specific list, I’ve asked Alex Weinert, the Group Program Manager who leads our Identity Protection team to do a guest blog. You’ll find it below.</p>
<p>I hope you’ll find this information useful and interesting!</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>Hey everyone!</p>
<p>I’m Alex Weinert, the Group Program Manager for the Identity Protection team in Microsoft’s Identity Division.</p>
<p>The Identity Protection team is responsible for preventing hackers and cyber criminals from getting access to user accounts in the Microsoft account (MSA) and Azure Active Directory (Azure AD) services. We safeguard hundreds of millions of unique users across more than 13 billion logins every day.</p>
<p>As a lot of you know, <a href="https://www.bing.com/search?q=Russian%20Hacker%20272.3%20million">a number of articles were published</a> last week about a Russian hacker offering 272.3 million stolen usernames and passwords. This has received a lot of press coverage so we thought you might be interested to learn how we handle these lists when we discover them.</p>
<p>The first thing to understand is that the vast majority of stolen credentials are acquired when a hacker breaches a vulnerable website that stores passwords in plaintext or uses weak encryption or hashing practices. (Stolen usernames and passwords are also commonly acquired in phishing attacks or malware.) The second thing to understand is that many people use the same username and password with multiple sites.</p>
<p>Taken together, this means that when someone else’s services are hacked, it can put accounts with the same username and password in our system at risk.</p>
<p>Because these kinds of breaches and attacks happen quite frequently, we’ve built a standard set of processes and automated services to make sure our users are always protected.</p>
<p>We discover stolen credentials in a bunch of different ways. Mostly our machine learning systems and algorithms find them before any disclosure, but we also find lists by working with local and national governments, industry partners, security researchers and academic institutions all around the world. We also work closely with Microsoft Digital Crimes Unit, Security Response Center, The Office365 team, The Xbox team and many others who contribute to Microsoft’s Intelligent Security Graph and use the combined results to detect and stop attacks.</p>
<p>When we discover a new list of usernames and passwords, we run them through an automated system that checks to see if any of the credentials match those in our MSA or Azure AD systems by comparing the hashes of the submitted password to the hashed password stored with the actual accounts. The good news is that, most of the time, the credentials passed around by criminals don’t match any accounts in our services because the data in this lists is fabricated or out of date.</p>
<p>For this particular list, 9.62% of the usernames matched an account in our systems. And of those, only 1.03% had a matching password. So overall <strong>less than 0.1% of the list had a valid match for username and password</strong> in our systems.</p>
<p>But remember, our machine learning systems and algorithms find and automatically protect most compromised credentials before any disclosure. In this case, <strong>we had already protected 58.3%</strong> of that 0.1% because we had already caught an invalid access attempt or other suspicious activity!</p>
<p>The result? Of all the accounts in this list, <strong>0.042 % of them were actually at risk.<br />
</strong></p>
<p><strong>Once we’ve identified the subset of accounts that are vulnerable, our automated mitigations kick in to protect them.<br />
</strong></p>
<p>In the case of consumer accounts in MSA, the account is marked as being at risk. The next time the rightful account owner logs in, we interrupt them, require that they verify their identity with a second factor, and then require them to change their password.</p>
<p>It looks like this:</p>
<p><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec1.png" alt="" /><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec2.png" alt="" /><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec3.png" alt="" /></p>
<p>In the case of business accounts in Azure AD, the <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection/">Azure Active Directory Identity Protection</a> service – currently in public preview – gives corporate IT administrators the option to use the same kinds of automated mitigation policies for their user accounts in Azure AD.</p>
<p>The Azure AD user experience looks like this (note the Wingtip Toys brand here is a placeholder logo):</p>
<p><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec4.png" alt="" /><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec5.png" alt="" /><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec6.png" alt="" /></p>
<p>The cool thing about this is that when we detect a user’s password is compromised, Azure AD admins can have the account automatically locked down and protected before the bad guy can ever use the credentials – just like we do for our Microsoft consumer accounts in MSA.</p>
<p>Here’s a screen shot of the admin console in <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection/">Azure AD Identity Protection</a>, where admins can see their users at risk:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec7.png" alt="" /></p>
<p>Drill into specifics:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec8.png" alt="" /></p>
<p>And set policies to automatically remediate users we find at risk:</p>
<p style="text-align: center"><img src="https://msdnshared.blob.core.windows.net/media/2016/05/051016_1519_Howweprotec9.png" alt="" /></p>
<p>Last week, Alex Simons mentioned in this blog that Microsoft had just published <a href="http://www.microsoft.com/sir">our 20<sup>th</sup> Security Intelligence Report</a>. In that report we explained that we detect more than 10 million credential attacks <em>every day</em> across our identity systems. This includes millions of attacks every day where the username and password are correct, but we detect that the person attempting to log in is a cyber-criminal.</p>
<p>So while 33 million Hotmail username/password pairs in the wild is definitely important to us, it is a relatively small volume, less than half of what we process in an average week, and a drop in the bucket compared to the more than <strong>4 </strong><strong>billion</strong> credentials we detected being attacked last year.</p>
<p>We hope this helps you understand how those articles you saw relate to your identity security – and how we’re using credential lists (and a <em>lot</em> of other signals) to keep your account safe.</p>
<p>And hey – if *you* ever want to contribute compromised credentials you’ve found, or any other security issue, <a href="mailto:
[email protected]">
[email protected]</a> is the right place to begin the process of reporting them and beginning a secure transfer. But please, don’t send us creds in email! Once we get your contact info we’ll work with you to make appropriate arrangements.</p>
<p>Thanks,</p>
<p>Alex Weinert [<a href="https://twitter.com/Alex_T_Weinert">@alex_t_weinert</a>]</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/feed/</wfw:commentRss>
<slash:comments>5</slash:comments>
</item>
<item>
<title>New enhancements to #AzureAD Domain Services</title>
<link>https://blogs.technet.microsoft.com/ad/2016/05/09/new-enhancements-to-azuread-domain-services/</link>
<comments>https://blogs.technet.microsoft.com/ad/2016/05/09/new-enhancements-to-azuread-domain-services/#comments</comments>
<pubDate>Mon, 09 May 2016 16:55:33 +0000</pubDate>
<dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator>
<category><![CDATA[Announcements]]></category>
<category><![CDATA[Azure Active Directory]]></category>
<category><![CDATA[Identity & Access Management]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/ad/?p=9845</guid>
<description><![CDATA[Howdy folks, Today we’re announcing a cool set of enhancements to Azure AD Domain Services (AAD DS). With > 3500 customers already actively using this new service (while it’s still in preview!), AAD DS has been a unexpected hit. Those customers have given us a lot of helpful feedback and today we’re announcing some new... <a href="https://blogs.technet.microsoft.com/ad/2016/05/09/new-enhancements-to-azuread-domain-services/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Howdy folks,</p>
<p>Today we’re announcing a cool set of enhancements to Azure AD Domain Services (AAD DS). With > 3500 customers already actively using this new service (while it’s still in preview!), AAD DS has been a unexpected hit. Those customers have given us a lot of helpful feedback and today we’re announcing some new features based on their requests:</p>
<ul>
<li>Secure LDAP access</li>
<li>Custom OU support</li>
<li>Administer DNS for your managed domain</li>
<li>Domain join for Linux VM’s (no, that is not a typo!)</li>
</ul>
<p>And in case you didn’t see the news when we originally announced it AAD DS is now available in Australia!</p>
<p>Mahesh Unnikrishnan, the Program Manager who leads our AAD DS efforts, has written up some details on these enhancements which you’ll find below.</p>
<p>I hope you’ll find these new capabilities useful. As always, we’d love to receive 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>Hi there!</p>
<p style="text-align: justify">I’m Mahesh Unnikrishnan, a Program Manager in the Identity division at Microsoft. Late last year, we <a href="https://blogs.technet.microsoft.com/ad/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-domain-controller/">announced the public preview</a> of an exciting new service called Azure AD Domain Services. We’ve seen incredible customer demand for this service. The past few months have been a great learning experience for us and we’ve gotten a ton of valuable feedback from our preview customers. We continue to evolve the service and refine it based on this feedback.</p>
<p style="text-align: justify">Today, I’m thrilled to announce updates to our public preview. We have quite a few new features for you to try out.</p>
<p><strong>Secure LDAP access to your managed domain<br />
</strong></p>
<p style="text-align: justify">Many directory-connected applications use LDAP (Lightweight Directory Access Protocol) to connect to Active Directory, in order to authenticate users or to lookup additional information about the user. Secure LDAP, also known as ‘LDAP over Secure Sockets Layer (SSL)/Transport Layer Security (TLS)’, provides a secure way to do this. Secure LDAP ensures that sensitive LDAP traffic in your domain is not visible to anyone with a network packet analyzer. This level of security is indispensable, if you want to connect to your directory from an external network or over the internet.</p>
<p style="text-align: justify">We’re excited to deliver support for Secure LDAP in Azure AD Domain Services. You can now connect over secure LDAP from any virtual machine within the virtual network in which you’ve enabled Azure AD Domain Services. You can also configure your managed domain to allow Secure LDAP connections over the internet. This is useful if you need to connect to your directory from another network or from a different location. This cool new functionality enables you to lift-and-shift applications that rely on Secure LDAP from your on-premises infrastructure and deploy them confidently in Azure.</p>
<p>Get started – <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-configure-secure-ldap/">Configure secure LDAP (LDAPS) for your managed domain</a></p>
<p><strong>Create and administer custom organizational units (OUs)<br />
</strong></p>
<p style="text-align: justify">Some customers told us they would like to lift-and-shift legacy on-premises line of business applications, which rely on service accounts to authenticate with the directory, to Azure. Some of these service accounts are configured with password policies that differ from those for end-user accounts. An example of this is configuring service account passwords to never expire. Other customers have told us how they would prefer to put sets of their domain-joined computers into different organizational units (eg. all web-servers in a single OU, database servers in a different OU etc.) for ease of administration.</p>
<p style="text-align: justify">With this nifty new feature, members of the ‘AAD DC Administrators’ group can now create a custom Organizational Unit (OU) on your managed domain. Further, they get full administrative privileges for the custom OU they’ve created and can perform tasks such as creating service accounts within the OU.</p>
<p>Get started – <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-create-ou/">Create an organizational unit on your managed domain</a></p>
<p><strong>Administer DNS for your managed domain<br />
</strong></p>
<p style="text-align: justify">Many of our Azure Infrastructure Services customers deploy workloads that require them to configure and deploy load-balancers or other non-domain joined virtual machines. They need to configure DNS in order to ensure these machines are reachable from other machines.</p>
<p style="text-align: justify">Azure Active Directory Domain Services provide DNS resolution for your managed domain within the virtual network in which you’ve enabled the service. Occasionally, it may be necessary to configure DNS on the managed domain in order to create records for machines that are not joined to the domain, create virtual IP addresses for load-balancers or configure external DNS forwarders. Members of the ‘AAD DC Administrators’ group can now administer DNS on the managed domain using DNS administration tools.</p>
<p>Get started – <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-administer-dns/">Administer DNS on your managed domain</a></p>
<p><strong>Domain join Linux virtual machines<br />
</strong></p>
<p style="text-align: justify">We’ve engineered Azure AD Domain Services to make it easy for you to join your Azure Infrastructure Services virtual machines to the managed domain. You can then manage these virtual machines using Group Policy and users can sign-in to the virtual machines using their corporate credentials.</p>
<p style="text-align: justify">We’ve published a <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-join-windows-vm/">step-by-step guide for joining a Windows virtual machine to your managed domain</a>.</p>
<p style="text-align: justify">We’ve also collaborated with our friends at Red Hat to show you how to <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-join-rhel-linux-vm/">join a Red Hat Enterprise Linux (RHEL 7) virtual machine to your managed domain</a>.</p>
<p><strong>We’re now in Australia!<br />
</strong></p>
<p style="text-align: justify">After launching the public preview, we’ve seen a lot of customer requests to add support for the Australia regions of Azure. We’re excited to announce that Azure AD Domain Services is now available in Azure’s Australia East and Australia Southeast regions.</p>
<p style="text-align: justify">We’re thrilled about the opportunity to evolve Azure AD Domain Services based on your feedback. We’d love for you to try out the service, especially these new features and <a href="https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-contact-us">share your feedback with us</a>.</p>
<p style="text-align: justify">Thanks,</p>
<p style="text-align: justify">Mahesh Unnikrishnan</p>
<p style="text-align: justify">Principal Program Manager</p>
<p>Microsoft Identity Division</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/ad/2016/05/09/new-enhancements-to-azuread-domain-services/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
</channel>
</rss>