PowerShell par défaut sur Windows Core

Bonjour à tous, juste un petit pense bête pour moi.

Etant un fervent utilisateur de "Windows Core" et utilisant énormément "PowerShell", je souhaitais configurer le démarrage des serveurs avec la console "PowerShell" par défaut.

Pour cela il faudra lancer "PowerShell.exe"

Lancer ensuite la commande ci-dessous:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' -name Shell -Value 'PowerShell.exe -noExit'


Cop

Redémarrer ensuite votre serveur "Windows Core".

Notre serveur redémarre correctement  sur la console "PowerShell" au lieu du "Shell Windows".

A bientôt. 😉😊

Azure Portal App

Bonjour à tous, petit article concernant l'application "Azure Portal App".

En effet vous avez maintenant la possibilité d'utiliser un client lourd sur votre Windows pour vous connecter à votre portail Azure.

Je trouve cela très pratique et en plus l'application est très stable.

Il suffit seulement de télécharger l’exécutable à l'adresse suivante:

https://preview.portal.azure.com/app/welcome

L'application se lance et vous demande de vous authentifier avec votre compte autorisé.

Vous retrouver le portail identique à celui du portail web.

 Ce qui est pratique c'est que l'on peut voir directement les notifications sur notre Ordinateur.

A bientôt. 😉

OFFICE 365 MESSAGE ENCRYPTION OME

Bonjour à tous, petit article sur une fonctionnalité plutôt pratique dans "Exchange Online" à savoir "OFFICE 365 MESSAGE ENCRYPTION (OME)"

L'idée de cette fonctionnalité, est donc de pouvoir chiffrer des mails que l'on souhaite envoyer et accroître la sécurité des échanges par messagerie.

Le principe est d'envoyer un  mail chiffré  au destinataire qui reçoit un lien le redirigeant vers un portail de visualisation permettant de déchiffrer et lire ce message.

Ci-dessous l’illustration du fonctionnement:

Le chiffrement OME s'appuie sur la fonctionnalité "Azure RMS" faisant partie "Azure Information Protection".

Ci-dessous les différentes documentations sur le sujet:

https://docs.microsoft.com/fr-fr/microsoft-365/compliance/email-encryption

https://docs.microsoft.com/fr-fr/microsoft-365/compliance/ome

https://docs.microsoft.com/fr-fr/microsoft-365/compliance/set-up-new-message-encryption-capabilities#targetText=The%20new%20Office%20365%20Message,Gmail%2C%20and%20other%20email%20services.

Egalement la partie licencing et abonnements ainsi que les questions fréquemment posées:

https://docs.microsoft.com/en-us/microsoft-365/compliance/ome-faq

La première chose consiste à activer "Azure RMS" si ce n'est pas déjà le cas.

Pour cela, nous allons nous connecter sur le portail d'administration "Office 365".

Dans la partie "Paramètres" et "Services et confidentialités" et sélectionner "Microsoft Azure Information Protection".

Nous activons donc "Rights Management".

En me connectant sur "Exchange Online" en mode PowerShell, je lance la commande "Get-IRMConfiguration" pour me rendre compte que la fonctionnalité "AzureRMSLicencingEnabled", n'est pas activée.

Nous allons devoir l'activée.

Une fois connectée, nous allons lancer la commande suivante:

Set-IRMConfiguration -AzureRMSLicencingEnabled $True

Nous vérifions à nouveau la bonne application.

Dans la documentation Microsoft, il est recommandé de tester la bonne configuration.

Pour ce test, nous allons lancer la commande "Test-IRMConfiguration -Sender "adresse@mail.com" 

Le test est négatif car comme on peut le voir, la commande n'arrive pas à récupérer les "Template RMS".

La commande n'arrive pas à récupérer les Template car la  valeur "LicencingLocation" ci-dessous est vide.

Pour modifier cela, nous allons devoir importer le module "AIPService" si vous ne l'avez pas déjà.

Nous allons ensuite nous connecter au portail "AIP".

Lancer ensuite les commandes suivantes.

$RMSConfig = Get-AadrmConfiguration

$LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl

Set-IRMConfiguration -LicensingLocation $LicenseUri

Set-IRMConfiguration -InternalLicensingEnabled $true

Nous vérifions la bonne application en se connectant à nouveau sur la console "PowerShell d'Exchange Online".

Nous relançons le test qui cette fois si fonctionne.

Pour terminer, nous allons ajouter le bouton permettant de chiffrer à notre client de messagerie en tapant la commande PowerShell suivante:

