Desktop, tablet and smartphone with app icons.

Protect your business with identity and access management in the cloud

Get single sign-on to thousands of cloud apps and access to web apps that you run on-premises with Azure Active Directory Premium. Built for ease of use, Azure Active Directory management tools enable collaboration and deliver holistic identity protection and adaptive access control.

Business case

Technical overview

Benefits of Active Directory

Single sign-on to any cloud and on-premises web app

Azure Active Directory provides secure single sign-on to cloud and on-premises applications including Microsoft Office 365 and thousands of SaaS applications such as Salesforce, Workday, DocuSign, ServiceNow, and Box.

See more supported SaaS apps

Easily extend Active Directory to the cloud

Connect Active Directory and other on-premises directories to Azure Active Directory in just a few clicks and maintain a consistent set of users, groups, passwords, and devices across both environments.

Connect on-premises directories with Azure

Works with iOS, Mac OS X, Android and Windows devices

Users can launch applications from a personalized web-based access panel, mobile app, Office 365, or custom company portals using their existing work credentials—and have the same experience whether they’re working on iOS, Mac OS X, Android and Windows devices.

Protect sensitive data and applications

Enhance application access security with unique identity protection capabilities that provide a consolidated view into suspicious sign-in activities and potential vulnerabilities. Take advantage of advanced security reports, notifications, remediation recommendations and risk-based policies to protect your business from current and future threats.

Protect on-premises web applications with secure remote access

Access your on-premises web applications from everywhere and protect with multi-factor authentication, conditional access policies, and group-based access management. Users can access SaaS and on-premises web apps from the same portal.

Reduce costs and enhance security with self-service capabilities

Delegate important tasks such as resetting passwords and the creation and management of groups to your employees. Providing self-service application access and password management through verification steps can reduce helpdesk calls and enhance security.

Enterprise scale and SLA

Azure Active Directory Premium offers enterprise-grade scale and reliability. As the directory for Office 365, it already hosts hundreds of millions of users and handles billions of authentications every day. The high availability service is hosted in globally distributed datacenters in 17 regions, with worldwide technical support that provides a 99.9% SLA.

Azure Active Directory applications: New apps

Boost mobile productivity with secured access to applications

Using Azure Active Directory Premium, Bristow Group provided its helicopter pilots and support crews—a highly mobile workforce—easier access to critical enterprise applications, both on-premises and in the cloud.

Read the case study

Save time with simplified identity management

Royal Dutch Shell chose Azure Active Directory to simplify identity management for vendors and employees. Now the company provides fast, secured access to external vendors, cutting onboarding time from months to less than a week.

Read the case study

AZURE ACTIVE DIRECTORY TEAM BLOG

