Azure on slash-root.fr

OneDrive : Client Linux OpenSource

Fri, 14 Jan 2022 14:56:22 +0100

Contexte

Dans le cadre de mon travail, j'ai récement migré sur Pop!_OS pour mon environnement du quotidien. Etant un utilisateur de plusieurs comptes OneDrive (perso & pro), il me fallait pouvoir synchroniser ceux-ci dans des dossiers différents de mon système.

Par exemple :

Mon compte OneDrive perso dans ~/OneDrive_Perso
Mon compte OneDrive pro dans ~/OneDrive_Pro

Bien evidément, cela doit fonctionner en tant que service.

Je suis tombé sur ce projet : https://github.com/skilion/onedrive

Update 07/12/2023 :
Le projet utilisé dans cet article est stoppé.
Utiliser / Adapter avec celui-ci : https://github.com/abraunegg/onedrive.git

C'est un outil sous licence GPL3 permettant d'intéragir avec OneDrive sous Linux.

Les fonctionnalités sont les suivantes :

State caching
Real-Time file monitoring with Inotify
Resumable uploads
Support OneDrive for Business (part of Office 365)
Shared folders (only OneDrive Personal)

J'ajouterai également qu'il est possible de faire du multi-comptes.

C'est parfait car c'est mon besoin 🙂

Installation

Pour information, j'ai réalisé cette installation sous Pop!_OS 21.10 mais celle-ci devrait fonctionner à partir des dérivés d'Ubuntu 18+. Pour Fedora, CentOS, ArchLinux, se référer directement à la page du projet cité plus haut.

Tout d'abord l'installation des pré-requis :

sudo apt install git libcurl4-openssl-dev libsqlite3-dev snap snapd
sudo snap install --classic dmd

Puis le clonage du projet et l'installation de l'outil :

git clone https://github.com/skilion/onedrive.git
cd onedrive
make
sudo make install

Configuration

La configuration est optionnelle. Par défaut, tous les fichiers seront stockés dans ~/OneDrive et les fichiers/dossiers commençant par . et ~ seront ignorés.

3 directives sont définissables :

sync_dir : Le répertoire où seront stockés les données.
skip_file : Les fichiers / dossiers à ne pas synchroniser. L'utilisation des wildcards * et ? sont autorisés. Le | peut être employé pour séparer différents patterns.

L'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.
sync_list : Spécifier les fichiers / dossiers à synchroniser. J'en parlerai dans un prochain article.

L'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.

Comme je veux utiliser 2 configurations différentes (une perso et une pro), j'ai créé 1 répertoire pour chaque compte où seront stockés mes données respectives :

mkdir -p ~/{OneDrive_Perso,OneDrive_Pro}

Ensuite, j'ai créé 2 dossiers de configuration (un dossier par compte) :

mkdir -p ~/.config/{onedrive_perso,onedrive_pro}

J'ai ensuite créé mes 2 fichiers de configurations (un fichier par compte).

OneDrive perso :

cat > ~/.config/onedrive_perso/config << EOF
# Directory where the files will be synced
sync_dir = "~/OneDrive_Perso"
# Skip files and directories that match this pattern
skip_file = ".*|~*"
EOF

OneDrive pro :

cat > ~/.config/onedrive_pro/config << EOF
# Directory where the files will be synced
sync_dir = "~/OneDrive_Pro"
# Skip files and directories that match this pattern
skip_file = ".*|~*"
EOF

Initialisation

L'étape suivante que j'ai réalisé a été de lier chaque configuration (perso et pro) à un compte OneDrive. Pour se faire j'ai exécuté dans un 1er temps la synchronisation de mon OneDrive perso :

onedrive --monitor --confdir="~/.config/onedrive_perso"

Un lien est généré :

Authorize this app visiting:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=22c49a0d-d21c-4792-aed1-8f163c982546&scope=files.readwrite%20files.readwrite.all%20offline_access&response_type=code&redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient

Enter the response uri:

En visitant cette URL, une authentification sur le compte OneDrive désiré est demandé. Puis, viens une page blanche (ou noire suivant votre thème) :

J'ai copié l'URI de cette page en réponse à mon prompt Enter the response uri:

