PI Services

Contexte

L’une des tâches régulièrement exécutées par un DBA est de restaurer ou d’attacher des bases entres différentes instances SQL. Lors de ce type d’opération, il est fréquent de rencontrer des erreurs d’authentification du type :

• Error 15023 : User already exists in the current database,
• Error 4064 : Cannot open user default database. Login failed,
• The database <VOTREBASE> is not accessible. (Object Explorer). A la vue de ces erreurs, un DBA peux être tenté de retirer manuellement les utilisateurs des différentes bases de données pour les ajouter, cette action – bien que fastidieuse – résoudrais le problème décrit, il existe néanmoins des solutions intégrées à SQL pour détecter et mapper les utilisateurs orphelins (orphaned users).

 

Explication du problème

Les utilisateurs orphelins apparaissent lorsque le SID d’un utilisateur d’une base de donnée ne correspond pas au SID du même utilisateur qui est renseigné dans la base master.

Le SID d’un utilisateur apparait donc à deux niveaux :

• Au niveau instance : dans les vues système '”sys.server_principals” et “sys.syslogins” présentes dans la table Master,
• Au niveau base de donnée : dans la table système sysusers.

Le SID d’un utilisateur (identifiant unique) sert à mapper un utilisateur d’une base de donnée au login renseigné dans l’instance SQL, donc lors de la restauration d’une base de donnée vers une instance SQL différente, il faut penser à re-mapper les utilisateurs orphelins.

Résolution

Afin de re-mapper les utilisateurs orphelins sans avoir à passer sur chaque utilisateur manuellement, on peux s’aider de sp_change_users, cette commande prends trois paramètres différents :

• Report pour détecter les utilisateurs orphelins :

• Update_one pour mapper manuellement un utilisateur de la base à un login de l’instance :

  USE <YOURDATABASE> GO sp_change_users_login @Action='update_one' @UserNamePattern='User1' @LoginName='User1' GO

• Auto_fix pour mapper automatiquement un utilisateur de la base à un login de l’instance et pour créer le login si absent de l’instance :

  USE <YOURDATABASE> GO sp_change_users_login @Action='auto_fix' , 'User1', null, 'Password' GO

Ce petit script va vous permettre de récupérer dans une variable un tableau de l’ensemble des process tournant sur le poste avec leurs ID et leurs propriétaire

$process=gwmi win32_process
$array=@()
foreach ($p in $Process)
{
    $temp=new-object psobject
    $temp |add-member -MemberType NoteProperty -name "ProcessName" -Value $p.name
    $temp |add-member -MemberType NoteProperty -name "ProcessID" -Value $p.ProcessID
    $temp |add-member -MemberType NoteProperty -name "User" -Value $p.getowner().user
    $array+=$temp
}

Exemple :

Ainsi, pour killer des processus, vous pouvez maintenant ajouter la contrainte par identification du propriétaire du Processus.

Exemple :

Nous allons killer les process Spotify de l’utilisateur ato

Tout d’abord on récupère les Processus respectant cette contrainte dans notre variable:

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"}

Et ensuite, on les Kill grâce à leurs identifiants :

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"} |%{stop-process -Id $_.processID}

Résultat : Plus de musique   (les processus Spotify de l’utilisateur ato ont été arrêtés).

Il peut être utile de disposer du nom d’utilisateur qui exécute un Processus.

Exemple en GUI :

Cependant en PowerShell, à l’aide de la commande Get-Process, nous ne disposons pas des utilisateurs.

Exemple en PS :

Il existe différente méthodes pour voir les processus sous PS.

Nous allons maintenant utiliser un appel wmi pour afficher les processus via la commande :

gwmi win32_process

Exemple :

En utilisant l’appel wmi, nous avons une propriété nous permettant de connaitre l’utilisateur propriétaire du processus que nous n’avons pas via la commande get-process

Exemple de récupération du propriétaire du processus Spotify à l’aide de la propriétée getowner :

(gwmi win32_process |? {$_.name -match "spotify"} |select -index 0).getowner().user

Nous avons maintenant récupéré le propriétaire du processus.

