Active Directory (Anglais)

Marching into the future of the Azure AD admin experience: retiring the Azure classic portal

AD -

Howdy folks,

Since we announced General Availability of the new Azure AD admin center in May, it’s been used by over 800,000 users from 500,000 organizations in almost every country in the world. The new admin center is the future for administration of Azure AD.

For over a year, we’ve been listening to your feedback and working to improve the new portal and the new experience. And we’ve heard you loud and clear that we have too many portals, that you want a single place where you can manage identity and access for your organization. So, on November 30, we’ll be retiring the Azure AD admin experience in the classic Azure portal.

Moving all admin capabilities to the new admin center and retiring our classic portal experience is a key milestone in our efforts to simplify the admin experience for Azure AD.

Azure AD admin center: the present and future for Azure AD administration

Now, the Azure AD admin center is where you can go to find admin experiences for the latest and greatest Azure AD capabilities. By focusing on the Azure AD admin center, we can make our admin experiences more consistent, and easier to use. And we can deliver them faster.

At the moment, there are a few tasks that can still only be done in the classic Azure portal. Don’t worry, these capabilities will be added to our new admin experience in the next few weeks, well before November 30.

Azure Information Protection and Access Control Service

The Azure Information Protection (or AIP, formerly Rights Management Service) admin experiences will also be retired in the Azure classic portal on November 30, but can be found here in the new Azure portal.

To learn more about Azure Information Protection, read our documentation. To share feedback about Azure Information Protection, send an email to MSIPAppFeedback.

Additionally, after November 30, admin experiences for Access Control Services will be available at a different URL. We’ll communicate the details of that change soon.

Wrapping up

We hope you love using the Azure AD admin center! If you have questions about using or administering Azure AD, reach out to our engineering team and our community in our forum. And if you’ve got specific feedback on our admin portal experience, like bug reports or feature requests, post them in the ‘Admin portal’ section of our feedback forum.

Thanks for your continued feedback! It’s what guides us as we work to make the admin experience the best it can be for you. Keep sharing your thoughts we’re always listening.

Best Regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

Active Directory Access Control List – Attacks and Defense

AD -

Recently there has been a lot of attention and a few different blog posts (references at the end of the post) regarding the use of Discretionary Access Control List (DACL) for privilege escalation in a Domain environment. This potential attack vector involves the creation of an escalation path based in AD object permissions (DACLs). For example, gaining Reset Password permissions on a privileged account is one possible way to compromise it by DACLs path.

Although DACL permissions are not the easiest topic to cover in one post and should be digested slowly, there are examples of potential attack scenarios we want to share. The following blog tries to shed some light on the subject, present the possible escalation paths and suggest relevant mitigations.


  • Active Directory Access Control
  • Protected accounts and groups
  • Delegated permissions
  • ACLs-Only escalation path
  • Hybrid path
  • Takeaways

Microsoft Windows environment implements access control by assigning security descriptors to objects stored in Active Directory. A Security Descriptor is a set of information attached to every object and contains four security components. In this blog, we will focus on the object creator (which user owns the object) and the Discretionary Access Control List (DACL – which users and groups are allowed or denied access) components. The two others components are the SACL, which defines which users and groups access should be audited and the inheritance settings of access control information.

A DACL is a list of access control entries (ACE). Each ACE represents a security identifier (SID) which specifies the access rights allowed or denied for that SID. When an access request is performed to an object, the system checks the ACEs in a sequence until it finds one or more ACEs that match the SIDs in the requestors token, and either denies or allows the requested access.

Figure 1 The DACL (discretionary access control list) applied on an OU named New York. By default, permissions of Active Directory objects are controlled by the built-in security accounts (Users & Groups) and they populate most, if not all, of the Active Directory objects DACL. Those ACEs are usually inherited from the domain object itself (e.g. DC=atalab,DC=local).

Figure 2 – Access permissions of “Authenticated Users” applied on “user1” account object (e.g. CN=user1,DC=atalab,DC=local)

Among the domain accounts, the most attractive ones are the privileged built-in accounts, e.g Domain Admins, Enterprise Admins, etc. These privileged built-in accounts are protected by a mechanism, Security Descriptor propagation or SDProp in short, that enforces a secured ACL on the account objects in Active Directory. This enforcement is done in order to prevent unauthorized modifications to these privileged accounts.

Protected Accounts and Groups

Most of the privileged built-in accounts are considered protected accounts and groups. Each of the protected accounts object permissions are set and enforced via an automatic process. This process, named SDProp, ensures the permissions on the object remain secured.

Figure 3 – Default ACE’s in AdminSDHolder object – Windows 2012 R2

