Improving Password Security In the Cloud and On-Premises

Posted on Leave a commentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:


Note all the below is what I currently know Microsoft do. This is based on info made public in June 2018 and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

Spring2018 = [spring] + [2018] = 2 points

Spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:


This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection 
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy does not support MFA for device join during the preview – you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.


Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}. Within this locations I see the AzureADPasswordProtection folder, containing three subfolders called Azure (empty), Configuration (initially empty) and PasswordPolicies (also initially empty).

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The following EventID’s have been seen:

  • DCAgent/30016: Forest registration has not happened yet
  • DCAgent/30001: The password for the specified user was accepted because an Azure password policy is not available yet.
  • DCAgent/30009: [audit mode] The password reset was allowed, but would have been rejected as the password used was on Microsoft’s block list
  • DCAgent/10014: Password compliant with the current Azure password policy
  • DCAgent/10015: The reset password for the specified user was validated as compliant with the current Azure password policy.
  • DCAgent/10017: Password reset rejected because it did not comply with the current Azure password policy
  • DCAgent/30016: The service is now enforcing the following Azure password policy along with the date/time stamp of the policy file it is using. This entry will state if audit or enforce mode is in play as well.


  • ProxyService/30000: A proxy registration message was sent to Azure and a successful response was received.
  • ProxyService/30001: A new proxy certificate credential was successfully persisted.
  • ProxyService/20000: A new password block list was downloaded.

Further log IDs and meanings can be found at

Once the proxy starts to work, the above empty folders begin to populate. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:


Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image or image

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:


It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.

Configuring Hybrid Device Join On Active Directory with SSO

Posted on 15 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, device, device registration, hybrid

