L’authentification Claims à travers la plate-forme Microsoft BI

Un collègue m’a transmis un article qui résume bien les capacités de la plate-forme Microsoft BI vis-à-vis l’authentification Claims.

En gros, ni Analysis Services (SSAS), ni SQL Server ne supportent l’authentification Claims. Ils ont besoin d’une identité Windows pour fonctionner. Extrait de l’article:

No SQL Server service, including Windows Azure SQL Database, is Claims-aware. If you are building a custom BI solution that includes SQL Server features, you will need a Windows user identity (or a SQL Server database user identity) to authenticate to the backend server.

Pour ce qui est de Reporting Services (SSRS), si le Claim a été créé via une authentification Windows, il sera possible de le convertir en jeton Window via le service Claims To Windows Token Service (C2WTS). C’est d’ailleurs ainsi que la délégation Kerberos fonctionne avec SSRS 2012.

Autrement, l’exécution du rapport se fera via le Trusted Account et vous devrez spécifier un utilisateur à utiliser pour vous connecter à vos bases de données:

Requirements include configuring the report server to use Trusted Accounts. 

(…)

Once you deploy the report to SharePoint, you must modify data source connection information to use stored credentials (a windows user identity or database credentials).

Je vous suggère fortement de lire l’article:

Using Claims Authentication across the Microsoft BI Stack
http://social.technet.microsoft.com/wiki/contents/articles/15274.using-claims-authentication-across-the-microsoft-bi-stack.aspx

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

Kerberos avec Windows Server 2008 R2, SharePoint 2010 et SSRS R2 sur la même machine + Host Header : La recette

La topologie d’un déploiement SharePoint avec Reporting Services n’est jamais la même. Il est possible d’installer Reporting Services sur le même serveur que SharePoint, de le placer sur un serveur applicatif séparé ou de le mettre à même le serveur de données (SQL et SSAS).

De plus la version de Windows a un impact sur la version d’IIS, SharePoint est soit WSS 3.0, WSS 4.0, MOSS 2007 ou MOSS 2010 et il y a SSRS R1 et SSRS R2 …

C’est pourquoi il y a beaucoup d’information sur Internet (voir références) mais très peu qui donne la recette exacte pour un déploiement donné. Mon article vise à lister les grandes lignes de mon déploiement ce qui pourrait vous aider dans un déploiement similaire.

Dans mon cas, le serveur de données (SQL / SSAS) était séparé du serveur SharePoint 2010 d’où la nécessité d’utiliser Kerberos (double hop). Afin de ne pas avoir à ajouter le serveur de données à la ferme (ex. pour qu’il serve à d’autres SharePoint), on a choisi d’installer une instance de Reporting Services à même le serveur SharePoint 2010.

On se retrouve avec la situation suivante: le Report Server Web Service et SharePoint utilisent le même “service class”. Comme il n’est pas possible d’enregistrer le même SPN (ex. HTTP/server.domain) sur deux comptes de services AD différents (un pour le AppPool de SharePoint et l’autre pour le service de Reporting Services) il faut donc utiliser le même compte de service pour les deux. Lire cet extrait de technet:

HTTP is the service class. The Report Server Web service runs in HTTP.SYS. A by-product of creating an SPN for HTTP is that all Web applications on the same computer that run in HTTP.SYS (including applications hosted in IIS) will be granted tickets based on the domain user account. If those services run under a different account, the authentication requests will fail. To avoid this problem, be sure to configure all HTTP applications to run under the same account, or consider creating host headers for each application and then creating separate SPNs for each host header. When you configure host headers, DNS changes are required regardless of the Reporting Services configuration.

Si vous avez plusieurs Application Pool dans SharePoint (ex. Project Server et SharePoint côte à côte), utilisez le même compte de service.