SDProp runs by default every sixty minutes. In every run, the permissions on the protected accounts are reset to match those of the AdminSDHolder container, located under the system container in the domain partition. The process applies its task recursively on all members of groups and disables inheritance on all protected accounts.

SDProp significantly reduces the potential attack vector against the privileged built-in accounts. However, there could be scenarios exposing the DACLs on non-built-in privileged accounts leading to potential escalation. Lets have a look at some of these scenarios.

Scenario 1: Delegated permissions

Active Directory allows an administrator to delegate permissions to regular domain accounts, e.g. user, group, computer, without adding the account to an administrative group. Commonly delegated permissions include Reset Password on user accounts, usually granted to helpdesk personnel, and the ability to add New Member to a group, often granted to the groups business owners. In addition, the owner of an object can modify permissions and delegate specific permissions to other users, for example, updating the title of a user account delegated to an HR service account.

When talking about theoffensive use of ACLs, adversaries may try to escalate privileges by abusing the delegated permissions and obtain access to accounts which have specific permissions on other AD objects.


  • A low-privileged account who has “Modify Group Membership” permissions on a help-desk group, may add any account to that group and effectively gain the same permission as the privileged group.
  • A helpdesk group which has the “Reset Password” permissions on an organization unit (OU) in the domain, will effectively gain full object control on the OU and all its child objects, as the OU permissions are inherited by its child objects (excluding objects protected by the SDProp process).

When the examples above are combined, they form a path. Attackers may use the path available after compromising the first account to gain permissions on multiple other objects. This ACL path will allow the attackers to escalate privileges to a privileged account which is not part of the accounts list that is protected by the SDProp mechanism.

However, an attacker wont be able to escalate privileges to privileged built-in accounts, as the ACLs on these accounts are protected by the SDProp mechanism.

Scenario 2: Changing the default ACL on the AdminSDHolder

Why would you change AdminSDHolder manually?To date, our team hasn’t found a solid reason.

You should be careful with changing the AdminSDHolder. The Exchange faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. More information can be found in the documentation,Appendix C: Protected Accounts and Groups in Active Directory.

If you have a good reason to change AdminSDHolder manually, please leave it in the comments below.

However, if you did change the DACL on the AdminSDHolder and added permissions to an additional user or group, you probably extended the domains attack surface. Thats because, with the new permission, there is an additional user or group that can manage the privileged built-in accounts. These accounts, which were granted permissions on the AdminSDHHolder, can be compromised, and often are less protected and monitored than the privileged built-in accounts. Once compromised, they can be used as the initial user in the ACL path to the privileged built-in account, e.g. a domain admin.

Rohan Vazarkar, Will Schroeder, and Andy Robbinsdid a great job with brining ACLs to the front, literally, with the announcement of BloodHound 1.3. Though the example in their blog post on how to plan an ACL-only attack path, ending as a domain admin may prove difficult in practice, due to the AdminSDHolder and SDProp, in case the permissions werent modified.

The hybrid path

However, the ACL attack path could be combined with other lateral movement scenarios. For example, an ACL attack-path could be used to compromise a helpdesk user, which in turn, can be used to connect to a server where a Domain Admin user is logged-in, then compromising the DA account.

Both attack surfaces in the hybrid path can be visualized in a graph and allow Blue Teams as well as Red Teams to map their Domain environments. BloodHound 1.3 is an open-source tool which uses a PowerShell script to collect the required data for creating the graph and graph theory to find potential attack paths. If you find a path with no obstacles, it probably leads somewhere.

ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.

Additional Resources

Advanced Threat Analytics is part of the Microsoft Enterprise Mobility + Security Suite (E3) or the Microsoft Enterprise CAL Suite (ECAL). Start a trial or deploy it now by downloading an Advanced Threat Analytics 90-day evaluation.

Ask questions and join the discussion with our team on the Microsoft Advanced Threat Analytics Tech Community site!

Simplifying transition from Hybrid MDM (ConfigMgr+Intune) to Intune standalone

AD -

We have heard repeatedly from our customers who are using System Center Configuration Manager connected with Microsoft Intune (hybrid MDM) that theyd like to move to a cloud-only experience with Intune on Azure. This experience brings many new benefits, such as large scale, unified admin console, RBAC, and more. To help customers easily transition, were introducing a new process of moving from hybrid MDM to Intune standalone.

Previously, the move from hybrid MDM to Intune standalone required a one-time authority switch that would move an entire tenant at once and force the admin to reconfigure all settings in Intune, including re-enrolling all devices. Our new approach will allow customers to move from hybrid MDM to Intune standalone in a more controlled manner without impacting end users. The new process consists of three parts: Microsoft Intune Data Importer, mixed authority, and an improved MDM authority switch.