The instructions from Microsoft at are missing some of the steps on setting up hybrid device join to Azure AD. This is a complete list of steps when Pass-Thru auth with SSO is enabled on the domain.

  1. Enable SSO – this is covered elsewhere. You can also do hybrid device join on a federated domain, though this is not covered here.
  2. On your AADConnect server ensure that the MSOnline PowerShell add in is installed – this is the AdministrationConfig-3.msi executable that is needed to run cmdlets like Get-MSOLUser. Is only supported by the MSOnline PowerShell module version To download this module, use this link
  3. Open an administrative PowerShell
  4. cd 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep'
  5. Import-Module .\AdSyncPrep.psm1
  6. This will enable the AD module and import some scripts for device writeback and device registration. We are looking at device registration here
  7. $aadAdminCred = Get-Credential

    #Enter a global admin credential

  8. Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred

    #[connector account name] is the name of your domain (domain.local for example) as shown in the AADConnect Synchronization Service Manager –

  9. You should see the message “Initializing your Active Directory forest to sync Windows 10 domain joined computers to Azure AD.” followed by “Configuration Complete”. Errors about Azure Registration mean you are running the wrong version of the Azure AD PowerShell cmdlets
  10. The required settings in AD (for one forest) are now done. If you have multiple forests, return to the above referenced document and run the script to register the Devices Registration Configuration node to AD
  11. If you have conditional access available (have at least one Azure AD Premium licence assigned to your admin account) then you can add Trusted Sites to Azure AD to control where MFA prompts for device join will happen outside of. Add each office public NATed IP address with /32 (or whatever is needed at the end) into Azure Active Directory (under > Conditional Access > Named Locations > New Location
  12. Add the same IPs to the “Configure MFA trusted IPs” link on the same page that you see the IP’s listed above
  13. Your list of devices under Azure Active Directory should now increase as users reboot Windows 10 1703 machines and later. See the above document about the GPO setting needed to role this out to older versions of Windows (Workplace Join settings)

Azure AD SSO and Disabled Computer Accounts

Posted on 5 CommentsPosted in Authentication, Azure Active Directory, Azure AD, Office, Office 365, SSO

When you set up Azure AD SSO, the Azure AD Connect application creates a computer account called AZUREADSSOACC. Do not disable this account, or SSO stops working.

I’ve had a few clients in the past week disable this when generally disabling all the computer accounts that have not logged in for X days.

Therefore if you have Azure AD SSO enabled, I suggest updating your documentation on disabling computer accounts – ‘cause not all computer accounts actually login as computers (I’m thinking Cluster services here as well) and consider actually whether or not disabling accounts for computers that are not logging in any more is necessary.

Then also take the AZUREADSSOACC account and set a description on it saying do not disable!


AADConnect Password Reset Date Sync Issues

Posted on 2 CommentsPosted in AADConnect, active directory, Azure Active Directory, Azure AD, sync error

Got this error the other day at a client and found nothing listed on Internet search for it, which of course means only I have this issue! But even so, lets get to see what it means and how to fix it.

The error turned up in the AADConnect tool and it reported sync-generic-failure on the Delta Synchronization stage when pulling data from Active Directory.

Error in evaluation of expression: IIF(IsPresent([pwdLastSet]),CStr(FormatDateTime(DateFromNum([pwdLastSet]),”yyyyMMddHHmmss.0Z”)),NULL) 
. Sync Rule: In from AD – User AccountEnabled
Destination: pwdLastSet

Following the above error was the entire stack dump of the issue (a few pages of errors) which are visible by clicking the sync-generic-failure link in AADConnect and clicking the Stack Trace button. Buried inside the stack dump are a few “InnerException” errors. These point out the real cause of the issue.

Argument 1 to function DateFromNum is out of range.


Not a valid Win32 FileTime.
Parameter name: fileTime

   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at SyncRuleExpressions.FunctionLibrary.DateTimeFunctions.DateFromNum(Value[] arguments)

This shows that the user in question (which is listed by DN in the stack dump) has an invalid value for the pwdLastSet attribute.

So we opened up the user and viewed the pwdLastSet value and it read -1

Now this value is valid – it is used in code and scripts to set this attribute to the current date and time, as normally this value is set by a script and so setting -1 means that you want the time for the last password set to be now.

In my clients domain either the script failed or something else did not work, and the property was set and stayed at -1 in the directory. Viewing this attribute in adsiedit showed it to be <never> and double-clicking this attribute showed the value to be -1.

In the end the fix was simple – we retyped -1 into the field in adsiedit and clicked OK. This time the attribute updated to the current date and time. Now that the attribute was a valid date/time, the AADConnect sync rule worked and the object was synced to Azure AD.

Azure MFA 503 Error When Authenticating

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

If you have installed version 7 of Azure MFA Server on-premises ( or at the time of writing) and have enabled IIS authentication with Forms Based authentication and the Native App, but when you need to authenticate you are presented with a 503 DLL error. The reason for this is that version 7 removed support for 32 bit Windows, but if the application pool in IIS for the website you are running is a 32 bit pool then the 64 bit DLL provided by MFA for authentication will not run. If you change the pool to 64 bit then the MFA authentication DLL will work, and your phone call/text or mobile app verification should occur. Of course, if you change the application pool to 64bit make sure that other DLLs used by the application are not 32 bit and so the application itself, rather than MFA, would not fail.

If the application is 32 bit and therefore the application pool needs to be using 32bit MFA DLL’s then you either need to upgrade your application to 64 bit or downgrade MFA Server to version 6.3. To obtain version 6.3 you need to raise a support call with Microsoft.

OU Filtering in AADConnect–What They Grey Boxes Mean

Posted on Leave a commentPosted in AADConnect, az, Azure Active Directory, Azure AD, dirsync, Office 365

So I had the chance to check this today. If you do OU filtering in the DirSync tools you will get an OU structure with various grey boxes in it. Here is an example:


It appears that both clip_image003and image are options in the sync tool. You get the first (grey with a tick ) if you select that box and untick some child objects. You get the second (grey box, no tick) if you unselect the parent and then individually select child OU’s.

If you do the second option (and get image)and then add a new OU under the parent it is not selected in the sync engine by default. Unfortunatly you cannot do this for the root of the domain during initial setup of AADConnect, as you need to select the domain in the provisioning wizard before unselecting OU’s). You can later go into the sync tool and change the domain to default unselected (image) by unselecting everything and then just selecting the OU’s you need. In this way you can be sure that later OU’s are not auto selected for syncing.

Remote Desktop And Login With AzureAD Account

Posted on Leave a commentPosted in Azure Active Directory, remote desktop

If you join a Windows 10 PC to Azure AD and then try and login to that PC over remote desktop you are in for a barrel of laughs! Or not!

