Quelques commandes à connaître pour diagnostiquer les problèmes avec Kerberos

Il n’est pas toujours possible d’accéder à la console d’administration d’Active Directory pour consulter les SPNs configurés pour un compte ou pour connaître la liste des services permis pour la délégation.

Voici donc une liste d’outils “Command Line” qui peuvent vous aider à effectuer des diagnostics lorsque votre ami des TI est absent.

KList (C:\Windows\System32)

  1. klist: liste les “tickets” actifs pour le compte courant
  2. klist purge: vide la liste des “tickets” pour le compte courant

SetSpn (C:\Windows\System32)

  1. setspn –l nomcompte: liste les SPNs configurés pour un compte donné
  2. setspn –s nomservice nomcompte: ajoute un SPN au compte spécifié après avoir vérifié qu’il n’y a aucun doublon
  3. setspn –d nomservice nomcompte: supprime un SPN au compte spécifié
  4. setspn –X: Vérifie qu’il n’y a pas de doublons, c’est à dire un SPN enregistré sur plus d’un compte. La présence de doublons peut empêcher Kerberos de fonctionner.

Script PowerShell (Maison)

Il manquait une manière d’obtenir la liste des services autorisés pour la délégation pour un compte donné. Ce script PowerShell vous permet de le faire (en obtenant la liste des SPNs configurés du même coup):

.\ListKerberos.ps1 nomcompte

Merci à mon collègue Georges Turpin pour la trouvaille et l’adaptation.

Voici le contenu du script:

param (
[string]$UserID = $(throw « -UserID required. »)
)

$strUserName = $UserID
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$strFilter = « (&(objectCategory=User)(samAccountName= » + $strUserName + « )) »
$objSearcher.SearchRoot = $objDomain
$objSearcher.PageSize = 1000
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = « Subtree »
$colResults = $objSearcher.FindAll()