"Set-IRMConfiguration -SimplifiedClientAccessEnabled $True"

Le bouton apparaît dans notre client Web, nous pouvons donc maintenant chiffrer nos mails manuellement.

Une fois le message envoyé, le destinataire reçois le mail ci-dessous:

Un code est ensuite envoyé à votre adresse mail.

Utilisez ensuite ce code secret pour décrypter le mail.

Dans cet article, nous avons pu voir comment chiffrer simplement un mail avec l'encryption OME dans Exchange Online.A bientôt. 😀😉

Vous pouvez maintenant consulter le mail chiffré.

Synchronisation des signatures Outlook sur plusieurs device

Bonjour à tous, juste une petite annonce très intéressante.

Suite à un vote massif sur le "user Voice d'outlook" Microsoft va travailler sur la mise en place de la synchronisation des signatures Outlook sur l'ensemble des devices connecter avec un compte Office 365 et Exchange Online.

Il faudra cependant utiliser la dernière version d'Outlook sur les différents équipements.

Voilà c'est tout pour le moment.

A très bientôt. 😉😊

Extension support Exchange 2010

Bonjour à tous, juste une information importante pour vous dire que le support "Exchange 2010" a finalement été prolongé jusqu’au 13 Octobre 2020 par "Microsoft" alors qu'initialement le support devait se terminer le "14 Janvier 2020".

https://www.zdnet.fr/actualites/microsoft-prolonge-de-neuf-mois-le-support-technique-pour-exchange-server-2010-39890709.htm

Bonne nouvelle donc, ça vous laisse encore quelques mois pour migrer vers "Exchange 2016", "Exchange 2019" ou même mieux vers "Exchange Online".


A bientôt.

Partie1: Migration Tenant à Tenant Office 365

Bonjour à tous, aujourd'hui première partie d'un série d'articles sur la migration de données d'un "Tenant office 365 à un autre".

Le scénario suivant a été imaginé:

- Un grand groupe a décidé de racheter une filiale d'un autre grand groupe.

- Le "groupe A" sera le groupe source et le "groupe B" sera le groupe cible.

- Le "groupe A" dispose de plusieurs noms de domaine et seul le domaine de la filiale (dans notre exemple ffo365.fr) sera migré vers le "groupe B".

- Les applications Office 365 utilisées par la filiale du Groupe A sont toutes concernées par la migration ( Exchange Online, Teams, OneDrive, SharePoint Online).

- La migration inclus également la migration des utilisateurs, des groupes et des postes de travail hébergés dans l' "Active Directory" de la filiale.

Les outils suivants seront utilisés:

- ADMT pour la migration des Objets "Active Directory" d'une forêt à une autre.

- L'outil "Fly d'AVPOINT" pour la migration des applications "Office 365".

- Script Powershell pour différentes tâches comme la reconfiguration des profils Outlook à la cible.

Les contraintes d'une migration "Tenant to Tenant Office 365:

- Impossible d'ajouter le même domaine sur les deux tenant Office 365 en même temps
- Privilégier l'utilisation d'un logiciel tiers pour faciliter la migration des données contenus dans les applications "Office 365" surtout pour "SharePoint Online" et "OneDrive".
-Coupure de service nécessaire pour la bascule finale (HNO obligatoire).

Le schéma ci-dessous nous montre l'infrastructure existante des deux côtés:

Le schéma ci-dessous nous montre l'infrastructure de coexistence pour la migration:

Les prérequis seront les suivants:

- Installation d'un serveur ADMT côté cible et  "Password Recovery Server" sur le contrôleur de domaine source. (Nous ne verrons pas l'installation, ce n'est pas l'objet des articles).
- L'outil tiers pour la migration des données "Office 365". Comme évoqué plus haut nous utiliserons l'outil "Fly" d' "Avepoint"
- Une sauvegarde des infrastructures source et cible ( Azure Ad Connect, ADFS...).
- L' approvisionnement de licences office 365 supplémentaires sur le tenant cible pour accueillir les utilisateurs filiale du Groupe A.
- Avoir les informations d'authentification du compte administrateur global Office 365 (account@contoso.onmicrosoft.com).

Voilà, la première partie est terminée.

Dans la deuxième partie nous verrons le "process"  et la mise en place de la coexistence.

A bientôt. 😉😊

Passer de l'authentification ADFS vers l’authentification Pass-Through et Seamless SSO

Bonjour à tous, aujourd'hui nouvel article concernant le changement du mode d’authentification des clients vers les services Azure.