Voici la liste des choses que j’ai eu à faire:

  1. Assigner le même compte de service à tous les AppPool de SharePoint ainsi que pour SSRS.
  2. Mettre <RSWindowsNegotiate /> pour <AuthenticationTypes> dans C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config
  3. Créer une adresse pour le Report Server en utilisant le nom de la machine (http://server/ReportServer) même si SharePoint utilise un HOST HEADER (de type A) pour une de ses applictions Web.
    image
  4. Configurer l’intégration SSRS dans SharePoint:
    image
  5. S’assurer que l’application Web SharePoint utilise Kerberos pour toutes les zones:
    image
    image
  6. Vérifier qu’IIS est en Negotiate,NTLM et non juste en NTLM (par défaut c’était correct). cscript adsutil.vbs get w3svc\NTAuthenticationProviders
  7. Comme SharePoint utilise des HOST Header, il faut désactiver le LoopbackCheck (manière explicite ou globale).
  8. Créer les SPNs pour SQL server sur le compte de service utiliseé par SQL Server (ex. cs-sql)MSSQLSvc/NetBIOS:1433
    MSSQLSvc/FQDN:1433
  9. Créer les SPNs pour SSAS sur le compte de service utiliseé par celui-ci (ex. cs-ssas)MSOLAPSvc.3/NetBIOS
    MSOLAPSvc.3/FQDN
  10. Créer les SPNs vers le serveur SharePoint (et dans mon cas vers le HOST HEADER de type A) pour le compte utilisé par SharePoint et SSRS (ex. cs-http)HTTP/NetBIOS
    HTTP/FQDN
    HTTP/HostHeader
    HTTP/HostHeaderFQDN (ex. HTTP/alias.domain.com)
  11. Permettre la délégation pour tous les services (Kerberos) pour le compte utilisé par SharePoint et SSRS.
    image
  12. Permettre la délégation vers SQL Server pour le compte de service utilisé par SSAS (ex. cs-ssas) si le cube doit accéder au comptoir de données (Datamart).
    image
  13. Pour le site IIS du SharePoint qui n’utilise pas de HOST HEADER (ex. SharePoint – 80) j’ai dû activer le Kernel Mode en spécifiant l’utilisation de l’identité du AppPool. Autrement je ne pouvais plus accéder à ce site, il demandait mon identité à l’infini (popup).Il faut Modifier C:\Windows\System32\inetsrv\config\applicationHost.config:

    <location path= »SharePoint – 80″>
    <system.webServer>
    <security>
    <authentication>
    <windowsAuthentication enabled= »true » useKernelMode= »true » useAppPoolCredentials= »true »>
    (…)
    </location>

Constrained Delegation

Normalement j’utilise la mécanique plus stricte pour la délégation Kerberos. Dans ce cas je n’ai pas réussi à la faire fonctionner. D’après ce que j’ai lu, il aurait fallu créer un HOST HEADER de type A différent pour le Report Server. Cela nous aurait permis d’avoir un SPN distinct pour celui-ci. Ainsi nous aurions pu utiliser un compte de service différent pour le Report Server et faire en sorte que le compte de service SharePoint (ex. cs-sharepoint avec HTTP/sharepoint.domain.com) délègue vers le compte de service ssrs (ex. cs-ssrs avec HTTP/reportserver.domain.com) qui aurait délégué vers SQL Server et SSAS.

WireShark

Quand tout fonctionne, voici les requêtes Kerberos que vous devriez voir passer dans WireShark sur le serveur SharePoint (rapport SSRS accédant des données sur un serveur SQL distant):
image
image

1) TGS-REQ – MSSQLSvc/server>.syntell.com:1433
image

2) TGS-REP – MSSQLSvc/server>.syntell.com:1433
image

3) TGS-REQ – krbtgt/SYNTELL.COM
image

4) TGS-REP – krbtgt/SYNTELL.COM
image

Quand je tentais d’utiliser la délégation spécifique, mon TGS-REQ et TGS-REP étaient sur:
Server Name (Enterprise Name): <compte de service sharepoint>@syntell.com ce qui ne fait aucun sens et échouait.

Références

  1. Kerberos delegation and Windows 2008
  2. Kerberos Issues With Reporting Services and SharePoint in a Distributed Environment
  3. Manage Kerberos Authentication Issues in a Reporting Services Environment
  4. Configuring Kerberos Authentication in SharePoint 2010
  5. How to: Register a Service Principal Name (SPN) for a Report Server
  6. Solving the Reporting Services Login issue in the February CTP of SQL Server 2008
  7. Free Software – SharePoint Kerberos Buddy – Detect And Repair Kerberos Issues

Kerberos, ASP.Net et IIS_WPG

Quel est le lien entre Kerberos, ASP.Net et IIS_WPG?

Lorsqu’une application ASP.Net est configurée pour utiliser l’authentification Windows:

<authentication mode= »Windows » />

Et qu’on souhaite personifier l’utilisateur entrant:

<identity impersonate= »true » />

Pour accéder un serveur SQL distant:

<connectionStrings>
<add name= »<ConnectionName> » connectionString= »Data Source=<ServerName>;Initial Catalog=<DataBaseName>;Integrated Security=SSPI » providerName= »System.Data.SqlClient » />

Si vous vous demandez la différence entre Integrated Security=SSPI et Integrated Security=True, vous pouvez aller lire ceci.

En passant, vous ne pouvez pas spécifier un utilisateur de domaine dans la chaîne de connexion (via User Id et Password). C’est uniquement un utilisateur SQL Server qui peut être utilisé. Pour utiliser une identité de domaine, il faut plutôt impersonifier celui-ci:

