Sunday, December 18, 2016

PKI - ADCS: certificate revocation (review)

In my last two blog posts, I reviewed methods for the verification of PKI / ADCS health and then encountered (and later resolved) a problem with the publication of the CRL (certificate revocation list). I wanted to take that opportunity to review some of the fundamental aspects of certificate revocation, which is what I will do in the following paragraphs.


The "revocation" of a certificate prevents the use of the certificate in question.

The revoked certificate can no longer be used for its assigned role: client authentication, server authentication, code signing, etc..

When we revoke a certificate, the serial number of the certificate is added to a list called the "certificate revocation list" or "CRL"). This list is digitally signed by the certificate authority (CA) and published to the locations indicated in the CDP properties. This is usually a web share (the "http" location) and optionally in Active Directory (the "ldap" location):

Just like a certificate, the CRL has a validity period. However, this period is much shorter, often only a single day or several days. The CA must publish a new CRL at regular intervals to replace the previous CRL that has expired.

There are two types of revocation lists:
  • Base CRL: a complete list of certificate serial numbers revoked by the CA.
  • Delta CRL: a list of certificates revoked since the last base CRL publication.

Applications will verify certificates presented to them by consulting the CRL and reject any certificates on this list.

We can revoke a certifcate in the Certificate Authority MMC:

Unlike certificate expiration, which prevents the use of a certificate outside its validity period (and notably after), certificate revocation prevents the use of a certificate even if it has not yet expired.

Reasons for certificate revocation

A certificate may be revoked for a number of reasons. Here are some examples.

Loss of the private key (by theft or negligence)

The mobile device (laptop, tablet, smartphone) of a user is lost or stolen. The private key, stored on the device (by default), could be recuperated by someone with malicious intent. Since PKI consists in the interaction of the private and public key, we prevent this interaction by revoking the certificate containing the public key of the computer or user.

Compromise of the issuing CA

If the CA has been compromised, and notably its private key, an attacker could use that key to set up a new CA and issue certificates trusted by clients that trust the original or "real" CA. We would revoke the certificate of the compromised CA which would invalidate all certificates issued by the CA (since no certificate issued by this CA - or its clone - should be trusted).

Retired users and devices

When users retire or equipment is retired, it is best practice to revoke the associated certificates.

Replacement of old certificates with new certificates

We may need or want to replace old certificates with new ones. In this case, it is best practice to revoke the old certificates.

When we revoke a certificate, we can (and should) indicate the reason for which we are revoking the certificate:

Revocation is an irreversible act for all these reasons except "Certificate Hold". Although possible, it is not recommended to revoke certificates temporarily because it is difficult to determine at what time(s) the certificate was valid.

Note: it is better to revoke certificates based on a policy.

We must not decommission a CA if the certificates it issued are still meant to be used. Those less familiar with PKI may ask: "But why not? I'll just use some other CA to issue certificates in the future." We should remember that a CA not only issues certificates but also publishes a CRL of certificates it has revoked. If the CRL is not renewed at the interval determined at installation, the CA will no longer function. This is what we observed in a previous blog post. Please see the "Remarks" section below for more details.

Who can revoke a certificate?

Users granted the "Issue and Manage Certificates" permission. By default, administrators of the CA have this right. Domain and Enterprise administrators posess it as well.


The CRL is signed by the CA that publishes it.

This is very important concerning redundancy. When checking the revocation status of a certificate, we can only use the CRL published by the CA that issued that certificate. We cannot simply fabricate a list of serial numbers and make it available on the network. Once again, the CRL must be signed and only the signature of the same CA that issued the certificates to start with is valid. Clients cannot simply consult the CRL published by another CA.

If the CA is unavailable for a time exceeding the CRL validity period (plus whatever grace period - or "CRL overlap" - we have configured) the CA will go offline and stop functioning.

Note: we can obtain redundancy if we configure CA clustering which is an entirely different subject.

The Delta CRL is almost never necessary.

The client downloads the CRL associated with the certificate that it must validate. The file is so small (in KB) that there should be no effect on bandwidth, especially with 1 Gb or 10 Gb links. It is only if the CRL is exceptionnally large (this is apparently the case in some defense sectors) that a delta CRL may be useful.

Clients cache the CRL locally

 They only download the new CRL when the cached CRL expires.

This is advantageous concerning network bandwidth but creates a gap during which a very recently revoked certificate could still be accepted.

Imagine that the CRL is published at 12:01 AM (00:01) every day (so every 24 hours which is rather frequent). If a certificate is revoked at 12:05 AM, clients will only be informed almost 24 hours later. In the meantime, they will continue to use the cached CRL which does not contain the serial number of the very recently revoked certificate.

Each organization must evaluate the risk of such a delay versus the load on resources and notably bandwidth. Unless the CRL is very large, the effect on current systems should be negligeable.

We can see what is in the CRL cache with this command:

certutil -URLcache CRL

We can purge the CRL cache with this command:

 certutil –setreg chain\ChainCacheResyncFiletime @now

CRL overlap

When we set up our PKI, we can configure what is called "CRL overlap" with the post installation script . This is a sort of grace period during which our PKI will continue to function even though the CRL has expired. This might provide sufficient additional time to resolve a problem.

These are the CRL overlap settings that I configured for my subordinate CA in my first series of PKI blog posts:

certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod "Days"

The overlap period cannot be longer than the validity period of the CRL. If the validity period was 3 days (which is what I configured elsewhere in the script), the overlap period could be 2 days at most.

OCSP (Online Certificate Status Protocol)

With this protocol, a client can validate single certificates as needed, via a web service, instead of downloading a CRL with the entire list of revoked certificates (most of which may not interest the client).  This is an optional function and I will not present it in this blog post.

