Author Archives: Chris Spanougakis

About Chris Spanougakis

Chris Spanougakis is a Microsoft Certified Trainer and has been a Microsoft Most Valuable Professional for 7 years. Motivated trainer and technology speaker, has participated in various Microsoft events and he is specialized in Windows Server products, such as Windows Server 2012, Exchange Server 2013, etc. You can meet him as a speaker in international events, sharing his passion about Microsoft technologies.

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

sourceAnchor
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:

consistencyguid-01

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

consistencyguid-02

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.

consistencyguidexistingdeployment01

consistencyguidexistingdeployment02

consistencyguidexistingdeployment03

consistencyguidexistingdeployment04

Thanks for your time!

Ping Access for #AzureAD is now Generally Available

 

Here I am again in an airport lounge, waiting to catch my flight to Athens, Greece, where I should start delivering tomorrow another MCSA Windows Server 2016 Bundle Course. This one will be delivered in Greek, but if you’re interested, we can deliver courses in English.

Anyway, I thought that I could write a blog post about the General Availability of Ping Access for Azure AD. I’ve written some posts in the past related to Ping Access and its great integration with Azure AD, so you can take a look at these articles here.

But what you can do with Ping Access? As the original announcement says, it’s a good solution if you need to provide secure remote access to applications that use header-based authentication.

Ping-Access

And this is how it works. Configure your applications to use PingAccess for Azure AD with just four steps:

  1. Configure Azure AD Application Proxy Connectors
  2. Create an Azure AD Application Proxy Application
  3. Download & Configure PingAccess
  4. Configure Applications in PingAccess

Do not forget to take a look at the documentation that gives you the full idea and detailed instructions on how to perform the steps above.

Thanks for your time!

Watch «Internet Safety : Message from experts» on YouTube

Courtesy of Rotary Kalamaria:

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.

gartnermq 

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!

ATTENTION: New scam e-mail claiming to be from Microsoft

In case you receive the following e-mail, DO NOT click anywhere in the message and delete it immediately (please notify your administrator).

It’s a fake message and has nothing to do with Microsoft. As you can see, the sender is by no way related to Office 365 services:

—–Original Message—–
From: Office 365 Online [mmiyazawa@gasei.cl]
Received: Δευτέρα, 12 Ιουν 2017, 6:23
To: user@company.com
Subject
: Terms of Service Update

Dear Office365 User,

Your account is not updated and will be shutdown within the next 24hours if you fail to update it.

Click here to update your email account now

Thank you for your patronage.

Sincerely,

Microsoft office365 Team

Copyright © 2017 

This e-mail may contain information that is privileged and confidential. If you suspect that you were not the intended recipient, please delete it and notify the sender as soon as possible.

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

 

1

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

2

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!

 

mcsa2016

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!