Contexte

Le post suivant explique comment récupérer des droits sysadmin sur un serveur de base de données suite à la perte du mot de passe du compte SA.

Afin de réaliser cette procédure il faut :

• Un compte administrateur local,
• Planifier un créneau d’interruption durant la récupération des droits SA.

Récupération des droits sysadmin

1. Démarrer l’instance SQL en “single user mode” (ou monouser) avec la commande suivante depuis le répertoire “C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn” :

Il est également possible d’exécuter l’opération avec l’instance démarrées en “minimal configuration” avec le switch –f.

2. Une fois la base de données démarrée en mode “single user” il est possible d’utiliser l’outil SQLCMD pour récupérer les droits sysadmin, exécuter la commande suivante :

3.Une fois connecté depuis SQLCMD, il faut créer un nouvel utilisateur (User1 dans l’exemple suivant) à qui affecter les droits sysadmin à l’aide des commandes suivantes :

4. Redémarrer l’instance SQL (avec la commande SQLServr.Exe) puis se connecter avec le login User1 afin de modifier le mot de passe du compte SA.

Contexte

Le log shipping est l’une des technologies proposée par SQL Server pour mettre en place une haute-disponibilité d’une ou plusieurs bases de données à moindre prix.

Le fonctionnement du log shipping peux être résumé en trois étapes “backup-copy-restore”.

Les logs de transactions des bases de donnée à répliquer sont sauvegardées depuis le serveur primaire puis copiés vers le (ou les) serveur secondaire où ils y seront restaurés sur les bases secondaires correspondantes.

Plus d’informations sur le fonctionnement du log shipping sont disponibles ici.

Prérequis

Les prérequis à l’installation sont les suivants :

Prérequis Applicatifs :

• Au moins deux serveurs avec SQL Server 2005 (Standard, Entreprise ou Workgroup) ou ultérieur,
• Un partage de fichier pour la copie des logs de transactions,
• Le service SQL Server Agent,
• Il est fortement conseillé d’avoir des instances SQL partenaires configurés à l’identique.

Permissions nécessaires :

• Disposer des droits sysadmin sur l’instance primaire et la secondaire,

Configuration du log shipping

Les actions décrites sont effectuées depuis le serveur primaire.

1. Vérifier que la base de donnée à répliquer est en mode de recovery “full” ou “bulk-logged” à l’aide de la requête suivante :

2. Depuis les propriétés de la base à répliquer, depuis l’onglet “Transaction Log Shipping” (1) cochez la case “Enable this as a primary database in a log shipping configuration” (2) puis cliquer sur “Backup Settings” (3) :

3. Depuis la fenêtre Backup Settings, indiquer le chemin réseau où le serveur primaire écriras les backups des logs de transactions des bases de données à répliquer (1) et éventuellement le chemin local (2) si un chemin local est utilisé. Noter que dans les deux cas le compte utilisé par le service SQL Server Agent du serveur secondaire doit avoir un accès en lecture à ce dossier, et le service SQL Server du serveur primaire doit avoir un accès en read/write.

Indiquer le nom du job de backup du serveur primaire (3) de manière à facilement le reconnaitre, éventuellement modifier le schedule proposé (4) par un schedule correspondant mieux à vos contraintes spécifiques puis cliquer sur OK.

4. Depuis la fenêtre Secondary Database Settings, se connecter au serveur secondaire (1), choisir une base de donnée existante ou indiquer le nom d’une nouvelle base (2) qui seras utilisée/créée sur le serveur secondaire, puis choisir le mode pour initialiser la base de donnée secondaire.

Ayant déjà créé initialisé la base distante, j’ai choisi l’option “No, the secondary database is initialized” (3)

5. Depuis l’onglet “Copy Files” (1), indiquer le chemin où les sauvegardes des logs de transactions seront copiés (2), indiquer la rétention des fichiers copiés (3) en faisant attention à ce que les fichiers ne soient pas supprimés avant leur restauration sur le serveur secondaire, personnaliser le nom du job de copie (4) et modifier son schedule si nécessaire (5)