Microsoft Intune Data Importer

One of the biggest hurdles with the process of moving from hybrid MDM to Intune standalone has been the need to recreate all the profiles, policies and apps targeted to users and devices. Microsoft Intune Data Importer is a new downloadable tool designed to automatically copy MDM data created in Configuration Manager to an Intune environment. Importable objects include configuration items, certificate profiles, email profiles, VPN profiles, Wi-Fi profiles, compliance policies, terms and conditions, and apps.

Because Active Directory (AD) groups can be synced to Azure AD groups, deployments for the imported objects can be imported if the user collections in Configuration Manager are based on AD groups. Deployments will appear as assignments in the Intune console.

Microsoft Intune Data Importer is available for download through GitHub. You can leave feedback for the tool there as well. We are continuing to add support for new settings, and your feedback will help us make improvements for future releases.

Mixed authority

The second big change in the migration process is what we refer to as mixed authority. Mixed authority allows admins to selectively migrate users from hybrid MDM to Intune standalone in a phased, controlled manner. This means that you can migrate some groups of users to Intune standalone while you continue to use hybrid MDM for the remaining users and devices. Once a user has been moved to Intune standalone, that user and all of their devices will be managed from the Intune on Azure console. You can then create and deploy policies, initiate remote actions, and enroll new devices as if this user were part of an Intune standalone environment. Tenant level policies, such as your iOS APNs certificate, will function for users and devices managed by both hybrid MDM and Intune standalone and will only be editable via the Configuration Manager console while in mixed authority mode.

With mixed authority, all tenants will use the Intune on Azure console and will not need to use the legacy Silverlight-based console for MDM management of migrated users. This new capability will be rolled out starting today. You will be notified through the Office 365 Message Center when your tenant is enabled for mixed authority. Note: the Silverlight-based console will still be required for tenants using the Intune PC client. Tenants using the Intune PC client will take longer to be enabled.

Putting it together

Microsoft Intune Data Importer tool and mixed authority are two pieces of the new migration strategy. We recommend running Microsoft Intune Data Importer first and making sure all policies and configurations are in place before migrating any users. If the policies targeted to a user are the same in both consoles, there will be no impact to the end user when they migrate.

Once you are satisfied with your testing in the Intune standalone environment, you will initiate the tenant MDM authority switch through the Configuration Manager console. Because of recent changes to the MDM switch, this will migrate any remaining hybrid MDM users. All of the policies and apps that were created in the Intune on Azure portal, as well as your tenant level policies, will be migrated and available for configuration in the Intune on Azure console. Enrolled devices will not be required to re-enroll.

We are really excited about the release of these new tools and cant wait for customers moving to Intune standalone to have a smoother, more predictable experience. You can learn how to use this new functionality in our detailed documentation.


Managed Service Identities and Azure AD: Helping Azure developers keep their secrets secret!

AD -

Howdy folks,

Just a quick note today! I am excited to announce a preview of a new integration between Azure and Azure Active Directory that is designed to make life easier for developers. It’s called Managed Service Identity, and it makes it simpler to build apps that call Azure services.

Typically, to call a cloud service you need to send a credential (i.e. an API key or the like) to authenticate your app. Managing these credentials can be tricky. They are, by definition, secrets! You don’t want them to show up on dev/ops workstations or get checked into source control. But they must be available to your code when your code is running.

So how do you get them there without anyone seeing them? Managed Service Identities!

Managed Service Identities simplifies solves this problem by giving a computing resource like an Azure VM an automatically-managed, first class identity in Azure AD. You can use this identity to call Azure services without needing any credentials to appear in your code. If the service you are calling doesn’t support Azure AD authentication, you can still use Managed Service Identity to authenticate to Azure Key Vault and fetch the credentials you need at runtime. Presto, no credentials in code!

You can read more about the Managed Service Identity preview on the Azure blog.

Happy coding!

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

Microsoft Intune provides support for iOS 11

AD -

Today, Apple announced the availability of iOS 11 (with public release scheduled for 9/19/2017) and were pleased to announce Microsoft Intunes support for this update. Apple began releasing developer and beta builds a few months back, and since then the Intune team has been busy working to ensure that all Intune MAM and MDM scenarios work seamlessly with iOS 11.

As you plan for this update within your organizations, you can have the confidence that all existing Intune and hybrid (Configuration Manager and Intune) capabilities will continue to work as expected when users upgrade to iOS 11. The only thing you need to do is ensure your users update to the latest version of the Company Portal, which is available now in the App Store.

App support for iOS 11