<identity impersonate= »true » userName= »accountname » password= »password » />

Vous devrez configurer Kerberos pour que l’identité de la personne qui accède à l’application ASP.Net puisse être déléguée jusqu’au serveur SQL.

Idéalement il faut définir un utilisateur de domaine qui sera utilisé pour l’Application Pool de l’application. Il faut ajouter des SPNs (ex. HTTP/webserver.domaine.com) sur cet utilisateur et activer la “Constrained Delegation” vers SQL Server.

image

Malgré tout, il se peut que vous obteniez cette erreur à partir d’un poste client (double hop):

Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.

Et c’est là qu’entre en jeu le groupe local nommé IIS_WPG.

This step is done to allow the application pool identity the ability to impersonate the user on the web server. If you look at the computer’s user right assignments you will see Impersonate a client after authentication and the IIS_WPG group is added there by default.

Référence: Fun with the Kerberos Delegation Web Site (étape 7)

Bref, le compte que vous avez utilisé pour l’Application Pool de votre application ASP.Net doit être ajouté au groupe local IIS_WPG pour être en mesure d’impersonifier un autre utilisateur.

image

Lorsqu’il s’agit d’une application SharePoint, cette étape n’est pas nécessaire car SharePoint ajoute automatiquement l’utilisateur de son Application Pool à ce groupe.

Une alternative à cette solution est de configurer SQL Server pour accepter l’authentification mixe et mettre cette utilisateur directement dans la chaîne de connexion de SQL.

Mais chez Syntell nous préférons utiliser Kerberos et désactiver l’authentification mixe.

Si vous avez des questions sur nos produits et services, n’hésitez pas à nous contacter.

L’affichage d’un rapport échoue à partir du site SharePoint mais fonctionne directement à partir du ReportServer en mode intégré