foreach ($objResult in $colResults)
{
$objUser = $objResult.GetDirectoryEntry()
$objUser.RefreshCache(@(« canonicalName »))

Write-host  »  servicePrincipalNames » -ForegroundColor Green

$i=1

foreach($SPN in $objUser.servicePrincipalName)
{
Write-host  »    SPN( » $i « )   =    » $SPN
$i+=1
}

Write-host «  »

    « – – – – – »

$objHash = @{}
$objHash.Add(« ADS_UF_SCRIPT », »&h0001″)
$objHash.Add(« ADS_UF_ACCOUNTDISABLE », »&h0002″)
$objHash.Add(« ADS_UF_HOMEDIR_REQUIRED », »&h0008″)
$objHash.Add(« ADS_UF_LOCKOUT », »&h0010″)
$objHash.Add(« ADS_UF_PASSWD_NOTREQD », »&h0020″)
$objHash.Add(« ADS_UF_PASSWD_CANT_CHANGE », »&h0040″)
$objHash.Add(« ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED », »&h0080″)
$objHash.Add(« ADS_UF_TEMP_DUPLICATE_ACCOUNT », »&h0100″)
$objHash.Add(« ADS_UF_NORMAL_ACCOUNT », »&h0200″)
$objHash.Add(« ADS_UF_INTERDOMAIN_TRUST_ACCOUNT », »&h0800″)
$objHash.Add(« ADS_UF_WORKSTATION_TRUST_ACCOUNT », »&h1000″)
$objHash.Add(« ADS_UF_SERVER_TRUST_ACCOUNT », »&h2000″)
$objHash.Add(« ADS_UF_DONT_EXPIRE_PASSWD », »&h10000″)
$objHash.Add(« ADS_UF_MNS_LOGON_ACCOUNT », »&h20000″)
$objHash.Add(« ADS_UF_SMARTCARD_REQUIRED », »&h40000″)
$objHash.Add(« ADS_UF_TRUSTED_FOR_DELEGATION », »&h80000″)
$objHash.Add(« ADS_UF_NOT_DELEGATED », »&h100000″)
$objHash.Add(« ADS_UF_USE_DES_KEY_ONLY », »&h200000″)
$objHash.Add(« ADS_UF_DONT_REQUIRE_PREAUTH », »&h400000″)
$objHash.Add(« ADS_UF_PASSWORD_EXPIRED », »&h800000″)
$objHash.Add(« ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION », »&h1000000″)

[string]$intUAC = $objUser.userAccountControl.Value

Foreach ($objKey in $objHash.Keys)
{
[string]$intKey = $objHash.Item($objKey)

If (($intUAC -bAnd $intKey) -ne 0)
{
switch ($objKey)
{
« ADS_UF_SCRIPT »{« The logon script is executed. »}
« ADS_UF_ACCOUNTDISABLE »{« The user account is disabled. »}
« ADS_UF_HOMEDIR_REQUIRED »{« The home directory is required. »}
« ADS_UF_LOCKOUT »{« The account is currently locked out. »}
« ADS_UF_PASSWD_NOTREQD »{« No password is required. »}
« ADS_UF_PASSWD_CANT_CHANGE »{« The user cannot change the password. « }
« ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED »{« The user can send an encrypted password. »}
« ADS_UF_TEMP_DUPLICATE_ACCOUNT »{« This is an account for users whose primary account is in another domain. »}
« ADS_UF_NORMAL_ACCOUNT »{« This is a default account type that represents a typical user. »}
« ADS_UF_INTERDOMAIN_TRUST_ACCOUNT »{« This is a permit to trust account for a system domain that trusts other domains. »}
« ADS_UF_WORKSTATION_TRUST_ACCOUNT »{« This is a computer account for a computer that is a member of this domain. »}
« ADS_UF_SERVER_TRUST_ACCOUNT »{« This is a computer account for a system backup domain controller that is a member of this domain. »}
« ADS_UF_DONT_EXPIRE_PASSWD »{« The password for this account will never expire. »}
« ADS_UF_MNS_LOGON_ACCOUNT »{« This is an MNS logon account. »}
« ADS_UF_SMARTCARD_REQUIRED »{« The user must log on using a smart card. »}
« ADS_UF_TRUSTED_FOR_DELEGATION » { « DELEGATION – Trust this user for delegation to any service (Kerberos only). » }
« ADS_UF_NOT_DELEGATED »
{
« DELEGATION – Trust this user for delegation to specified services only (use any protocol): »
$objUser.properties[« msDS-AllowedToDelegateTo »]
}
« ADS_UF_USE_DES_KEY_ONLY »{« Restrict this principal to use only Data Encryption Standard (DES) encryption types for keys. »}
« ADS_UF_DONT_REQUIRE_PREAUTH »{« This account does not require Kerberos pre-authentication for logon. »}
« ADS_UF_PASSWORD_EXPIRED »{« The user password has expired. »}
« ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION »
{
« DELEGATION – The account is enabled for delegation: »
$objUser.properties[« msDS-AllowedToDelegateTo »]
}
default {« Could not find the UAC »}
}
}
}
}

Est-ce que cette information vous a été utile? Utilisez-vous d’autres outils? N’hésitez pas à commenter …

Oui vous pouvez utiliser C2WTS sur un serveur unique (Single Server Install) avec SharePoint 2013

Problématique

Un article de TechNet crée de la confusion au niveau de la configuration de SharePoint 2013 lorsque tout est sur le même serveur.

Le paragraphe suivant est le coupable:

Note: Some of the configuration steps may change, or may not work in certain farm topologies. For instance, a single server install does not support the Windows Identity Foundation C2WTS services so claims to windows token delegation scenarios are not possible with this farm configuration.

Ou en français:

Remarque : certaines étapes de configuration peuvent changer, ou peuvent ne pas fonctionner dans certaines topologies de batteries de serveurs.  Par exemple, une installation de serveur unique ne prend pas en charge les services C2WTS Windows Identity Foundation, c’est pourquoi les scénarios de délégation de jetons Windows ne sont pas possibles avec cette configuration de batterie de serveurs.

Cela laisse sous-entendre que la sécurité de données (SSAS) ne peut être utilisée avec SharePoint 2013, SSRS et SSAS. Il faudrait donc configurer les sources de données pour utiliser un compte en particulier ce qui empêcherait de retourner des données différentes selon l’utilisateur du rapport.

