Tag Archives: systemplus

#AzureAD Connect and the on-premises AD Recycle Bin: What do you need to know about the sourceAnchor attribute

Starting from Windows Server 2008 R2, we had the really good option to enable Active Directory Recycle Bin. After all these years you should be familiar with that option, since we talk often about this topic for that last… 8 years.

If you just want to refresh your memory and learn about the on-premises AD Recycle Bin, you can take a look at this article.

But wait: these days is common to sync our on-premises AD objects to the cloud using AAD Connect, but how this new feature is related to our “local” AD Recycle BIn?

The story here is really simple: If you accidentally deleted an on-premises AD user object and restore it using AD Recycle Bin, Azure AD restores the corresponding Azure AD user object. So lets dig a little bit deeper on this topic and check all the different options that we get:

  • If you accidentally deleted an on-premises AD user object, the corresponding Azure AD user object will be deleted in the next sync cycle. By default, Azure AD keeps the deleted Azure AD user object in soft-deleted state for 30 days.

  • If you have on-premises AD Recycle Bin feature enabled, you can restore the deleted on-premises AD user object without changing its sourceAnchor value. When the recovered on-premises AD user object is synchronized to Azure AD, Azure AD will restore the corresponding soft-deleted Azure AD user object.

  • If you do not have on-premises AD Recycle Bin feature enabled, you may be required to create an AD user object to replace the deleted object. If Azure AD Connect Synchronization Service is configured to use system-generated AD attribute (such as ObjectGuid) for the Source Anchor attribute, the newly created AD user object will not have the same Source Anchor value as the deleted AD user object. When the newly created AD user object is synchronized to Azure AD, Azure AD creates a new Azure AD user object instead of restoring the soft-deleted Azure AD user object. So practically you create a brand new object, without being possible to restore the original AD object: it’s just a new account. Remember: By default, Azure AD keeps deleted Azure AD user objects in soft-deleted state for 30 days before they are permanently deleted. However, administrators can accelerate the deletion of such objects. Once the objects are permanently deleted, they can no longer be recovered, even if on-premises AD Recycle Bin feature is enabled.

As we already said above, with AD Recycle Bin you can restore an object without changing its sourceAnchor value. The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely identifies an object as being the same object on-premises and in Azure AD. The attribute is also called immutableId and you’ll often see that we use both names. So practically this attribute cannot be changed, and for this reason you should have a clear idea on how things work here.

This attribute is used during the following cases:

  • When a new sync engine server is built (a new sync between your on-premises AD and Azure AD), or rebuilt after a disaster recovery scenario, this attribute links existing objects in Azure AD with objects on-premises.
  • If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to «hard match» existing objects in Azure AD with on-premises objects.
  • If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely identify a user.

It’s really important to select the appropriate attribute, since we said that it cannot be changed:

  • Be less than 60 characters in length
    • Characters not being a-z, A-Z, or 0-9 are encoded and counted as 3 characters
  • Not contain a special character: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ‘ ; : , [ ] » @ _
  • Must be globally unique
  • Must be either a string, integer, or binary
  • Should not be based on user’s name, sometimes we change the user name!! 
  • Should not be case-sensitive and avoid values that may vary by case
  • Should be assigned when the object is created

Remember: The sourceAnchor attribute is case-sensitive. A value of “chrisSpanougakis” is not the same as “chrisspanougakis”.

If you have a single forest on-premises, then the attribute you should use is objectGUID. This is also the attribute used when you use express settings in Azure AD Connect and also the attribute used by the old DirSync. Generally speaking, there are a lot of cases that is recommended to use the objectGUID attribute, even when we use multiple forests and we do not move users between forests.

Is it possible to change the sourceAnchor attribute?
No. As soon as you create the object and you sync it to Azure AD, it’s not possible to change it anymore. If you want to change it, you should uninstall and reinstall Azure AD Connect. If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as previously used. If you’ve been using DirSync and move to Azure AD Connect, then you must use objectGUID since that is the attribute used by DirSync. If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD Connect sync throws an error and does not allow any more changes on that object before the issue has been fixed and the sourceAnchor is changed back in the source directory.

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects. But fortunately, there is a workaround for this: you must use a configurable AD attribute (for example, msDS-ConsistencyGuid) as the sourceAnchor attribute.

