Thursday, October 15, 2015

FR (French) - Active Directory - NTP et la synchronisation horaire

English abstract: I examine EventID 12 in which the domain controller (with PDCe role) cannot connect to an external time source, how to configure the time service, and adjust settings if the PDCe role is transferred to another domain controller.


***

Je venais d'installer une paire de contrôleurs de domaine (désormais abrégé en "DC"), le premier avec une interface anglaise et le second avec une interface française, et, pour vérifier que tout allait bien, j'ai exécuté (entre autres commandes) DCDIAG.

Parmi les différentes vérifications effectuées, DCDIAG rapporte des avertissements enregistrés dans le journal "Système" de l'Observateur d'événements. Après le démarrage d'un DC, ces enregistrements peuvent être assez nombreux et souvent les problèmes relevés se résolvent tout seuls une fois que tous les services démarrent et que le DC entame le processus de "réplication" avec ses partenaires.

Un de ces avertissements se rattache à la "source de temps" dont voici les principaux détails (cliquer sur l'image pour l'agrandir) :



Et voici de quoi il s'agit...

L'identité des ordinateurs clients se vérifie avec le protocole Kerberos qui utilise un système de tickets horodatés que je ne présenterai pas en détail ici. Il suffit de savoir que, par défaut, ce système d'authentification tolère une déviation maximale de 5 minutes entre l'horloge des noeuds en question. Si, donc, l'horloge d'un poste client marque 1h00 et l'horloge du DC qui l'authenifie marque 1h15 (soit une différence de 15 minutes) l'authentification est vouée à l'échec. Ce serait également un problème pour les serveurs membres qui sont, du point de vue de l'authentication, des clients des DC aussi.

En principe, de tels écarts d'horloge ne devraient pas se produire.

  • Les clients (au sens large) obtiennent l'heure du DC qui les authentifie.
  • Les DC obtiennent l'heure du DC tenant le rôle du PDCe (émulateur de PDC).
  • Les PDCe (dans une forêt à plusieurs domaines) obtiennent l'heure du PDCe du domaine racine de la forêt.
  • Le PDCe du domaine racine obtient l'heure exacte d'une source externe dite "fiable".

En fait, s'il y a des problèmes de communication entre noeuds, l'heure pourrait dévier de plus de cinq minutes par rapport à l'heure juste.

En outre, il faut, chez le PDCe du domaine racine, une configuration manuelle afin d'obtenir l'heure de la source externe.

A cela, je dois ajouter les remarques suivantes :

  1. La synchronisation avec une source de temps externe est souhaitable mais non pas indispensable. Kerberos requiert que l'heure soit la même entre membres du domaine (avec une déviation maximale de 5 minutes par défaut). L'heure affichée par le PDCe pourrait être 1h05, et l'heure selon telle horloge atomique 1h45, sans que cela provoque la moindre défaillance dans l'authentification.
  2. C'est le protocole NTP "Network Time Protocol" qui gère l'heure pour Windows Server. NTP recourt au temps universel coordonné ("TUC" ou "UTC" en anglais) ce qui permet à des DC se trouvant dans des fuseaux horaires différents de fonctionner ensemble. Les paramètres pour l'heure locale existent dans le registre et convertissent le TUC en heure locale pour l'affichage dans la barre des tâches en bas et à droite de l'écran (par exemple). NTP utilise le port 123.


Malgré ma première remarque ci-dessus, il vaudrait mieux que l'heure affichée à l'écran des ordinateurs corresponde bien à l'heure juste. Nous pouvons atteindre cet objectif en configurant le PDCe du domaine racine de sorte qu'il obtienne l'heure d'une source de temps externe fiable.

Voici un site canadien qui propose une liste des sources :

http://www.nrc-cnrc.gc.ca/fra/services/heure/synchronisation_reseau.html


Et voici une liste des sources aux Etats-Unis :

http://tf.nist.gov/tf-cgi/servers.cgi


Nous pouvons vérifier l'heure exacte à ce site :

www.heure.com


Note : ces ressources sont loin d'être les seules. J'invite le lecteur à en chercher qui conviennent le mieux à sa situation géographique. En effet, il est préférable d'utiliser une source à proximité - à supposer bien sûr des liens Internet de qualité égale. Il faut s'assurer d'ailleurs que la source soit bien fiable - ce que le site américain montre dans une certaine mesure (si le site était toujours occupé, nous ferions bien d'en choisir un autre).


***

Maintenant, configurons notre PDCe pour qu'il obtienne l'heure d'une source externe.

