Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

SQL Server–Détecter et modifier les comptes utilisés pour l’exécution de jobs

Contexte

Il arrive souvent qu’un compte utilisateur soit utilisé pour l’exécution d’un job SQL, il s’agit d’une mauvaise pratique car le compte utilisateur peut être amené à changer de mot de passe ce qui provoqueras une erreur d’exécution des jobs en question.

Ce post explique comment détecter puis modifier les comptes utilisés.

Analyse

Le script suivant permet de détecter les jobs exécuté via un compte user (DOMAIN\USER-%) tout en ne remontant pas les jobs lancés par un compte de service (DOMAIN\SERVICE-%).

Les variables “DOMAIN\USER-%” et “DOMAIN\SERVICE-%” sont à modifier en fonction de la nomenclature utilisée pour nommer les comptes. Le “%” correspond à toute chaîne de zéro caractères ou plus Ce caractère générique peut être utilisé comme préfixe ou comme suffixe.

select s.name,l.name
from  msdb..sysjobs s
  left join master.sys.syslogins l on s.owner_sid = l.sid
where l.name like ‘DOMAIN\USER-%’ and  l.name not like ‘DOMAIN\SERVICE-%’

Résolution

Il faut ensuite récupérer le SID du compte utilisateur à changer depuis l’active directory, ainsi que le SID du compte à utiliser, par exemple, SA.

Pour récupérer le SID d’un utilisateur SQL, executer la commande suivante “select sid,name,denylogin from MASTER..syslogins where name=’SQLUser’”

Le script suivant permet de modifier l’owner des jobs d’une instance SQL depuis le SID “0x02” vers le SID “0x01” :

UPDATE msdb..sysjobs
SET owner_sid = CONVERT(varbinary(max), ‘0x01’, 1)
where owner_sid = CONVERT(varbinary(max), ‘0x02’, 1)

[Powershell] Ecrire dans un Excel distant.

Exécuter Excel sur un poste Distant.

Quel est l’interêt ?

En dehors du fait qu’installer Excel sur un serveur n’est pas forcément une bonne pratique, dans mon cas cela me permet d’automatiser à 100% mes scripts Powershell, ces derniers fournissent des rapports détaillés à mes interlocuteurs, sans que je n’ai besoin de faire quelques modifications que ce soit (contrairement à un CSV).
Ainsi les scripts tournent de nuit et permettent à chacun de trouver son rapport le matin en arrivant, et ce même pendant mes vacances.

Comment ça marche

Pour exécuter Excel sur un poste distant via Powershell il faudra cumuler 2 paramètres.

  1. Activer CredSSP pour la délégation des identifiants.
  2. Autoriser le compte d’exécution à se servir de l’application Excel à Distance.

Voyons comment réaliser cela.

1- Activer CredSSP

J’ai déjà traité le sujet ICI.

2- Gestion Excel Distant

Attention la modification que nous allons réaliser n’est pas sans conséquence, comme nous pourrons le voir après, l’application Excel devient vraiment limitée pour tout autre utilisateur que celui qui sera déclaré.

Pour pouvoir autoriser le compte d’exécution à se servir de l’application Excel à distance, nous aurons besoin de la MMC.

Sur la machine qui traitera le fichier Excel :

  • Ouvrir la MMC > Ajouter ou supprimer des composants logiciels enfichables > Services de composants.

  • Développer Services de composants > Ordinateurs > Poste de travail > Configuration DCOM

  • Sur « Microsoft Excel Application » faites clic droit « propriétés », dans la fenêtre sélectionnez l’onglet « Identité »

  • Cochez la case « Cet utilisateur » puis faites « parcourir », sélectionnez « Tout l’annuaire » et enfin recherchez le compte d’exécution du script.

  • Entrez le mot de passe de votre compte d’exécution et faites « Appliquer ».

Maintenant que le paramètre est fixé seul le compte définit est « autorisé » à se servir de l’application Microsoft Excel, l’expérience pour tout autre utilisateur est vraiment dégradé (pas d’impression, de sauvegarde, message d’erreur…); par conséquent si vous souhaitez pouvoir continuer à utiliser Excel, je vous invite à repasser sur « L’utilisateur exécutant » et n’activer la fonction que lors de l’exécution du script (pour ma part je ne l’active sur mon poste que la nuit).

Exemple de message d’erreur.

 

Annexe

En annexe un petit article sur la gestion d’Excel en Powershell :

https://blog.piservices.fr/post/2013/03/27/Powershell-Creation-de28099objets-personnalises

 

Exchange 2013 – Erreur HttpEvent 15021

Problématique

Sur un serveur Exchange 2013, la connexion PowerShell ne s’effectue pas et le portail d’administration affiche une page blanche.

2018-03-29_105153

2018-03-29_105411

Dans le journal d’événements système un grand nombre d’erreur HttpEvent 15021 est présent.

2018-03-29_105128

Ces erreurs peuvent intervenir après le changement d’un certificat sur le serveur Exchange.

Résolution

Le problème vient de la liaison du certificat qui est incorrect sur le port 444. Il faut donc la supprimer et la recréer.

Pour cela, afficher l’ensemble des liaisons SSL avec la commande :

netsh http show sslcert

2018-03-29_105203

Récupérer les valeurs du hash et l’application ID de la liaison sur le port 443.

Supprimer la liaison du port 444 avec la commande :

netsh http delete sslcert ipport=0.0.0.0:444

2018-03-29_105239

Et recréer une liaison en utilisant le hash et l’application ID du port 443 avec la commande :

netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXXX appid=”{XXXXXXXX}”

2018-03-29_105352

Dans le journal d’événements deux avertissements HttpEvent 15300 et 15301 apparaissent.

2018-03-29_105518

Une fois la modification effectuée, la connexion PowerShell et le portail d’administration sont de nouveau accessibles.