Monday, August 31, 2015

Office 365 - Disable DirSync

After some reflection, I have decided to create a test environment in which a third-party service (OneLogin) will replace ADFS and also DirSync for Active Directory synchronization and SSO (Single Sign On) with Office 365. OneLogin is one of the primary players in the "Identity Provider" business, the other being Okta. I have selected OneLogin simply because I may have to work with the product in the future and want to become more familiar with it. So far, I have not worked with either OneLogin or Okta in a professional context and have no reason (other than the reason stated above) to favor one over the other.

Until now, I have used a combination of DirSync and ADFS to synchronize segments of my on-premises Active Directory database with Office 365 and provide SSO. I now will examine a scenario in which we would replace both ADFS and DirSync with OneLogin.

Please note that OneLogin may or may not be a satisfactory replacement for DirSync. OneLogin can sync many Active Directory object attributes (or properties) to Office 365 but not necessarily all those required by your organization. If necessary, your organization can use OneLogin instead of or as a replacement for ADFS and still use DirSync. That is indeed a possible combination. For further details, please consult this document (or contact OneLogin):

Provisioning User Attributes to Office 365

In my previous blog post, I disabled ADFS in preparation for the installation of the OneLogin Active Directory Connector (ADC) that will provide SSO functionality. In the following lines, I will disable DirSync as well (underlying once again that this is optional, OneLogin being perfectly compatible with DirSync).


If we opt to disable DirSync, we can do so at one of two locations: at the PowerShell command line or in the Office 365 Portal. I will use the PowerShell method here.

First, and as for disabling ADFS, we must have installed the "Windows Azure Active Directory Module for PowerShell" (the "basic" or "native" PowerShell commands that come with current server operating systems cannot manipulate elements of Office 365).

We first import the MS Online module and then connect to MS Online (in other words, Office 365):

PS C:\> Import-Module MSOnline
PS C:\>
PS C:\> Connect-MsolService

At this point, we are prompted for credentials. We should enter Global Admin credentials for our Office 365 account:

If we want to see the current status of DirSync (enabled or disabled) we can execute this command:

PS C:\> (Get-MsolCompanyInformation).DirectorySynchronizationEnabled

In other words, this displays the value of the  "DirectorySynchronizationEnabled" property of the "MsolCompanyInformation" object which happens to be "True".

We can adjust this value with the following cmdlet:

PS C:\> Set-MsolDirSyncEnabled -EnableDirSync $false

(We will be prompted for a confirmation).

There is no "command completed successfully" message but we can confirm the change with the command presented above. Now the value is "false":

PS C:\> (Get-MsolCompanyInformation).DirectorySynchronizationEnabled

If we prefer to make the change in the Office 365 portal, this is where we would go:

In my case, the screenshot reflects the change made above. The only option is to "Set up" synchronization, which means it is currently disabled.

Saturday, August 29, 2015

Office 365 - Disable Federation (ADFS)

SSO (Single Sign On) for Office 365 is usually provided by Active Directory Federation Services (ADFS).

Note: see this blog post for a description of SSO:

Office 365 - Hybrid Migration - Part 1: ADFS configuration

However, we may opt for another SSO service such as those of third-party providers OneLogin or Okta (these are the two "big names" in the identity provider business). If we have not implemented ADFS, we would simply configure the third-party system as directed. If we do have ADFS in place, we have to disable federation in Office 365 before implementing the third-party solution. This process is sometimes called "defederation".

As for DirSync, we may retain it as a solution, or not, depending on our needs. I may address that aspect in another blog post. For now, I will concentrate on ADFS.

In the following paragraphs, I'll outline the procedure to disable federation with ADFS and thus allow use of a third-party tool.

First, we open the Windows Azure Active Directory Module for PowerShell:

We then import the MSOnline module which allows us to execute commands in our Cloud environment (Office 365):

Import-Module MSOnline

We then connect to the online service:


At this point, we have to enter Global Administrator credentials for the domain we want to manage.

This would be something like:

