Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

[Powershell] Excel ne s’enregistre pas via le Planificateur de tâches

par | 21 Juin 2018 | , , , ,

Lancer un script Powershell via le planificateur de tâches ne pose aucun problème, en revanche si ce dernier souhaite utiliser Excel (par l’intermédiaire de la commande « new-object -comobject excel.application« ) on peut rencontrer un problème.

Je dis « on peut » car cela fonctionne si l’on a pas coché la case « Run Whether user is logged on or not« , en revanche si cette dernière est cochée, Excel ne sera pas en mesure d’enregistrer le fichier.

Pourquoi ?

Par défaut l’application Excel s’exécute avec le compte « Utilisateur exécutant (The Launching User)« , mais si j’utilise une tâche planifiée qui ne nécessite pas que je sois connecté Excel ne parvient pas a déterminer qui fait appel à lui.

Que Faire ?

Simplement en déclarant qui  exécute l’application Excel via la MMC -> Services des composants.

Je vous renvoie au point 2 (Gestion de l’Excel distant) de mon précédent article : [Powershell] Ecrire dans un Excel distant.

Sécurité : Local Admin Password Solution (LAPS) – Partie 3

par | 11 Avr 2018 | , , ,

Vérifications Serveur / Clients

Depuis le serveur

Vérifions l’état du mot de passe du compte Administrateur Local d’une machine cible.

Avec le client lourd  :

Avec Powershell :

Depuis l’Active Directory dans l’onglet éditeur d’attribut 

Depuis le poste Client

Avec un compte faisant partie de « Read_Laps »

Réalisons donc une mise à jour de la stratégie de groupe 

Nous allons pouvoir vérifier l’état du mot de passe du compte admin local.

 

Avec le client lourd  :

Avec Powershell :

Avec un compte faisant partie de « Reset_Laps »

Avec le client lourd  :

Avec Powershell :

 

Test de connexion

Nous testerons donc de nous connecter à la machine avec le nouveau mot de passe

C’est fonctionnel.

Sécurité : Local Admin Password Solution (LAPS) – Partie 2

par | 10 Avr 2018 | , , ,

Mise en Oeuvre :

Installation sur l’infrastructure :

Pour réaliser l’installation de LAPS sur un serveur membre nous aurons besoin dans un premier temps d’un compte avec les droit Administrateur Local sur le serveur, puis de bénéficier des droits Admin du Schéma puis Admin du domaine ou Admin de ou des Unités d’Organisation en fonction de l’étendue sur laquelle vous souhaiter déployer LAPS. (Pour ma part je l’ai fait avec un compte « Admin du Domaine » sur lequel j’ai accordé les droits « Admin du schéma » le temps de l’installation).

L’installation se fait en suivant les étapes ci-dessous :

  1. Installation de LAPS avec les composants Serveur.
  2. Extension du schéma.
  3. Attribution des droits.
    1. Droits pour les computers .
    2. Création des groupes de sécurité.
    3. Délégation des droits aux groupes de sécurité sur les OU.
  4. Paramétrage des GPO
    1. Import des fichiers ADMX et ADML.
    2. Création et paramétrage de GPO.

Etape 1 : Installation de LAPS avec les composant serveur :

Le fichier msi fournit par LAPS permet d’installer les composants clients et serveurs, par défaut seul les composants clients sont installés, dans notre cas nous souhaitons déployer les composant serveurs nous sélectionnerons donc les « Management Tools« .

Vous remarquerez la présence de 3 modules pour les « Management Tools » :

  1. Fat Client UI : Soit l’interface utilisateur client lourd permettant de récupérer les mot de passe en clair dans l’AD
  2. Powershell module : L’interface Powershell
  3. GPO Editor Templates : Les ADMX

Etape 2 : Extension du schéma

Exécuter Powershell en tant qu’Administrateur.

 

# Import du module
Import-module AdmPwd.PS
# Update du schéma
Update-AdmPwdADSchema