The way to get it to work is as follows:

  1. Ensure that Windows 10 PC is running Version 1511 or later (type WinVer from the Run dialog)
  2. Ensure the target PC is enabled for Remote Desktop
  3. Ensure the Network Level Authentication is disabled
  4. Run MSTSC on your PC (the source) and enter the target PN name, your username (email address) and click Save As (which you will find under “Show Options”):
  5. Close the Remote Desktop Connection window without connecting.
  6. Open the saved RDP file in Notepad
  7. Add the following to the bottom of the text in Notepad as shows:


  1. In Notepad this appears as:
  2. Save the RDP file and then double-click it to connect. You will now be able to login with your AzureAD account over Remote Desktop
  3. If you cannot login, check the alternative name that your device uses for your user account. On the AzureAD joined computer, logged in as the target user, run “whoami” from the command line. It will report something like AzureAD\firstlast. You could try that value (both AzureAD and the name) as your username.

Upgrading Azure Multi-Factor Authentication Server

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

A new version of Azure MFA Server was released at the end of March 2016, version This provides an in place upgrade to the previous version This version is based on .NET 4.5 and not .NET 2.0, which is the big change in the product, along with new end user functionality in the ADFS Adapter. Note the upgrading the ADFS Adapter piece is prone to issues, which I have documented here.

This blog post just outlines the standard upgrade process. It takes about 10 minutes and the service is uninstalled and reinstalled, but leaves the database and settings in place – so it requires downtime or a load balancer. If you have more than one MFA server in a cluster then the older versions still running will still work for users but the administration screens are read only once at least one server is upgraded. All servers should therefore be upgraded in a short interval.

Before upgrading, take a copy of the “Program Files\Multi-Factor Authentication Server” folder as a backup is useful, especially if you have the ADFS Adapter installed as the service name has changed and that breaks ADFS Server.

Then, the following are just the sequence of screenshots from the installation (upgrade) so you know what to expect:

The old version has a 2013 splashscreen:


The MFA admin page points out that a new version is available:


Ensure you have the May 2014 Cumulative Update on your Windows Server 2012 R2 boxes (you ought to regardless of this prompt):


Visual C++ (x86 and x64) versions will be installed:







Then there follows a long pause of a good few minutes. Hang in there, the old software is still in place and running. The new installer will start shortly:



And complete in less time than you waited for the installation to start:


The service restarts and this machine is now running the 7.0… version

If you start the admin console you will see that it is copyright 2016:


You will also get prompts about upgrading any of the installed components. If you look in Programs and Features at this time you will see that there might be some components still on version 6.3.1:



You will also see that the admin portal is running mixed versions:


If you open the admin console on another node, you will be warned about the mixed versions:


As long as you upgrade all the components one after the other you should get no issues, so I don’t recommend an order for these components to be installed in, but I do not recommend leaving them not upgraded:



I also recommend installing the required components in advance, as that is quicker. For an upgrade you need to install ASP.NET45 under IIS Application Development in Server Manager. You will return here at the end to uninstall .NET 2/3.5 if appropriate.


When it comes to upgrading though, I do recommend you upgrade on component and then the next. Don’t start them all at once – though you will be prompted all at once to do this. So pick one, click Yes and wait for that to complete. It will take a few minutes for each installer to start, so be patient:


Note that the installer does not suggest the correct Application Pool for each component. So make sure you select the correct one each time.




Then move onto the next installer. If you closed the Yes/No prompt for each installer you can reach it via that area of the admin console:


Remember to set the Application Pool correctly as well:


Like the User Portal installer, there is not much to see so close the installer when finished. Ensure you are running the latest .NET updates as well though:


I have documented the ADFS Adapter upgrade on this post, as there are specific issues with it.

If once you have upgraded all the previously installed components, you visit Programs and Features you can see that the Mobile App is not upgraded. The mobile app is not installed via the admin console, so the console will not prompt about the install. To install the Mobile App run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi from C:\Program Files\Multi-Factor Authentication Server. You will need to start this installer from an administrative cmd prompt:


Again, change the Application Pool to the correct value for the application. It will show the Virtual Directory as well here, and unlike this example, this is recommended to be something easy to type on a mobile device. Upgrading the app does not recall the previous virtual directory name, and so you should ensure that you enter that here as well. If you upgrade it and do not change the Virtual Directory name then you need to uninstall it and reinstall it, but remember to copy the upgraded web.config from the virtual directory first. It contains the username and password of the SDK user account.