Plusieurs forums discutent de cette affirmation donc celui-ci. Une hypothèse est que Single Server Install a probablement été inversé pour “Standalone” qui signifie que Windows Internal Database est utilisée plutôt qu’une vrai version de SQL Server.

Solution

Peu importe, nous l’avons testé et cela fonctionne parfaitement!

Dans mon article Reporting Services 2012 et la configuration Kerberos: désolé vous devrez utiliser la constrained delegation avec C2WTS je disais que dès que C2WTS est utilisé, la constrained Kerberos delegation doit être utilisée. Je maintiens mon affirmation avec l’exception suivante: pas si tout est sur le même serveur.

Quand tout est sur le même serveur, utilisez vos comptes de services réguliers qui délèguent vers “Any Services”:

Service Compte
SQL Server (engin relationnel) cs-sql
Analysis Services cs-ssas
Reporting Services cs-ssrs ou cs-web
SharePoint (Web Apps) cs-web
C2WTS Local System

La clé pour que cela fonctionne sur un seul serveur est d’utiliser “Local System” comme compte de service pour C2WTS.

Si vous utilisez un compte de domaine pour C2WTS ça ne fonctionnera pas. Vous n’avez même pas besoin de configurer la délégation Kerberos pour le serveur (i.e. servername$).

Cela vous permettra d’avoir le scénario suivant:

  1. Frédérick demande l’affichage d’un rapport SSRS 2012 stocké dans SharePoint 2013.
  2. IIS l’authentifie via Windows Authentication et la plomberie Microsoft .NET convertira le jeton Windows en Claim.
  3. SharePoint et SSRS fonctionnent en claims.
  4. Puis lorsqu’il est temps d’interoger la source de données (SSAS) il faut obtenir une identité Windows car SSAS n’est pas Claim-Aware. C’est là qu’intervient C2WTS et celui-ci génère un jeton pour Frédérick qu’il envoie à SSAS.
  5. SSAS peut donc retourner les données propres à Frédérick (sécurité de données).

image

Le déploiement sur un seul serveur est pratique pour réaliser des tests ou pour des solutions de moindres envergures.

J’espère donc que cet article contribura à réduire la confusion sur ce sujet.

Et vous, utilisez-vous les déploiement sur un seul serveur avec de la sécurité de données?

Références

Claims to Windows Token Service (C2WTS)
http://technet.microsoft.com/en-us/library/hh231678.aspx

Claims to Windows Token Service (c2WTS) Overview
http://msdn.microsoft.com/en-us/library/ee517278.aspx

Does C2WTS work on a single server install??
http://social.technet.microsoft.com/Forums/sharepoint/en-US/85bd9bf4-ce25-4faf-85ea-6e3bbf081f24/does-c2wts-work-on-a-single-server-install?forum=sharepointadminprevious

Problème de connexion OLEDB avec SSAS et Kerberos

Nous avons rencontré un problème d’authentification Kerberos sous Windows 2008 en utilisant une connexion OLEDB vers Analysis
Services.

Il est parfois nécessaire d’utiliser le pilote OLEDB comme source de données avec Reporting Services. Le pilote par défaut, Microsoft Analysis Services, nous force à requêter des mesures sur les colonnes et le reste sur les lignes. Dans certains cas particulier, le MDX à utiliser ne peut respecter cette règle et il faut alors utiliser le pilote OLEDB.

Dans notre situation, il y avait un serveur pour SharePoint/SSRS et un autre pour SQL/SSAS. Il fallait donc configurer ceux-ci pour la délégation Kerberos.

Il y a cependant un bogue avec Windows 2008 (R1) et Kerberos qui est corrigé uniquement via un Hot Fix.

Voici l’erreur qu’on obtient:

The following system error occurred:
Errors in the compression library: The data could not be decompressed.

La fonction demandée n’est pas prise en charge
Erreurs de la bibliothèque de compression : Impossible de décompresser les données.

La solution est de demander le Hot Fix à Microsoft en fournissant une adresse de courriel. Presqu’immédiatement on reçoit le Hot Fix et il suffit de l’appliquer sur le serveur Windows 2008.

Voici le lien vers le Hotfix (kb 969083):

http://support.microsoft.com/kb/969083