Tuesday, December 13, 2016

PKI - ADCS: Health Check - part 2 (problem resolution)

We encountered a problem with Active Directory Certificate Services in my previous blog post:

In this blog post, we will attempt to resolve it.


So what was the problem?

It looks like the CRL of the root CA has expired (it was published in two places - on a web share (http) and in Active Directory (ldap)):

What about the CRL of the subordinate CA?

It is hard to see because the subordinate CA (issuing CA) is offline and no details are displayed:

But let's look in some other places, like "Manage AD Containers" (please consult the previous blog post if you do not know what or where this is). Everything looks fine until I come to the "CDP Container" tab:

I notice that both the CRL published by the root CA and the CRL published by the subordinate CA have expired. Both CAs will have to publish a new CRL and we will have to copy (by one method or another) the offline root CA's CRL to the subordinate CA.

Even so, I'm wondering if I cannot start the ADCS service and obtain more information?

The short answer is... No.

At one point, I attempted to start the service. This fails: 

Note: if we had not already determined that the expired CRL(s) is the problem, the reference to the revocation function is yet another pointer in this direction.

I attempt to publish the CRL on the subordinate CA. Maybe we can update the CRL at this level and make at least some progress?

Note: seriously, I would not have bet much on that option since the ADCS service is not even running...


We could (but should not) disable revocation checking.

First of all, does it even resolve the problem?

We disable revocation checking with this command (and then restart the ADCS service):

certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

At first glance, this seems to improve matters.

After restarting the service, the subordinate CA is able to publish a new CRL (I repeated the same process as above) and I can expand the PKI Health Check tool:

Note the green check on the "Machlinkit Issuing CA" and compare with the previous screenshots.

At least the CRL of the issuing CA is up-to-date (status is OK from top to bottom):

But this is not a good solution for several reasons:

It only disables revocation checking on our subordinate CA. All other clients will continue to attempt to consult the CRL (which will result in failure since the CRL of the root CA is still not available).

Even if we were stubborn and disabled revocation checking on all clients (perhaps with a registry edit via Group Policy), we would prevent a critical security function from taking place. It would be impossible to reject compromised certificates. If the credibility of our PKI is important, disabling CRL would precisely destroy this credibility.

As it is very poor practice to disable revocation checking, I will re-enable it with this command:

certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

As you might have expected (if you realize that both CRLs must be valid - 1 out of 2 is not enough), the subordinate CA goes offline again, once revocation checking is re-enabled and the ADCS service (certsvc) restarted.

We must publish an updated CRL from the root CA. There is no (acceptable) method to avoid this.

So I start and logon to the offline root CA (in my case, this is a virtual machine with no network adapters).


Once we have logged into the root CA, we can trigger the publication of a new CRL with one of two methods...

At the command line:

certutil -crl

Or in the Certificate Authority MMC:

We attempted this in one of the screenshots above - it's the same place and process on the root CA. We then copy the CRL file to the subordinate CA with removable media ((virtual) floppy, USB, etc.).

Note: it is worth specifying that the new CRL published on the root CA can be found in this location:


We will copy (or publish) the CRL file to three locations on the subordinate (issuing) CA:
  1. The (local computer) certificate store of the subordinate CA
  2. The web share indicated in the CDP record.
  3. Active Directory

The web share is the most simple operation. It is a matter of copying the CRL file to the location indicated:

I predict that if the CRL is available even in one location, the subordinate CA will detect it when I restart the ADCS service.

This is indeed what happens.

If we expand PKI View to the issuing CA, we notice, first of all, that we can descend to this level now, even though revocation checking was re-enabled. We also notice (see the screenshot below) that the CRL in the http location has a status of OK:

However, the CRL published to Active Directory is still in the "expired" state.

We still need to publish the CRL of the root CA to the local computer store of the subordinate CA as well as Active Directory. The commands below allow us, respectively, to achieve that double objective:

certutil -addstore -f Root C:\PKI\PKI-ROOT-CA.crl

certutil -dspublish -f C:\PKI\PKI-ROOT-CA.crl

Of course, you would adjust the path to the CRL to indicate the location to which you copied the CRL of the root CA.

Here is a screenshot of the operation:

Now if we consult the PKI Health Check tool, the status is OK for the entire system and the Machlinkit issuing CA is online (note the green check):

Sunday, December 11, 2016

PKI - ADCS: Health Check - part 1

In February and March 2015, I dedicated nine blog posts to the subject of Public Key Infrastructure with Active Directory Certificate Services.

This was the first of nine posts:

PKI (Public Key Infrastructure) with ADCS, Part 1: Introduction

At this time, I am reviewing some PKI best practices and verification of PKI health with various tools, in particular the PKI Health Tool (or "PKI View").

The subject was in fact already adressed, albeit indirectly, in my original series on posts on PKI:

PKI (Public Key Infrastructure) with ADCS, Part 7: configuration of the subordinate CA

Although I had addressed (very briefly) troubleshooting errors revealed by the PKI Health Check tool, I wanted to take advantage of this review to present a problem that will occur a year or so after the initial PKI installation if we do not manage our certificate services with diligence (expiration of the Root certificate CRL - "certificate revocation list"). In a blog post to follow, I will demonstrate the solution to this problem.


We should verify our PKI after installation (which I did as shown in the second link provided above) and at regular intervals later.

In particular, we want to determine if clients can access certification authority (CA) certificates and certificate revocation lists (CRLs).

Note: I'll use the terms "CA" and "CRL" in the rest of this blog post for concision.