Password: **********

We then verify which domains are federated with the following cmdlet:


In my case, it is the domain that is federated:

Note: I added... | format-list name,status.auth* so all the output would be neatly aligned to the left. Otherwise, by default, authentication displays on the far right on the screen

We have to connect to the ADFS server from O365 at this time:

Set-MsolADFSContext -Computer ADFS-1

Note: ADFS-1 is the name of my ADFS server.

And now, we can convert the domain to standard (as opposed to federated):

Convert-MsolDomainToStandard -DomainName -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt

Note: we can name the password text file to whatever we want. In my case, this file was not even created.

We should obtain a result like this (click to enlarge):

Apparently, we still need to execute one more cmdlet to set domain authentication to "managed" even though the preceding cmdlet seems to do this (note the output above):

Set-MsolDomainAuthentication -Authentication Managed -DomainName

Now users can logon to Office 365 / Exchange Online even if the ADFS server is unavailable. That is because they authenticate against Azure Active Directory to which their passwords have been synchronized via DirSync.

This is what the user will see:

When they start to enter their password, they will no longer be redirected to an ADFS server but will be able to continue to enter their credentials as shown above.

And despite the absence of an ADFS server (currently powered off), they can indeed access their email:


Of course, we no longer have SSO and users will have to enter their credentials every time they access their email (or other Office 365 services). If this is not acceptable, we either have to retain ADFS or implement a third-party service such as those offered by OneLogin or Okta.

Friday, August 28, 2015

Active Directory - domain controllers in different languages

Can we have (in the same domain) domain controllers with an OS in different languages, for example some in English and some in French?

This question is asked from time to time on Technet forums:

Compatibility in AD between Polish and english

Domain controllers with different OS languages

Many companies, large and not so large, are often multinational and staff members, IT personnel included, may speak different languages. Some administators, regardless of their mastery of English, may prefer a management interface in their native language.

I've installed two Windows 2008 domain controllers, one in English (DC3) and one in French (DC4). In the following lines, I'll present some of my observations.

As far as translation of the interface, on the French domain controller, the primary Active Directory interfaces are all translated, for example:

  • Active Directory Sites and Services (ADSS) becomes "Sites et services Active Directory"
  • Active Directory Users and Computers (ADUC) becomes "Utilisateurs et ordinateurs Active Directory"
  • Active Directory Domains and Trusts (ADDT) becomes "Domaines et approbations Active Directory"

On the other hand, some elements retain their English names:

The ADUC interface is more interesting. All the elements retain their English names (except the folder "Requêtes sauvegardées" for "Saved queries"):

Yet... I am sure these names are normally localized (in this case, translated into French).

My explaination: if the first domain controller is in a particular language, certain replicated elements will retain the original language, even on localized domain controllers.

Indeed, in a solely French environment, most of the user names are indeed translated into French:

What about some of the common Active Directory commands, repadmin for example?

The output is localized:


C:\>repadmin /showrepl

Repadmin: running command /showrepl against full DC localhost
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 75a4a675-5ee2-40c6-b693-718d57461eeb
DSA invocationID: 75a4a675-5ee2-40c6-b693-718d57461eeb


C:\>repadmin /showrepl

Repadmin : exécution de la commande /showrepl sur le contrôleur de domaine complet localhost
Options DSA : IS_GC
Options de site : (none)
GUID de l'objet DSA : 58d00eef-a083-47a5-9cf7-d854ac13bf79
ID de l'invocation DSA : d6e3c414-ab12-4d71-a3bc-135aba5ac84c

Otherwise (and even though there is not much to replicate in my very simple test environment), replication functions just fine between domain controllers with different language versions.

What if I create a user on DC3? Once replication takes place, what do user properties look like if I examine them on DC4?

The various properties are all translated into the localized language (French, in this case):


All in all, we can conclude:
  • Domain controllers with different language versions can function together.
  • Certain Active Directory objects will be replicated with the names in the language of the first server promoted to domain controller status, even on domain controllers using another language.