Archives de catégorie : Kerberos

Dépannage des publications Web Application Proxy avec Kerberos Constrained Delegation

Vous avez vraiment cru que je ferai un truc simple comme annoncé dans mon billet Kerberos Constrained Delegation avec Web Application Proxy expliquée? Je déconnais. L’application simple, c’est SharePoint 2013. J’avais déjà abordé Web Application Proxy dans le billet « Quand Windows Azure Pack rencontre Web Application Proxy (WAP versus WAP) » pour publier le portail est les API des tenant à l’extérieur. Ça c’était simple. Maintenant on passe la vitesse supérieure.

Pour ce billet, je pars du principe que les éléments suivants sont en place :

  • Vos contrôleurs de domaine reposent sur Windows Server 2012 minimum
  • Votre infrastructure ADFS est en place et opérationnelle (ADFS 3.0, donc Windows Server 2012 R2)
  • Votre serveur Web Application Proxy est déjà en place et membre du domaine
  • Votre infrastructure SharePoint 2013 est en place
  • Votre application dans SharePoint 2013 a été correctement configurée pour utiliser Windows Integrated Authentication (WIA) et plus précisément Kerberos

Coté SharePoint, je n’ai donc qu’un seul prérequis, mais un prérequis de taille, celui que notre front-end accepte d’utiliser des tickets Kerberos pour l’authentification et non pas du NTLM. En fait, rien que ça, c’est pas si simple que cela. De nombreux billets sont consacrés sur ce thème. Que l’admin SharePoint qui n’a pas transpiré lors de l’activation de l’authentification Keberos sur une ferme SharePoint se lève, je veux le voir, … Donc Si votre ferme SharePoint 2013 est correctement configurée, on peut continuer.

Pourquoi Kerberos?

Par défaut, SharePoint connais les méthodes d’authentifications suivantes :

  • Windows Integrated Authentication
  • Form-Based Authentication
  • SAML token-based authentication

Le dernier repose sur une mise en œuvre intégrée avec ADFS. Sur le papier c’est sexy mais c’est un poil compliqué à mettre en œuvre. Si nous n’avions que des utilisateurs externes (genre partenaires ça a du sens mais de moins en moins avec les solutions hybride). En plus dans un contexte de publication avec Web Application Proxy, c’est tellement simple à mettre en œuvre, presque trop simple.

Le Form-Based Authentication est le plus simple à mettre en œuvre mais dans ce cas, aucune chance de pouvoir faire de la pré-authentification en DMZ avec notre Web Application Proxy. Par exclusion, il ne reste qu’un seul choix : Windows Integrated Authentication.

WIA pour les intimes. Avec lui, on peut faire de la pré-authentification et même du SSO. Problème qui dit SSO, dit aussi Kerberos obligatoire. Le Windows Integrated Authentication n’est qu’un fournisseur qui permet de négocier une méthode d’authentification parmi une liste bien fournie :

  • Kerberos
  • NTLM
  • Digest
  • Basic

Exit les deux derniers et NTLM, on fait tout ce qu’on peut pour s’en débarrasser. Du point de vue de Web Application Proxy, on va fonctionner en Kerberos-Constrained Delegation. Cela signifie qu’une fois authentifié via l’ADFS Proxy (porté par WAP), le WAP va négocier et présenter un ticket Kerberos au nom de l’utilisateur connecté. Pourtant, celui qui fera la demande, c’est le compte de service ADFS. Si vous avez bien tout suivi, en toute logique, notre serveur WAP est donc membre du domaine ou alors membre d’un domaine avec lequel on dispose d’une relation d’approbation bidirectionnelle. Allez relire la section correspondante du document cité dans mon précédent billet.

Subtilités de mise en œuvre

La mise en œuvre est détaillé chez Microsoft à cette URL. Ça aide pas beaucoup pour SharePoint 2013. Une petite recherche sur Internet devrait vous aider sur ce sujet. Passons un peu de temps coté Web Application Proxy. Dans l’interface de configuration de WAP, on ne trouve pas le choix Kerberos Constrained Delegation. C’est vrai. Procédons par élimination. Si on choisissait « Pass-Throught », WAP ne serait utilisé que pour sa fonction de reverse-proxy HTTPS. L’authentification serait déportée sur le frontal SharePoint 2013, pas de Kerberos, pas de SSO. Logiquement, ce sera donc le choix « Active Directory Federation Services (ADFS).

clip_image001

 