Cet article peut vous intéresser si vous êtes dans la situation suivante:
  1. Vous utilisez la sécurité intégrée de Windows dans IIS, SharePoint, SSRS et dans l’intégration SSRS/SharePoint.
  2. Reporting Services est configuré en mode intégré et si vous faites afficher un rapport en passant directement par le ReportServer (ex. http://servername/ReportServer), le rapport s’affiche correctement.
  3. Dès que vous tentez de faire afficher le même rapport en passant par le site SharePoint cela échoue avec cette erreur
    (Anglais)
    An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode
    (Français)
    Une erreur inattendue s’est produite au cours de la connexion au serveur de rapports. Vérifiez que le serveur de rapports est disponible et configuré pour le mode SharePoint intégré.

     

    image

     

  4. Vous utilisez des host headers ou des noms DNS pour vos sites SharePoint. C’est utilisé par exemple pour avoir plusieurs applications Web sur le même port (l’URL est différent).
Cette situation est sournoise car il y aura peu d’indices:
  1. Si votre serveur de base de données est sur un autre ordinateur, vous ne verrez pas d’entrées Logon dans l’observateur d’événements –> Security pour le compte de service utilisé par SSRS.
  2. Si vous utiliser Sql Server Profiler pour voir passer les requêtes faites par SSRS sur le serveur de données, vous ne verrez rien d’intéressant (par rapport à un environnement qui marche).
  3. Les journaux de SSRS ne contiendront rien à part l’information de démarrage du service.
Ce sont finalement les journaux d’IIS  (C:\Windows\System32\LogFiles\W3SVC1) qui m’ont aidé à mettre le doigt sur le bobo. Dans une situation normale, lors d’un click sur un rapport SSRS dans SharePoint, on devrait avoir trois entrées POST:
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 – 401 2
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 – 401 1
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 DOMAINE\UTILISATEUR  200 0
Dans l’environnement problématique, on avait un 401.1 (unauthorized) pour la troisième requête (et pas de nom d’utilisateur):
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 – 401 2
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 – 401 1
POST /_vti_bin/ReportServer/ReportService2006.asmx – 80 200 0
Cela ne peut pas fonctionner! C’est pourquoi le processus ne va pas plus loin et que cette erreur générale est lancée.
Heureusement il y a une solution et c’est de désactiver le contrôle de bouclage (Loopback checking):

Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.
10.1 How to Change the DisableLoopbackCheck Registry Key
  1. Open the Registry Editor (regedit).
    Caution: Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
  2. Open the following key: HKLM\System\CurrentControlSet\Control\Lsa.
  3. Create a new DWORD value called DisableLoopbackCheck.
  4. Set the value to 1.
  5. Reboot the server.
    Note: This is required for the change to take effect.
  6. If this resolves the issue, there is a more secure way of making this change. Instead of making the server-wide change that DisableLoopbackCheck implements, you can disable checking for specific host names. For more information about how to do this, see the following article in the Microsoft Knowledge Base: http://support.microsoft.com/kb/896861
Références
  1. Reporting Services SharePoint Integration Troubleshooting
  2. DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Kerberos est bien configuré mais votre SSRS ne marche pas en mode distribué

La manière la plus facile d’intégrer SSRS à SharePoint est de l’installer sur le même serveur que celui utilisé par SharePoint (WSS ou MOSS).

Cependant, il peut être plus logique, plus performant, plus flexible dans l’avenir d’installer SSRS sur un autre serveur. Par exemple, le mode Scale-Out de la version Enterprise permet d’avoir plus d’un serveur Reporting Services pour une ferme SharePoint.

Vous décidez d’aller de l’avant avec une installation distribuée sur deux ordinateurs :

clip_image001[6]
Source : How to: Install and Configure SharePoint Integration on Multiple Servers
http://msdn.microsoft.com/en-us/library/bb677365.aspx

Vous suivez les instructions correctement afin d’installer et configurer les bons logiciels sur les deux machines. Vous créez vos SPNs pour chaque service (SQL Server, SSAS, SSRS et SharePoint). Vous avez configuré la délégation Kerberos standard (unconstrained) ou spécifique (constrained).

Vous avez déployé un projet SSRS de test sur votre site SharePoint et cela fonctionne correctement quand vous naviguez localement (à partir du serveur #1).

Par contre, dès que vous tentez d’exécuter un rapport à partir d’un fureteur distant, vous obtenez l’erreur suivante :

Une erreur inattendue s’est produite au cours de la connexion au serveur de rapports. Vérifiez que le serveur de rapports est disponible et configuré pour le mode SharePoint intégré.

 

An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode.

clip_image003[5]

Vous lisez sur la sécurité SSRS en mode SharePoint  et suivez leur recommandation:
image
Source: Security Overview for Reporting Services in SharePoint Integrated Mode
http://msdn.microsoft.com/en-us/library/bb283324.aspx

Quelques points dignes de mention:

Et là vous ne comprenez pas pourquoi ça ne marche toujours pas … Vous êtes en train de vous demander si votre installation est corrompue et vous vous apprêtez à tout réinstaller. Continuez à lire!

En utilisant l’outil WireShark et en utilisant « kerberos » comme filtre, je pouvais voir passer les AS_REQ, AS_REP, TGS_REQ, TGS_REP qui passent entre les serveurs et le contrôleur de domaine. Dans mon cas, je ne voyais jamais la demande de délégation d’identité du compte de service SharePoint vers le SPN de SSRS.

Normalement, sur votre serveur #1 (SharePoint sans SSRS), vous devriez voir ce trafic Kerberos lors de l’exécution d’un rapport à partir d’un fureteur distant :

clip_image007[6]

Vous voyez que suite à la requête à RSViewerPage.aspx, il y a une demande (TGS-REQ) pour le service http/ms-sql2008r2.syntell.com qui est le site IIS du serveur SSRS. Si cette demande n’a pas lieu c’est que votre serveur SSRS n’est pas configuré pour fonctionner en mode Kerberos. La réponse (TGS-REP) devrait inclure l’identité de l’utilisateur qui a exécuté le rapport à partir d’un fureteur distant.

Un autre indice, dans l’observateur d’événements sur la machine SSRS, dans la section Sécurité, vous voyez une tentative d’authentification pour un utilisateur anonyme (ANONYMOUS LOGON).

clip_image009[5]

En plus de dire à IIS qu’il faut être en mode Negociate,NTLM il faut aussi le dire à ReportServer. C’est ce que j’ai découvert à la dure …

Ce dernier a un fichier de configuration (rsreportserver.config) situé ici :

C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config

Dans ce fichier il y a une section Authentication -> AuthenticationTypes qui doit être mise à RSWindowsNegotiate ou RSWindowsKerberos :

<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate />
</AuthenticationTypes>

La valeur par défaut dépend du compte de service qui a été mis initialement pour le service de SSRS. Normalement on met un utilisateur de domaine dès l’installation alors on se retrouve avec RSWindowsNTLM ce qui désactive l’utilisation de Kerberos avec SSRS …

Voyez par vous-même :

By default, the RSReportServer.config file includes the RSWindowsNegotiate setting if the Report Server service account is either NetworkService or LocalSystem; otherwise, the RSWindowsNTLM setting is used. You can add RSWindowsKerberos if you have applications that only use Kerberos authentication.

http://msdn.microsoft.com/en-us/library/cc281253.aspx

Et enfin ça marche!

clip_image011[6]