Visit the 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>Fri, 08 Sep 2017 16:24:20 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <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, <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>]]></description> <content:encoded><![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. 

<h2>Datacenter and Service Security 
</h2>
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. 

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. 

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. 

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. 

<h2>Threat detection 
</h2>
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: 

<ul>
<li>Breach detection: 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! 
</li>
<li>Penetration tests: 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. 
</li>
<li>Audit: 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. 
</li>
</ul>
And did we say we encrypt all your data in Azure AD? Yes, we do we use BitLocker to encrypt all Azure AD identity data at rest. What about on the wire? We do that as well! All Azure AD APIs are web-based using SSL through HTTPS to encrypt the data. Access to information is restricted through token-based authorization and each tenant’s data is only accessible to accounts permitted in that tenant. In addition, our internal APIs have the added requirement to use SSL client/server authentication on trusted certificates and issuance chains. 

<h2>A final note 
</h2>
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. 

(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.) 

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. 

Best regards, 

Alex Simons (Twitter: @Alex_A_Simons) 

Director of Program Management 

Microsoft Identity Division
]]></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>8</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 <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>]]></description> <content:encoded><![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 important topic for many of you, so I think it’s warranted.
Going forward the following defaults will now apply to all new Azure AD Tenants:
<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>
It’s important to note that these new defaults will not apply to your tenant if you have customized these settings or if you are using federation. Additionally if you want to override these settings with your own custom setting, you can do that.
<h2>Why now?</h2>
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.
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.
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.
<h2>What do these lifetimes control?</h2>
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>.
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.
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.
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.
<h4>Refresh token inactivity</h4>
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.
This change won’t apply to your tenant if you configured Refresh Token Max Inactive Time to a custom value or if you configured federation with Azure AD and another authentication system
<h4>Single/multi-factor refresh token MaxAge</h4>
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.
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.
<h4>Refresh token MaxAge for confidential clients</h4>
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.
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.
Please note that MaxAge for confidential clients can’t be modified; it can, however, be revoked if needed, by using the steps in the How can I revoke refresh tokens? section 
below.
<h2>Can I change/revert these settings?</h2>
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.
To specifically revert the lifetimes in your tenant to their previous values, follow the guidelines below.
<h4>Set defaults in tenant to older values</h4>
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.
To get started:
<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>
Connect-AzureAD -Confirm 
</li>
<li>
<div>To create the policy, run the following command:</div>
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” 
</li>
</ol>
<h2>How can I revoke refresh tokens?</h2>
Revoking a user’s active refresh tokens is simple and can be done on an ad-hoc basis. You do this by setting the StsRefreshTokensValidFrom 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.
Follow these steps to revoke a user’s refresh tokens:
<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>
Connect-msolservice 
</li>
<li>
<div>Set the StsRefreshTokensValidFrom parameter using the following command:</div>
Set-MsolUser -UserPrincipalName <UPN of the User> -StsRefreshTokensValidFrom (“<current date>”) 
</li>
</ol>
<h2>Let us know what you think!</h2>
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.
Best regards,
Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
 
[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]
]]></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>30</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> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/30/todays-identity-news-improvements-to-azure-ad-connect-health-sync-error-reporting/#respond</comments> <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. <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>]]></description> <content:encoded><![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. 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!
Best regards,
Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
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!
—-
Hello,
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.
<h1>So, what’s new?</h1>
In this short post, we wanted to make three key announcements about sync error reports:
<ul>
<li>Accessing the sync error report does NOT require Azure AD Premium.</li>
</ul>
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent1.jpg" />
<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>
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent2.jpg" />
<ul>
<li>We’ve added a dedicated category for the “FederatedDomainChange” errors.</li>
</ul>
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/083017_0111_TodaysIdent3.jpg" />
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>.
<h1>That’s great! Tell me more…</h1>
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 all tenants and does not require Azure AD Premium.
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.
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.
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.
If you have any feedback or comments do reach out to us at <a href="mailto:askaadconnecthealth@microsoft.com">askaadconnecthealth@microsoft.com</a>.
Thank you,
The Azure AD Connect Health Team
]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/30/todays-identity-news-improvements-to-azure-ad-connect-health-sync-error-reporting/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </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 <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>]]></description> <content:encoded><![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 model. 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!
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.
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.
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>.
<h2>Getting Started</h2>
Here’s how to get started with the preview:
<ol>
<li>
<div style="text-align: justify">If Azure AD Domain Services is not enabled for your Azure directory <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>

</li>
<li>
<div style="text-align: justify">If you’ve already enabled Azure AD Domain Services for your Azure directory 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 production instance, 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 test instance, 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>
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. 

<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/082817_2047_Newpublicpr1.png" />
<h2>The Road to GA</h2>
We have quite a bit of work still to go before we can GA this feature. The two biggest remaining are:
<ol>
<li>
<div style="text-align: justify">We’re going all in on resource manager virtual networks: 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>

</li>
<li>
<div style="text-align: justify">Migration process for existing managed AD domains: 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>
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!
Best regards,
Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
]]></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>6</slash:comments> </item> <item> <title>Azure AD and Intune now support macOS in conditional access!</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/</link> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/#comments</comments> <pubDate>Wed, 23 Aug 2017 16:00:07 +0000</pubDate> <dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Authentication]]></category> <category><![CDATA[Conditional Access]]></category> <category><![CDATA[Mac OS]]></category> <category><![CDATA[Office 365]]></category> <category><![CDATA[SaaS]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54665</guid> <description><![CDATA[Howdy folks, Conditional access is one of athe fastest growing services in EMS and we are constantly getting feedback from customers about new capabilities they would like us to add to it. One of the most frequently requested is support for macOS. Customers want to have one consistent system for securing user accessing to Office <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/">Continue reading</a>]]></description> <content:encoded><![CDATA[Howdy folks,