La synchro démarre (oui, j'aime bien watch dogs legion...) :

Ensuite, je teste mon compte OneDrive_Pro :

onedrive --monitor --confdir="~/.config/onedrive_pro"

Il est important de libèrer le token office avant. J'étais, au préalablement, identifié sur mon compte perso.

Pour cela, je me suis déconnecté avec mon navigateur internet de mon compte office perso précédement connecté à l'aide de l'URL suivante : https://www.office.com/?auth=2

5. Services

Lors de l'installation de l'outil un service a été créé : /usr/lib/systemd/user/onedrive.service.

J'ai décidé de garder ce service pour mon compte perso et d'en créer un second pour mon compte pro :

cp /usr/lib/systemd/user/onedrive.service /usr/lib/systemd/user/onedrive_pro.service

J'ai ensuite édité mon 1er service (onedrive perso) pour correspondre à sa configuration :

vi /usr/lib/systemd/user/onedrive.service

Puis, j'ai modifié la ligne ExecStart :

ExecStart=/usr/local/bin/onedrive --monitor --confdir="~/.config/onedrive_perso"

Et enfin la même modification pour mon serive OneDrive pro :

vi /usr/lib/systemd/user/onedrive_pro.service

Cette fois-ci, j'ai modifié comme suit :

ExecStart=/usr/local/bin/onedrive --monitor --confdir="~/.config/onedrive_pro"

Pour terminer, j'ai activé mes 2 services :

systemctl --user enable onedrive.service
systemctl --user enable onedrive_pro.service
systemctl --user start onedrive.service
systemctl --user start onedrive_pro.service

6. Vérifications / Logs

Pour vérifier le bon fonctionnement des services, j'utilise ces 2 commandes :

journalctl --user-unit onedrive -f
journalctl --user-unit onedrive_pro -f

7. Désinstallation

sudo make uninstall
rm -rf ~/.config/onedrive*

Azure : Synchronisation AD On-Premise <> Azure AD

Sat, 20 Nov 2021 04:03:05 +0100

Azure AD" />

Objectif

L'objectif de ce document est de mettre en place une synchronisation des utilisateurs, des mots de passes, et des groupes d'un Active directory local vers une infrastructure Azure AD et d'attribuer des licences Microsoft 365 aux utilisateurs du domaine. Ceux-ci n'auront qu'une seule identité entre le domaine local et leurs services Microsoft 365.

Contexte

Contrôleur de domaine local : SRV-AD (Windows Serveur 2019 Standard)
Domaine local : starwars-bzh.local
Tenant Azure AD : starwarsbzh.onmicrosoft.com
Architecture du domaine local :

Vérifier l’activation de la corbeille Active Directory

En PowerShell :

Get-ADOptionalfeature -Filter {name -like "Recycle Bin Feature"}

Si la valeur EnabledScope est vide, cela signifie que la corbeille Active Directory n'est pas activée.

Activer la corbeille Active Directory

En PowerShell :

Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "starwars-bzh.local" -server srv-ad

Les options -Target et -Server doivent être adapté avec l'infrastructure du domaine local. Un message d'avertissement apparait car c'est une action irréversible mais ça peut sauver des vies.

Maintenant, la corbeille Active Directory est activée.

Configurer l’alias UPN

Le domaine local est starwars-bzh.local et le domaine Microsoft 365 public associé est starwarsbzh.onmicrosoft.com. Pour que la synchronisation fonctionne, un alias UPN doit être mis en place dans le domaine local. L'idée est de remplacer le @starwars-bzh.local par @starwarsbzh.onmicrosoft.com pour tous les utilisateurs qui seront synchronisés vers Azure.

Sur le contrôleur de domaine, ouvrir la MMC Domaines et approbation Active Directory :

domain.msc

Effectuer un clic droit sur le nom de la console et cliquer sur Propriétés :

Renseigner la zone Autres suffixes UPN avec le domaine Microsoft 365 déclaré soit starwarsbzh.onmicrosoft.com puis appliquer.

Ensuite, il faut modifier en masse l'UPN par défaut des utilisateurs qui seront synchronisés dans Azure AD. Si on regarde les propriétés d'un compte utilisateur dans l'AD, on voit que l'on peut changer l'UPN par défaut.

Changer l'UPN par défaut :

Au lieu de la faire à la main sur chaque utilisateur, il est possible de le faire en masse.

En PowerShell :

Get-ADUser -Filter * -SearchBase "OU=Services,OU=Starwars-BZH,DC=starwars-bzh,DC=local" | Foreach{

$UPNNew = $_.UserPrincipalName -replace "@starwars-bzh.local","@starwarsbzh.onmicrosoft.com"

Set-ADUser -UserPrincipalName $UPNNew -Identity $_.SamAccountName

}

L'option -SearchBase est à adapter selon les OU contenant les utilisateurs qui seront à synchroniser. La cmdlet Get-ADUser est récursive.

Installer Azure AD Connect

Télécharger l'outil à l'adresse suivante : https://www.microsoft.com/en-us/download/details.aspx?id=47594
Puis lancer l'installation sur le contrôleur de domaine local.
Accepter les termes de la licence puis continuer :

Un message d'avertissement s'affiche indiquant que le domaine local n'est pas routable sur Internet. Une installation personnalisée est donc préférable :

Aucune des options suivantes n'est nécessaire. Il n'y a donc rien à cocher. Cliquer sur Installer :

Dans la partie Connexion utilisateur, Synchronisation de hachage du mot de passe est coché. Cela permet de synchroniser le mot de passe de l'AD local avec Azure AD. Le mot de passe ne transite pas en clair mais uniquement son hash. La case Activer l'authentification unique peut être cochée si on souhaite mettre en place du SSO (Single-Sign-On). Ainsi l'utilisateur n'aura pas à ressaisir sont mot de passe du domaine lors de l'accès aux services Azure (Microsoft 365).

Dans la partie Connexion à Azure AD, un compte administrateur général du tenant Azure est requis :

Dans la partie Connexion de vos annuaires, la forêt locale est bien détectée. Cliquer sur Ajout d'un annuaire. Il est préférable de créer un nouveau compte dans l'AD local qui sera utilisé par les outils effectuant la synchronisation entre l'AD local et Azure AD. Un compte administrateur du domaine est requis afin de pouvoir créer cet utilisateur. Cet utilisateur sera stocké dans le container Users. Il ne devra être en aucun cas modifié ou supprimé.

La connexion à l'AD local est configurée :

Les suffixes UPN apparaissent comme Non ajouté. Cela est tout à fait normal car il n'y a pas de domaines DNS spécifiques du type starwarsbzh.fr. Si un domaine DNS en .fr a été ajouté au tenant Azure, celui-ci sera noté comme Vérifié. Nom d'utilisateur principal doit être sur userPrincipalName. La case Continuer sans faire correspondre tous les suffixes UPN à des domaines vérifiés est à cocher.

Sélectionner les OU à synchroniser entre l'AD local et Azure AD :

Dans la partie Identification de manière unique de vos utilisateurs, laisser le choix par défaut :

Dans la partie Filtrer les utilisateurs et appareils, laisser le choix par défaut :

Dans la partie Fonctionnalités facultatives, laisser par défaut. A noter que la Réécriture du mot de passe peut être intéressante afin de permettre aux utilisateurs de réinitialiser leur mot de passe directement à partir de Microsoft 365. Toutefois cela demande un niveau de licence Azure AD Premium P1. Sans cette option, le mot de passe est écrit dans l'Active Directory et synchronisé sur votre tenant, et non l'inverse.

Le processus de synchronisation peut démarrer :

Pour modifier la configuration, il suffit de relancer l'assistant en cliquant sur l'icône Azure AD Connect présente sur le bureau puis sur le bouton Configurer (Modification des OU à synchroniser, ajout de nouvelles fonctionnalités).

Vérifier la bonne présence des utilisateurs et des groupes dans le portail d'administration de Azure AD.

Affecter les licences Microsoft 365

Afin de pouvoir affecter une licence Microsoft 365 à un utilisateur, il va falloir dans 1er temps lui attribuer un Lieu d'utilisation. Ce paramètre se trouve dans le profil de l'utilisateur dans Azure AD :

Attention, une fois le Lieu d'utilisation affecté à un utilisateur. Un délai de 5 minutes peut être nécessaire avant de pouvoir lui attribuer une licence.

Une licence Microsoft 365 peut ensuite être attribué à un utilisateur :

Vérifier la synchronisation

Un outil nommé Synchronization Service Manager a également été installé sur le contrôleur de domaine local permettant de vérifier l'état de la synchronisation. Par défaut celle-ci s'effectue toutes les 30 minutes.

A noter que si un mot de passe est modifié dans l'AD local, celui-ci sera répliqué sous 2 minutes au sein d'Azure AD.