Clients need to access the certificate of the CA that issued the certificate being verified as well as the certificate that provided the issuing CA with its own certificate. This process establishes a "chain of trust" and validates the "certification path" from the certificate being verified to the root CA of the PKI that produced the certificate in question.

We can see this "chain" when we open a certificate and look at the "Certification Path" tab.

Moreover, clients need to access the CRL to see if the certificate has been revoked.

  • The client uses the URL indicated in the certificate's AIA extension (Authority Information Access) to download the certificates needed to establish the chain of trust.
  • The client uses the URL indicated in the certificate's CDP extension (CRL Distribution Point) to access the list of revoked certificates that can no longer be trusted.

PKI Health Tool

If we want to verify the health of the PKI overall (rather than a specific certificate) we can use the "PKI Health Tool". Previously a down-loadable utility, it is part of the Active Directory Certificate Services (ADCS) role since Windows Server 2008.

We can access it in various ways.

We can enter pkiview.msc in the run dialog box and open the tool.

We can also open Server Manager, expand the Roles section: ADCS | Enterprise PKI

At the top level (PKI-ROOT-CA) we can see (in the first example below) that the status is OK. This takes into account all layers below.

Note: there is a green check on the icon of the issuing CA as well. This is always a good sign.

But what if there is a problem? Here is another example:

But what, exactly, is not right?

We need more details. At what level is the problem happening? Is it a problem with one of the CA certificates or with one of the CRLs?

So let's expand the structure and descend to the next level...

We can see the certificate of the Root CA (which is OK). We can also see that the Root CA certificate (necessary for certificate chaining) is available at both the http and ldap locations. On the other hand, the CRL for the Root CA, while available, has expired. Such an error has serious consequences as we can see when attempting to view the details of the subordinate (issuing) CA:

The issuing CA is offline and our PKI is no longer functional.

Note: I demonstrate how to correct this in a future blog post.

Some remarks...

The error icons have color codes that reflect (more or less) the severity of the problem:
  • Yellow - the CRL is expiring (but not yet expired).
  • Red - the CRL has expired or the AIA/CDP location cannot be accessed.
  • Red X - the CA is offline.

The status column provides more details about the error. Besides "OK", we may see:
  • Expiring - the certificate or CRL in question is expiring.
  • Expired - the certificate or CRL in question is expired.
  • Unable to download - the certificate or CRL in question could not be downloaded.

We should also note that we can adjust the number of days or hours for the certification expiration status.

We right-click on the Enterprise PKI icon and select Options

Besides viewing the Certificate Templates (which I would usually access through the Certification Authority MMC), we can view the "AD Containers" that hold certificates:

This can be useful for troubleshooting. In the screenshot above, the status is OK for all certificates in the AIA container. In the next blog post, we will see errors for a CRL in the CDP container.

Server Manager - Active Directory Certificate Services role

In the Active Directory Certificate Services role section of Server Manager, we have access to three useful tools:

  1. Event Viewer (filtered for ADCS related entries).
  2. System Services (where we can verify that services necessary for ADCS are running). Like for Event Viewer, this is the Services administrative tool (services.msc) filtered for ADCS related entries.
  3. ADCS Best Practices Analyzer.

Here is a view of the first two tools (yes, "Events" can be expanded):

The ADCS BPA is rather limited (at least in Windows 2008). There are only 8 checks, for example:


The tools presented so far are graphical tools. We can also use the certutil command line utility, especially if we require a high level of detail.

For example, we viewed a certificate earlier and validated the "chain of trust" to the certificate of the root CA. We can view (and save or output to a text file) much of the background certification validation process with certutil and in particular the following commands:

  • certutil -verify -urlfetch NameOfCert.cer
  • certutil -URL NameOfCert.cer

The output of the first command is quite verbose, possibly as long as this entire blog post. Therefore, I will only present a very brief sample here:

In the section above, certutil validates the AIA and CDP information of the certificate that was designated.

The second command opens a window where we can select various options and verify the URL for the AIA and the CDP (these were presented above):


This concludes my review of some of the tools we can use to verify the health of our Windows ADCS PKI. Although not presented in this blog post, we should remember that ADCS has numerous logging options which could also prove useful in the management and troubleshooting of a PKI. In a future blog post (probably the next one), I will demonstrate how to resolve the problem that caused our subordinate CA to go offline.

Monday, December 5, 2016

Exchange 2016 CU3 - updated pre-requisites, Active Directory preparation... and a word of caution.

This is my first blog post about Exchange 2016 CU3 (cumulative update 3). In fact, I had composed a blog post about the installation of the pre-release version of Exchange 2016 on July 26, 2015. In  an effort to avoid needless repetition, I will refer the reader to that blog post for general information about hardware and software pre-requisites. Only updates or corrections will be presented below.

Exchange 2016 (Preview) - original blog post on preview version

Here is the link to the Exchange 2016 system requirements:

Exchange 2016 system requirements

In the following paragraphs, I will concentrate on changes in system requirements since my original post in July 2015.



No significant changes

Operating system

Besides Windows Server 2012 and 2012 R2, the most recent Microsoft documentation lists Windows Server 2016 (Standard or Data Center) as a supported operating system on which Exchange 2016 can be installed. However, for Server 2016, the minimal version of Exchange 2016 is CU3.

In the title to this post, I implied there would be a word of caution (a warning) and here it is...

Although Windows 2016 Server is officially supported, a very serious problem affects Exchange 2016 on this platform when the server is part of a Database Availability Group (or "DAG"), so serious that Microsoft recommends that we do not install Exchange 2016 (CU3) on Windows 2016 Server. We should use Windows 2012 R2 instead.

You can read the statement made by the Microsoft Exchange team on their blog "You Had Me At EHLO":