Conditional access is one of athe fastest growing services in EMS and we are constantly getting feedback from customers about new capabilities they would like us to add to it. One of the most frequently requested is support for macOS. Customers want to have one consistent system for securing user accessing to Office 365 on all the platforms their employees are using.

So I’m excited to share that Azure Active Directory and Intune now support macOS platform for device-based conditional access! Administrators can now restrict access to Intune-managed macOS devices using device-based conditional access according to their organization’s security guidelines.

With the public preview of macOS device-based conditional access, you’ll be able to:

<ul>
<li>Enroll and manage macOS devices using Intune
</li>
<li>Ensure macOS devices adhere to your organization’s compliance policies
</li>
<li>Restrict access to applications in Azure AD to only compliant macOS devices
</li>
</ul>
Get started with macOS conditional access public preview in two simple steps:

<h2>Configure compliance requirements for macOS devices in Intune 
</h2>
Use the Intune service in Azure Portal to create a device compliance policy for macOS devices in a few easy clicks:

<img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI1.png" alt="" />
	
Configure compliance requirements for device health, properties, and system security per your organization’s requirements.

<img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI2.png" alt="" />
	
For more details, go to <a href="https://aka.ms/macoscompliancepolicy">https://aka.ms/macoscompliancepolicy</a>.

(Important Note: for Conditional Access on macOS to work, the device will need to have the Intune Company Portal app installed). 

<h2>Restrict access to Azure AD applications for macOS devices 
</h2>
Create a targeted conditional access policy for macOS to protect the Azure AD Applications. Go to conditional access under Azure AD service in Azure portal to create a new policy for macOS platform.

<img src="https://msdnshared.blob.core.windows.net/media/2017/08/082317_1729_AzureADandI3.png" alt="" />
	
For more details on conditional access policies, go to <a href="https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access-azure-portal">Conditional Access in Azure Active Directory</a>.

After you’ve taken these steps, macOS users covered in the policy will be able to access Azure AD connected applications only if their Mac conforms to your organization’s policies.

<h2>Supported OS versions, applications, and browsers 
</h2>
In the public preview, the following OS versions, applications, and browsers are supported on macOS:

Operating Systems 

<ul>
<li>macOS 10.11+
</li>
</ul>
Applications 

The following Office 2016 for macOS applications are supported:

<ul>
<li>Outlook v15.34 and later
</li>
<li>Word v15.34 and later
</li>
<li>Excel v15.34 and later
</li>
<li>PowerPoint v15.34 and later
</li>
<li>OneNote v15.34 and later
</li>
</ul>
Browsers 

<ul>
<li>Safari
</li>
</ul>
Try it out today and let us know what you think! We look forward to hearing from you.

Best regards,

Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)

Director of Program Management