You need to use Azure AD Connect (version 1.1.524.0 and after) in order to be able to use the msDS-ConsistencyGuid attribute. For on-premises AD User objects whose msDS-ConsistencyGuid attribute isn’t populated, Azure AD Connect writes its objectGUID value back to the msDS-ConsistencyGuid attribute in on-premises Active Directory. After the msDS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

How we enable the ConsistencyGuid feature?
When installing Azure AD Connect with Express mode, the Azure AD Connect wizard automatically determines the most appropriate AD attribute to use as the sourceAnchor attribute. Since we talk here about a fresh installation of Azure AD Connect, the wizard checks the state of the msDS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn’t configured on any object in the directory, the wizard uses the msDS-ConsistencyGuid as the sourceAnchor attribute.

But: If the attribute is configured on one or more objects in the directory, the wizard concludes the attribute is being used by other applications and is not suitable as sourceAnchor attribute, In this case, the wizard selects to use objectGUID as the sourceAnchor attribute.

Once the sourceAnchor attribute is decided, the wizard stores the information in your Azure AD tenant. The information will be used by future installation of Azure AD Connect. Practicall when the wizard finishes, you should see something like this:


If you do a custom installation of Azure AD Connect, you have the option to select how users will be identified in Azure AD:


Select the first option if you want Azure AD to pick the attribute for you. If you select this option, Azure AD Connect wizard applies the same logic as we described above, during the Express installation of Azure AD Connect. The second option will let you select a specific attribute.

Change the attribute on an a existing installation
If you have an existing Azure AD Connect deployment which is using objectGUID as the Source Anchor attribute, you can switch it to using ConsistencyGuid.

  • Start the Azure AD Connect wizard and click Configure to go to the Tasks screen.

  • Select the Configure Source Anchor task option and click Next.





Thanks for your time!

Gartner’s 2017 Magic Quadrant presents #AzureAD as a leader for Access Management

Well, some of you may not really know who Gartner is, and why this “Magic Quadrant” is so important. Just to clarify a few things, I’ll copy some information from Wikipedia:

“The Magic Quadrant (MQ) are a series of market research reports published by the United States research and advisory firm, Gartner, which aim to provide a qualitative analysis into a market and its direction, maturity and participants. Their analyses are conducted for several specific technology industries and are updated every 1–2 years.

Gartner rates vendors upon two criteria: completeness of vision and ability to execute. Using a methodology which Gartner does not disclose, these component scores lead to a vendor position in one of four quadrants:

  • Leaders – Vendors in the Leaders quadrant have the highest composite scores for their Completeness of Vision and Ability to Execute. A vendor in the Leaders quadrant has the market share, credibility, and marketing & sales capabilities needed to drive the acceptance of new technologies. These vendors demonstrate a clear understanding of market needs, they are innovators and thought leaders, and they have well-articulated plans that customers and prospects can use when designing their infrastructures and strategies. In addition, they have a presence in the five major geographical regions, consistent financial performance, and broad platform support.
  • Challengers – A vendor in the Challengers quadrant participates in the market and executes well enough to be a serious threat to vendors in the Leaders quadrant. They have strong products, as well as sufficiently credible market position and resources to sustain continued growth. Financial viability is not an issue for vendors in the Challengers quadrant, but they lack the size and influence of vendors in the Leaders quadrant.
  • Visionaries – A vendor in the Visionaries quadrant delivers innovative products that address operationally or financially important end-user problems at a broad scale, but has not yet demonstrated the ability to capture market share or sustainable profitability. Visionary vendors are frequently privately held companies and acquisition targets for larger, established companies. The likelihood of acquisition often reduces the risks associated with installing their systems.
  • Niche Players – Vendors in the Niche Players quadrant are often narrowly focused on specific market or vertical segments. This quadrant may also include vendors that are adapting their existing products to enter the market under consideration, or larger vendors having difficulty developing and executing on their vision.”

And now that you know all that information, let’s get to the facts: Gartner released their 2017 Magic Quadrant for Access Management (AM MQ), which shows that Azure Active Directory is placed in the “leaders” quadrant and is positioned very strongly for completeness of vision. The full Gartner report can be found here.


As you can see, Microsoft is a leader, providing a complete identity and access management solution for employees, partners, and customers, all backed by world-class identity protection based on Microsoft’s Intelligent Security Graph.

Thanks for your time!

#AzureAD Conditional Access support for Microsoft Teams & the Azure Portal


More news today from the Azure AD product group: Conditional Access is extended to be used in the Azure Portal. But wait: have you ever used Conditional Access? If not, try to perform a search in my blog for “Conditional Access», or simply click this link, https://systemplus.gr/?s=conditional+access and you’ll get a lot of information about this feature.