6. Depuis l’onglet “Restore Transaction Logs” (1), choisir “Standby Mode” et cocher la case “Dissconnet users in the database when restoring backups” (2) celà permet d’accéder à la base de données secondaire en Read-Only contrairement au mode “No-Recovery” qui met la base en état de restauration, personnaliser le nom du job de restauration (3) et en modifier le schedule si nécessaire (4)

Vérification

Il convient suite à la mise en place du log shipping de vérifier son fonctionnement en mode manuel (c-à-d en exécutant manuellement les jobs de Backup-Copy-Restore) et automatiquement selon les schedule définis pour chaque jobs.

Il est possible de mettre en place des alertes par email pour informer le DBA de la bonne exécution des jobs de réplication depuis l’onglet Transaction log shipping des propriétés de la base répliquée.

Le script ci-dessous utilise le module powershell PSPKI pour determiner les certificats arrivant a expiration dans $offset jours. (60 par defaut) et alerte si il y a au moins un certificat concernés.

Le module PSPKI est disponible sur le lien https://pspki.codeplex.com/

#SCRIPT DE RAPPORT DES CERTIFICATS ARRIVANT A EXPIRATION
# ! : La variable $computername doit contenir imperativement le FQDN du serveur ADCS 


#Parametres 
param( 
  [string]$computername = "$env:computername.$env:userdnsdomain",
  $offset = 60,
  $WarnNbCert = 1
  )


$Scriptname = "Check_ADCS_Certificat_Expiration"