Microsoft Identity Division
]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/feed/</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item> <title>Cloud App Security new remediation feature</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/cloud-app-security-new-auto-remediation-feature/</link> <pubDate>Wed, 09 Aug 2017 16:00:50 +0000</pubDate> <dc:creator><![CDATA[Cloud App Security Team]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54115</guid> <description><![CDATA[Require users to sign in again in case of suspicious behavior Real-time remediation for security threats is a key challenge for companies, where attackers can move quickly to access critical data. Cloud App Security team is excited to introduce a new feature for threat protection through integration with Azure Active Directory: when a suspicious user <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/cloud-app-security-new-auto-remediation-feature/">Continue reading</a>]]></description> <content:encoded><![CDATA[<h2>Require users to sign in again in case of suspicious behavior</h2>
Real-time remediation for security threats is a key challenge for companies, where attackers can move quickly to access critical data. <a href="https://www.microsoft.com/en-us/cloud-platform/cloud-app-security">Cloud App Security</a> team is excited to introduce a new feature for threat protection through integration with <a href="http://www.microsoft.com/identity">Azure Active Directory</a>: when a suspicious user activity is detected by Cloud App Security, you can now prevent access to corporate data accessed through apps that use Azure AD by requiring the user to sign in again.
Lets explore two key reaction capabilities of this feature:
<h3 style="padding-left: 30px">Respond to anomalous behavior</h3>
External sharing of sensitive files, download of sensitive files from unrecognized locations, or any activity thats considered abnormal can trigger alerts in Cloud App Security portal. These alerts provide immediate notification of potential security incidents and assist admins with proactive investigation.
In the event of suspicious user behavior, the new auto-remediation feature allows the security admin to take immediate action, and requiring the user to sign-in again to all apps.
<h3 style="padding-left: 30px">React to account takeover</h3>
When an attacker gains unauthorized access to an account, a common industry practice is to disable the account. But this is not enough! If the account is actively being used to exfiltrate data, gain elevated privileges in the organization, or any other method that keeps the attackers session active, they can still use the compromised account.
The new Cloud App Security capability allows an admin to require the user to sign in again and mitigate the attack. Cloud App Security invalidates all the user’s refresh tokens issued to cloud apps.
<h3>How to implement this feature</h3>
Requiring the user to sign in again can be set during the policy creation phase, or initiated directly from an alert as part of the resolution options for a user. Initiating governance actions directly from the policy allow for automatic remediation. In this case, the admin needs only to select this option and it will be enforced.
<a href="https://msdnshared.blob.core.windows.net/media/2017/07/image541.png"><img width="445" height="268" title="image" class="aligncenter" style="float: none;padding-top: 0px;padding-left: 0px;margin-left: auto;padding-right: 0px;margin-right: auto;border: 0px" alt="image" src="https://msdnshared.blob.core.windows.net/media/2017/07/image_thumb443.png" border="0" /></a>
Policy setting: require user to sign-in again
Alternatively, an admin can select to require another sign in as part of the reactive investigation of an alert as seen below. In either case, to ensure secure productivity, the user is protected and can continue working with minimal interruption.
<a href="https://msdnshared.blob.core.windows.net/media/2017/07/image542.png"><img width="624" height="209" title="image" class="aligncenter" style="float: none;padding-top: 0px;padding-left: 0px;margin-left: auto;padding-right: 0px;margin-right: auto;border: 0px" alt="image" src="https://msdnshared.blob.core.windows.net/media/2017/07/image_thumb444.png" border="0" /></a>
Require user to sign in again during investigation of a specific alert
<h3>Better together</h3>
Our goal is to provide a holistic and innovative security approach with Enterprise Mobility + Security. Cloud App Security and Azure Active Directory together offer unique value that help you gain better control over your cloud, by identifying suspicious activities which may be indicative of a breach and then respond immediately.
<h2>Learn more and give us feedback</h2>
We know how important visibility, control and threat protection are for you, especially when it comes to cloud apps. Our goal is to continuously innovate to provide a top-notch user experience, visibility, data control and threat protection for your cloud apps. If you would like to learn more about our solution, please visit our technical <a href="https://docs.microsoft.com/en-us/cloud-app-security/governance-actions">documentation</a> page.
Your feedback is key to our product development process. If you have questions, comments or feedback, please leave a comment below or visit our <a href="https://techcommunity.microsoft.com/t5/Microsoft-Cloud-App-Security/bd-p/MicrosoftCloudAppSecurity">Microsoft Cloud App Security Tech Community page</a>.
]]></content:encoded> </item> <item> <title>Azure AD Automated Expiration for Office 365 Groups is now in Public Preview</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/automated-expiration-for-office-365-groups-using-azure-ad-is-now-in-public-preview/</link> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/automated-expiration-for-office-365-groups-using-azure-ad-is-now-in-public-preview/#comments</comments> <pubDate>Wed, 09 Aug 2017 15:39:39 +0000</pubDate> <dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Identity Governance]]></category> <category><![CDATA[Office 365]]></category> <category><![CDATA[Public Preview]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54405</guid> <description><![CDATA[Howdy folks, One of the coolest collaboration features in Office 365 is Office 365 groups. Your employees can create these groups on the fly and use them to collaborate with their co-workers on projects, sharing team documents, emails and calendars. These groups are easy and fast to create and judging by their usage telemetry, they <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/automated-expiration-for-office-365-groups-using-azure-ad-is-now-in-public-preview/">Continue reading</a>]]></description> <content:encoded><![CDATA[Howdy folks, 

One of the coolest collaboration features in Office 365 is Office 365 groups. Your employees can create these groups on the fly and use them to collaborate with their co-workers on projects, sharing team documents, emails and calendars. These groups are easy and fast to create and judging by their usage telemetry, they are VERY popular. 

However as the number of Office 365 groups increases, it can create a bit of a mess, for instance when a project is completed but the group is still hanging around. To help address that issue, we’ve just turned on the public preview of Office 365 groups expiration! 

With this new feature you can set an expiration timeframe for any Office 365 group you choose. Once that timeframe is set, owners of any groups set to expire will be asked to renew them if they still need them. Groups that aren’t renewed will be deleted. And using a feature we shipped earlier called “Soft-delete of groups”, any group that was not meant to be deleted can be restored within 30 days by the group owners. 

<h2>Getting started</h2>
Office 365 groups expiration can be configured from the Azure Active Directory portal, as well as programmatically via Azure Active Directory PowerShell. Below is a quick tutorial on how to get started with the functionality in the new Azure portal experience. 

<ol>
<li>
<div style="text-align: justify">To create a policy for your tenant, simply select Users and groups, go to Group settings, and select Expiration. 
</div>
</li>
</ol>
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080917_1535_AutomatedEx1.png" /> 

<ol>
<li>
<div style="text-align: justify">Specify the group lifetime in days and select which groups you want the expiration settings to apply to. 
</div>
</li>
</ol>
Group owners will receive a renewal notification 30 days before the expiration date, and from that notification they can renew their group with a single click! 

<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080917_1535_AutomatedEx2.png" /> 

If the owners don’t renew their group within the required timeframe, their group will expire and be deleted. Owners of deleted groups will receive a notification letting them know their group has been deleted and giving them the opportunity to restore their group for 30 days after its deletion date. Learn more about <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-lifecycle-azure-portal">how to configure Office 365 groups expiration</a>. 

<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080917_1535_AutomatedEx3.png" /> 

This functionality is made possible with a cool feature we recently rolled out that allows you to soft-delete and restore Office 365 groups! You can now restore your group and all its content, including Sharepoint, Planner, and Outlook, for a period of 30 days from when the group was deleted. Check out more details about <a href="https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-restore-azure-portal">how to restore deleted Office 365 groups</a>. 

The Office 365 groups expiration feature is available in public preview today for Azure AD Premium customers. Please note that this feature will require Azure AD Premium when it GAs. 

<h2>Let us know what you think!</h2>
We would love to hear your feedback! If you have any suggestions for us, questions, or issues to report, please leave a comment below. We’re always looking for ways to improve. 

Best regards, 

Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>) 