If your organization used the app wrapping tool or SDK to build your apps, be sure that you’ve updated them with the latest version 7.1.3. You can download the app wrapper and SDK here.

Intune App Protection policies, will continue to work for iOS 11, on apps that have been updated. The core Office Mobile apps have been updated, with the rest expected to be updated in the coming days. For more details on Office app updates, check out this Intune MAM support blog.

For more tips on iOS 11 support, visit the Intune product support blog.

Azure AD B2B Collaboration in Microsoft Teams

AD -

Howdy folks,

Today I am excited to let you know that we’ve just enabled Guest Access in Microsoft Teams, built on the B2B collaboration features of Azure AD!

You can now enable partner collaboration in Teams for interactions across chat, apps, and file sharing, all with the ease of use and enterprise-grade protection Azure Active Directory has long enabled for your employees.

Now anyone with an Azure Active Directory account in any organization can be invited as a guest user in Microsoft Teams!

Customers have already created more than 8 million guest users using the B2B features of Azure AD and we’re only getting started. Adding support for Microsoft Teams has been a top customer request, so we’re excited to turn on this new capability to keep the momentum going. I hope you’ll give it a try today!

So, go ahead, log in to Teams today and invite your partners to work with you.

And as always, connect with us for any feedback, discussions, and suggestions. You know were listening!

Best Regards,

Alex Simons (@Twitter:@Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

P.S.: We are already working to add additional Azure AD capabilities in Teams, including support for external users with any corporate or consumer email account. Look for more news on that soon!

Azure Active Directory Premium is now in limited preview in US Government Cloud

AD -

Howdy folks,

Today I’m happy to announce the limited preview for Azure Active Directory Premium on the US Government Cloud.

With this preview, Government customers will have the opportunity to explore Azure Active Directory Premium in the US Government Cloud. This preview is for customers that have specific compliance needs (e.g., FedRAMP or DoD requirements), and while certifications aren’t in place yet, we plan to have them in place for General Availability.

Getting started

To gain access to this limited preview, just complete our onboarding survey and someone from our engineering team will connect with you to discuss next steps.

We know you probably have questions, and we’ve tackled a few of the big ones below.

Pricing and licensing

The Azure Active Directory Premium for US Government Cloud is free during this preview period. We will announce pricing details as we get closer to General Availability.

Is there a preview for other EMS services?

This preview is currently limited to Azure Active Directory Premium. Other EMS services are not currently in preview. We’re planning to conduct additional previews in the future and will be sure to announce them as they’re rolled out.

Where I do learn more about Azure for Government?

To learn more about Azure for Government, take a look at the Azure Government Cloud blog, Azure Government website, and our “Welcome to Azure Government” docs page. To learn more about Microsoft’s stance on compliance accreditations and regulations, please visit the Microsoft Trust Center.


We look forward to hearing your feedback! If you have any suggestions for us, questions, or issues to report, please leave a comment at the bottom of this post, or tweet with the hashtag #AzureAD.

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

How we secure your data in Azure AD

AD -

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, 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 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 Privileged Access Workstation guidance). 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.

Threat detection

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:

  • 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!
  • 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.
  • 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.

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.

A final note

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

Now Available: Cumulative Update 6 for Configuration Manager UNIX and Linux clients

AD -

Cumulative Update 6 (Build 5.0.7958.2432) is now available at this Download Center link. This update contains new full versions of the UNIX and Linux clients with numerous bug fixes, as well as support for new Linux distro versions, such as Ubuntu 16.04. Additionally, support for certain very old UNIX and Linux versions that are no longer supported by their vendors has been removed, including IBM AIX version 5.3, Oracle Solaris version 9, HP-UX on PA-RISC hardware, HP-UX version 11iv2, and SUSE Linux Enterprise Server version 9. Customers who are using Configuration Manager with these unsupported UNIX and Linux versions can continue to run the existing Cumulative Update 5 (Build 5.0.7958.1254) clients.

The CU6 version can be installed as an upgrade to existing clients using the -keepdb option as documented here (System Center 2012 and 2012 R2 Configuration Manager) and here (System Center Configuration Manager current branch).

CU6 is for use with the following versions of Configuration Manager:

  • System Center 2012 Configuration Manager Service Pack 2
  • System Center 2012 R2 Configuration Manager Service Pack 1
  • System Center Configuration Manger (current branch and LTSB) – all supported versions

Azure Information Protection Documentation Update for August 2017

AD -

Hi everybody

Our technical writer, Carol Bailey, is letting you know whats new and hot in the docs for August.

Reminders: Follow us on Twitter (@DanPlastina) and join in our peer community

Dan (on behalf of the Information Protection team)