#Verification de l'existence d'une source ayant le nom du script dans l'eventlog Application pour loguer certains events
Function NewEventSource
{
if(!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Application\$Scriptname"))
    {
    New-EventLog -LogName "Application" -Source $Scriptname
    }
}


#Log du lancement du script
NewEventSource
Write-EventLog -LogName application -Source $Scriptname -EntryType Information -EventId 1002 -Message "Execution du script $Scriptname"

#Write-Host 
Write-Host “Rapport des certificats délivrés par $computername arrivant a expiration dans $offset jours” -ForegroundColor “Yellow” 



#Import PSPKI PowerShell module 
if(Get-Module -Name PSPKI | Where-Object { $_.name -eq “PSPKI” }) 
{ 
Write-Host “PSPKI PowerShell module already imported…” -ForegroundColor “Yellow” 
} 
else 
{ 
Write-Host “Importing PSPKI PowerShell module…” -ForegroundColor “Yellow” 
    try
    {
    Import-Module -Name PSPKI
    }
    catch
    {
    write-host "Erreur lors de l'import du module PSPKI - Verifier que le module est disponible"
    } 
} 
Write-Host


Write-Host 
$caname = $computername.ToLower() 
$todaysdate = Get-Date
$count = Get-CertificationAuthority $caname | Get-IssuedRequest -Filter “NotAfter -ge $todaysdate”, “NotAfter -le $((Get-Date).AddDays($offset))” | Measure-Object | Select-Object -Property Count -ExpandProperty count
$countdisplay = "Nombre de certificats délivrés par $computername arrivant a expiration dans $offset jours: $count `n"
write-host -BackgroundColor white -ForegroundColor Blue $countdisplay

$display = $(Get-CertificationAuthority $caname | Get-IssuedRequest -Filter "NotAfter -ge $todaysdate", "NotAfter -le $((Get-Date).AddDays($offset))")
write-host "DETAILS:"
$display

$result = $display | foreach {$_.CommonName ; ":" ; $_.NotAfter ; " **** "}


# Ajout a l'eventlog
if ($count -ge $WarnNbCert)
{
NewEventSource
Write-EventLog -LogName application -Source $Scriptname -EntryType Warning -EventId 1001 -Message "$countdisplay (CommonName : NotAfter) `n $result"
}
Else
{
NewEventSource
Write-EventLog -LogName application -Source $Scriptname -EntryType Information -EventId 1000 -Message "$countdisplay"
}

Introduction

Azure AD Connect est devenu, depuis quelques mois, le nouvel outil de synchronisation d'identité entre une infrastrcture Active Directory On-Premise et Azure Active Directory. Ce dernier doit remplacé les outils existants (Dirsync et Azure AD Sync) en consolidant les fonctionnalités de chacun de ceux-ci. Aussi, il apporte de nombreuses fonctionnalités comme la synchronisation des attributs étendus, la synchronisation Azure AD vers Active Directory On premise des groupes ou encore une interface de monitoring Azure AD Connect Health. Malheureusement, toutes ces nouvelles fonctionnalités nécessitent de souscrire à la version basic voir premium d’Azure Active Directory.

Du point de vue de l'installation, Microsoft à simplifié les choses pour les personnes disposant déjà d'un des outils précédemment cités. Le but de cet article est de partager un retour d'expérience sur la mise à jour de Dirsync vers Azure AD Connect au travers d'un guide pas à pas puis de détailler les changements entre les deux outils.

Azure AD Connect peut être téléchargé via le lien suivant :

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Mise à jour

Lors du lancement du programme d'installation, il est d'abord demandé d'accepter la licence utilisateur.

Il s'en suit une analyse du serveur existant afin de valider que la configuration Dirsync est compatible avec le processus de migration Azure AD Connect. Si celle-ci n'est pas compatible, il faudra alors réaliser une installation complète du produit. Cela implique de reconfigurer intégralement l'outil (comptes, base de données, règles de filtrage, ….). Plusieurs causes peuvent être responsables de la non prise en charge de la migration :

• Un trop grand nombre d'objets à synchroniser (+ de 50000)

• L'utilisation d'une DLL d'extension personnalisée. Ces dernières permettent d'étendre les fonctionnalités de synchronisation en réalisant du filtrage plus poussé ou une transformation sur certains attributs. Il s'agit d'un concept hérité de Forefront Identity Manager (FIM). En effet Azure AD Connect, comme ses prédécesseurs est toujours basé sur cet outil.

• La suppression d'attributs dans les règles de synchronisation.

Lorsque l'analyse est terminée, il faut indiquer le chemin d'installation ainsi que les informations d'accès à la base de données et éventuellement un compte de service. Comme pour Dirsync, ce dernier doit posséder les droits "Replicate Directory Changes" au niveau du domaine.

Le programme installe ensuite les prérequis.

Les informations (login/mot de passe) du compte utilisé par Dirsync pour accéder à Azure Active Directory doivent être renseignées.

Puis, il est nécessaire d'indiquer un compte Active Directory ayant les droits administrateur de l'entreprise.

La dernière étape consiste à choisir si l'on a activé le mode hybride et s'il faut démarrer la synchronisation dès la fin de l'installation. Ne pas cocher la case permet néanmoins de valider que la configuration a été correctement reportée depuis Dirsync.

Enfin, l'installation s'exécute (une dizaine de minutes).

Revue post installation

Une fois l'installation terminée, DirSync est désinstallé et est remplacé par Azure AD Connect. De nouvelles icônes apparaissent :

• Azure AD Connect : Permet de voir et configurer les paramètres principaux de l'outil

• Synchronization Rules Editor : Cet utilitaire sert à la configuration des règles de filtrages et de transferts d'attributs et ne se trouvent plus dans la console de gestion de FIM.

• Synchronization Service : Cet icône mène à la console de FIM contenant les connecteurs de gestion des identités qui a été renommé pour l'occasion. Comme pour Dirsync, il y a deux connecteurs :

  • Active Directory on premise / Azure AD Connect : import uniquement (sauf en cas d'utilisation du writeback avec Azure AD Premium)

  • Azure AD Connect / Azure Active Directory

• Synchronisation Service Key Management Utility : Utilitaire de gestion de la clé encryptant les données dans Azure AD Connect

NB : Elles sont identiques à celles présentes dans Azure Active Directory Sync.

De plus, comme pour Dirsync, une tâche planifiée nommée Azure AD Sync Scheduler est créée. Elle s'exécute toutes les trois heures (mais il est bien sûr possible de changer ce comportement).

Revue de la configuration

Azure AD Connect :

L'utilitaire Azure AD Connect permet plusieurs options :

• Revue de la configuration actuel

• Configuration des options de synchronisation

• Mise à jour du connecteur

• Gestion du mode staging

La première option permet simplement une revue de la synchronisation mise en place avec une visualisation des annuaires synchronisés et des options activées (synchronisation du mot de passe, des attributs étendues, mapping de l'attribut servant d'UPN dans Office 365). En effet depuis Windows Azure Active Directory Sync, il est possible d'implémenter une synchronisation multi-forêt. Aussi, une synchronisation vers des annuaires différents d'Active Directory est prévue par Microsoft mais cette fonctionnalité n'est pas encore implémentée.

NB : L'option de filtrage par groupe n'est disponible que pour une nouvelle installation et n'est conseillé par Microsoft que dans le cadre d'un déploiement progressif.

Les trois autres options nécessitent d'indiquer un compte administrateur Azure Active Directory  afin de modifier certaines options de configuration.

Le second onglet offre la possibilité d'ajouter d'autres annuaires Active Directory pour la synchronisation.

Il permet aussi d'activer ou désactiver certaines options comme la gestion du mode hybride d'Exchange ou l'écriture inversée (Azure AD vers Active Directory On premise).

L'actualisation du connecteur peut être utilisée après une mise à jour de votre schéma Active Directory. Ainsi, Azure AD Connect pourra mettre à jour ses connecteurs en cas de changement.

Enfin, la dernière option concerne l'activation du mode staging. Lorsqu'il est activé, aucun changement n'est synchronisé/exporté vers Active Directory (si le Writeback est activé) ou vers Office 365. Cela permet de valider sa configuration avant d'appliquer un changement.

Synchronization Service :

Il s'agit de la console Synchronisation Service de Forefront Identity Management. Cependant pour chaque connecteur (appelé Management Agent), les options de configuration sont bien plus légères que dans Dirsync. Il n'est possible de configurer que les paramètres de connexion à l'annuaire, les attributs accessibles et le filtrage par unité d'organisation (via le bouton Container de l'onglet Configure Directory Partitions). En effet, la configuration des filtres par attribut et des règles de jointure d'attribut s'effectue via l'outil présenté dans le chapitre suivant. Cette nouveauté était apparue avec Azure Active Directory Sync.

Synchronization Rules Editor :

Cet outil  change la manière dont sont gérées les règles de synchronisation. Cette gestion ne s'effectue plus au sein de la console de synchronisation héritée de Forefront Identity Manager. Néanmoins, cette nouveauté permet d'utiliser la syntaxe déclarative de FIM qui n'était utilisable qu'au travers de FIM portal (et qui nécessite des CAL pour chaque utilisateur géré par ce système). Ce langage donne la possibilité d'effectuer des opérations simples sans passer par du développement en C# ou VB.Net. Les deux liens ci-dessous expliquent la syntaxe et la détaille :

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-understanding-declarative-provisioning-expressions/

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-functions-reference/

L'utilitaire offre une vision globale des règles entrantes (import depuis Active Directory On premise ou Azure AD) et sortantes (export vers Active Directory On premise ou Azure AD). Toutes ces règles ont une priorité (la plus faible étant prioritaire sur les autres). Si ces dernières ont un poids supérieur à 100 alors elles correspondent aux règles par défaut de l’outil.

Nous remarquons sur l'image précédente qu'il y a une règle avec une priorité de 99. Il s'agit d'une règle personnalisée reprise lors de la migration de Dirsync. Celle-ci filtre les utilisateurs via un attribut Active Directory. On peut définir le type d'objet source (ici l'annuaire Active Directory On premise) et le type d'objet dans la Metaverse, c’est-à-dire dans la base de données d'Azure AD Connect. Enfin, on peut redéfinir la priorité de la règle. 

L'onglet suivant permet de définir le ou les attributs utilisé(s) pour filtrer les objets (ici des utilisateurs mais cela peut aussi s'appliquer à des groupes par exemple). La définition du filtrage se fait de la même façon que sur Dirsync (les objets satisfaisants la règle étant exclus de la synchronisation).

Ensuite, il est possible de définir une règle de jointure entre un objet provenant de la source (annuaire Active Directory ou Azure Active Directory) et la metaverse. Cette jointure s'effectue sur un attribut. Dans le cas de notre règle de filtrage, il n'existe pas de règle de jointure. Cependant il n'est pas nécessaire d'en ajouter.

En effet, si l'on ouvre la règle avec la priorité 100 (In From AD - User Join), on remarque qu'une règle de jointure existe déjà pour les objets de types utilisateurs.

Enfin, on définit les valeurs transmises depuis la source vers la metaverse. Elles peuvent être de trois types :

• une valeur constante

• un attribut source

• un attribut source transformé via la syntaxe déclarative

Dans le cadre d'un filtrage par attribut pour la synchronisation, les objets non synchronisés doivent posséder l'attribut cloudFiltered avec la valeur True dans la metaverse.

Conclusion

L'installation est donc très similaire à celle de Dirsync et demande les mêmes informations (compte administrateur de l'entreprise, serveur SQL, ...). De plus, le processus de mise à jour est simplifiée au maximum. Néanmoins, pour les personnes n'ayant pas utilisées Azure Active Directory Sync, l'administration et notamment la configuration les règles de synchronisation est différente.

