Tag Archives: mvp

#AzureAD Domain Services admin UX in the new Azure Portal is now in Public Preview

Back in October 2015 and 2016 I’ve written some posts related to the new Azure AD Domain Services feature of Azure Active Directory, which is a brilliant way to provide managed domain services like domain join, group policy, LDAP, and Kerberos/NTLM authentication, all fully compatible with Windows Server Active Directory. You can search and read these articles by clicking on this link here: https://systemplus.gr/?s=azure+ad+domain+services

We’re happy to see that today we have a user interface to manage this great feature just right into the new Azure Portal, so let’s see how it works. As you will see, it’s now possible to create virtual networks, configure group membership of the delegated administrator group, and enable domain services into a simple, intuitive, step-by-step experience.

  1. If Azure AD Domain Services is not enabled for your Azure directory – Create a new managed domain using the new Azure portal, we’ll talk about this in a moment.

  2. If you’ve already enabled Azure AD Domain Services for your Azure directoryContact the Azure AD team via email to migrate your existing managed AD domain to the new Azure portal. From there, you can administer your existing managed AD domain using the new Azure portal.

So what do you need to do in order to enable Azure AD Domain Services?

  1. Go to the Azure portal.
  2. In the left pane, click on New.
  3. In the New blade, type Domain Services into the search bar:


Click to select Azure AD Domain Services from the list of search suggestions. On the Azure AD Domain Services blade, click the Create button:


Then you should proceed to the next step, which is to specify the DNS domain name for the managed domain. You can also choose the resource group and Azure location to which the managed domain should be deployed:


Choose the DNS domain name for your managed domain.

  • The default domain name of the directory (with a .onmicrosoft.com suffix) is specified by default.

  • You can also type in a custom domain name.

Ensure that the DNS domain name you have chosen for the managed domain does not already exist in the virtual network. Specifically, check whether:

  • You already have a domain with the same DNS domain name on the virtual network.

  • The virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don’t have a domain with the same DNS domain name on your on-premises network.

  • You have an existing cloud service with that name on the virtual network.

The next configuration task is to create an Azure virtual network and a dedicated subnet within it. Click Virtual network to select a virtual network.

  1. On the Choose virtual network blade, you see all existing virtual networks. You see only the virtual networks that belong to the resource group and Azure location you have selected on the Basics wizard page.

  2. Choose the virtual network in which Azure AD Domain Services should be enabled. Click Create new, if you prefer to create a new virtual network. It is highly recommended to use a dedicated subnet for Azure AD Domain Services.


Click Subnet to pick the dedicated subnet in this virtual network, within which to enable your new managed domain. In the Create subnet blade, specify a name for the subnet, and click OK when you’re done. For example, create a subnet with the name ‘DomainServices’, making it easy for other administrators to understand what is deployed within the subnet.


The last step is to create an administrative group in your Azure AD directory. This special administrative group is called AAD DC Administrators. Members of this group are granted administrative permissions on machines that are domain-joined to the managed domain. On domain-joined machines, this group is added to the administrators group. Additionally, members of this group can use Remote Desktop to connect remotely to domain-joined machines. The wizard automatically creates the administrative group in your Azure AD directory. This group is called ‘AAD DC Administrators’. If you have an existing group with this name in your Azure AD directory, the wizard selects this group. You can configure group membership using the Administrator group wizard page:


The last step is to actually start the deployment of Azure AD Domain Services:


Don’t forget to check the related documentation here.

Thanks for your time!

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

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!

#AzureAD Privileged Identity Management Approval Workflows are now in Public Preview


Some more great news today from the Azure AD Team! The public preview of some major updates to the Azure AD Privileged Identity Management service is now on. If you want to know more about Azure AD PIM, you can taka a look at this article: https://spanougakis.wordpress.com/2016/09/13/azuread-identity-protection-azure-ad-privileged-identity-management-and-azure-ad-premium-p2-available-sept-15th-2016/

But let’s see what’s new:

  • A new, improved user experience
  • New approval workflow for improved role security
  • Audit History for everyone in temporary role assignments

You should have all these new features available today, assuming that you have a paid Azure AD P2 subscription.

The new Approval Workflow 
Let’s try to logon to the Azure AD portal as a user that will request access to be a Global Administrator. So this is how it works: the user will request a Global Administrator role, but he will be notified that the approval is pending, as you can see below:




Now, the Global Administrator has to use the Azure AD Portal to approve the request:



As soon as the request is approved, you can ….

View all temporary role assignments with the new “My Audit History
Just navigate to the My Audit History, a new view in the updated user interface that lets you see status and activation history for all your temporary role assignments:


Don’t forget to check Audit History, which gives you a full log of all previous role approvals:


Thanks for your time!