The Documentation for Azure Information Protection has been updated on the web and the latest content has anAugust2017(or later) date at the top of the article.

Updates this month support the recent service updates, and information about the current preview version of the Azure Information Protection client. With the changes to activation, the default policy and default templates, and setting permissions for protection, the Quick start tutorial has been updated to reflect these changes. Let us know how you get on with the updated instructions! We always listento your feedback, which is why the documentation updates also include corrections and clarifications for existing features.

We value customer feedback and try to incorporate it whenever possible. If you have feedback about the documentation, you can contact us by emailing

What’s new in the documentation for Azure Information Protection, August 2017

Documentation articles that have significant technical changes since the last update (July 2017):

Quick start tutorial for Azure Information Protection

– This tutorial has been updated to use the Azure portal for activation, and creates a new sub-label that you configure for permissions. Previous versions of the tutorial edited an existing sub-label and linked one of the default templates to configure the protection settings.

How does Azure RMS work? Under the hood

–Updated the cryptographic controls section, to clarify that Azure Information Protection supports key lengths of 1024 bits and 2048 bits.

Migrating from AD RMS to Azure Information Protection
– Updated guidance if you are currently running in cryptographic mode 1. The final step is also updated for rekeying if you have a Microsoft-managed key.

Activating Azure Rights Management

– Updated to remove the instructions for activating by using the Azure classic portal now that the option to do this in the Azure portal is no longer in preview.

The default Azure Information Protection policy

– Updated the current default policy with the information that starting August 30, label names and descriptions now include translated versions. For the Recipients Only sub-labels, the previous Do Not Forward protection option is automatically replaced with the user defined permissions for Do Not Forward in Outlook.

How to configure a label for Rights Management protection

– Updated for the new (preview) option for user defined permissions, and the Edit Template button.

Hold your own key (HYOK) requirements and restrictions for AD RMS protection

– Updated the additional limitations section to clarify the Do Not Forward entry, and added a new limitation for user defined permissions when this new preview option is configured for Word, Excel, PowerPoint, and File Explorer.

How to configure a label for visual markings for Azure Information Protection
– Updated to clarify when visual markers get applied for the current GA version of the client, and the current preview client. Also updated with the information that visual markers support one language only, and that the current preview client supports multiple lines of text for visual markers.

How to configure conditions for automatic and recommended classification for Azure Information Protection

– Updated for the new previewoptions for information types and regular expressions.

Configuring and managing templates for Azure Information Protection

– Updated with the information that you can now edit the default templates, and information about when you can select the new Edit Template button.

Configure labels and templates for different languages in Azure Information Protection

– Updated to include templates.

Installing and configuring the Azure Rights Management connector

– Updated to include information about the installation log.

Microsoft-managed: Tenant key lifecycle operations
– Updated therekeysection to replace the previous instructions now that you canuse PowerShell to rekey your tenant key and no longer have to contact Support for this key management operation.

Azure Information Protection client administrator guide
– Updated the .msi prerequisites for Office 2013 and added a new prerequisite for Office 2016. Also added a link to the client languages that Office supports.

Classify and protect a file or email by using Azure Information Protection

– Updated the instructions for setting custom permissions when you usethe current preview client and browse for users and groups. This option uses the Select Users or Groups dialog box for your on-premises Active Directory. To use this option, your computer must be connected to the internal network, your computer must be joined to the domain, and you must have an on-premises Active Directory.


– This cmdlet from the AzureInformationProtection module (and the equivalent from the RMSProtection module) is updated to correct the information about the -LogFile parameter.



Changes to the Token Lifetime Defaults in Azure AD

AD -

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 following defaults will now apply to all new Azure AD Tenants:

  • Refresh Token Inactivity: 90 Days
  • Single/Multi factor Refresh Token Max Age: until-revoked
  • Refresh token Max Age for Confidential Clients: until-revoked

It’s important to note that these new defaults will only apply to new tenants and that if you want to override these settings with your own custom setting, you can do that.

Why now?

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.

What do these lifetimes control?

To understand the lifetimes and the changes we’ve made, it’s important to understand the basics of tokens issued by Azure AD.

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.

Refresh token inactivity

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

Single/multi-factor refresh token MaxAge

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.

Refresh token MaxAge for confidential clients

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

Can I change/revert these settings?

You can use the configurable token lifetimes feature to control these lifetimes.

To specifically revert the lifetimes in your tenant to their previous values, follow the guidelines below.

Set defaults in tenant to older values

If you are new to Azure AD, we recommend you learn how to get an Azure AD tenant before you proceed.

To get started:

  1. Download the latest Azure AD PowerShell Module Public Preview release.
  2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:

    Connect-AzureAD -Confirm

  3. To create the policy, run the following command:

    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”