So to stick back to the news, it’s now possible to create Conditional Access policies in order to better secure access to the Azure Portal. Previously, the only way to do this, was by enforcing Multi-factor Authentication. Although it works, MFA is sometimes related to frustration by the user, so there must be another way to secure access. Now it’s possible to allow access to Azure portal only under certain conditions (sign-in risk, location, device) and from trusted devices.

Here is how it works: you should create a new Conditional Access policy for a new cloud app named “Microsoft Azure Management”. This policy will apply to all Azure management options we have: portals, ARM provider, even PowerShell will be affected.



And then you can specify the components of this new policy, like devices, users, sign-in risk, trusted IPs, etc.


But please be careful, it’s easy to lock yourself out if you specify the wrong conditions in the policy!

The exact same concept applies to another cloud app called “Microsoft Teams”, part of the Office 365 family. Practically, by configuring a new conditional access policy here, you can secure the data in Teams and prevent leakage on untrusted devices. It’s important to note that Conditional Access policies created for Exchange Online and SharePoint Online cloud apps also affect Microsoft Teams as the Teams clients rely heavily on these services for core productivity scenarios such as meetings, calendars and files.


Thanks for your time!

Do you have the skills to be a MCSA on Windows Server 2016? Try our free test!



You probably want to get certified as a MCSA on Windows Server, but do you have the skills and the technical knowledge?

Find out by trying our free practice test! Just respond to the questions in 5 mins and immediately get the results!

You can find the test here.

Good luck!

New feature updates for #AzureAD Application Proxy, WorkFolders supported also

I’ve already presented Azure AD Application Proxy many times, it’s a great feature of Azure AD that you can use to publish your web apps to users outside of the company without VPNs. firewalls and the like.

If you don’t know what is Azure AD Application Proxy, please take a look at this recorded presentation that I did a few months ago. You can find the video here.