Director of Program Management 

Microsoft Identity Division 

]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/09/automated-expiration-for-office-365-groups-using-azure-ad-is-now-in-public-preview/feed/</wfw:commentRss> <slash:comments>18</slash:comments> </item> <item> <title>An update to Azure AD Conditional Access for Office.com</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/04/an-update-to-azure-ad-conditional-access-for-office-com/</link> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/04/an-update-to-azure-ad-conditional-access-for-office-com/#comments</comments> <pubDate>Fri, 04 Aug 2017 16:00:43 +0000</pubDate> <dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Conditional Access]]></category> <category><![CDATA[Exchange]]></category> <category><![CDATA[Office 365]]></category> <category><![CDATA[SharePoint]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54355</guid> <description><![CDATA[Howdy folks, Today I’m writing to provide some background about a change in how conditional access policies will soon be enforced when users access Office.com. Notifications about this change have been sent out, but several of you have asked for additional details. What’s changed? On August 24th, a change will roll out that requires users <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/04/an-update-to-azure-ad-conditional-access-for-office-com/">Continue reading</a>]]></description> <content:encoded><![CDATA[Howdy folks,
Today I’m writing to provide some background about a change in how conditional access policies will soon be enforced when users access Office.com. Notifications about this change have been sent out, but several of you have asked for additional details.
<h2>What’s changed?</h2>
On August 24th, a change will roll out that requires users to satisfy any policies set on Exchange Online and SharePoint Online when accessing Office.com. For example, if a policy requiring multi-factor authentication (MFA) or a compliant device has been applied to SharePoint or Exchange, this policy will also apply to users signing into Office.com.
<h2>Why?</h2>
This change addresses feedback we’ve gotten from customers who have noticed that some features break in Office.com when a policy is applied to Exchange or SharePoint. These include searching for documents and email, loading your customizations in the app launcher, creating new documents, and viewing your calendar.
These features access Exchange and SharePoint data, so they’re subject to Exchange and SharePoint policies. By requiring users to satisfy these policies when they access Office.com users will have access to Exchange and SharePoint data, so these features will continue to work.
<h2>What else do I need to know?</h2>
<ul>
<li>Any policies that have been applied to Exchange and SharePoint browser access will apply.</li>
<li>Policies set specifically for mobile and desktop applications will be skipped since Office.com is accessed through the browser. This applies to conditional access policies set through the Azure Management Portal, the “Classic” Azure Portal, and the Intune management portal.</li>
<li>Policies set using Office 365 MDM will not apply since they are targeted for mobile apps.</li>
<li>If a policy is set for Exchange and SharePoint, both policies will take effect when Office.com is accessed.</li>
</ul>
<h2>The impact</h2>
The main impact will be to users who use Office.com but have not already satisfied SharePoint and Exchange policies. In these cases, they can take the steps to satisfy policy or, in cases in which this is not an option, where users are attempting to access Office.com to install Office applications, they can do so from <a href="https://aka.ms/office-install">https://aka.ms/office-install</a>.
Overall, we believe this will improve the end-user experience on Office.com by keeping it consistent no matter how users are accessing the page. But we want to hear directly from you about how this change has impacted your users’ experience, so keep sharing your feedback with us!
Best regards,
Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/04/an-update-to-azure-ad-conditional-access-for-office-com/feed/</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>The new Azure AD Signin Experience is now in Public Preview</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/02/the-new-azure-ad-signin-experience-is-now-in-public-preview/</link> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/02/the-new-azure-ad-signin-experience-is-now-in-public-preview/#comments</comments> <pubDate>Wed, 02 Aug 2017 16:00:27 +0000</pubDate> <dc:creator><![CDATA[Alex_SimonsMS]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Authentication]]></category> <category><![CDATA[Cloud]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=54155</guid> <description><![CDATA[Howdy folks, We’re continuing to make progress on converging the Azure AD and Microsoft account identity systems. One of the big steps on this journey is to redesign the sign-in UI so both systems look consistent. Today I’m happy to announce that this updated design is in public preview! What’s changing: Redesign of Azure AD <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/08/02/the-new-azure-ad-signin-experience-is-now-in-public-preview/">Continue reading</a>]]></description> <content:encoded><![CDATA[Howdy folks,
We’re continuing to make progress on converging the Azure AD and Microsoft account identity systems. One of the big steps on this journey is to redesign the sign-in UI so both systems look consistent. Today I’m happy to announce that this updated design is in public preview!
What’s changing:
<ol>
<li>
<div>Redesign of Azure AD & Microsoft account sign-in experiences</div>
Azure AD & Microsoft account sign-in pages will both change to have a consistent look and feel, so you won’t experience anymore jarring transitions when you move between the two.</li>
<li>Pagination of the Azure AD sign-in page 
The new design prompts you to enter your username on the first screen followed by a credential (typically a password) on a second screen. We’ve done a lot of testing of this design and our telemetry shows that people are able to sign in with a notably higher success rate using this approach. It also sets us up to be able to easily introduce new forms of authentication like <a href="https://blogs.technet.microsoft.com/enterprisemobility/2017/04/18/no-password-phone-sign-in-for-microsoft-accounts/">phone sign-in</a> and certificate-based authentication.</li>
</ol>
Here are a few screen shots of this new experience:
Paginated sign-in flow (desktop view) 