The message was posted on November 4th, 2016 and as of December 5th no solution has been announced (besides the recommendation to use Windows 2012 R2 instead).


Windows 10 is now supported for Management Tools.

Active Directory

No significant changes except the addition of Windows 2016 domain controllers as supported domain controllers.

Coexistence with previous versions of Exchange

The minimal versions of Exchange 2010 and 2013 are currently:

  • Exchange 2010 SP3 Rollup 11 (Rollup 15 is the latest rollup at the time of this writing)
  • Exchange 2013 CU10



I will change the installation order for the Exchange 2016 pre-requisites and Active Directory schema extensions (compared to the order in my blog post on the Exchange 2016 pre-release).

All the actions below were taken on the future Exchange 2016 server (unless otherwise indicated).

Note: this server is a domain member with TCP/IP settings configured for such an environment. I will not detail the basic configuration of the server here. We should also make sure that we connect as a user that not only has administrative rights to the server itself but also has the status of domain, enterprise and schema administrators. In particular, this is necessary for the preparation of Active Directory. 

Step 1 - Install required roles and features

On the future Exchange server, we open a PowerShell prompt and execute the following command:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Note: yes, you can copy and paste. No need to retype!

Step 2 - Install .NET Framework 4.5.2

My test server is running Windows 2012 R2. If you are using a different operating system, check the system requirements for the proper .NET version. I have found that Windows Update installs this version of .NET on Windows 2012 R2 (at least if you select it...). Otherwise, download the offline installer.

.NET 4.5.2 Offline Installer

Step 3 - Install "Unified Communications Managed API"

Unified Communications Managed API 4.0 Runtime

Step 4 - Prepare the Active Directory schema

First, we download the Exchange 2016 CU3 installation files on the future Exchange 2016 server...

Cumulative Update 3 for Exchange Server 2016 (KB3152589)

After navigating to the location where we saved the files, we execute this command:

setup /ps /IAcceptExchangeServerLicenseTerms

Note: /ps is a shortcut for /PrepareSchema.

At first, I attempted to install Exchange 2016 CU3 in an existing Exchange 2010 SP3 / Office 365 hybrid environment and encountered an error:

A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: "Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML". Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows "/TenantOrganizationConfig MyTenantOrganizationConfig.XML".

Error when you run Setup /PrepareSchema to prepare the schema for an existing Exchange hybrid environment

So we have to do two things:

  1. Create the MyTenantOrganizationConfig.xml file.
  2. Re-run the command with the /p (or /PrepareAD switch) instead of the /ps switch AND add the /TenantOrganizationConfig switch, designating the .xml file created in step 1.

This was the detailed solution:

Exchange 2010 hybrid environment - Get-OrganizationConfig

But I was still not able to upgrade the schema and prepare Active Directory.

Once again, I will refer the reader to the TechNet discussion that finally resulted in a solution:

MyTenantOrganizationConfig error

However, I will summarize...

After consultation with someone from Microsoft, I disabled the hybrid detection function with a registry change at the following location on the (future) Exchange server:


Note: create the keys when necessary.

Here is the registry change (yes, REG_SZ):

Disabling hybrid detection allowed the setup /PrepareAD command to complete.

I have to hope this will not cause other problems in the future.


Now I am ready to install Exchange 2016 CU3.

However, I will wait to do so in my hybrid environment because my priorities have very recently changed and I need to experiment with some aspects of Office 365. I'm not sure what effect installing Exchange 2016 would have. If it forced me to manage the hybrid environment from Exchange 2016 (and not Exchange 2010 anymore), my testing with Office 365 may produce inaccurate results.

Because of this, I will probably (after all the above...) opt to install Exchange 2016 in another ("clean") test environment so I can continue experimenting with the functions of Office 365 that interest me.

Tuesday, November 29, 2016

CentOS - 15 : système de fichiers - arborescence

Je ne savais pas comment titrer ce billet de blogue...

Il s'agit de présenter la hiérarchie du système de fichiers qui se ramifie à partir de root ou "/".

Voici une liste des répertoires qui se trouvent à la racine de l'arborescence :

Dans les paragraphes suivants, je veux présenter chacun avec une description plus ou moins concise.