Introduction

Avec le développement de l'authentification unique en entreprise, ADFS (Active Directory Federation Services) est devenu un rôle de plus en plus déployé. Même si son déploiement reste simple et très documenté (grâce notamment, au déploiement d'Office 365), il est courant de rencontrer des difficultés lorsque l'on souhaite ajouter une fédération ou réaliser une configuration spécifique.

Au cours de cette article, il sera question de résoudre une erreur pouvant se produire lors de l'ajout d'une fédération, c’est-à-dire lorsque l'on veut utiliser son système d'authentification d'entreprise avec un partenaire (une application SAAS par exemple). Généralement, les informations permettant d'établir une fédération sont contenues dans un fichier de métadata qui est accessible depuis une url ou qu'il faut importer via un fichier. Cependant, des erreurs dans le fichier de métadata fourni par le partenaire peuvent empêcher d'avoir une configuration correcte.

Problème rencontré

L'ajout d'une fédération s'effectue dans la console de gestion ADFS via l'action "Add relying party trust" dans le menu "Trust Relationships / Relying Party Trusts".

Lorsque l'assistant s'ouvre, il est possible de choisir la méthode de configuration de la fédération. Il existe trois méthodes :

• Une url d'accès au metadata : il s'agit de la méthode nécessitant le moins de maintenance. Les mises à jour des métadata sont prises en compte automatiquement. Si vous souhaitez fournir les vôtres via cette méthode (afin de faciliter la configuration pour le partenaire), il suffit d'ouvrir l'accès à l'url suivante https://NOM_DNS/federationmetadata/2007-06/federationmetadata.xml (n'oublier pas de remplacer NOM_DNS par le nom DNS d'accès au service ADFS).