Voici les paramètres NTP tels que nous les voyons dans le registre avant configuration...

DC3 (anglais) :



DC4 (français) - PDCe :



Les paramètres à noter sont indiqués par de points rouges :

  1. L'endroit dans le registre où nous pouvons observer les paramètres qui nous intéressent et en particulier :
  2. NTPServer
  3. Type

Ce sont là les valeurs par défaut - et le simple fait de désigner un DC comme PDCe ne configure nullement les valeurs appropriées. Nous devons les configurer avec les commandes présentées ci-dessous. Note : nous pouvons vérifier le détenteur des rôles FSMO avec cette commande : netdom query fsmo



La commande suivante configure le PDCe pour qu'il cherche l'heure chez une source externe ("time.nist.gov" dans notre cas) :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual


Dans d'autres documents, j'ai observé aussi la commande présentée avec deux paramètres supplémentaires :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update


Le changement s'observe tout de suite dans le registre du PDCe (DC4) :




En revanche, les paramètres de l'autre DC ne changent pas :




Ensuite, nous devons faire redémarrer le service w32tm:

net stop w32time
net start w32time

Et synchroniser l'heure avec la source externe:

w32tm /resync

Voilà ! Nous y sommes. Notre PDCe est configuré pour obtenir l'heure exacte d'une source externe. Au lieu des messages d'erreur présentés au début de cet article, nous avons de simples messages d'information nous faisant savoir que :




***

Maintenant, je déplace le rôle du PDCe vers DC3 :

C:\>ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC3
Liaison à DC3...
Connecté à DC3 en utilisant les informations d'identification d'un utilisateur connecté localement.
server connections: quit
fsmo maintenance: transfer pdc

[...]

Les paramètres dans le registre s'ajustent-ils en conséquence ?