Upon completion of all nodes in the MFA cluster, the admin portal shows all versions the same:


Finally, note that though you may pick the Application Pools during the various installers, new pools with new names (starting ASP.NET v4.0) are created but not used. The old app pools are upgraded to .NET 4.0 and I recommend removing the unused pools at your convenience as both the unused and used pools are the same apart from in name:

image image


Password Writeback Errors

Posted on 9 CommentsPosted in Azure, Azure Active Directory, Group Policy, IAmMEC, Office 365, password

I had been struggling with password writeback testing and was coming across the following set of errors, and found that searching for them uncovered nothing online. So I wrote this blog to remind me and help you solve these issues. These errors are all visible in the Application log of the Event Viewer.

User Restrictions

The following error is because the user has “user cannot change password” option set in Active Directory:

EventID 33004: TrackingId: 7344da2c-ab9d-42ef-adea-4a17d07fdeb9, Reason: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName:, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

And also, as the second error generated:

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5716): ..\server.cpp(11139): 0x80230626 (The password could not be updated because the management agent credentials were denied access.)
Azure AD Sync 1.0.8641.0″


Group Policy Restrictions

Its possible that the errors you see for password writeback in the application log are due to restrictions on the user’s password that they have chosen. If the password is not complex enough then you get a warning in the password reset page the user is visiting in Azure, but you can also get this is a Group Policy restriction is in place even if you have set a strong password. The text in the error message in the Azure password change portal reads “This password does not meet your corporate password policy. Please make sure to use a mix of upper and lowercase letters, numbers, symbols, and to update your password to one that you haven’t used previously.”. Therefore though Azure accepted the passwords (original and new) the on-premises server rejected them with the following:

Event ID 33008: TrackingId: 3c8c78dc-9167-4286-9384-e2f0e777af87, Reason: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName:, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)


Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5236): ..\server.cpp(11139): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
Azure AD Sync 1.0.8641.0″

This of course seems self explanatory – your password is not complex enough for your rules on-premises but complex enough to get past the Azure initial checks that it imposes.


This error though is especially annoying in test scenarios where you have turned off all the complexity checks. To test why you are getting this error, first check its a password change error and not something else, and try and change the users password on-premises. You should get the same restriction. Then use the cmd prompt to check the password settings for the user.

</p> <p>net user username /domain</p> <p>

This will report the following:

User name                    user1
Full Name                    First Last
User’s comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            7/7/2015 3:19:00 PM
Password expires             Never
Password changeable          7/8/2015 3:19:00 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   7/8/2015 10:31:05 AM

Logon hours allowed          All

Local Group Memberships
Global Group memberships     *Domain Users
The command completed successfully.


In this example, notice the highlighted. Here there password minimum age requirement in Group Policy has been removed:


But the domain controller (after running gpupdate to force the change to the domain controller) still enforces a single day to allow the change to occur.

For test scenarios, modify group policy to 0 days (rather than not defined) and probably increase the max age from the suggested default of 30 days:


After running gpupdate, you get the following for the net user command:

Password last set            7/8/2015 10:42:05 AM
Password expires             Never
Password changeable          7/8/2015 10:42:05 AM

Now you should be able to change your password in Azure against an on-premises user.

Strong Password Required

In the password change portal, the user is required to enter a strong password regardless of any restrictions that you have on-premises. So even if you are testing and have removed all history and complex and renewal requirements for the password, Azure will ensure that a strong password of 7 or more characters is entered regardless of your on-premises policy. In fact, Azure does not know your on-premises policy for password restrictions and enforces its own in addition to the one you have.

You get errors in the portal that read “Strong password required. Combine at least three of the following: uppercase letters, lowercase letters, numbers, and symbols.”. You also cannot reset the password to the same and the errors you get look like the following options:

image image image image 


For completion of the blog, here is what you should see in the event log when it is working:

Event ID 31006: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordRequestStart, Details:

Event ID 31007: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordSuccess, Details: Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName:

Configuring Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 45 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[This blog post was last updated 5th October 2017 – added support to Exchange Hybrid for msExchDelegateLinkList attribute which was announced at Microsoft Ignite 2017 for the support of keeping auto-mapping working cross on-premises and the cloud]