• Un fichier de metadata : il s'agit d'un fichier fourni par le partenaire dont le contenu est identique à celui présent via la première méthode.

• Une configuration manuelle : il faut insérer chaque paramètre manuellement

La méthode qui nous intéresse ici et qui peut poser problème est la seconde. En effet, si le fichier contient des erreurs de syntaxe, le message suivant peut apparaitre :

Some of the content in the federation metadata was skipped because it is not supported by AD FS. Review the properties of the trust carefully before you save te trust to the ADFS configuration database.

Même si celle-ci n'est pas bloquante, elle peut entrainer une mauvaise configuration de la fédération.

Résolution

Les conseils ci-dessous sont issues de retour d'expérience. Lorsque l'erreur ci-dessus est rencontrée, il convient de modifier le fichier est de faire des tests de façon dichotomique afin d'obtenir une configuration valide. Par exemple, on peut supprimer les assertions une à une afin de trouver celle(s) qui posent problème. Il faudra ensuite vérifier si elle est nécessaire pour le bon fonctionnement de la fédération (auquel cas, un correctif devra être trouvé) ou si elle peut être supprimée.

La principale erreur rencontrée dans un fichier de métadata est la présence d'assertion pour plusieurs versions  de SAML. En effet ADFS supporte les standards SAML en version 1.0, 1.1 et 2.0 permettant d'échanger des informations avec un partenaire de manière sécurisée. Même si cela permet à un partenaire de ne maintenir qu'un seul fichier de métadata, ADFS ne tolère la présence que d'une version de SAML par fichier. Par exemple, la présence concomitante de ces deux assertions doit être proscrite :