Si on continue dans cette logique, on doit sélectionner un ADFS Relying Party. Dans une infrastructure ADFS 3.0 (Windows Server 2012 R2) fraichement installée, on nous propose un unique choix : Device Registration Service. Ce que nous recherchons, c’est une fournisseur d’identité auquel on va soumettre la demande d’authentification pour notre application publiée.

clip_image002

 

L’astuce, c’est comment faire consommer le Claims à notre SharePoint 2013 qui n’a aucune idée de ce que c’est. Lui, c’est WIA (Kerberos) ou rien. La réponse se trouve dans ADFS. Les applications dites « Claims-Aware » reconnaissent en ADFS un fournisseur d’identité de confiance qu’elles peuvent solliciter pour authentifier les utilisateurs. Pour cela on déclare un « relying Party » qui permet d’établir un lien de confiance entre l’infrastructure ADFS et l’application qui va venir consommer ce service. Le problème, c’est que notre SharePoint 2013, tel qu’il est configuré, il est tout sauf « Claims-Aware ». C’est pour cette raison que dans ADFS 3.0, on peut déclarer deux types de Trusts :

clip_image003

 

Les « Non-Claims Aware relying party trusts » ont été introduit pour les applications qui ne savent pas traiter les claims mais qui connaissent WIA. Le Welcome Screen du wizard de la console ADFS est très clair sur ce point.

clip_image004

 

Vu que notre application ignore le concept de claims, on a pas besoin de décrire le contenu du claims à construire, ni à configurer la dite application pour utiliser notre infrastructure ADFS comme fournisseur d’authentification. Les options configurables sur un « Non-Claims Aware relying party trust » sont :

  • Un nom unique clairement identifiable
  • Le fait d’utiliser un facteur d’authentification tier (Multi-Factor Authentication) et les exigences qui vont avec

 

Au final, notre utilisateur obtiendra bien un claims ADFS mais vu qu’il aura été délivré par un Relying Party ne supportant pas les Claims, notre serveur WAP devra jouer de sa personne et obtenir un ticket Kerberos pour le compte de l’utilisateur. C’est là que la Kerberos Constrained Delegation rentre en jeu.

Quelques points de configuration

Pour pouvoir déboguer le bouzin, il faut déjà avoir du contenu. Le problème, c’est que dans sa configuration par défaut, notre infrastructure ADFS ne journalise pas tout. Un peu de Powershell Get-AdfsProperties | Select Loglevel. Rien sur les authentification en elle-même, aucune trace des accès réussi ou des échecs. Certes on pourra retracer les jeton Kerberos mais si c’est pas Kerberos qui est en cause, ça va pas nous aider.

clip_image005

 

Pour cette raison, je recommande de reconfigurer l’attribut LogLevel de la manière suivante : Set-AdfsProperties -LogLevel $((Get-AdfsProperties).LogLevel + « SuccessAudits » + « FailureAudits »)

Get-AdfsProperties | Select Loglevel

clip_image006

 

Qu’est-ce que ça change me direz-vous. Tout.

clip_image007

 

On découvre qu’on est maintenant en mesure de journaliser les authentifications réussies et échouées mais qu’il faut encore un peu plus de travail. Plus précisément, il faut permettre à ADFS de générer des évènements dans le journal de sécurité, c’est un droit qui a été octroyé lors de l’installation d’ADFS. Le compte de service utilisé par ADFS a été configuré pour avoir le privilège de générer des évènements de sécurité.

clip_image008

Note : Si vous avez des GPO qui configurent les droits utilisateurs, pensez à repositionner le privilège, sinon ADFS n’aura rien à vous dire.

Enfin, il faut indiquer ce que l’on veut auditer. Pour les applications, on a un journal spécial nommé « Application Generated ». Avec la commande AuditPol.Exe, on constate que par défaut, ce journal ne contiendra rien. AuditPol.Exe /Get /Subcategory « Application Generated ».

clip_image009

 

Avec un peu de configuration, on arrive à corriger cela.

AuditPol.Exe /Set /SubCategory: »Application Generated » /Success:Enable /failure:Enable

AuditPol.Exe /Get /Subcategory « Application Generated »

clip_image010

 

Dans la GPO locale, c’est plus clair :

clip_image011

 

Pourtant, il reste une subtilité. Nous sommes dans la section « Advanced Audit Policy Configuration » introduite avec Windows Server 2008 R2. Si on remonte d’un niveau, on voit bien que le paramètre précédemment configuré est bien présent. Ce qui m’intéresse, c’est l’avertissement.

clip_image012

 

Allons voir le paramètre qui manque. On a donc besoin de lui.

clip_image013

 

Suivi de bout en bout