<ul style="margin-left: 72pt">
<li>Username and password are collected on separate pages</li>
<li>This mock shows default branding – when no company branding is configured</li>
</ul>
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080217_0505_ThenewAzure1.png" />
Desktop UI (with company branding configured) 

<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080217_0505_ThenewAzure2.png" />
Mobile UI 

<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/080217_0505_ThenewAzure3.png" />
You might have noticed that we’ve been rolling out the new design on Microsoft accounts over the last few weeks. Now, it’s Azure AD’s turn. Starting today, you’ll see a banner on the Azure AD sign-in page giving users the option to opt-in to see the new experience. This is a great opportunity for you to do a few sanity checks:
<ol>
<li>
<div>Check to see that your existing company branding, if configured, works well with the new layout</div>
Any company branding you currently have configured will be carried forward to the new UI: sign-in image, banner logo, username hint, sign-in page text and background color. However, the opaque white box in the middle of the new design might obscure the subject focus of your existing image. If you need to make any changes, you can make them in the “Company branding” pane in the Azure Portal.</li>
<li>
<div>Verify automation that runs on the sign-in page</div>
Since sign-in is now done over two screens, any existing automation might break. Do a quick test and update your code if necessary.</li>
<li>
<div>Update documentation and training material 
</div>
Documentation containing screenshots and step-by-step guides for signing in might have to be updated to explain the paginated flow and show the new UI.</li>
</ol>
Note that there are still a few pages like MFA that will continue to show the old design. We’re working hard to bring the new design to these pages over the next few weeks.
We know that this will be a disruptive change for some of you, but we believe that this sets us up for an exciting future of innovation in the sign-in space. To give you time to prepare for the change, we’ll leave the new experience as an opt-in public preview for the next few weeks. We plan to switch over to the new UI by default during the last week of September.
Let us know if you have any questions, and as always, we’re looking forward to your feedback and suggestions. Head on over to the <a href="http://social.technet.microsoft.com/Forums/windowsazure/en-US/home?forum=windowsazureaditpro">Azure Active Directory Forum</a> to share your thoughts with us.
Best Regards,
Alex Simons (twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/08/02/the-new-azure-ad-signin-experience-is-now-in-public-preview/feed/</wfw:commentRss> <slash:comments>70</slash:comments> </item> <item> <title>New Public Preview: Azure AD Domain Services admin UX in the new Azure Portal</title> <link>https://blogs.technet.microsoft.com/enterprisemobility/2017/07/11/new-public-preview-azure-ad-domain-services-admin-ux-in-the-new-azure-portal/</link> <comments>https://blogs.technet.microsoft.com/enterprisemobility/2017/07/11/new-public-preview-azure-ad-domain-services-admin-ux-in-the-new-azure-portal/#comments</comments> <pubDate>Tue, 11 Jul 2017 16:00:25 +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 Cloud]]></category> <category><![CDATA[Public Preview]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/enterprisemobility/?p=53575</guid> <description><![CDATA[Howdy folks, I’m excited to announce the public preview of Azure AD Domain Services in the new Azure portal. You can now create new managed AD domains and perform administrative tasks like configuring secure LDAP using the Azure portal. If you follow the blog, you already know that Azure AD Domain Services is pretty cool. <a class="read-more" href="https://blogs.technet.microsoft.com/enterprisemobility/2017/07/11/new-public-preview-azure-ad-domain-services-admin-ux-in-the-new-azure-portal/">Continue reading</a>]]></description> <content:encoded><![CDATA[Howdy folks,
I’m excited to announce the public preview of Azure AD Domain Services in the new Azure portal. You can now create new managed AD domains and perform administrative tasks like configuring secure LDAP using the Azure portal. If you follow the blog, you already know that Azure AD Domain Services is pretty cool. It provides managed domain services like domain join, group policy, LDAP, and Kerberos/NTLM authentication, all fully compatible with Windows Server Active Directory.
What might surprise you is that over 8000 (!!) customers are already using Azure AD Domain Services today!
And qith this new public preview, we’ve made it even easier to create a managed AD domain using our brand-new wizard experience. The wizard knits tasks like creating virtual networks, configuring group membership of the delegated administrator group, and enabling domain services into a simple, intuitive, step-by-step experience.
<img alt="" src="https://msdnshared.blob.core.windows.net/media/2017/07/071117_0536_NewPublicPr1.png" />
<h2>Getting started</h2>
Here’s how to get started with the new Azure portal experience:
<ol>
<li>
<div>If Azure AD Domain Services is not enabled for your Azure directory <a href="https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-getting-started">Create a new managed domain</a> using the new Azure portal.</div>
</li>
<li>If you’ve already enabled Azure AD Domain Services for your Azure directory <a href="https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-contact-us">Contact us</a> via email to migrate your existing managed AD domain to the new Azure portal. From there, you can administer your existing managed AD domain using the new Azure portal.</li>
</ol>
<h2>Note: This public preview release supports only classic Azure virtual networks. We don’t support Resource Manager-based virtual networks yet, but the team is hard at work making that happen and we hope to preview it soon! 
</h2>
<h2>We want to hear from you!</h2>
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 simply comment below.
Best regards,
Alex Simons (Twitter: <a href="https://twitter.com/Alex_A_Simons">@Alex_A_Simons</a>)
Director of Program Management
Microsoft Identity Division
]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/enterprisemobility/2017/07/11/new-public-preview-azure-ad-domain-services-admin-ux-in-the-new-azure-portal/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> </channel> </rss>

