Saturday, May 14, 2016

New Version of AADConnect–Version

Source -

A new version of AADConnect (version is available as of today.

Released: 2016 May

New features:

Fixed issues and improvements:

  • Added filtering to the Sync Rule Editor to make it easy to find sync rules.
  • Improved performance when deleting a connector space.
  • Fixed an issues when the same object was both deleted and added in the same run (called delete/add).
  • A disabled Sync Rule will no longer re-enable included objects and attributes on upgrade or directory schema refresh.

Read more at source -

Tuesday, May 10, 2016

Azure Identity Protection

Source -

The Identity Protection team is responsible for preventing hackers and cyber criminals from getting access to user accounts in the Microsoft account (MSA) and Azure Active Directory (Azure AD) services. We safeguard hundreds of millions of unique users across more than 13 billion logins every day.

As a lot of you know, a number of articles were published last week about a Russian hacker offering 272.3 million stolen usernames and passwords. This has received a lot of press coverage so we thought you might be interested to learn how we handle these lists when we discover them.

The first thing to understand is that the vast majority of stolen credentials are acquired when a hacker breaches a vulnerable website that stores passwords in plaintext or uses weak encryption or hashing practices. (Stolen usernames and passwords are also commonly acquired in phishing attacks or malware.) The second thing to understand is that many people use the same username and password with multiple sites.

Taken together, this means that when someone else’s services are hacked, it can put accounts with the same username and password in our system at risk.

Because these kinds of breaches and attacks happen quite frequently, we’ve built a standard set of processes and automated services to make sure our users are always protected.

We discover stolen credentials in a bunch of different ways. Mostly our machine learning systems and algorithms find them before any disclosure, but we also find lists by working with local and national governments, industry partners, security researchers and academic institutions all around the world. We also work closely with Microsoft Digital Crimes Unit, Security Response Center, The Office365 team, The Xbox team and many others who contribute to Microsoft’s Intelligent Security Graph and use the combined results to detect and stop attacks.

When we discover a new list of usernames and passwords, we run them through an automated system that checks to see if any of the credentials match those in our MSA or Azure AD systems by comparing the hashes of the submitted password to the hashed password stored with the actual accounts. The good news is that, most of the time, the credentials passed around by criminals don’t match any accounts in our services because the data in this lists is fabricated or out of date.

For this particular list, 9.62% of the usernames matched an account in our systems. And of those, only 1.03% had a matching password. So overall less than 0.1% of the list had a valid match for username and password in our systems.

But remember, our machine learning systems and algorithms find and automatically protect most compromised credentials before any disclosure. In this case, we had already protected 58.3% of that 0.1% because we had already caught an invalid access attempt or other suspicious activity!

The result? Of all the accounts in this list, 0.042 % of them were actually at risk.

Once we’ve identified the subset of accounts that are vulnerable, our automated mitigations kick in to protect them.

In the case of consumer accounts in MSA, the account is marked as being at risk. The next time the rightful account owner logs in, we interrupt them, require that they verify their identity with a second factor, and then require them to change their password.

It looks like this:

In the case of business accounts in Azure AD, the Azure Active Directory Identity Protection service – currently in public preview – gives corporate IT administrators the option to use the same kinds of automated mitigation policies for their user accounts in Azure AD.

The Azure AD user experience looks like this (note the Wingtip Toys brand here is a placeholder logo):

The cool thing about this is that when we detect a user’s password is compromised, Azure AD admins can have the account automatically locked down and protected before the bad guy can ever use the credentials – just like we do for our Microsoft consumer accounts in MSA.

Here’s a screen shot of the admin console in Azure AD Identity Protection, where admins can see their users at risk:

Drill into specifics:

And set policies to automatically remediate users we find at risk:

Last week, Alex Simons mentioned in this blog that Microsoft had just published our 20th Security Intelligence Report. In that report we explained that we detect more than 10 million credential attacks every day across our identity systems. This includes millions of attacks every day where the username and password are correct, but we detect that the person attempting to log in is a cyber-criminal.

So while 33 million Hotmail username/password pairs in the wild is definitely important to us, it is a relatively small volume, less than half of what we process in an average week, and a drop in the bucket compared to the more than 4
billion credentials we detected being attacked last year.

We hope this helps you understand how those articles you saw relate to your identity security – and how we’re using credential lists (and a lot of other signals) to keep your account safe.

And hey – if *you* ever want to contribute compromised credentials you’ve found, or any other security issue, is the right place to begin the process of reporting them and beginning a secure transfer. But please, don’t send us creds in email! Once we get your contact info we’ll work with you to make appropriate arrangements.

Read more at source -

Thursday, May 5, 2016

Advanced Threat Analytics new version 1.6 is now available

Source -

We really love and are proud of what we do: we continue to innovate in order to help you identify advanced persistent threats (APTs) and insider threats in your network before they cause damage. As of today, we are glad to share that Advanced Threat Analytics (ATA) is monitoring over 5 million users and 10 million devices!

I want to personally thank our customers and community for your interest with our solution and more importantly making the leap from the traditional security approach to User and Entity Behavioral Analytics (UEBA) with our solution. Your feedback and input have been essential to our product development.

Today, we are proud to announce that ATA’s new version (1.6) is publicly available. With this blogpost, I would like to share detailed information about this update and explain the exciting new enhancements our team developed.

As pioneers of the UEBA market, we set the bar very high and we are introducing exciting new capabilities and innovation:

  • New detections such as
    • Pass-The-Hash, Brute Force and others based on unusual protocol behavior
    • Elevation of privileges
    • Reconnaissance via Net Session enumeration
    • Compromised Credentials via Malicious DPAPI Request
    • Compromised Credentials via Malicious Replication Requests
  • New deployment option with the ATA Lightweight Gateway helping with branch sites and IaaS deployments
  • New and improved detection engine that significantly improves our performance and scale
  • Support for automatic updates and upgrades using Microsoft Updates
  • Improvements in third party integration to enrich detection

New Detections

Attackers are constantly evolving and improving their Tactics, Techniques and Procedures (TTPs). This is why one of our focus areas is detecting advanced attacks that are being used “in the wild”. Let’s take a look at some of the new detections we have:

Reconnaissance via Net Session enumeration: Reconnaissance is a key stage within the advanced attackers’ kill chain. Domain Controllers (DCs) function as file servers for the purpose of Group Policy Object distribution, using the SMB (Server Message Block) protocol. As part of the reconnaissance phase, an attacker can query the DC for all active SMB sessions on the server, allowing the user to gain access to all the users and IP addresses associated with those SMB sessions. SMB session enumeration may be used by attackers for targeting sensitive accounts, helping them move laterally across the network.

Compromised credentials via Malicious Replication Request: In Active Directory (AD) environments replication happens regularly between Domain Controllers. An attacker may spoof an AD replication request (sometimes impersonating a Domain Controller) allowing the attacker to retrieve the data stored in AD, including password hashes, without utilizing more intrusive techniques like Volume Shadow Copy.

Compromised Credentials via Malicious DPAPI Request: Data Protection API (DPAPI) is a password-based data protection service. This protection service is used by various applications that store user’s secrets, such as website passwords and file-share credentials. In order to support password-loss scenarios, users can decrypt protected data by using a recovery key which does not involve their password. In a domain environment, attackers can remotely steal the recovery key and use it to decrypt protected data on all of the domain-joined computers.

New deployment option

The ATA Lightweight Gateway is a new deployment option that enables you to deploy the ATA Gateway on the on-premises or IaaS Domain Controllers, removing the need for dedicated hardware and/or port-mirroring configuration. The ATA Lightweight Gateway introduces automatic and dynamic resource management based on the available resources on the DC. This intelligent capability will make sure that the existing operations of the DC will not be affected. In addition, the ATA Lightweight Gateway simplifies the deployment of the ATA Gateway in branch sites where there is a limitation of hardware resources and/or port-mirroring support and reduce the TCO.

Performance and Scale

In this new version of ATA (1.6), the performance and scale were greatly improved, enabling ATA to monitor large enterprise environments. This is possible due to significant improvements we have made in our detection engine. In addition, the changes we’ve made enable us to drastically reduce the storage requirements and now ATA requires x5 less space than the previous versions.

Automatic Updates Support

We know that a security solution should always be up to date. This is why with this new version we are introducing automatic updates to ATA. So no more manual downloads and upgrades!

Starting with this version, all releases will automatically update and upgrade via integration with Microsoft Updates (includes WSUS and SCCM integrations). Updates will include new behavior algorithms, detections, features and hotfixes in a simple and seamless way.

Once available in the Microsoft Update cloud service, or in the on-premises WSUS/SCCM, the ATA Center will automatically identify and download the updates. After the ATA Center is updated, all ATA Gateways (unless configured otherwise) will automatically download and deploy the updates from the ATA Center.

Third Party Integration

We are constantly expanding our support for additional 3rd party data sources to enrich our detection of insider threats and APTs. In this version we are introducing the Support for IBM QRadar – This new ATA version supports receiving events from IBM QRadar SIEM solution, in addition to the previously supported SIEM solutions (RSA Security Analytics, HP Arcsight and Splunk).

Read more at source -

Tuesday, May 3, 2016

Azure AD Connect Configuration Documenter

Source -

AAD Connect configuration documenter is a tool to generate documentation of an Azure AD Connect installation. Currently, the documentation is only limited to the Azure AD Connect sync configuration.

The goal of this project is to:

  • To enable quick understanding of the synchronization configuration and "how it happens"!
  • To build confidence in getting things right when making changes to the default configuration!!
  • To know what was changed when you applied a new build of Azure AD Connect!!!


  1. .NET Framework 4.5 to be able to run the tool
  2. A fair understanding of MIIS 2003 / ILM 2007 / FIM 2010 / MIM 2016 sync engine technical concepts to be able to understand the report.

How to use the tool:

  • Download the latest release from the releases tab under the Code tab tab and extract the zip file to an empty local folder on a machine which has .NET Framework 4.5 installed.
    • This will extract the Documenter application binaries along with the sample data files for "Contoso".
    • Make sure that the tool runs by double-clicking on the cmd file AzureADConnectSyncDocumenter.cmd.
  • Export the Server Configuration of your pilot / test Azure AD Connect sync server by running Get-ADSyncServerConfiguration cmdlet defined in ADSync module shipped with Azure AD Connect.
    Import-Module ADSync 
    Get-ADSyncServerConfiguration -Path "<CompletePathToOutputFolder>"
  • Copy the configuration export files produced in the previous step to a folder under the "Data" directory of the Documenter tool.
    • e.g. the "Pilot" configuration files for the customer "Contoso" are provided as a sample under the "Data\Contoso\Pilot" folder.
  • If you want to document the changes from a specific baseline, export the server configuration of your baseline / production Azure AD Connect server and copy the output to a folder under the Documenter "Data" directory.
    • e.g. the "Production" configuration files for the customer "Contoso" are provided as a sample under the "Data\Contoso\Production" folder.
  • Edit AzureADConnectSyncDocumenter.cmd for the values of "Pilot" and "Production" directories.
    • If you don't have a baseline / production config, specify the same path as the "Pilot" config.
  • Run the updated batch file. Upon successful execution, the generated report will be found in the Documenter "Report" folder.

Read more at source -

Tuesday, March 8, 2016

Microsoft Azure Datacenter IP Ranges

Source -

This file contains the Compute IP address ranges (including SQL ranges) used by the Microsoft Azure Datacenters. A new xml file will be uploaded every Wednesday (Pacific Time) with the new planned IP address ranges. New IP address ranges will be effective on the following Monday (Pacific Time). Please download the new xml file and perform the necessary changes on your site before Monday.

Download the XML file from

Friday, February 26, 2016

Updated Version of AADConnect (


Updated version of AADConnect – Version is available for download now.

More information and bug fix information can be found in

Released: 2016 February

Fixed issues:

  • Upgrade from earlier releases does not work if installation is not in the default C:\Program Files folder.
  • If you install and unselect Start the synchronization process.. at the end of the installation wizard, re-running the installation wizard will not enable the scheduler.
  • The scheduler will not work as expected on servers where the date/time format is not US-en. It will also block Get-ADSyncScheduler to return correct times.
  • If you installed an earlier release of Azure AD Connect with ADFS as the sign-in option and upgrade, you cannot run the installation wizard again.

Released: 2016 February

New features:

  • Automatic upgrade feature for Express settings customers.
  • Support for the global admin using MFA and PIM in the installation wizard.
    • You need to allow your proxy to also allow traffic to if you use MFA.
    • You need to add to your trusted sites list for MFA to properly work.
  • Allow changing the user's sign-in method after initial install.
  • Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all domains are available.
  • Scheduler is built-in to the sync engine.

Features promoted from preview to GA:

New preview features:

  • The new default sync cycle interval is 30 minutes. Used to be 3 hours for all earlier releases. Adds support to change the scheduler behavior.

Fixed issues:

  • The verify DNS domains page didn't always recognize the domains.
  • Prompts for domain admin credentials when configuring ADFS .
  • The on-premises AD accounts are not recognized by the installation wizard if located in a domain with a different DNS tree than the root domain.


Released: 2015 December

Fixed issues:

  • Password sync might not work when you change passwords in AD DS, but works when you do set password.
  • When you have a proxy server, authentication to Azure AD might fail during installation or un upgrade on the configuration page.
  • Updating from a previous release of Azure AD Connect with a full SQL Server will fail if you are not SA in SQL.
  • Updating from a previous release of Azure AD Connect with a remote SQL Server will show the error “Unable to access the ADSync SQL database”.


Released: 2015 November

New features:

  • Can reconfigure the ADFS to Azure AD trust.
  • Can refresh the Active Directory schema and regenerate Sync Rules.
  • Can disable a sync rule.
  • Can define "AuthoritativeNull" as a new literal in a Sync Rule.

New preview features:

New supported scenario:

Fixed issues:

  • Password synchronization issues:
    • An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes both OU and attribute filtering.
    • Selecting a new OU to include in sync does not require a full password sync.
    • When a disabled user is enabled the password does not sync.
    • The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been removed.
    • Improved troubleshooting.
  • Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
  • Not able to change the group used for group filtering after initial install.
  • Will no longer create a new user profile on the Azure AD Connect server for every user doing a password change with password writeback enabled.
  • Not able to use Long Integer values in Sync Rules scopes.
  • The checkbox "device writeback" remains disabled if there are unreachable domain controllers.


Released: 2015 August

New features:

  • The Azure AD Connect installation wizard is now localized to all Windows Server languages.
  • Added support for account unlock when using Azure AD password management.

Fixed issues:

  • Azure AD Connect installation wizard crashes if another user continues installation rather than the person who first started the installation.
  • If a previous uninstall of Azure AD Connect fails to uninstall Azure AD Connect sync cleanly, it is not possible to reinstall.
  • Cannot install Azure AD Connect using Express install if the user is not in the root domain of the forest or if a non-English version of Active Directory is used.
  • If the FQDN of the Active Directory user account cannot be resolved, a misleading error message “Failed to commit the schema” is shown.
  • If the account used on the Active Directory Connector is changed outside the wizard, the wizard will fail on subsequent runs.
  • Azure AD Connect sometimes fails to install on a domain controller.
  • Cannot enable and disable “Staging mode” if extension attributes have been added.
  • Password writeback fails in some configuration because of a bad password on the Active Directory Connector.
  • DirSync cannot be upgraded if dn is used in attribute filtering.
  • Excessive CPU usage when using password reset.

Removed preview features:

  • The preview feature User writeback was temporarily removed based on feedback from our preview customers. It will be re-added later when we have addressed the provided feedback.


Released: 2015 June

Initial release of Azure AD Connect.

Changed name from Azure AD Sync to Azure AD Connect.

New features:

New preview features:


Released: 2015 May

New Requirement:

  • Azure AD Sync now requires the .Net framework version 4.5.1 to be installed.

Fixed issues:

  • Password writeback from Azure AD is failing with a servicebus connectivity error.


Released: 2015 April

Fixed issues and improvements:

  • The Active Directory Connector does not process deletes correctly if the recycle bin is enabled and there are multiple domains in the forest.
  • The performance of import operations has been improved for the Azure Active Directory Connector.
  • When a group has exceeded the membership limit (by default, the limit is set to 50k objects), the group was deleted in Azure Active Directory. The new behavior is that the group will remain, an error is thrown and no new membership changes will be exported.
  • A new object cannot be provisioned if a staged delete with the same DN is already present in the connector space.
  • Some objects are marked for being synchronized during a delta sync although there is no change staged on the object.
  • Forcing a password sync also removes the preferred DC list.
  • CSExportAnalyzer has problems with some objects states.

New features:

  • A join can now connect to “ANY” object type in the MV.


Released: 2015 February


  • Improved import performance.

Fixed issues:

  • Password Sync honors the cloudFiltered attribute used by attribute filtering. Filtered objects will no longer be in scope for password synchronization.
  • In rare situations where the topology had very many domain controllers, password sync doesn’t work.
  • “Stopped-server” when importing from the Azure AD Connector after device management has been enabled in Azure AD/Intune.
  • Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join error.


Released: 2014 December

New features:

  • It is now supported to do password synchronization with attribute based filtering. For more details, see Password synchronization with filtering.
  • The attribute msDS-ExternalDirectoryObjectID is written back to AD. This adds support for Office 365 applications using OAuth2 to access both, Online and On-Premises mailboxes in a Hybrid Exchange Deployment.

Fixed upgrade issues:

  • A newer version of the sign-in assistant is available on the server.
  • A custom installation path was used to install Azure AD Sync.
  • An invalid custom join criterion blocks the upgrade.

Other fixes:

  • Fixed the templates for Office Pro Plus.
  • Fixed installation issues caused by user names that start with a dash.
  • Fixed losing the sourceAnchor setting when running the installation wizard a second time.
  • Fixed ETW tracing for password synchronization


Released: 2014 October

New features:

  • Password synchronization from multiple on-premise AD to Azure AD.
  • Localized installation UI to all Windows Server languages.

Upgrading from AADSync 1.0 GA

If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:

  • Locate the Sync Rule you have modified and take a note of the changes.
  • Delete the Sync Rule.
  • Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.

Permissions for the AD account

The AD account must be granted additional permissions to be able to read the password hashes from AD. The permissions to grant are named “Replicating Directory Changes” and “Replicating Directory Changes All”. Both permissions are required to be able to read the password hashes


Released: 2014 September

Initial release of Azure AD Sync.

ead more at source -

Tuesday, January 5, 2016

Azure AD Delegated App Access Management

Source -

Earlier this year, we shipped a preview of employee self-service app access for Azure AD to help our enterprise IT customers streamline their app access request and approval processes. This feature allows employees to add more applications in their Azure AD access panel, and allows IT to create optional approval workflows that puts app access grant decision making in the hands of a department lead or other delegated administrator. To everyone who tried and it provided feedback, thank you!

This feature is now generally available as part of Azure AD Premium, and we've added some cool new features to give delegated administrators even more control.

In addition to approving requests, delegated admins now get a control panel in the Azure AD access panel that allows them to see which apps they manage access for, and also directly assign and remove user access to those apps. Here's what the app control panel looks like for Google Apps:

This control panel allows team leads to directly grant app access to employees without IT involvement, and without requiring the employee to file a request.


Read more at source -

Friday, January 1, 2016

Microsoft Most Valuable Professional (MVP) Award


Microsoft Most Valuable Professional (MVP) Award – Enterprise Mobility

Perfect start to my 2016.  Received the Microsoft Most Valuable Professional (MVP) award for the 6th time.

Received the following good news this morning.


Dear Santhosh Sivarajan,
Congratulations! We are pleased to present you with the 2016 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Enterprise Mobility technical communities during the past year.
Also in this email:

  • About your MVP Award Gift
  • How to claim your award benefits
  • Your MVP Identification Number
  • MVP Award Program Code of Conduct

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say "Thank you for your technical leadership."

Patrick Malone
Community & Advocacy Programs

Tuesday, November 24, 2015

Topologies for Azure AD Connect

Source -

Here is article from Andreas Kjellman on supported Azure AD Connect topologies.

The objective of this topic is to describe different on-premises and Azure AD topologies with Azure AD Connect sync as the key integration solution. It describes both supported and unsupported configurations.

Legend for pictures in the document:


On-premises Active Directory forest

Active Directory with filtered import

Azure AD Connect sync server

Azure AD Connect sync server “Staging mode”

GALSync with FIM2010 or MIM2016

Azure AD Connect sync server, detailed

Azure AD directory

Unsupported scenario

Single forest, single Azure AD directory


The most common topology is a single forest on-premises, with one or multiple domains, and a single Azure AD directory (a.k.a. tenant). Azure AD authentication is done with password synchronization. This is the topology supported by the express installation of Azure AD Connect.

Single forest, multiple sync servers to one Azure AD directory


It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of objects (with the exception of a staging server). This could be attempted because one domain in a forest is not reachable from a common network location or in an attempt to distribute the sync load across several servers.

Multiple forests, single Azure AD directory


Many organizations have environments that include multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest deployed. Typical examples are designs with account-resource forests, merger and acquisitions related forests or forests used to outsource data.

When you have multiple forests all forests must be reachable by single Azure AD Connect sync server. The server does not have to be joined to a domain and can be placed in a network DMZ if required to be able to reach all forests.

The Azure AD Connect wizard will offer several options for how to consolidate users so even if the same user is represented multiple times in different forests, the user will be represented only once in Azure AD. There are some common topologies described below. You configure which topology you have by using the custom installation path in the installation wizard and select the corresponding option on the page “Uniquely identifying your users”. The consolidation is only happening for users. If groups are duplicated, these are not consolidated with the default configuration.

Common topologies are discussed in the next section: Separate topologies, Full mesh, and Account-Resource.

In the default configuration delivered by Azure AD Connect sync, the following assumptions are made: 1. Users have only one enabled account and the forest where this account is located is used to authenticate the user. This is for both password sync and for federation; userPrincipalName and sourceAnchor/immutableID will come from this forest. 2. Users have only one mailbox. 3. The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there is no mailbox on the user, then any forest can be used to contribute these attribute values. 4. If you have a linked mailbox, then there is also another account in different forest used for login.

If your environment does not match these assumptions, the following will happen: - If you have more than one active account or more than one mailbox, the sync engine will pick one and ignore the other. - If you have linked mailboxes but no other account, these accounts will not be exported to Azure AD and the user will not be a member of any groups. In DirSync a linked mailbox would be represented as a normal mailbox so this is intentionally a different behavior to better support multi forest scenarios.

Multiple forests, multiple sync servers to one Azure AD directory


It is not supported to have more than one Azure AD Connect Sync server connected to a single Azure AD directory (with the exception of a staging server).

Multiple forests – separate topologies

“Users are represented only once across all directories”



In this environment, all forests on-premises are treated as separate entities and no user would be present in any other forest. Each forest has its own Exchange organization and there is no GALSync between the forests. This could be the situation after a merger/acquisition or in an organization where each business unit is operating isolated from each other. In Azure AD these forests will be in the same organization and appear with a unified GAL. In this picture, each object in every forest will be represented once in the metaverse and aggregated in the target Azure AD directory.

Multiple forests – match users

Common for all multi-forest scenarios where you select one of the options under “User identities exist across multiple directories” is that distribution and security groups can be found in every forest and can contain a mix of users, contacts, and FSPs (Foreign Security Principals).

FSPs are used in ADDS to represent members from other forests in a security group. The sync engine will resolve the FSP to the real user and represent the security group in Azure AD with all FSPs resolved to the real object.

Multiple forests – full mesh with optional GALSync

“User identities exist across multiple directories. Match using: Mail attribute”



A full mesh topology allows users and resources to be located in any forest and commonly there would be two-way trusts between the forests.

If Exchange is present in more than one forest, there could optionally be an on-premises GALSync solution representing a user in one forest as a contact in every other forest. GALSync is commonly implemented using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016. Azure AD Connect cannot be used for on-premises GALSync.

In this scenario, identity objects are joined using the mail attribute. As a consequence of this, a user with a mailbox in one forest is joined with the contacts in the other forests.

Multiple Forests – Account-Resource Forest

“User identities exist across multiple directories. Match using: ObjectSID and msExchMasterAccountSID attributes”



In an account-resource forest topology, you have one or more account forests with active user accounts.

This scenario includes one forest that trusts all account forests. This forest has typically an extended AD schema with Exchange and Lync. All Exchange and Lync services as well as other shared services are located in this forest. Users have a disabled user account in this forest and the mailbox is linked to the account forest.

Office 365 and topology considerations

Some Office 365 workloads have certain restrictions to supported topologies. If you plan to use any of these, please refer to each workload’s supported topologies pages.


Exchange Online
If there is more than one Exchange organization on-premises (i.e. Exchange has been deployed to more than one forest) then you must use Exchange 2013 SP1 or later. Details can be found here: Hybrid deployments with multiple Active Directory forests

Skype for Business
When using multiple forests on-premises then only the account-resource forest topology is supported. Details for supported topologies can be found here: Environmental requirements for Skype for Business Server 2015

Staging server


Azure AD Connect supports installing a second server in “Staging mode”. A server in this mode will only read data from all connected directories and will therefore have an updated copy of the identity data. In case of a disaster where the primary server fails, it is easy to manually fail over to the second server using the Azure AD Connect wizard. This second server can preferably be located in a different datacenter since no infrastructure is shared with the primary server. Any configuration change made on the primary server must be copied to the second server by you.

A staging server can also be used if you want to test a new custom configuration and the effect it will have on your data. You can preview the changes and adjust the configuration. When you are happy with the new configuration you can make the staging server the active server and set the old active server in staging mode.

This method can also be used if you want to replace the sync server and want to prepare the new one before you shut down the currently active server.

It is possible to have more than one staging server if you want to have multiple backups in different data centers.

Multiple Azure AD directories

Microsoft recommends to have a single directory in Azure AD for an organization. Before you plan to use multiple Azure AD directories these topics cover common scenarios which will allow you to use a single directory.


Delegation using administrative units
Administrative units management in Azure AD


There is a 1:1 relationship between an Azure AD Connect sync server and an Azure AD directory. For each Azure AD directory, you will need one Azure AD Connect sync server installation. The Azure AD directory instances are by design isolated and users in one will not be able to see users in the other directory. If this is intended, this is a supported configuration but otherwise you should use the Single Azure AD directory models described above.

Each object only once in an Azure AD directory


In this topology one AAD Connect Sync server is connected to each Azure AD Directory. The Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects to operate on, for example by scoping each server to a particular domain or OU. A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces as well. For example, in the picture above three separate UPN suffixes are registered in the on-premises AD:,, and The users in each on-premises AD domain use a different namespace.

In this topology there is no “GALsync” between the Azure AD directory instances so the address book in Exchange Online and Skype for Business will only show users in the same directory.

With this topology only one of the Azure AD directories can enable Exchange hybrid with the on-premises Active Directory.

The requirement for mutually exclusive set of objects also applies to write-back. This makes some writeback features not supported with this topology since these assume a single configuration on-premises. This includes: - Group writeback with default configuration - Device writeback

Each object multiple times in an Azure AD directory

SingleForestMultiDirectoryUnsupported SingleForestMultiConnectorsUnsupported

It is unsupported to sync the same user to multiple Azure AD directories. It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in another Azure AD directory. It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.

GALsync by using writeback

MultiForestMultiDirectoryGALSync1Unsupported MultiForestMultiDirectoryGALSync2Unsupported

Azure AD directories are by design isolated. It is unsupported to change the configuration of Azure AD Connect sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between the directories. It is also unsupported to export users as contacts to another on-premises AD using Azure AD Connect sync.

GALsync with on-premises sync server


It is supported to use FIM2010/MIM2016 on-premises to GALsync users between two Exchange orgs. The users in one org will show up as foreign users/contacts in the other org. These different on-premises ADs can then be synchronized to their own Azure AD directories.

Read more at source -

Wednesday, November 4, 2015

New Version Of AADConnect

Source -

Released: 2015 November

New features:

  • Can reconfigure the ADFS to Azure AD trust.
  • Can refresh the Active Directory schema and regenerate Sync Rules.
  • Can disable a sync rule.
  • Can define "AuthoritativeNull" as a new literal in a Sync Rule.

New preview features:

New supported scenario:

Fixed issues:

  • Password synchronization issues:
    • An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes both OU and attribute filtering.
    • Selecting a new OU to include in sync does not require a full password sync.
    • When a disabled user is enabled the password does not sync.
    • The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been removed.
    • Improved troubleshooting.
  • Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
  • Not able to change the group used for group filtering after initial install.
  • Will no longer create a new user profile on the Azure AD Connect server for every user doing a password change with password writeback enabled.
  • Not able to use Long Integer values in Sync Rules scopes.
  • The checkbox "device writeback" remains disabled if there are unreachable domain controllers.

Read more at source -

Popular Posts


Twitter Delicious Facebook Digg Stumbleupon Favorites More