Ce répertoire contient des binaires importants comme :

  • cat
  • cp (copier fichiers ou répertoires)
  • date (afficher la date et l'heure)
  • hostname (afficher le nom d'hôte de la machine)
  • ls (afficher le contenu d'un répertoire)
  • mkdir (créer un répertoire)
  • mount (monter un système de fichiers)
  • mv (déplacer ou renommer un fichier)
  • pwd (afficher l'emplacement dans l'arborescence où l'utilisateur se trouve)
  • rm (supprimer un fichier)
  • rmdir (supprimer un répertoire)
  • su (changer l'identité de l'utilisateur)
  • umount (démonter un système de fichier)

Les noyaux (shells) comme bash s'y trouvent aussi.


Ce répertoire contient des fichiers nécessaires pour le démarrage. Cependant, les fichiers de configuration pour les chargeurs de démarrage (boot loaders - comme GRUB) résident dans le répertoire /etc. Qui plus est, d'autres fichiers, dont certains servant à faire démarrer ou éteindre la machine, se trouvent dans le répertoire /sbin (présenté plus bas).

Le noyau système se trouve ici.


Ce répertoire contient les fichiers représentant les périphériques branchés à la machine : les disques durs, les lecteurs de CD/DVD/disquettes, carte son, clavier et souris. Le premier disque dur de type SCSCI sera /dev/sda et le second /dev/sdb, par exemple.

Ces fichiers se créent de manière dynamique lors du démarrage du système d'exploitation et au fur et à mesure que les périphériques sont détectés. C'est le service udev qui s'en occupe.


Ce répertoire contient tous les fichiers de configuration du système. Ce ne sont pas des fichiers binaires qui se trouvent ailleurs, dans /bin, ou dans /sbin par exemple.

Note : le répertoire /etc/sysconfig est spécifique à RHEL/CentOS.

Quelques exemples :


C'est un fichier qui associe un nom d'hôte à une adresse IP.


Ce sont des fichiers pour le serveur web Apache.



Ce répertoire contient les répertoires personnels des utilisateurs, donc un sous-répertoire pour chaque utilisateur. Ce répertoire peut devenir assez grand si on y entrepose des images ou des extraits vidéos.

lib et lib64

Ces répertoires contiennent des "bibliothèques" que le système utilise en exécutant les programmes dans /bin et /sbin. S'il s'agit d'un système à 32 bits, il utilise /lib mais /lib64 pour les systèmes à 64 bits. Ce sont les équivalents des .dll dans le monde de Windows.

media et mnt

C'est le point de montage par défaut où nous pouvons monter des systèmes de fichiers ou des périphériques, /mnt/floppy ou mnt/cdrom par exemple. /media est pour les lecteurs de CD/DVD et USB. /mnt est plutôt pour les systèmes de fichiers.


C'est pour les logiciels qui ne font pas partie du système d'exploitation, des programmes de bureautique (traitement de texte, etc.) de tierce partie par exemple.


Ce répertoire contient ce qu'on a décrit comme des "pseudo-fichiers" qui montrent l'état du noyau (shell).


C'est le répertoire "personnel" de root. Il s'agit, paraît-il, de garder tous les éléments de root dans un répertoire plutôt que de les voir s'accumuler à la racine proprement dite, soit "/".


Ce répertoire contient des programmes (ou "binaires") pour la gestion du système d'exploitation, et en particulier pour le démarrage, la fermeture, et l'administration des disques. Parmi ces binaires, nous comptons :

  • fdisk
  • fsck.* (vérification des disques)
  • grub
  • ifconfig
  • mkfs.* (remplacer l'astérique par les différents systèmes de fichiers : ext3, ext4, xfs, par exemple).
  • reboot
  • shutdown

En effet, Linux distingue les binaires en général et les binaires pour l'administration du système, les premiers se trouvant sous /bin et les seconds sous /sbin.

sbin signifie "system binaries".

Mais ce n'est pas tout...


D'autres binaires peuvent se trouver sous /usr/bin et /usr/sbin ou encore /usr/local/sbin.

Voici quelques exemples :

  • ftp
  • telnet

Ce sont donc des binaires pour les utilisateurs à la différence des binaires pour le système, même si la distinction n'est toujours évidente.

Autrefois, il paraît que /usr contenait tous les objets associés à l'utilisateur y compris ceux qu'on mettrait plutôt dans /home aujourd'hui.


C'est ici que CentOS enregistre les fichiers temporaires. De temps en temps, le contenu de ce répertoire est effacé (Je ne sais pas à quelle fréquence). Ce répertoire peut se trouver sur un système de fichier spécial nommé tmpfs (encore une différence avec Windows).

Note : oui, je sais que l'ordre alphabétique n'a pas été respecté parce que je voulais faire mettre /sbin et /usr l'un après l'autre, s'agissant tous deux de répertoires de fichiers binaires, et seulement ensuite /tmp.


Le répertoire /var contient des fichiers de taille "variable" d'où son nom. Il s'agit, par exemple, de fichiers associés à l'impression (le fichier "spool"), à la journalisation, et apparemment de fichiers temporaires qui ne résident pas dans /tmp.

Saturday, November 12, 2016

CentOS - 14 : systèmes de fichiers

Les systèmes de fichiers servent à organiser le stockage des données sur un support comme les disques durs ou les médias amovibles (disquette, clé USB) et à présenter ces données à l'utilisateur.

CentOS 7 est capable d'utiliser divers systèmes, comme, par exemple :
  • ext3
  • ext4
  • XFS
  • GFS2
  • swap

En ce moment, XFS constitue le système de fichiers par défaut de CentOS 7. Il possède toutes les qualités d'un système de fichiers moderne : journalisation, défragmentation et optimisation pour les fichiers de grande taille.

Autrefois, ext3 et ext4 étaient les choix préférés, et encore aujourd'hui ext4 reste une option tout à fait sérieuse. Comme XFS, il offre les fonctions de journalisation et de défragmentation (ce qui manque à ext3).

GFS2 est pour le stockage SAN.

Le système de fichiers swap est adapté spécialement pour les partitions swap dont le rôle correspond au fichier de pagination sous Windows. Dans le monde de Linux, cependant, il ne s'agit pas d'un simple fichier de pagination mais d'une partition de disque avec un système de fichiers conçu exprès pour cette fonction.

Note: il est possible d'utiliser un simple fichier sous Linux aussi mais cette solution serait moins efficace.

A ce sujet, il est recommandé d'avoir une taille de partition swap 2 fois la quantité de mémoire vive pour une quantité de mémoire vive jusqu'à 2 Go. Au-delà, la recommandation est d'égaler la quantité de mémoire vive plus 2 Go.

Comment créer un système de fichiers ?

Avec la commande mkfs

Nous ajoutons un point (.) suivi par le type de système de fichiers souhaité, et puis, la partition où nous voulons créer le système, par exemple :

mkfs.xfs /dev/sdb1

mkfs.ext4 /dev/sdb2

Nous pouvons donner une étiquette avec le paramètre -L :

mkfs.ext4 -L /databases /dev/sdb2

Et voilà, les partitions sdb1 et sdb2 ont désormais un système de fichiers.

Mais dans le monde de Linux, cela n'accomplit pas grand chose en soi.

Encore faut-il créer un "point de montage" (mount point), c'est-à-dire un répertoire dans lequel la partition sera montée.

Au fond, il s'agit d'inscrire le nouveau système de fichiers parmi les autres fichiers de l'arborescence. Nous pouvons bien dire "fichiers", car les répertoires, chez Linux, sont simplement des fichiers capables de contenir d'autres fichiers.

Quand nous naviguons dans l'arborescence et entrons dans ce répertoire (le point de montage), nous accédons, en fait, à la partition que nous avons montée (et aux fichiers qui s'y trouvent).

A retenir : c'est le système de fichiers choisi pour la partition qui permet d'y organiser les fichiers et aussi, qui nous permet de les voir et de les manipuler.

A retenir : le répertoire donnant accès au nouveau système de fichiers s'appelle le "point de montage".

Comment monter le système de fichiers ?

D'abord, je crée un répertoire à la racine (root) que je nomme "vol" (ce n'est qu'un exemple - nous sommes libres de choisir le nom qui nous convient) :

mkdir /vol

Les concepts de "partition" et de "volume" sont comparables et, en faisant des recherches sur l'emplacement préféré pour ces points de montage, j'ai lu que certains suivent une norme Macintosh et les mettent dans un répertoire avec ce nom (/vol ou /volume). Ce choix me convient. En fait, nous pourrions nommer le répertoire ce que nous voudrions et le créer ailleurs du reste. On pourrait utiliser le répertoire /mnt mais j'ai compris que certains préfèrent que ce soit réservé aux montages temporaires (?).

Ensuite, je monte le système de fichiers dans notre point de montage (le répertoire /vol) :

mount /dev/sdb2 /vol

Allons voir ce que cela donne.

Nous pouvons observer les systèmes de fichiers montés avec la commande "df". Je vais exécuter la commande avec le paramètre "h" qui signifie, en substance, "humain" ou plus précisément "human readable".

Voici le statut quo avant que j'exécute la commande mount ci-dessus :

Il n'y a que la partition /dev/sda1, montée dans le répertoire /boot.

Note : la partition /dev/sda1 a pour système de fichiers xfs, ce que nous pourrions voir avec le paramètre "T", soit "df -T" :

Et voici ce que nous voyons après :

Nous avons donc monté une nouvelle partition / nouveau système de fichiers : /dev/sdb2 monté dans le répertoire /vol.

Nous pouvons obtenir d'autres renseignements avec la commande mount, sans paramètres mais avec grep pour limiter la sortie aux systèmes de fichiers associé avec (dans notre cas) le répertoire /vol :

Comment éditer le fichier fstab

(Afin que notre système de fichiers soit monté automatiquement à chaque démarrage)

En pratique, nous voudrions le plus souvent que le système d'exploitation monte notre nouveau système de fichiers à chaque démarrage sans intervention manuelle. Cela peut s'accomplir par la modification du fichier fstab auquel le système d'exploitation a recours pour gérer le montage des systèmes de fichiers.

Voici le contenu de ce fichier par défaut (du moins dans mon installation de CentOS 7) :

Note : c'est la commande suivante qui affiche le contenu de fstab:

cat /etc/fstab

Nous devons ajouter notre nouveau système de fichiers en le désignant par un des moyens suivants :

  • le chemin de la partition, par exemples : /dev/sdb2
  • l'UUID de la partition (universally unique identifier - nous le verrons plus bas)
  • l'étiquette (le cas échéant), par exemple : "/databases"

L'UUID est le meilleur choix.

L'étiquette (ou "label") n'est pas obligatoire, n'est donc pas nécessairement présente, et rien n'empêcherait un administrateur inattentif de désigner deux systèmes de fichiers avec la même étiquette.

Quant au chemin de la partition, il pourrait changer si un nouveau disque était branché sur la machine. Supposons, par exemple, que la partition que nous voulons monter soit désignée par le nom /dev/sdb1. Si un nouveau disque était branché, le système d'exploitation pourrait le détecter le premier et lui donner le nom "sdb". Le disque que nous avons connu sous le nom de "sdb" serait désornais "sdc" et la première partition "sdc1". 

Mais comment trouver l'UUID de la partition ?

Avec la commande blkid :

Veuillez vous reporter à la capture d'écran suivant. Nous avons ouvert le fichier fstab avec l'éditeur de texte de notre choix et nous ajoutons l'UUID, le point de montage (/vol), le type de système de fichiers (ext4), certaines options ou le simple mot "defaults" si les valeurs par défaut nous conviennent, et puis (le plus souvent) deux 0 :

  • Il est facultatif d'entourer l'UUID de guillemets.
  • Nous pouvons mettre soit un espace, soit une tabulation entre les éléments de chaque ligne.
La configuration ci-dessous fonctionnerait tout aussi bien :

Après avoir examiné les différentes options fstab, j'en ai conclu que les valeurs par défaut me conviendraient parfaitement bien la plupart du temps et je ne vais pas présenter les autres dans ce billet de blogue. Pour en savoir plus, vous pourriez faire une recherche sur ces termes :

options fstab

Et voici une ressource pour commencer :

Mais qu'en est-il des deux zéros ?
  • Le premier zéro réglait l'archivage de la partition effectué par la programme "dump" et ne sert plus.
  • Le second zéro concerne les système ext* (ext3, ext4), et quelques autres, mais non pas xfs. Il établit l'ordre de la vérification des systèmes de fichiers au démarrage.

Quoi qu'il en soit, quand nous faisons redémarrer la machine, le système de fichiers devrait être monté sans intervention manuelle de notre part, ce qui nous pouvons vérifier avec la commande suivante :


Sunday, November 6, 2016

Office 365 / Exchange Online: management with PowerShell - review of some basic concepts

Preface: I'm taking a break from my recent Linux CentOS 7 posts. While working on an Office 365 problem, I was asked to retrieve some information about my Office 365 tenant using various PowerShell cmdlets. I don't often connect to Office 365 with PowerShell so I thought I would take this opportunity to review some of the basic concepts here.


We can manage our Office 365 subscription with the Office 365 Admin Center and Exchange Online with the Exchange Admin Center.

Note: I will concentrate on Exchange Online. There may be other Admin Centers available depending on your subscription.

Most administrators are probably familiar with the graphic interfaces below.

For example, after connecting to the Office 365 portal, I find myself in the Office 365 Admin Center:

If I go to the icon designated by the red dot in the screenshot (above), I can select Exchange...

And then find myself in the Exchange Admin Center where I can manage the Exchange aspects of my Office 365 subscription :

We can also manage both our Office 365 tenant and Exchange Online in particular via a remote PowerShell connection.

In the lines that follow, we'll see how to establish connections to Office 365 / Exchange Online.


First, I'm going to use a Windows 7 SP1 machine with .Net 4.5.2 and PowerShell version 4:

PS C:\> $PSVersionTable.PsVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

But that is not enough.

Normally, I would enter the following cmdlets:

Import-Module MSOnline

And then...


I would then see the following prompt for credentials:

But this is what I see instead:

Note: click to enlarge.

What is missing?

We need to install the "Microsoft Azure Active Directory module for Windows PowerShell" or simply, the "Azure Active Directory PowerShell Module" (yes, it's the same thing).

Since links may change, I would perform an online search for the module, download it and then install it.

The file was named "AdministrationConfig.msi" when I downloaded it for the last time.

After installation, we may see an icon for "Microsoft Azure Active Directory module for Windows PowerShell". However, once the module is installed, we can use the regular icon for PowerShell also. Both have the Azure Active Directory cmdlets.

We can now connect (we should see the prompt for credentials shown earlier) and can execute Azure Active Directory cmdlets to obtain information about our Office 365 tenant.

Among some of the more useful informational cmdlets (Get-*) are:
  • Get-MsolCompanyInformation
  • Get-MsolDomain 
  • Get-MsolSubscription

I will not post the output here as there is too much information about my tenant.

We can view other MS Online cmdlets with this command:

Get-Command *msol*

or (aliased)

gcm *msol*

For example, we can see users and groups in our Azure Active Directory with these cmdlets:
  • Get-MsolUser
  • Get-MsolGroup
These may be users / groups created in our O365 tenant or synced from on-premises.

We can act on Azure Active Directory objects with the Add-*, New-*, Remove-*, Reset-*, Restore-*, Set-* and other cmdlets.


But what about managing Exchange Online with remote PowerShell?

First, we must set the execution policy to "RemoteSigned" if it is not already.

We verify with this cmdlet:


We set the policy with this cmdlet:

Set-ExecutionPolicy RemoteSigned

If you do not set the policy to RemoteSigned, you will encounter this error:

Otherwise, the set of cmdlets below should allow us to access Exchange Online via remote PowerShell and manage objects (mailboxes, etc.) as needed:

$Cred = Get-credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $Cred -Authentication Basic 

Import-PSSession $Session -DisableNameChecking -AllowClobber

Note: in the link referenced at the end of this post, the parameters -DisableNameChecking and -AllowClobber are not used. It was someone from Microsoft technical support that suggested them to me. I've included a second link below so the reader can see what these parameters do.

Below is an example of a cmdlet we could run, showing some O365 characteristics such as the database (a reference to "db109"), the server name, the organizational unit and the various Office 365 quotas, notably the 50 GB mailbox size:

It is best practice to close Exchange Online sessions with the cmdlet Remove-PSSession, for example:

Remove-PSSession $Session

Note: we have a limit of three remote sessions.

We can see the number of sessions with this cmdlet:


This would close all active sessions:

Get-PSSession | Remove-PSSession

For more information:

Friday, October 28, 2016

CentOS - 13 : disques et partitions - lsblk et fdisk

Disques et partitions sous CentOS

CentOS est compatible avec toutes sortes de disques : IDE/SATA, SCSI/SAS et les plus récents SSD.

Ce sont des fichiers dans le répertoire /dev qui constituent le lien entre le système d'exploitation et les différents disques disponibles. Il en va de même pour les autres périphériques d'ailleurs.

Ces disques (et les partitions) sont désignés de la manière suivante :


  • xx - indique le type de disque dur : hd pour les IDE et sd pour les SCSCI, SATA et SAS.
  • y - indique le disque dur à partir de "a", soit a, b, c, etc..

Un exemple :


C'est le premier disque dur du système

  • N - représente la partition. C'est un chiffre, à compter de 1.

sda1 - C'est la première partition du premier disque dur.

sda2 - Ce serait la seconde partition.

sdb1 - Ce serait la première partition du second disque dur.

Allons jeter un coup d'oeil dans le répertoire /dev afin de voir les différents types de périphériques disponibles et en particulier les disques durs.

Précisons que nous nous servons d'une machine virtuelle avec le matériel suivant pour cet exercice :

Note : il s'agit des propriétés de la machine virtuelle dans VMware Workstation.

 Et voici ce que nous pouvons voir dans le répertoire /dev :

Je ne ferais que quelques remarques...
  • Les objets en bleu sont des dossiers et les objets en jaune de "simples" fichiers. Les fichiers exécutables seraient en vert. Ce sont les fichiers jaune qui nous intéressent.
  • fd0 représente le lecteur de disque "floppy". Je ne m'explique pas sa présence étant donné l'absence d'un tel périphérique dans mon système.
  • Nous avons un seul disque dur - sda - avec deux partitions : sda1 et sda2.
  • sda représente le disque lui-même et contient le MBR (Master Boot Record). Le MBR réside en dehors de toute partition particulière.
  • sr0 représente le lecteur de CD/DVD et cdrom est un lien symbolique vers ce lecteur.

J'ai désigné l'objet "tty1" d'un point rouge parce qu'il m'a intrigué. Je m'aperçois de cette séquence de lettres et de chiffres chaque fois que j'ouvre une session :

De quoi s'agit-il ?

Si j'ai bien compris, il représente la console à laquelle je me suis trouvé lorsque j'ai ouvert la dernière session. Autrefois, il y avait une distinction entre "console" (visible elle aussi d'ailleurs parmi les fichiers contenus dans /dev) et les nombreux fichiers tty*. La console était bien la console et les fichiers tty* représentaient les périphériques en série qu'on pouvait brancher sur le serveur. Aujourd'hui, les fichiers tty* représentent des consoles virtuelles, à compter de tty1.

Si nous voulons cibler un type de périphérique, nous pouvons peaufiner l'affichage avec grep :

Mais comment faire pour obtenir plus d'informations sur les disques en question ? Par exemple, quelle en est la taille ? Et comment faire pour afficher les seuls disques du système au lieu de l'ensemble des périphériques ?

lsblk est une commande susceptible de fournir au moins certaines réponses à ces questions :

Outre fd0 et sr0, nous avons un disque dur (sda) de 20 Go avec une partition de démarrage (sda1) de 500 Mo et une autre partition de 19,5 Go (sda2). Nous avons donc des disques (type = disk), un seul en fait ; des partitions (type = part) et puis quelque chose du type "lvm".

LVM (Logical Volume Manager) permet de rassembler des disques physiques et même des partitions physiques en un "fond commun" à partir duquel on peut tailler de nouvelles "partitions logiques". Suivant l'arborescence dans la capture d'écran ci-dessus, nous constatons que la partition physique sda2 se découpe en deux partitions logiques : centos-root et centos-swap. La première, à 17,5 Go, est la partition principale et la second, à 2 Go, joue le rôle de fichier de pagination (swap file) dans le monde Windows. En fait, Linux peut recourir à un fichier pour la pagination mais l'utilisation d'une partition dédiée est préférée.

Note : je ne traite pas davantage de LVM dans ce billet.

lsblk --fs nous montre le système de fichiers choisi pour les partitions :

xfs est le système de fichiers de CentOS7 / RHEL7 par défaut. ext3 et ext4 figurent parmi les autres options.


Mais comment faire pour créer une partition ou en supprimer une? Nous pouvons choisir entre plusieurs outils : fdisk, gdisk et parted. Je me servirai de fdisk dans ce billet.

Note : fdisk est capable de gérer des partitions d'une taille maximale de 2 To. Il faut recourir à gdisk ou parted pour des partitions plus grandes.

De même que lsblk, fdisk est capable d'afficher la liste des disques installés dans le système :

fdisk -l

Cette commande inclut tous les disques. Pour cibler un disque en particulier, nous saisissons cette commande :

fdisk -l /dev/sda

Note : à supposer que ce soit le disque sda qui nous intéresse.

Pour cette expérience, j'ai ajouté un second disque (virtuel) de 20 Go.

Comme je m'y attendais, fdisk et lsblk présentent ce disque sous le nom de "sdb", par exemple :

Alors, comment fait-on pour créer une nouvelle partition sur le disque /dev/sdb ?

D'abord, nous exécutons fdisk en désignant bien /dev/sdb, soit :

fdisk /dev/sdb

Voilà ce qui s'affiche :

Note : vous pouvez cliquer sur les images pour les agrandir.

Nous choisissons les options suivantes :

  • n - pour nouvelle partition
  • p - pour partition primaire
  • 1 - pour la première partition (ou rien, car 1 est la valeur par défaut)

Pour une partition de 1 Go, nous appuyons sur Entrée/Retour pour le premier secteur et +1G pour le dernier secteur.

Et surtout... nous tapons bien "w" ("write") à la fin pour que le changement prenne effet : 

Nous pouvons confirmer la création de la nouvelle partition avec lsblk :

Je répète les mêmes étapes pour la création d'une seconde partition de 1 Go sur /dev/sdb :

Encore une fois, la nouvelle partition est visible dans la sortie de la commande lsblk :

Nous pouvons voir les choses d'une autre perspective avec fdisk qui montre en particulier quelle partition est la partition d'amorçage :

Mais comment supprimer une partition ?

Dans l'exemple ci-dessous, je vais supprimer la seconde partition du second disque dur.

Nous ciblons le second disque dur avec la command suivante :

fdisk /dev/sdb

Et puis...

  • d - pour supprimer ("delete")
  • 2 - pour choisir la seconde partition

Nous pouvons constater (toujours dans la capture d'écran ci-dessus) l'absence de la partition sdb2 que nous venons de supprimer.

Mais surtout, il faut taper "w" pour que la suppression soit effective.

Comme nous pouvons nous y attendre, l'outil lsblk montre la même chose :


Et voilà une première incursion dans le monde des disque et partitions sous Linux. J'ai l'intention d'en examiner d'autres aspects ainsi que les systèmes de fichiers dans les billets de blogues à venir.