Non, les paramètres ne changent pas (ce sont les mêmes que ceux que vous voyez dans les prises d'écran ci-dessus).

Il faut régler cela manuellement.

Je saisis ces commandes à DC4 (l'ancient PDCe) :

w32tm /config /syncfromflags:domhier /update

net stop w32time
net start w32time


Allons voir les changements dans le registre :



Le paramètre "Type" reprend sa valeur originale (NT5DS au lieu de NTP) alors que le paramètre pour "NtpServer" ne change pas. C'est le paramètre "Type" qui détermine la pertinence du paramètre "NtpServer" . Si "Type" est égal à NT5DS, le DC utilise la hiérarchie de domaine (domhier) pour savoir l'heure qu'il est. Cela est valable même si le paramètre "NtpServer" retient la valeur "time.nist.gov,0x8" (dans notre exemple).



Je saisis ces commandes à DC3 (nouveau PDCe) pour qu'il obtienne l'heure exacte d'une source externe :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update

net stop w32time && net start w32time

w32tm /resync /rediscover

Note : ce sont des variations des commandes saisies plus tôt mais qui produisent le même effet.


Nous pouvons constater que le paramètre "Type" de DC3 est maintenant "NTP" :




***

Désormais, DC3 (le nouveau PDCe) obtiendra l'heure de la source externe et DC4 obtiendra l'heure de DC 3 (comme tout autre DC). Les autres clients, tant serveurs que stations de travail, obtiendront l'heure du DC qui les authentifie au moment de l'ouverture d'une session sur le réseau. Cela vaut, bien entendu, pour les membres du domaine. Ce système de synchronisation horaire ne serait pas valable pour les clients qui ne s'authentifient pas auprès d'un DC.

Sunday, October 11, 2015

Office 365 with OneLogin: Part 4

In this blog post, I'll take a look at the user experience with OneLogin: how does the user connect to their Office 365 mailbox using either Outlook Web App (OWA) or Outlook, now that OneLogin is providing our SSO services?

***

For SSO with web browsers, there is a pre-requisite: we must install, manually or otherwise, a browser extension (or addon) for the browser in question on the client machines. I'll keep it simple and use Internet Explorer 11 (IE 11) as an example.


Installing the OneLogin browser extension

First, we can download the addon here:

Internet Explorer extension

Note: we would have to install the addon with an administrator account or use some software deployment solution if a manual install is not practical, because of, for example, the number of client machines. There is a wide variety of software deployment solutions, even one of which would go beyond the scope of this post. Once again, I will simply install the addon manually.


Once the extension (or addon) is downloaded, we simply double-click on the executable to begin the installation and then click "Next", keeping the default options (first three screenshots):







Click on "Finish" (etc.) to complete the installation.



User experience with Internet Explorer / OWA


For this blog post, as I stated above, I will use Internet Explorer 11. For the end-user, versions 9 and 10 are supported as well as the latest version of Chrome, Firefox and Safari. Please see OneLogin documentation (or contact tech support) for further details.

When the user logs on and opens IE, they may see a notice stating that the OneLogin addon is ready for use (click to enlarge):



If this happens, they should simply click "Enable".


The preferred method to access your Office 365 app via OneLogin is to use the following URL:

https://yourdomain.onelogin.com

So if your domain is contoso.com, you enter:

https://contoso.onelogin.com

Instead of entering this URL manually, it would obviously make more sense to create a desktop shortcut or add the link to favorites. For example:




If everything is configured correctly (as described in the previous blog posts), this should take the user directly to the OneLogin "App Home" page where they will see (in our scenario) the Office 365 icon:




Note: for best results, we should assign the appropriate apps (in our case, Office 365) to the user before they logon. This task was completed in Part 2 of this series.


All we need to do at this point is click on the Office 365 icon and after a moment we are in:



It's then a simple matter of clicking on the Mail, Calendar, People (Contacts) or Tasks icon depending on what we want.


***

It is possible to use the URL www.onelogin.com by entering it manually or with a shortcut:



This is a little less efficient however. It brings us to the OneLogin home page where we have to click on the "LOG IN" link in the upper right-hand:

Simply clicking on the link will take us to the App Home page but we do have to click - unlike with the previous method that takes us directly to the App Home page without the detour to the company home page.



User experience with Outlook

The directions provided by OneLogin for the Outlook configuration assume that Outlook is installed after OneLogin has been configured:


In my case, the Outlook client was already configured to access Office 365 and I first thought it was necessary to reconfigure the Outlook profile (perhaps making it contact OneLogin first... somehow).

Although the directions seem to suggest Outlook will be connecting "through OneLogin" and provide an example of a URL ( some.one@oneloginchannel.com ), we actually need to use our own  domain name. So if our domain name was contoso.com (and if that was the domain used for our email addresses), we would enter the user name as:

user.name@contoso.com

Note: to reach this point, we follow the procedure to configure an Outlook profile (please refer to online documentation if you need more guidance):








Note: where do I enter the user's password? I see where in the OneLogin document reference earlier but there is no place to do so in the screenshot above. I discovered that if I backspace and remove the last letter of the email address (and then retype it), two text-boxes for the password appear,

 If we click "Next" as needed, we should see a confirmation message like this, with green check marks:




One important note: if you have a hybrid Exchange environment, your Exchange server(s) must be on when executing the steps above. Unlike the web interface, Outlook will interact with the onsite Exchange servers even if the mailbox in question is located in Office 365.


Once I complete the steps above, I can open Outlook and see my email messages.




Saturday, October 3, 2015

Office 365 with OneLogin: Part 3

Below, I have presented the necessary steps to configure Office 365 SSO (Single Sign On) with OneLogin.

Please note that even before completing what follows (but after completing the steps in my two previous blog posts), I was able to connect to Office 365 via the OneLogin website, although SSO was not yet functional.

Indeed, I had to enter my credentials a second time to connect to OneLogin. Once connected, I could click on the Office 365 icon and connect to Office 365 - this time without (re-)entering credentials.

I used the these directions as a guide:

CONFIGURING DESKTOP SSO


***

First, I want to enable SSO. I accomplish this by logging on to the OneLogin website at www.onelogin.com and going to "SETTINGS | Desktop SSO":




The next step (below) requires the assistance of OneLogin tech support. We check the option "Basic Settings - Enable" and inform OneLogin of the IP address(es) of our local site (or sites). Someone from OneLogin will enter the IP address(es) that will display in the text box below (mine have been edited out for confidentiality):


Note: mobile devices are not present in my test environment so I did not check the last option. Contact OneLogin tech support for more information.

We then enter the "redirect URL" that OneLogin will consult when a request for authentication is made, apparently using the connection established by the server running the Active Directory Connector (ADC). Indeed (and after "http://), we enter the name of the ADC server (simply "ADC" in my case), followed by the port and then "/onelogin/idp". So...

http://ADC:8080/onelogin/idp



Note: steps 1 and 2 (in the screenshot above) refer to a script and documentation to modify Windows Authentication. I was able to make SSO work by simply entering the URL (no need for the script). The script seems to be most useful if you want to use IIS in a scenario presented in this OneLogin document (with a comments section):

CONFIGURING DESKTOP SSO USING A REMOTE AUTHENTICATION SCRIPT IN IIS

As for the Account ID and Remote Token, these two boxes were already populated for me. I have edited out the values for confidentiality.

There is one very important remark to make at this point. Once Desktop SSO is enabled, you may not be able to logon to OneLogin directly with the credentials used to create your OneLogin account. This is because OneLogin now refers authentication requests to your on-premises Active Directory via the server with the Active Directory Connector. If the user does not exist in Active Directory, logon will fail.

There is a solution. Connect to OneLogin using the following type of URL...

https://yourdomainname.onelogin.com/login?remote=off

Where your domain would be the name of your domain minus the .com, .org, .edu or .net (etc.) at the end. Using the well-known fictitious Microsoft domain "contoso.com", that would be:

https://contoso.onelogin.com/login?remote=off

So contoso without the .com.

***


The steps outlined above enable SSO. I will present the user experience in a later blog post.

The following steps seem improve the SSO experience. When I attempted to login to Office 365 (via OneLogin) using a web browser (IE 11), I was not required to re-enter my credentials at any time (the initial login to my Windows desktop client machine was enough). However, the Office 365 logon portal displayed and there was a perceptible delay at this point, even though, ultimately, the logon process to O365 completed with no further manual intervention on my part.

After completion of the following steps, there was no delay at the Office 365 logon portal. The process seemed more efficient, more "streamlined". One of the steps also enables provisioning Office 365 via OneLogin rather than DirSync (the native Microsoft tool).

Note: this is optional. You can use DirSync if you prefer. Consult the documentation for the advantages and disadvantages of the respective options.

I used these directions as a guide for the next steps:


Note: take notice of the pre-requisites listed in the "Before you begin" section.

If you are not familiar with OneLogin and SSO, it might be best to start with this article and then follow the "Next Topic" link at the bottom of each page for a complete overview of the process:

Introduction to Office 365 Integration with OneLogin


So I log on to the OneLogin site (use the alternate URL presented above if necessary) and go to the APPS tab where I select Office 365. This displays the screen below, which includes several tabs as well. I first go to the Configuration tab:


Although I have edited out my personal information above , we would enter:
  1. Our organization's registered domain, for example: contoso.com
  2. An Office 365 account name (a global administrator account is recommended).
  3. The password of this account.

We would use the following format for the "API user name":

A_GlobalAdminAccount@yourSubDomain.onmicrosoft.com


So, using the same fictitious example as above:

globaladmin1@contoso.onmicrosoft.com

We then click on the blue "Connect" button (notice that the default status is "Not Connected" (in red).



That opens the Microsoft Azure assistant (or wizard) where we logon to Office 365...






And grant access OneLogin access to Office 365:




If all goes well, the status of the "API Connection" should change to "Connected" (in green):




Moving to the Parameters tab, we map Office 365 attributes to OneLogin attributes. Three are required and (at least in my case) were already configured by default:


Note: the settings highlighted above are appropriate for the  "Active Directory without DirSync" scenario. In fact, I will use OneLogin's provisioning system rather than Microsoft's native DirSync tool (which is an option however). Moreover, you can map other attributes as well. Consult the OneLogin documentation (or tech support) for additional information.


Next, I will adjust settings under the SSO tab.

Note: I will not present all tabs and related information since not all are necessary for the configuration of SSO. 


In this section, we will enable WS-Federation with SAML. Go to the SSO tab and read the important notice: ensure that your domain, API username and API password are correct and that you are connected (see Configuation tab):


Then click on "Enable automatic SAML configuration" (above).


The following message displays, essentially reminding us once again that the domain, API username and API password must be correct. Click on continue:



OneLogin federates your account with Office 365:


Note: it can be defederated if necessary.

At this point, we should test the app by attempting to access our email via Outlook or OWA. I'll skip that part here and present it in my next blog post. If I can access email (or another Office 365 feature) then I have finished this task and can click on "Yes. I'm Done":




There is one last section (tab) to configure if we are using OneLogin to provision users in Office 365 rather than using the native Microsoft DirSync tool. This section can be found under the "Provisioning" tab:


Click the "Enable" option (see above) to use OneLogin provisioning.

The other options were already checked by default.

One reminder: if you intend to use OneLogin instead of ADFS and DirSync, disable these services as described in my two blog posts dedicated to these subjects (they precede the series of blog posts on OneLogin). Of course, if you intend to use DirSync, you would leave the option unchecked and would not have disabled directory synchronization in your Office 365 tenant.

 ***

In my next blog post, I will present the user experience (what the user sees when they attempt to connect to Office 365 via OneLogin).