Maintenant qu’on a de quoi journaliser les accès, voyons à quoi ressemble un accès utilisateur fonctionnel depuis le Web Application Proxy pour notre application SharePoint 2013 publiée. La première trace, c’est sur le serveur ADFS qu’on va la trouver. C’est notre point de départ. La chose à noter ici, c’est l’Activity ID. Il est unique pour chaque accès, c’est donc lui qui nous permettra de relier les évènements.

clip_image014

Note : L’évènement 403 référence une autre information importante : L’adresse IP source de la demande, donc de notre client.

En suivant l’Activcity ID, on trouve l’évènement 410. Son intérêt, c’est de savoir par quel Endpoint la demande d’accès est arrivée. Avec une infrastructure basique composée d’un seul serveur ADFS c’est facile mais si on a une infrastructure utilisant plus de cinq serveur ADFS (on utilise donc plus le Windows Integrated Database mais une véritable instance SQL Server), ça se complique. En plus, c’est Event nous précise que la demande est arrivée par le serveur Web Application Proxy. C’est un attribut qui sera référencé dans le claims. C’est que qui permettra par exemple d’exiger une authentification additionnelle tel que Multi-Factor Authentication (MFA).

clip_image015

 

Coté ADFS, l’évènement 412 nous indique qu’un jeton a été délivré par notre infrastructure ADFS. L’Activity ID que nous connaissons déjà nous permet de suivre le cheminement de notre demande d’accès. Maintenant, on va garder l’attribut Instance ID dans un coin de notre tête.

clip_image016

 

Car on va suivre l’évènement 501 ou plutôt les évènements 501. Si toutes les informations ne peuvent figurer dans un même évènement, on en aura donc plusieurs. Le lien entre eux, ce sera notre Instance ID. ADFS nous donne le contenu du claims, aussi bien les attributs contenus que les valeurs associées.

clip_image017

 

Dans mon cas, cet évènement est intéressant car il indique les groupes dont mon utilisateur est membre (attribut GroupSid).

clip_image018

 

A ce stade, notre infrastructure ADFS a délivré un claims. Or, notre infrastructure sait que notre application n’est pas Claims-Aware. Elle doit donc demander un ticket Kerberos pour le compte de l’utilisateur qu’elle vient d’authentifier. Sur nos contrôleurs de domaine, on va donc trouver le trace d’un évènement 4768. C’est juste la demande. Au passage, on remarque que celle-ci a été réalisée localement par la mention ::1. Ben oui, sur ma maquette, mon ADFS est installé sur mon contrôleur de domaine, je sais c’est mal.

clip_image019

 

Toujours sur nos contrôleurs de domaine, l’évènement 4769, nous donne un peu plus d’informations, genre l’UPN de l’utilisateur qui fait la demande de ticket Kerberos.

clip_image020

 

C’est maintenant qu’on sait si la délégation Kerberos fonctionne. Notre ADFS tente de l’utiliser pour s’authentifier. On voit bien que c’est le process « C:\Windows\ADFS\Microsoft.Identity.Server.ServiceHost.Exe » qui fait la tentative.

clip_image021

 

L’évènement 4624 nous confirme que la demande d’authentification utilisant mon identité a bien fonctionné. L’évènement précise bien que c’est le compte de service ADFS qui a obtenu une ouverture de session pour mon compte.

clip_image022

 

Dernière étape, le Web Application Proxy. Ça se passe dans le journal « Microsoft-Windows-Web Application Proxy/Admin ». Jusqu’à maintenant mon Web Application Proxy se contentait de jouer son rôle de Proxy ADFS. Maintenant c’est au tour de la publication. Suite à l’authentification, le WAP connecte l’utilisateur en utilisant le Claims ADFS précédemment obtenu. C’est l’évènement 12027 qui va nous intéresser.

clip_image023

 

Pour finir avec l’évènement 14008 qui nous indique que le Web Application Proxy a réussi à présenter le ticket Kerberos obtenu par notre ADFS. On notera que le mode d’authentification auprès du back-end server est bien « Windows Integrated Authentication (WIA) »

clip_image024

 

A ce stade, Web Application Proxy a fini son travail. Si cela échoue à ce niveau, c’est que l’utilisateur connecté n’a pas accès. Il est peut-être pas membre des bons groupes. Si la négociation venait à échouer, c’est que la délégation Kerberos n’est pas correctement configurée, on a alors l’évènement 13022.

clip_image025

Note : Un truc tout bête mais lorsqu’on met en place une nouvelle publication qui repose sur le KDC, on met donc en place de nouveaux SPN sur notre serveur WAP. Pour que ceux-ci soient pris en compte, encore faut-il redémarrer le serveur WAP. Merci pour ce rappel Maxime RASTELLO.