Get Enterprise Mobility + Security free for 90 days

Try now

Aug	SEP	Oct
	10
2016	2017	2018

Protect your business with identity and access management in the cloud

Benefits of Active Directory

Single sign-on to any cloud and on-premises web app

Easily extend Active Directory to the cloud

Works with iOS, Mac OS X, Android and Windows devices

Protect sensitive data and applications

Protect on-premises web applications with secure remote access

Reduce costs and enhance security with self-service capabilities

Enterprise scale and SLA

Azure Active Directory applications: Featured apps

Box

Citrix

Citrix GoToMeeting

Concur

Docusign

DropBox for Business

Dynamics CRM

Facebook at Work

Google Apps

Jive

MyDay

Office 365 Exchange Online

Office 365 SharePoint Online

NetSuite

Salesforce

Salesforce Sandbox

ServiceNow

Workday

Azure Active Directory applications: New apps

Clockworks

FileCloud

Cezanne HR

Flat for Education

Insider Track

BGS Online

Nexonia

Proofpoint on Demand

Lifesize Cloud

Reward Gateway

Pacific Timesheet

Cisco Spark

Recognize

Yonyx Interactive Guides

Identity Panel

Hall Monitor

MediaValet

Origami Risk

Complion

Predictix

Mojo Helpdesk

SharpCloud Standard

Boost mobile productivity with secured access to applications

Save time with simplified identity management

AZURE ACTIVE DIRECTORY TEAM BLOG

Get Enterprise Mobility + Security free for 90 days

Follow us

Share this page