Le problème survient avec les versions suivantes de Windows:

  1. Windows Server 2008 Datacenter
  2. Windows Server 2008 Enterprise
  3. Windows Server 2008 Standard
  4. Windows Vista Enterprise 64-bit Edition
  5. Windows Vista Home Basic 64-bit Edition
  6. Windows Vista Home Premium 64-bit Edition
  7. Windows Vista Ultimate 64-bit Edition
  8. Windows Vista Business
  9. Windows Vista Business 64-bit Edition
  10. Windows Vista Enterprise
  11. Windows Vista Home Basic
  12. Windows Vista Home Premium
  13. Windows Vista Ultimate

Intégrer une application ASP.Net MVC sous un site Web IIS hébergeant WSS 3.0 / SharePoint 2007

WSS 3.0 et MOSS 2007 utilisent le .NET Framework 2.0. Les projets de développement Web récents utilisent souvent ASP.Net MVC avec le .NET Framework 4.0. Il y a quelques éléments à configurer pour faire fonctionner une application ASP.Net 4.0 sous SharePoint. Voici la recette:

  1. Vous devez créer un « Application Pool” utilisant le “.NET Framework 4.0” et empruntant la même identité (le même compte de service) que l’ “Application Pool” de SharePoint.Puisque le site IIS a un SPN unique (ex. HTTP/nomgentil.domaine.com), celui-ci est déjà défini sur le compte de service en question. Ainsi, il suffira d’ajouter la déléguation vers SQL Server ou SSAS à ce compte selon ce que fait l’application ASP.Net.
  2. Vous devez copier le répertoire de votre application ASP.Net sous le répertoire contenant SharePoint. Ex. C:\Inetpub\wss\nomgentil.domain.com\ApplicationMVC
  3. Les permissions par défaut ne sont pas les même que pour les sites placés directement sous C:\Inetpub alors assurez-vous de donner les permissions Windows à Users ou autre au répertoire de votre application MVC.
  4. Il faut convertir le virtual directory en application dans IIS en prenant bien soin d’utiliser le pool d’application défini précédemment.
  5. Une application ASP.Net utilise un fichier Web.Config afin de configurer différents éléments propres à .Net. Ce qu’il faut savoir c’est qu’il y a un lien d’héritage entre les Web.Config des applications Web. Ainsi si l’application B est placée sous l’application A dans IIS, elle hérite du Web.Config.Le problème c’est qu’en étant sous SharePoint, on hérite de certains éléments incompatibles avec une application utilisant le “.NET Framework 4.0”.

    Il faut donc modifier le web.config de SHAREPOINT pour indiquer qu’on ne souhaite pas hériter de certaines sections dans les sites enfants. Plus spécifiquement, il faut entourer les noeuds <system.web> et <System.Workflow.ComponentModel.WorkflowCompiler> d’un noeud <location path= ». » inheritInChildApplications= »false »>. Par exemple:

    <location path= ». » inheritInChildApplications= »false »>
    <system.web>

    </system.web>
    </location>

  6. On hérite aussi des “Handler Mappings” du site SharePoint et il y en a beaucoup. Il faut au moins enlever (dans l’application ASP.Net MVC) celui qui intercepte * et qui porte le nom AboMapperCustom-<numéro> pointant vers ASP.Net 2.0 (aspnet_isapi.dll). Autrement les images, CSS et autres fichiers statiques ne fonctionneront pas.image

    Cela aura pour effet d’ajouter ceci au web.config de votre application:

    <handlers>
    <remove name= »AboMapperCustom-3515455823″ />
    </handlers>

  7. IIS Reset
  8. Si vous avez une erreur qui dit que le fichier de configuration n’est pas accessible, donnez temporairement les droits en lecture au groupe local IIS_IUSRS sur ce fichier (l’erreur indique le chemin d’accès).Quand IIS n’arrive pas à déterminer l’authentification utilisée (ex. il y a un nœud dupliqué dans les web.config parent et enfant), il doit avoir accès en mode anonyme. Après l’erreur qui sera affichée sera détaillée (ex. le nœud qui ne peut être redéfini etc.)

Références
Troubleshooting HTTP 500.19 Errors in IIS 7
http://blogs.iis.net/webtopics/archive/2010/03/08/troubleshooting-http-500-19-errors-in-iis-7.aspx