How can I revoke refresh tokens?

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:

  1. Download the latest Azure AD PowerShell V1 release.
  2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:


  3. Set the StsRefreshTokensValidFrom parameter using the following command:

    Set-MsolUser -UserPrincipalName <UPN of the User> -StsRefreshTokensValidFrom (“<current date>”)

Let us know what you think!

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: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

Today’s Identity News: Improvements to Azure AD Connect Health sync error reporting

AD -

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: @Alex_A_Simons)

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!



Many of you may know about the Azure AD Connect Health 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 reports about synchronization errors that might occur while syncing data from on-premises AD to Azure AD using Azure AD Connect.

So, what’s new?

In this short post, we wanted to make three key announcements about sync error reports:

  1. Accessing the sync error report does NOT require Azure AD Premium.

  1. The sync error report now includes errors due to the Duplicate Attribute Resiliency feature.

  1. We’ve added a dedicated category for the “FederatedDomainChange” errors.

To view the report, upgrade to the latest version of AAD Connect (also works with version or higher) and then simply navigate to the Azure AD Connect Health Dashboard.

That’s great! Tell me more…

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 Duplicate Attribute Resiliency feature. 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, is changed to, 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

Thank you,

The Azure AD Connect Health Team

Azure Information Protection Status Update – August 2017

AD -

Hi Everyone, and welcome to this months posting from the AIP team to ensure you always know what we are working on, whats in the current releases of AIP and any other information that we can include to help you stay current.

With that, I will hand over to Adam Hall who leads our Customer and Partner Experience team.


Hello again to our Azure Information Protection community! We encourage you to visit last months Azure Information Protection Status update in case you missed it, and of course were listening to your feedback and feature requests. Speaking of which, its been a busy month with updates for admins and developers, so lets take a look.

For Admins:

  • We also fixed some bugs:
    • Disallow creation of templates with same name, that cause customers to see templates with _0 suffixes.
    • Performance fix for signup
  • The current GA client is
  • The latest Preview client now posted is
For Developers:
  • New in the RMS 4.2.5 SDK for Mobile
    • Improved performance for Android and iOS SDK
    • Bitcode support in iOS SDK
    • Telemetry interface
  • New integrations underway using AIP PowerShell or RMS 2.1 SDK
    • Sailpoint Secure IQ integration
    • Teradact for document redaction
  • Microsoft Information Protection SDK

These updates were heavily influenced by your great feedback. Your feedback allowed us to ship new features, verify bug fixes, and generally improved our product. We thank you for this ongoing engagement!

Upcoming milestones:

Other things to be aware of:

  • The RMS Protection tool is moving to End Of Life on February 10, 2018. This functionality is replaced by the Azure Information Protection client.

As we let you know previously, we have adopted UserVoice as a platform for you to tell us what we should be working on, and I would ask and encourage you all to take a look and place your votes to help us understand the priorities you have.


We hope this helps you with your testing, planning, and deployments and we welcome your commentary and feedback. We also know this can be a lot to absorb, and we are here to help! Engage with us on Yammer or Twitter and let us know whats important to you by voting on UserVoice!

It really is very easy to get started with AIP. We have a lot of information available to help you, from great documentation to engaging with us via Yammer and e-mail. What are you waiting for? Get to it!

Thank you,

Dan Plastina on behalf of our enthusiastic Azure IP team.
Twitter: @DanPlastina
Useful links: (PDF)

New public preview: Azure AD Domain Services support for Azure Resource Manager virtual networks

AD -

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. Learn more about Azure Resource Manager. 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 we previewed recently.

Getting Started

Here’s how to get started with the preview:

  1. If Azure AD Domain Services is not enabled for your Azure directory Create a new managed AD domain using the Azure portal. Be sure to select ‘Resource Manager’ as the virtual network type.

  2. 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.
    1. 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.
    2. 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.

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.

The Road to GA

We have quite a bit of work still to go before we can GA this feature. The two biggest remaining are:

  1. 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.

  2. 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.
We want to hear from you!

As always, your feedback is very important to us! Please share your comments, questions, or concerns on our discussion forum, send us an email at, or comment below. We’re listening!

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

Webinar: Find out how Check Point’s threat intelligence enhances EMS’ device based conditional access

AD -

Join us for a webinar to find out how the combined power of Microsoft Intune and Check Points Sandblast mobile helps you secure mobile devices from advanced cyberthreats, and helps ensure that only compliant devices have access to company resources.