Etape 3 : Attribution des droits.

Pour attribuer aux machines le droit de modifier leurs attributs exécutez :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Machines,DC=LAB,DC=INFO"

Pour créer les Groupes de sécurité afin de déléguer les droits (Lecture et Réinitialisation), vous avez deux options (en graphique via ADAC ou User & computers AD, ou avec Powershell, pour ma part ce sera Powershell).

 

# Création du Groupe Read_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Read_Laps" -Description "Group For Read Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

# Création du Groupe Reset_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Reset_Laps" -Description "Group For Reset Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

Nb: Le nom des groupes est un choix personnel, libre à vous de mettre autres choses.

Nous allons maintenant déléguer les droits sur une OU à l’aide des commandes suivantes :

 

# Permet d'attribuer le droit de lecture du mot de passe au Groupe "Read_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdReadPasswordPermission -Identity "OU=COMPUTERS,OU=Main,DC=LAB,DC=ORG" -AllowedPrincipals Read_Laps –Verbose

# Permet d'attribuer le droit de changement du mot de passe au Groupe "Reset_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdResetPasswordPermission –Identity "OU=COMPUTERS,OU=IT,OU=Main,DC=LAB,DC=ORG" –AllowedPrincipals Reset_Laps –Verbose

Nb : Le droit peut être déléguer sur l’ensemble du domaine, pour ma part seul les « Domain Admins » bénéficie de ce privilège.

Etape 4 : Paramétrage des GPO.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

  • C:\Windows\PolicyDefinitions\AdmPwd.admx -> A copier dans le « %systemroot%\sysvol\domain\policies\PolicyDefinitions« 
  • C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml -> A copier dans le « %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US » (Option à répéter pour chaque langage de votre AD).

Nb: Si toutefois vous n’aviez pas les répertoires ci-dessus, il faudra les créer manuellement avec un compte ayant les droits.

Il ne nous reste plus qu’à déployer les stratégies de groupe pour définir le comportement de LAPS.

  1. On ouvre donc « Group Policy Management » et on créé une nouvelle GPO (Dans cet Démo, on la nommera simplement « LAPS »).
  2. On accède aux nouveaux paramètres : Computer Configuration -> Policies -> Administrative Templates -> LAPS

C’est donc à partir de ces nouveaux paramètres que nous allons pouvoir activer ou inhiber LAPS et pouvoir agir sur les différentes politiques de sécurité :

  • Intervalle de changement de mot de passe.
  • Longueur et complexité du mot de passe.
  • Définir le nom du compte Administrateur (Seulement si ce dernier à été renommé).

Activation de LAPS

Paramètre du nom de compte Administrateur : Ne pas configurer si le compte est celui par défaut.

Spécifications de longueur et complexité du mot de passe.

La configuration serveur est maintenant terminée.

Installation sur le client :

Comme par défaut le fichier msi n’installe que les composants client, il vous sera possible de scripter l’installation à l’aide de le commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

La partie client de LAPS est un CSE (Client Side Extension), soit une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. Il s’agit donc bien d’une installation d’un composant de l’OS et non un nouveau service, que vous pourrez retrouver par défaut sous %programfiles%\LAPS\CSE\AdmPwd.dll

A chaque déclenchement du CSE, ce dernier :

  • vérifie si le mot de passe est expiré à l’aide du dernier changement stocké dans l’attribut ms-Mcs-AdmPwdExpirationTime.
  • S’il l’est, en génère un de manière aléatoire basé sur les politiques de sécurité définies par la GPO.
  • Met à jour le mot de passe et l’inscrit en clair dans l’attribut ms-Mcs-AdmPwd et modifie l’attribut ms-Mcs-AdmPwdExpirationTime de l’objet Ordinateur dans l’Active Directory.

Voila la configuration est maintenant terminée, mappons la GPO et vérifions.

 

Derniers articles

Catégories

Archives

Auteurs/Autrices