Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

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

par | 22 Juin 2018 | , , ,

Réinitialisation du mot de passe :

Avec un compte faisant partie de « Read_Laps »

Normalement lorsqu’un compte ne fait pas partie du groupe « Reset_Laps« , il ne bénéficie pas du droit de réinitialiser le mot de passe, vérifions cela.

Avec le client lourd  :

En effet nous pouvons constater que lorsque l’on essaie de réinitialiser le mot de passe le client affiche au bas de la fenêtre un message « Failed to request password reset« 

Avec Powershell :

Avec Powershell le résultat est le même (voir plus explicite), l’utilisateur ne possède pas les droits.

Avec un compte faisant partie de « Reset_Laps »

 

Maintenant nous allons utiliser un compte qui se trouve dans le groupe « Reset_Laps » mais pas dans le groupe « Read_Laps« , par conséquent il n’est pas possible de lire le mot de passe mais je devrais pouvoir le réinitialiser. 

Avec le client lourd  :

Cette fois-ci nous pouvons constater que le mot de passe n’est pas lisible, et au bas du client lourd le message « Password reset request was successful« .

Avec Powershell :

Conclusion :

Grâce à cette solution gratuite de Microsoft vous pouvez améliorer la sécurité de votre parc informatique en réduisant la portée d’attaque d’une intrusion à l’aide du compte administrateur local.

 

https://www.microsoft.com/en-us/download/details.aspx?id=46899&wt.mc_id=fy16techdays

https://technet.microsoft.com/en-us/library/security/3062591?wt.mc_id=fy16techdays

https://blogs.msdn.microsoft.com/laps/

https://support.microsoft.com/en-us/kb/3062591

[Powershell] Héritage des GPO bloqué

par | 21 Juin 2018 | , ,

 

Voici quelques commandes Powershell pour trouver les OU dont l’héritage est bloqué:

$GPOBlocked = Get-ADOrganizationalUnit -SearchBase "DC=LAB,DC=Org" -Filter * | Get-GPInheritance | Where-Object {$_.GpoInheritanceBlocked}
$GPOBlocked.count
$GPOBlocked | Select Name,Path

Le DistinguishedName (Path) n’est pas toujours agréable à lire je fais donc une conversion en CanonicalName, ensuite vous pouvez afficher les données à l’écran ou les écrire dans un fichier:

$GPOBlocked | ForEach-Object {
        $Name = $_."Name"
        $Path = $_."Path"
        $CanonicalName = Get-ADOrganizationalUnit -Filter {DistinguishedName -like $Path} -Properties CanonicalName | Select-Object -ExpandProperty CanonicalName
        Write-Output "$Name; $CanonicalName" | Add-Content C:\Temp\GpoInheritanceBlocked.txt
    }

 

 

[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.

Derniers articles

Catégories

Archives

Auteurs/Autrices