Heres what well cover:
  • SandBlast Mobiles comprehensive mobile threat defense capabilities that help you stay secure from advanced mobile threats, including: malware attacks via infected apps, Man-in-the-Middle attacks on compromised Wi-Fi networks and hotspot logins, exploitation of operating systems for rooting and jailbreaking, and malicious links sent on SMS messages.
  • Well also review EMS approach to managing mobile productivity and our conditional access capabilitieswhich ensure that only the right users under the right conditions have access to your data and resources.
  • And finally, well look at the inner workings of this integration which will cover an overview of the admin experience and the technical exchange between the services, as well as a review of the end user experience.
Register today

This webinar will be presented by experts from both the SandBlast Mobile and EMS teams. Click the links below to register:

Americas: Wednesday, September 13 10:00 am (PT) Europe + Asia: Wednesday, September 13 10:00 am (CEST)

Update 1708 for Configuration Manager Technical Preview Branch – Available Now!

AD -

Hello everyone! We are happy to let you know that update 1708 for the Technical Preview Branch of System Center Configuration Manager has been released. Technical Preview Branch releases give you an opportunity to try out new Configuration Manager features in a test environment before they are made generally available. This month’s new preview features include:

  • Restart computers from the admin console – You can now restart a computer with a client notification action for devices.
  • Create and run scripts with optional parameters – You can now create and run scripts with optional parameters to devices and collections.
  • Software Center Customization – You can add enterprise branding elements and specify the visibility of tabs in Software Center. You can add a Software Center specific company name, set a color theme, set a company logo, and set the visibility of tabs for client devices.
  • Management Insights – You can gain valuable insights into the current state of your environment based on analysis of data in the site database.

Update 1708 for Technical Preview Branch is available in the Configuration Manager console. For new installations please use the 1703 baseline version of Configuration Manager Technical Preview Branch available on TechNet Evaluation Center.

We would love to hear your thoughts about the latest Technical Preview! To provide feedback or report any issues with the functionality included in this Technical Preview, please use Connect. If there’s a new feature or enhancement you want us to consider for future updates, please use the Configuration Manager UserVoice site.


The System Center Configuration Manager team

Configuration Manager Resources:

Documentation for System Center Configuration Manager Technical Previews

Try the System Center Configuration Manager Technical Preview Branch

Documentation for System Center Configuration Manager

System Center Configuration Manager Forums

System Center Configuration Manager Support

Download the Configuration Manager Support Center

Azure AD and Intune now support macOS in conditional access!

AD -

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:

  • Enroll and manage macOS devices using Intune
  • Ensure macOS devices adhere to your organization’s compliance policies
  • Restrict access to applications in Azure AD to only compliant macOS devices

Get started with macOS conditional access public preview in two simple steps:

Configure compliance requirements for macOS devices in Intune

Use the Intune service in Azure Portal to create a device compliance policy for macOS devices in a few easy clicks:

Configure compliance requirements for device health, properties, and system security per your organization’s requirements.

For more details, go to

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

Restrict access to Azure AD applications for macOS devices

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.

For more details on conditional access policies, go to Conditional Access in Azure Active Directory.

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.

Supported OS versions, applications, and browsers

In the public preview, the following OS versions, applications, and browsers are supported on macOS:

Operating Systems

  • macOS 10.11+


The following Office 2016 for macOS applications are supported:

  • Outlook v15.34 and later
  • Word v15.34 and later
  • Excel v15.34 and later
  • PowerPoint v15.34 and later
  • OneNote v15.34 and later


  • Safari

Try it out today and let us know what you think! We look forward to hearing from you.

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

Microsoft Intune provides support for Android Oreo

AD -

Upgrade with confidence

Today Google announced the general availability of the Android Oreo update (also known as Android O or Android 8.0). The Intune team has been anticipating this day for months. Developer preview bits for Oreo first became available back in March 2017, and since then weve been kicking the tires on it, flashing it onto our test devices, integrating it into our test suites, and testing it under MDM and MAM scenarios. We always make day 0 support for new versions of operating systems a priority, and we are happy to announce that Intune has day 0 support for Android O.

You can be confident that once your users upgrade to the released version of Android O, Intune’s device and app management features will continue to work seamlessly. This applies to all facets of Android management with Intune including work profile management, non-work profile management, and App Protection Policies. The only thing you need to do is update to the latest version of the Company Portal, which is available now in the Google Play Store.



A few things have moved or changed with this update. For more details on these changes check out our support blog.

Looking forward

This past year has been busy for the teams within Intune developing Android solutions, with the introduction of support for work profiles (Android for Work) as well as continued work on the ecosystem of Microsoft and third-party apps that support App Protection Policies. Well continue to work closely with the Android Enterprise team to ensure Intune delivers the best Android platform experience possible for our customers.