[Updated 18th June 2017 in advance of the release of AADConnect version 1.1.553.0. This post contains updates to the below scripts to include the latest attributes synced back to on-premises including publicDelegates, which is used for supporting bi-directional sync for “Send on Behalf” of permissions in Exchange Online/Exchange Server hybrid writeback scenarios]

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available and in preview for some of the writeback types at the time of writing. This enabled objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features (apart from Exchange Hybrid writeback) require AADConnect and not and of the earlier verions (which will be actively blocked by the end of 2017 anyway). Install and run the AADConnect program to migrate from DirSync to AADSync and then in the Synchronization Options on rerunning the AADConnect wizard you can add all these writeback functions.

In all the below sections you need to grant permission to the connector account. You can find the connector account for your Active Directory forest from the Synchronization Service program > Connectors > double-click your domain > select Connect to Active Directory Forest. The account listed here is the connector account you need to grant permissions to.

SourceAnchor Writeback

For users with (typically) multi-forest deployments or plans or a forest migration, the objectGuid value in Active Directory, which is used as the source for the attribute that keys your on-premises object to your synced cloud object – in AAD sync parlance, this is known as the SourceAnchor. If you set up AADConnect version 1.1.553.0 or later you can opt to change from objectGuid to a new source anchor attribute known as ms-ds-consistencyGuid. To be able to use this new feature you need the ability for AADConnect connector account to be able to read ObjectGUID and then write it back to ms-ds-consistencyGuid. The read permissions are typically available to the connector account without doing anything special, and if AADConnect is installed in Express Mode it will get the write permissions it needs, but as with the rest of this blog, if you are not using Express Mode you need to grant the permissions manually and so write permissions are needed to the ms-ds-consistencyGuid attribute. This can be done with this script.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$ForestDN = "DC=contoso,DC=com"

$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd | Out-Null

Note that if you use ms-ds-consistencyGuid then there are changes required on your ADFS deployment as well. The Issuance Transform Rules for the Office 365 Relying Party Trust contains a rule that specifies the ImmutableID (aka AADConnect SourceAnchor) that the user will be identified as for login. By default this is set to ObjectGUID, and if you use AADConnect to set up ADFS for you then the application will update the rule. But if you set up ADFS yourself then you need to update the rule.

Issuance Transform Rules

When Office 365 is configured to federate a domain (use ADFS for authentication of that domain and not Azure AD) then the following are the claims rules that exist out of the box need to be adjusted. This is to support the use of ms-ds-consistencyguid as the immutable ID.

ADFS Management UI > Trust Relationships > Relying Party Trusts

Select Microsoft Office 365 Identity Platform > click Edit Claim Rules

You get two or three rules listed here. You get three rules if you use -SupportMultipleDomain switch in Convert-MSOLDomainToFederated.
Rule 1:
Change objectGUID to ms-DS-ConsistencyGUID
Rule Was:
c:[Type == “”]
=> issue(store = “Active Directory”, types = (“”, “”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
New Value:
c:[Type == “”]
=> issue(store = “Active Directory”, types = (“”, “”), query = “samAccountName={0};userPrincipalName,ms-DS-ConsistencyGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:


To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:


Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

If you have multiple forests, then you need add the SCP record for the tenant name in each separate forest. The above will do it for the forest AADConnect is installed in and the below script can be used to add the SCP to other forests:

$verifiedDomain = ""  # Replace this with any of your verified domain names in Azure AD
$tenantID = "27f998bf-86f2-41bf-91ab-2d7ab011df35"  # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"  # Replace this with your AD configuration naming context
$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:


And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:

Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector " - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector " - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null

#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for User Writeback

[This functionality is not in the current builds of AADConnect]

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:


Prepare for Windows 10 Registered Device Writeback Sync

Windows 10 devices that are joined to your domain can be written to Azure Active Directory as a registered device, and so conditional access rules on device ownership can be enforced. To do this you need to import the AdSyncPrep.psm1 module. This module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device sync:

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds 
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName 

To successfully run these cmdlets you need to have the latest version of the Microsoft Online PowerShell modules installed (the V1.1 versions, not the V2.0 preview). You can get these from (which in turn needs MSOL Signin Assistant from and the Windows Management Framework v5 from If you get errors in the above, make sure you have the correct version, download from above and try the scripts again.

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.