Dans ce cas là, il suffira de supprimer les assertions en SAML v1.0.

D'autre part, une erreur courante est d'intégrer des URLs non sécurisées (HTTP au lieu de HTTPS). Cela n'est pas autorisé.

Dernière erreur courante, ADFS est permissif sur la syntaxe et plus précisément sur la casse des assertions. Ainsi, l'assertion suivante est invalide si HTTP-Redirect est remplacé par HTTP-REDIRECT.

Aussi, si vous souhaitez accéder à la syntaxe complète du langage SAML afin de valider un fichier de métadata, vous trouverez ci-dessous des liens détaillant la syntaxe selon la version :

• SAML v2 : https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

• SAML v1.1 : https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

Problème rencontré

Après l'installation d'une autorité de certification d'entreprise, j'ai rencontré une erreur m'empêchant de publier des modèles de certificats dont la version est supérieures à 1. Ce problème fut rencontré sur Windows 2012 R2 mais ne peut être généralisé à toute installation avec ce système d'exploitation. Néanmoins, cet article permet de résoudre cet incident. Voici tout de même le contexte dans lequel s'est produit ce problème. L'autorité de certification était de type Subordinate  Enterprise et avait été installé avec un fichier CAPolicy.inf contenant notamment la ligne "LoadDefaultTemplates=False". Ce dernier évite de publier les modèles par défaut.

Bien qu'il soit possible de créer des nouveaux modèles dans l'annuaire Active Directory, ces derniers n'étaient pas visibles lors de leur publication via la console de gestion d'autorité de certification.

De plus, même les modèles générés par défaut comme “Workstation Authentication” (modèle de version 2) ou encore “OCSP Response Signing” (modèle de version 3) n'apparaissent pas dans la liste des modèles publiables.

Contrairement à un mauvais choix de type d'autorité de certification (standalone au lieu d'enterprise), il reste possible de publier des certificats mais seulement ceux dont le numéro de version est égale à 1.

Solution

Cette erreur est due à un problème de configuration du registre. Pour rappel, les paramètres de configuration de l'autorité de configuration sont stockés dans “HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\NOM_CA” où “NOM_CA” représente le nom de l'autorité de certification.

Pour corriger l'erreur, il faut mettre à jour le registre via la ligne de commande ci-dessous (celle-ci doit être exécutée en mode administrateur) :

Enfin, pour que la modification soit prise en compte, il est nécessaire de redémarrer le service d'autorité de certification. Vous pouvez réaliser cette opération graphiquement ou via les commandes suivantes :

NB : Une KB Microsoft (http://support.microsoft.com/kb/967332) décrit un problème similaire lors de la mise à jour d'une autorité de certification 2003 ou 2008 en édition Standard vers une édition Enterprise de Windows 2008. En effet, seule cette dernière permet d'installer une autorité de certification de type Enterprise. Cependant, cette KB n'existe pas sous Windows 2012 et supérieure. Il n'y a d'ailleurs plus de contrainte sur l'édition du système d'exploitation installée (tous les types d'autorités de certification pouvant être installées sur une édition standard comme datacenter depuis Windows Server 2012). Néanmoins, l'erreur décrite dans cet article peut tout de même être rencontrée.

Le script ci-dessous interroge le psdrive dédié au magasin de certificat local a la machine pour lister les certificats dont la date d’expiration approche (paramètre $expireInDays) et alerter si le nombre de certificats concernés depasse le seuil donné (Paramètre $NbThreshold).

Le parametre $blacklist permet d’exclure les certificats dont l'expiration est considéré OK (root & co, on Windows Server 2003, 2008 & 2012)