But today there are some great news: if you use the new connector version of App Proxy you can use it with applications that take up to 180 seconds to respond to a request. Use the new Backend Application Timeout setting in the Azure Portal to publish these applications by changing the value from “Default” (85 seconds) to “Long” (180 seconds. This setting is in the “Application Proxy” menu for your application.

If your application consistently responds in less than 85 seconds, it is recommended to keep the default setting. This ensures the Application Proxy Connector does not consume unnecessary resources. To learn how to manually upgrade your Connector or how the automatic updates will roll out, please see the Connector update documentation. If you already have the newest Connector, you can close all ports other than 443 and 80 and reduce your overhead.

Take also a look at the configuration documentation regarding the ports that you can now use.


But there is also another great feature. It is possible to use Azure AD App Proxy to give access to your users to the WorkFolders that you use internally. This article was somehow hidden in a Microsoft blog, so we’ve discovered it and …


Work Folders updates for Windows 10 version 1703, Android and iOS

In this recent announcement, we can see that is now possible to offer the following functionality:

  • Remote users can securely access their files on the Work Folders server using Azure Active Directory Application Proxy
  • Improved single sign on experience (fewer authentication prompts) when using Azure Active Directory Application Proxy
  • Group policy setting to manage the Work Folders directory location on Windows devices

Don’t waste more time! Click here to read all the documentation about how you can do it.


Integration of #AzureAD with Workday is now in Public Preview

Well, these guys never stop giving us new features and technologies. So today the Azure AD Product Group announced that we have an integration of Azure AD with Workday.

Some of you probably do not know anything about Workday. Well, it’s a great application that can be used by the HR, the Finance and the IT department, and can unify finance and HR, giving you real-time insights, global visibility, and predictive analytics.


And here is the good part: Integration, meaning that when the employee information changes in Workday, like a name change or a title change, this information has to replicate to Azure AD, Windows Server AD on-premises, Office 365 and to third-party apps that use these identities. Additionally, key user attributes like email addresses need to be automatically written back to Workday when mailboxes are provisioned or updated in your organization’s email system.

By using Azure AD Connect and the existing library of SaaS app connectors in conjunction with these new features, we can now achieve end-to-end user provisioning from Workday to our identity systems and SaaS apps.

This feature is available in public preview today for all customers using Azure AD Premium P1. To get started, check out this Tutorial for Configuring Workday for Inbound Synchronization.



You can learn more about Workday here.


EMS Conditional Access using #AzureAD: What is all about


It’s really not the first time that you see this feature, EMS Conditional Access, in this blog. Just try to make a search, just like this: https://spanougakis.wordpress.com/?s=conditional+access and you’ll get a lot of related information.

So as you can see, we need to find a way to protect our corporate data, while allowing our users to be productive, just using any device, giving them the best possible experience.

We should now start exploring what we can do using conditional parameters at the application, user or location layer. Take a moment to take a look at the following diagram:


How to protect data using the Application layer in EMS
Some of your cloud applications might contain sensitive information, and you should consider control access. As you can see on the right side of the picture above, you could create policies that can ask for Multi-Factor Authentication, depending on the location it’s being accessed from. These policies can be applied to any cloud (SaaS) or on-premises app protected by Azure Active Directory, including their rich, mobile or browser-based clients.

User layer conditional access
That’s probably the easy part, because if you use Azure AD Premium as your identity management mechanism, you already know that you can specify to which users or groups these conditional access policies should apply. You can assign multiple conditions at the location, application or device information levels to users or multiple groups, You can also create exclusions.

Location layer conditional access 
Just define a set of trusted IPs, but also define what will happen when the user tries to access an application from an unknown location, for example you could ask for MFA.

Let’s see a common scenario that implements all the previous topics:



But what about devices?
You need device compliance, just to make sure that you allow only managed and compatible devices to access your data-sensitive applications. This can be done by using Device compliance policies to enforce device compliance requirements. Some of these could be device enrollment, domain join, passwords and encryption, but also the OS that runs on devices.

You can use compliance policy settings in Microsoft Intune to create a set of rules for and to evaluate the compliance of employee devices. When devices don’t meet the conditions set in the policies, the end user is guided though the process of enrolling the device and fixing the issue that prevents the device from being compliant.

In this scenario, when you use a conditional access policy in combination with a device compliance policy, only users with compliant devices—in addition to any other rules you’ve set—will be allowed to access the service.

This is how it works:


Microsoft recently partnered with Lookout, and this integration can give you all the information that you need, related to mobile device risks, including advanced mobile threats and app data leakage. If a device is found to be not compliant due to a mobile risk identified by Lookout, access is blocked and the user is prompted to resolve the issue with one-step guidance from Lookout before they can regain access. Note that Lookout licenses must be purchased separately from EMS:


But the same policies can be applied to on-premises apps also. Microsoft has now partnerships with popular network access providers such as Cisco ISE, Aruba ClearPass, and Citrix NetScaler. Now you can extend your Intune conditional access capabilities to work with these networks. Every time that a user tries to access an on-premises application, additional checks can be made for Intune-managed and compliant devices before allowing user access through these devices.

It’s also important to take into consideration some additional threats and risks, so we can use….

Risk-based conditional access
Today’s threats are really sophisticated, but the good thing is that after every attack we know that there is a pattern that fortunately can be analyzed. Every month Microsoft updates more than 1 billion PCs, services more than 450 billion authentications, and analyzes more than 200 billion emails for malware and malicious websites. They gather information about every kind of attack there is, and they push the data directly into the Microsoft Intelligent Security Graph.

So now that we have the data, we can use it as part of a conditional access policy we create. It’s important to know that in many cases these risks are automatically recognized by Microsoft, and when they are detected they could block user access.

The same happens when they detect the possibility of leaked credentials. Microsoft security researchers search for credentials that have been posted on the dark web, which usually appear in plain text. Machine learning algorithms compare these credentials with Azure Active Directory credentials and report any match as “leaked credentials.”

Can you travel from Europe to the US in just an hour? Probably not. So when two sign-ins originate from different geographic locations within a window of time too short to accommodate travel from one to the other, it’s probably an indication of someone else that used your credentials to sign-in.

Infected devices
The Microsoft Intelligent Security Graph maintains a list of IP addresses known to have been in contact with a bot server. Devices that attempt to contact resources from these IP addresses are possibly infected with malware and are therefore flagged.

Anonymous IP addresses
Why should you hide your IP address? Probably because you want to perform some malicious activities. In this scenario, a risk-based conditional access policy can require MFA as additional proof of identity.

IP addresses with suspicious activity
Multiple failed sign-in attempts that occur over a short period of time, across multiple user accounts, and that originate from a single IP address, also trigger a risk event. This scenario can be analyzed and enforce the correct conditional access policy if required.

To get a full picture of conditional access from EMS, you can download this white paper with a lot of additional information, so please cheek it out.

Thanks for your time!