Role Based Access Control: A Configuration Manager favorite, now in Intune

AD -

Role Based Access Control (RBAC) has been a favorite feature of the System Center Configuration Manager community since its introduction, and now its available in Intune. RBAC in Intune enables you to easily define who can perform various Intune tasks within your organization, and who those tasks apply to. RBAC gives you greater flexibility and control while ensuring your IT administrators have the necessarypermissions to perform their job.

Integration with Azure AD Directory Roles for high level access control

The new Intune admin experience on Azure delivers deeper levels of integration with Azure Active Directory, which includes Azure AD Groups as well as integration with Azure AD Directory Roles. This integration provides the underpinnings of Intunes RBAC capabilities and our overall permissions management story. RBAC for Intune starts by leveraging four Azure AD Directory Roles that define high level administrative access to Intune workstreams and tasks:

  • Global Administrator / Company Administrator: users in this role have access to all administrative features in Azure AD, including conditional access. They can also manage all of Intune.
  • User Administrator: users in this role can manage users and groups but cannot manage all of Intune.
  • Intune Service Administrator: users in this role can manage all of Intune, including management of users and devices, as well group creation and management. This role does not allow for management of Azure ADs Conditional Access settings.
  • Conditional Access Administrator: users in this role can manage Azure ADs Conditional Access policies, but not all of Intune.
Intune Roles for finer-grained control based on job function

From there you can define finer-grained controls by leveraging built-in Intune roles, which are designed to mirror your IT Departments job functions. There are five pre-defined roles built into Intune:

  • Policy and Profile Manager: users in this role have rights to manage configuration and compliance policies.
  • Application Manager: users in this role have rights to manage mobile and Intune managed app protection policies.
  • Helpdesk Operator: users in this role have rights to manage tasks appropriate for end-user service desk support personnel.
  • Read Only Operator: users in this role have rights to view Intune information without the ability to change configurations and policies.
  • Intune Role Administrator: uses in this role have rights to manage of Intune Roles.


You can also create custom roles with any permissions required for a specific function. For example, if an IT department group manages applications, policies and configuration profiles, you can add all of those permissions together in one custom role.

And if youre into automation you can automate any RBAC task such as creating custom roles, or adding/modifying role assignments using the Microsoft Graph API. We also have a set of PowerShell scripts that can help you get started.

Get started using RBAC in Intune today

For more detail on our RBAC story and how to get started using it in your Intune admin experience on Azure, check out this blog post from Dave Randall, the Program Manager responsible for RBAC in Intune. Daves post includes step by step screenshots that walk you through the capabilities, and shows you how granular you can get with defining access for roles.

RBAC gives IT administrators a simple way to enable powerful control over who can perform various administrative tasks within their organization and they are available to use today in our new admin experience on Azure.

Update on new Cloud App Security discovery, investigation, and threat detection features

AD -

We believe in continuous innovation to bring you deeper visibility, better data control, and strong threat protection for your cloud apps. The Cloud App Security team provides frequent releases and continuously updates and enhances our solution.

Today, we would like to share enhancements in discovery, investigation, and threat detection features with our recent release:

Automatically upload any log format for discovery analysis

We have been supporting custom log formats, and thanks to your input, we have now embedded it into our log collectors and automated log upload functionality. This means now you can easily use custom log formats for automated log uploads, for instance from your SIEM or any other custom log format you use.

View and Investigate user activity in cloud apps with a special focus on IP addresses

Extending our previously released user insights, you can now view detailed information about IP addresses in the Activity Drawer. From within each specific activity, you can click on the IP address tab to view consolidated data about the IP address, including the number of open alerts for the specific IP address, and a trend graph for the recent activities together with a location map.

For example, while investigating impossible travel alerts, you can easily understand where the IP address was located and whether it was involved in suspicious activities or not.

You can also perform actions directly in the IP address drawer that enable you to tag an IP address as risky, VPN, or corporate to enable investigation and policy creation. For more information please see IP address insights at our technical documentation site.

Gain enhanced visibility into Salesforce activities

More visibility into Salesforce objects such as leads, accounts, campaigns, opportunities, profiles, and cases allows configuration of a policy based on these objects. An example would be to create an alert when a user views an unusually large number of account pages. This is available through the Salesforce App Connector, when you have enabled Salesforce Event Monitoring (part of Salesforce Shield).

For more information regarding our releases, please refer to our release notes.

Your feedback is key to our product development process. If you have questions, comments or feedback, please leave a comment below or visit our Microsoft Cloud App Security Tech Community page.


S'abonner à Philippe BARTH agrégateur - Active Directory (Anglais)