La plupart du temps, pour intégrer certaines applications comme "Office 365" et unifier les authentifications en y ajoutant du SSO, les entreprises mettaient en place une infrastructure ADFS dans leur infrastructure "On-Premise".

La grosse contrainte de l'ADFS, c'est que cela demande une infrastructure importante et complexe surtout si l'on souhaite y ajouter de la haute disponibilité à savoir:

- 2 serveurs ADFS
- 2 Serveurs Azure AD Connect
- 2 Serveurs WAP
- Un load balancer entre les serveurs WAP

Comme vous pouvez le constater cela demande beaucoup de maintenance.

Pour pallier à ça, Microsoft à décider de créer "Azure AD Pass Through Authentication et Seamless SSO"

L'idée est également de ne pas stocker les mots passes dans "Azure AD" comme on le faisait avec ADFS.

Je ne vais pas vous faire une présentation du produit qui est déjà sortie il y a deux ans, Microsoft le fera bien mieux que moi.

https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/how-to-connect-sso 

Le tableau ci-dessous résume les différences entre Azure AD Pass Through Authentication et Seamless SSO" et "ADFS".

La solution qui va nous intéresser le plus sera celle avec le "Pass-Through" car elle ne synchronise pas les mots de passe dans "AzureAD".

Pour pouvoir modifier la façon dont va s'authentifier les utilisateurs, il suffit de se connecter sur le serveur "Azure AD Connect" et de relancer l’exécutable ci-dessous.

L'assistant se lance.

Choisir "Change user sign-in"

Authentifiez-vous avec le compte principal pour Azure AD.

Si "ADFS" est coché, il vous suffit de cocher "Pass-through authentication" et "Enable single sign-on"

Authentifiez-vous avec un "compte administrateur du domaine On-premise"

L'assistant d' "Azure AD Connect"vérifie les composants.

Tout est prêt pour la reconfiguration d' "Azure AD Connect"

Vous pouvez également lancer la synchronisation à la fin du processus.

La reconfiguration se lance.

L'agent pour la fonctionnalité "Pass-through autentication" s'installe sur notre serveur.

Il configure ensuite l'agent "Pass-through autentication"

Activation du sso.

L'opération s'est correctement déroulée.

Nous pouvons également voir que notre domaine "FFO365.FR" n'est plus fédéré et est passé en mode "Managed".

Sur la console "Azure AD" nous pouvons voir la bonne configuration

Lors de la mise en place Azure AD Pass Through Authentication et Seamless SSO" un compte "AZUREADSSOACC" a été créé dans l'OU "Computer"      

Le compte ordinateur "AZUREADSSOACC" est utilisé pour lors de la connexion à "Azure AD/O365" pour générer le ticket Kerberos utilisateur.

La clé Kerberos de l’ordinateur "AZUREADSSOACC" est partagée avec "Azure AD/O365".

La clé Kerberos de l’ordinateur "AZUREADSSOACC" peut et doit être changée régulièrement, ce que je conseille fortement.

Pour que le SSO soit complètement fonctionnel pour les utilisateurs, il faudra ajouter les exceptions ci-dessous dans internet Explorer:

https://autologon.microsoftazuread-sso.com

https://aadg.windows.net.nsatc.net

Pour connaitre les compatibilités des navigateurs je vous laisse le soin de consulter le lien ci-dessous.

https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/how-to-connect-sso 

Nous allons créer notre GPO pour les utilisateurs.

Les deux liens ci-dessus seront a configurer sur le paramètre suivant:

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet

Control Panel > Security Page. 

Dans Assignment List. Entrer les valeurs suivantes :

Modifier ensuite le paramètre ci-dessous:

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet

Control Panel > Security Page > Intranet Zone. 

Activer Allow updates to status bar via script.

Je vérifie la bonne application sur mes postes.

Je vérifie ensuite la bon fonctionnement en allant sur le portail Office 365.

Haute disponibilité:

Si vous souhaitez mettre en place de la haute disponibilité, il vous faudra déployer d'autres agents sur d'autres serveurs qui doivent pouvoir communiquer sur les ports 443 et 80.

Pour cela lancer le lien ci-dessous:

http://aka.ms/getauthagent

Exécuter le programme:

Authentifiez-vous sur Azure.

Vérifiez ensuite sur le portail Azure AD la présence du deuxième agent.

Dans cet article nous avons pu voir comment changer l'authentification ADFS vers l’authentification Pass-Through et seamless SSO.

A bientôt. 😏