Si cela ne fonctionne toujours pas, il faut se poser les bonnes questions. Pour cela, le document publié par l’équipe produit est excellent. Tout est dit dans l’illustration ci-dessous : clip_image026

 

Conclusion

Si par malheur, notre mise en place ne fonctionne pas avec SharePoint 2013 ou tout autre application, commencez par séparer les problèmes. D’un côté assurez-vous que lorsque vous vous connectez, il y a bien un jeton Kerberos d’obtenu et de présenté, de l’autre utilisez une ressource plus simple que SharePoint 2013 pour tester. Pour cela, je conseille de mettre en œuvre un simple site web IIS tel que documenté ici : Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy.

 

Bonus Track

Pour le bonus track, j’ai retenu Windows XP. Par défaut, cela ne fonctionne pas pour ces clients, au motif que seuls les clients supportant SNI sont supportés. Si on observe notre publication WAP au travers d’un outil tel que celui de Qualys SSL Labs. On observe le résultat illustré ci-dessous :

clip_image027

 

Par défaut, c’est donc pas possible. La solution, c’est le mode FallBack de SNI que l’équipe en charge de Web Application Proxy a documenté dans ce billet : How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

GPO tip for lazy admins

During my DirectAccess deployments projects, I have to deal with security group membership for computer accounts. Restarting my DirectAccess clients to update the computer Kerberos ticket takes times. Waiting for the tickets to be renewed takes too much time. There might have an alternate solution. Let’s have a look at the great tools of Mark RUSSINOVICH available at this location.

 

Let start with the initial state of my DirectAccess computer. The GPRESULT.EXE command result indicates that the computer is not already member of the “Lazy Admin group”. I don’t want to restart the computer!

0

 

First SysInternalTool : LOGONSESSIONS.EXE that provides information about sessions opened on the DirectAccess client computer. We can see that the computer account have a Kerberos Ticket. The local System account SID is : S-1-1-18 :

1

 

We now have the LogonID of the Computer account. Let’s have some additional information about this session with the KLIST.EXE command line.

2

 

We have Kerberos tickets negotiated by the computer account. Let’s purge these tickets.

3

 

An force the computer to obtain new Kerberos tickets with a simple GPUPDATE.EXE /FORCE command.

4

 

Does my computer negotiate new Kerberos tickets? Yes! Let’s look at  the GPRESULT.EXE results. And surprise, the computer is now member of a new security group and apply a new GPO.

5

 

It is simple by design. SysInternal Tools are best friends of the lazy admins.

 

BenoitS – Simple and Secure by design but Business compliant.

Processus de localisation d’un contrôleur de domaine (Suite)

Comme si ce n’était pas assez complet, Arnaud Jumelet vient de publier le détail du processus de localisation des contrôleurs de domaine. La on rentre dans le détail de la détermination du site Active Directory et ses subtilités (forcer un site Active Directory par exemple).

 

Bref, à conserver dans un coin.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

La synchronisation horaire en environnement virtuel

Dès lors qu’un système d’exploitation est virtualisé (Citrix, Vmware, Microsoft, …), le socle de virtualisation se propose de fournir un certain nombre de services additionnels sous forme de “Integration services” ou tout autre nom. L’un de ces services trait à la synchronisation horaire.

 

D’un certain point de vue, l’approche est intéressante. Cependant le bon fonctionnement de bon nombre de protocoles sont liés à une stricte synchronisation horaire. Kerberos est un exemple assez connu dans le monde “Microsoft” avec sa tolérance de seulement cinq minutes (configurée par la stratégie de domaine).  Kerberos n’est pas un cas isolé. L’ensemble des processus liés à la réplication Active Directory utilisent l’heure GMT. Dès lors qu’un ou plusieurs systèmes ne sont pas à l’heure ou pire donc l’heure n’est pas stable, on peut s’attendre à bon nombre de problématiques.

 

La toute récente KB976924, fait référence à cette problématique dans le cadre des contrôleurs de domaines hébergés sous Hyper-V. Cependant, cette problématique ne concerne pas seulement Hyper-V. La problématique est la même quelque soit l’Hyperviseur.

 

Personnellement j’étendrait même cette KB aux serveurs membres car eux aussi ont besoin de conserver une synchronisation horaire stable. Qu’arriverait-il à un cluster CCR Exchange 2007 si l’heure n’était pas stable? Ou alors à une PKI avec les listes de révocations.

 

Benoîts – Simple and Secure by Design