locked
TMG 2010 + Enterprise Portal + RS RRS feed

  • Discussion générale

  • Bonjour à tous,

    Est-ce que quelqu'un a déjà expérimenté de publier un Enterprise Portal (un Sharepoint pour l'ERP AX2009) + Reporting Services ?

    Le serveur Sharepoint qui héberge le site web pour AX doit être exposé et accessible sans VPN en https.

    Nous aimerions donc laisser le serveur Sharepoint (qui est forcément inscrit à l'AD) dans le LAN et donc se servir de TMG pour publier le site Sahrepoint AX nommé Enterprise Portal.

    Merci de votre aide.

    lundi 3 janvier 2011 21:10

Toutes les réponses

  • Bonjour, Non je n'ai jamais publier ce type de service, Sharepoint avec SQL RS seulement. Les seules difficultés que j'ai rencontré avec SQL RS, c'est d'utiliser un nom de connexion FQDN SQL RS identique en interne qu'en externe. Il ne s'appuie pas sur des solutions comme SharePoint AAM ou équivalent. As-tu déjà essayé ? as-tu rencontré des difficultés ? Quels sont les particularités de l'ERP que tu nous parles ? C'est un module complémentaire installé sur SharePoint ? Bonne journée, Alex
    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    mercredi 5 janvier 2011 10:18
  • Bonjour Alexandre et merci de votre réponse,

    J'ai justement lu plusieurs de vos billets et en particulier un sur une problématique d'authentifications multiples quand on veut ouvrir un fichier EXCEL dans une bibliothèque Sharepoint et ma problématique ressemble à ce billet en fait.

    L'ERP Dynamics AX2009 a donc un client lourd mais aussi une partie Web qui s'appuie, depuis AX2009, sur un socle Sharepoint (MOSS ou WSS au choix). Ensuite dans AX, on "déploie" en fait un site Sharepoint que AX appelle "Enterprise Portal" (EP pour les intîmes :-))

    Cette EP contient des onglets : Ventes, Finances, Achats, Services Employés, etc...Comme le client lourd mais en techno ASP, Webpart, usercontrols ,etc....

    Et sur chaque page de garde de chaque onglet, MS a eu la bonne idée d'y mettre des Tableaux de bords en fonction du profil de la personne et c'est Tabeau de bords sont fait avec .....SSRS et SSAS ! MAIS dans des IFRAME : donc un portail qui contient un autre site (RS) mais PAS INTEGRE au Portail : donc 2 sites : 2 ourvertures de port, et IE, quand il est ouvert sur un poste qui n'est pas sur l'AD --> Multiple authentifications !

    Donc on a un Sharepoint qui contient un site AX (EP) qui appelle un autre site (RS) pour les rapports : car MS ne supporte pas que l'on intégre RS dans l'EP : que du bonheur

    Et c'est en lisant ton billet sur TMG que j'ai demandé à MS ce qu'ils en pensaient....@Suivre...

    mercredi 5 janvier 2011 11:42
  • Hello,

    Merci pour la lecture de mon blog :) Donc tu as du bien saisir la notion concernant la persistance des cookies pour les clients issues d'un autre contexte qu'IE (comme word, ...) afin d'assurer le SSO.

    Il semblerai que ce soit très lié à SRS donc; Je sais par expérience que dès que tu as du SRS, il te faut le même nom de domaine FQDN en interne qu'en externe.

    Par exemple, si tu tentes de te rendre à ton SharePoint local avec l'url sharepoint.domaine.fr et que cela fonctionne, alors il te faut la même url en externe. Si cependant, tu as plutôt une url interne du type : sharepoint.domaine.intra alors fais une modification dans ton poste pour créer un fichier HOST afin de résoudre sharepoint.domaine.fr avec l'@ip interne de ton serveur SharePoint. Tu verras que SRS ne fonctionnera plus. Il faudra donc modifier les liens de connexions avec ce nouveau FQDN. Quand cela fonctionnera uniquement avec sharepoint.domaine.fr, alors en externe cela pourra fonctionner.

    Attention, cela te demande de basculer tout le monde en interne vers cette nouvelle url (modification DNS générale). L'ayant vécu à deux reprises dans des clients moyens comptes, ben cela n'a pas été de la tarte pour la migration ...

    Après, je ne sais pas si il y a encore qqchose vraiment spécifique à EP; je pars du principe que tout semble lié à SRS, c'est ma vision et n'engage que moi.


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    jeudi 6 janvier 2011 16:12
  • Hello aussi,

    De rien pour le blog, c'est un plaisir. "La persistance des cookies..." c'est ce qu'appelle MS "credential caching" ?

    J'aimerais en faite bien résoudre la problématique en installant un TMG en reverse proxy et ainsi publier le site Sharepoint AX appelé Enterprise Portal qui contient le fameux RS

    Pour l'instant, avec MS, nous avons un Sharepoint en accès public en DMZ, et je comprends bien botre retour d'expérience sur la problématique de nommage avec le RS => idem dans le monde AX => même ,om interne/externe, on a dû modifier le host comme vous dites, modifier URLROOT dans rsreportserver.config et ReportServerUrl dans RSWebApplication.config...

    Et bien sûr, on mis un certificat SSL à ce satané RS + modif dns local, etc....

    Par ailleurs, cela pose des problèmes au niveau de la machine Sharepoint qui est inscrite au DOMAINE et DMZ :-(

    + Toute la plateforme en negociate pour passer en Kerberos...

     

    Donc j'aimerais vraiment solutionner pas mal de pb avec TMG2010

     

     

    jeudi 6 janvier 2011 18:12
  • Concernant SharePoint, y'aura pas de souci car SharePoint a une gestion de noms alternatifs (AAM) qui permet d'indiquer les urls publiques, extranet, etc...

    Alors en le publiant, c'est quoi le problème. On va commencer par là :)


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    jeudi 6 janvier 2011 22:11
  • Hello Alexandre,

    Oui on est d'accord Sharepoint n'est pas la cause mais bien accès à d'autres sites web à partir du site sharepoint (comme RS et on a aussi un site spécifique pour nos besoins en plus).

    Quand on déploie AX sur Sharepoint, il créé le site http://NOM_MACHINE_SP/sites/dynamicsax : donc le nom court bien local et non FQDN et encore moins nom dns externe, et comme tu le sais, les cname, pas bon...

    Donc le partenaire a créé une étendu du site pour crééer un 2ième site mais en nom "externe" : soit

    Sans d'autres sites que le site Sharepoint principal : pas de pb je pense, mais après quand on accède au RS et à l'autre site web spéc (simple site web dynamique en asp...) : tu vois ça devient galère

    Surtout quand on a mis la machine Sharepoint en DMZ, donc entouré de firewall...On est loin des bestpractice MS qui dit d'installer un 2ième AD en "External" dans la DMZ (pour faire court) : je pourrais mettre le lien de cette superbe doc MS ici..

    vendredi 7 janvier 2011 06:39
  • Hello,

    On est d'accord sur le fonctionnement du produit à présent. Cepdant, la question que je me pose, as-tu tenté de le publier à travers un serveur TMG ?

    L'idée est de connaître quelles sont les fonctionalités qui fonctionneront et celles qui ne fonctionneront pas. Ensuite, on pourra être plus à même de déterminer ce qu'il faut étudier pour rendre le tout fonctionnel, étant donné que je ne trouve pas d'articles sur la publication MOSS+AX+SRS avec TMG et que visiblement personne intervient sur ce thread.

    Maintenant, tu peux aussi voir les choses différement. Avec une solution de publication comme Microsoft Forefront UAG, plus de possibilités te seront ouvertes afin de rendre accessible l'application. De plus l'application sera mieux protégée.

    Bonne journée,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    vendredi 7 janvier 2011 13:41
  • Re-Hello Alexandre,

    Non pour l'instant, nous n'avons pas implémenté TMG, grande découverte, j'ai juste essayé sur une maquette : AAM du Sharepoint + 1 port d'écoute web + wizard Sharepoint du TMG, mais on est comme Christophe Colomb qui croyait voir des indiens pour l'instant... :-[ @suivre car j'y crois.

    Je vous donne le lien où l'on trouve la doc de MS pour "exposer" (et non publier) un site Enterprise Portal d'AX :

    Vous avez Page 13 un schéma d principe : "Overview of a traditional perimeter network"

    http://download.microsoft.com/download/8/3/1/8312ab9d-98a7-4d96-b8f5-d78a087b5b1b/Install%20and%20Configure%20a%20Microsoft%20Dynamics%20AX%20Enterprise%20Portal%20server.doc

    L'EP web server est bien un Sharepoint où l'on déploie l'EP pour AX.

    Par contre je suis comme vous : je ne trouve rien pour "publier un EP+RS via TMG"

    J'ai cru comprendre aussi que UAG était encore plus puissant, saudd que tu ne peux pas faire de la redirection facilement en /* ....?

    On aurait besoin de faire un test d'un reverse proxy (MS) simplement sans fonctionnalités : VPN (on a déjà un ISA, sans Firewalls, sans filtrage peut être) : du simple MAIS qui fait du SSO => Je me logue à un portail Sharepoint 1 fois MÊME si mon PC n'est pas sur le Domaine (workgroup)

    Bonne apm,

    Hervé

     

    vendredi 7 janvier 2011 14:32
  • J'ai cru comprendre aussi que UAG était encore plus puissant, saudd que tu ne peux pas faire de la redirection facilement en /* ....?

    Hello,

    Alors avec UAG, j'ai envie de dire : Jusqu'à présent je n'ai rien trouvé de bloquant. Le produit est tellement souple de par la flexibilité de code personnalisés, qu'à ce jour il reste à mon avis le produit le plus à même à répondre à tous les enjeux techniques d'une entreprise; et ceci aussi bien pour des scénarios de mobilité que simplement interne. Donc je rebondis directement sur la dernière partie de ton message, ou il faut que tu saches qu'UAG dispose de grosses fonctionnalités de Web-SSO.

    Bon courage pour tes tests,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    samedi 8 janvier 2011 13:24
  • Merci Alexandre,

    Merci pour ta précision sur UAG, j'ai sûrement mal interprété un de tes billets qui m'a fait pensé que TMG suffirait dans mon cas :

    http://www.alexgiraud.net/blog/Lists/Categories/Category.aspx?Name=Microsoft%20TMG%202010

    [...]

    "Microsoft propose aujourd'hui deux solutions de Reverse Proxy : Microsoft Forefront TMG et UAG. Nous n'allons pas rentrer dans le détail des différences car ici je vais présenter la publication avec TMG et non avec UAG, j'y reviendrais dans quelques temps avec un autre billet consacré à la publication SharePoint avec UAG. Ce qu'on peut déjà retenir, c'est qu'avec UAG on pourra apporter beaucoup plus de sécurités grâce à la conformité du client pour permettre des stratégies d'accès, de téléchargements, d'envois de données et de zones restreintes. Ce sera donc des outils supplémentaires qui permettra à une entreprise d'étendre la publication SharePoint à des partenaires, ou autres tout en ayant un niveau de sécurité très stricte. Pour finir, le moteur de filtrage UAG n'autorise pas le site SharePoint avec un /*, mais fonctionne uniquement par des règles d'autorisations sur chaque url connue (/_layouts/etc…. ) et n'utilise jamais de /*. Et pour chacun de ces règles, le « verbage » HTTP est vérifié (contenu POST, GET, …). C'est ainsi grâce à UAG que l'on obtiendra le meilleur niveau de sécurité."

    Ce que j'avais comprise c'est que UAG amène plus de sécurité mais plus compliqué à configurer pour débuter et implémenter facilement et rapidement

    Je vais donc télécharger UAG aussi, on ne sait jamais :-)

    Pour l'instant, j'ai un TMG2010 sp1 U1 :-)

    Merci pour de me souhaiter courage, de toute façon, on ne le fera pas tout seul.

    Hervé

    samedi 8 janvier 2011 17:35
  • Bonjour à tous,

    Juste un petit update sur cette demande,

    MSFT est venu pour voir comment répondre à notre demande en implémentant TMG sur une plateforme de "test".

    Ce n'est pas encore pour la plateforme de prod mais les tests sont tout à fait satisfaisants : sans VPN, nous pouvons nous connecter à l'Enterprise Portal (partie web de AX2009) en navigatant dans les rapports (Reporting Services), même les doc dans la bibliothèque sharepoint, et même un autre site spécifique en rentrant UNE SEULE FOIS son identitié.

    Il reste un peu de réglage, d'adaptation mais on peut dores et déjà se servir de cette plateforme pour former nos collaborateurs au produit AX côté web, sans VPN, sans être dans le LAN, et sans être forcément sur l'AD principal qui sert aux plateformes AX.

    Donc, on tient la bonne démarche avec TMG 2010 :-)

    samedi 12 février 2011 16:25
  • Bonjour à tous,

    En complément de tout ce qui a été dit, il est intéressant de reposer ici TMG et UAG dans leurs rôles respectifs. Bien que TMG soit très performant sur la partie firewalling (NIS par exemple) et sur la sécurité lié au surf sur l'internet (et donc aux risques : malware, filtrage d'URL.. le tout en temps réel grâce au "cloud"), le produit a toujours gardé ses services de publication WEB (reverse proxy + cache)

    UAG est quant à lui la passerelle d'accès distant de microsoft, et contient toutes les briques techniques pour publier et sécurier les accès (au sens large) et en particulier les applications WEB, ou hybrides (WEB + TCP). Avec UAG, vous aurez alors un certain nombre de services supplémentaires :

     Services utilisateurs : authentification forte, Web SSO, Portail, ..

     Sécurité : firewall applicatif (appelé URL Set), optimizer (fonctions avancées de réécriture de flux), analyse du poste et conformité, ..

    La question à se poser est donc les services que vous souhaitez avoir, au dela du fait simplement de publier a l'internet l'application. En effet, dès qu'une application contient des données sensibles, alors il faut proposer une architecture qui permet de sécuriser l'accès.. et par sécuriser, il y a beaucoup d'aspects comme l'authentification, la tracabilité, la conformité, la perte d'information.

    En fonction du contexte, nous avons donc une passerelle technique (TMG), et une passerelle applicative (UAG) capable d'aller loin et faire face aux enjeux de protection de l'application et des données.

    J'ai fait une session sur la publication et la protection de Sharepoint aux Tech days il y a quelques jours, le contenu est facilement transposable pour d'autres applications "business".. ca devrait être en ligne très bientôt (PPT et vidéo).

    Salutations.

    Frédéric

     


    Frederic (MSFT)
    mardi 15 février 2011 02:30
  • Bonsoir Frédéric,

    Je commence par la fin : je suis allé voir le site des td11 samedi, mais un peu trop bien sûr...J'ai vu le programme avec le marjeting sublîme du Cloud (pour info : on est partenaire et vendons du cloud :))...

    J'attends les premières prez du fameux techdays...

    Vous n'êtes pas curieux de savoir qui est venu de chez MSFT pour voir ce que l'on pouvait faire avec TMG ? Je vous mets sur la voix...Il fait partie de MCS ;-)

    Nous sommes venus à TMG car nous sommes sur un projet Dynamics AX en pleine refonte de notre ERP. Et pour des soucis de multiples authentificatios sur la partie Web de AX appelé "EP", nous cherchions une solution et non un produit.

    Pour l'instant TMG répond "fonctionnellement" à la demande. Maintenant, vous pensez bien que nous n'avons pas de recul sur la solution mise en place, mais nous n'avons pas le choix ; c'est un choix qui dépasse la techno choisie car nous devons démarrer en PROD bientôt.

    Votre session td11 sur la publication et protection de sharepoint nous intéresse, et vais attendre la video :-)

     

    Merci Frédéric,

     

    mardi 15 février 2011 19:18
  • Salut !

    Je pense que le conseil est bon.. a partir du moment ou il répond au cahier des charges ;-) encore une fois, TMG est une très bonne plateforme de publication "technique" d'applications WEB.  Si les services apportés correspondent aux attentes, alors aucun soucis.

    si vous vous voulez allez plus loin et surtout "sécuriser la couche applicative", alors UAG est la solution. Moi mon "gros conseil", est surtout de bien comprendre la différence entre les deux produits "DANS VOTRE SCENARIO" pour ensuite faire le choix qui correspond au besoin.

    En effet, alors que TMG est vendu par serveur (1 serveur peux publier X personnes) UAG (car il fournit de nombreux autres services) nécessite une CAL utilisateur. Je peux citer aussi une vision inverse d'analyse sur le "cout", par exemple si vous avez besoin de faire de l'auth forte. Par défaut "cartes à puces, et tokens" sont supportés sur TMG mais on un coût elevé (mais très fort). UAG étant plus souple (versus TMG qui se développe en C++/SDK) sur cette partie authentification, de nombreux autres solutions sont disponibles (SMS OTP, Grilles, ...) qui en termes de coût peuvent aller jusqu'e "dévisé par 10". Ce qui a la fin peut faire un calcul du type :

    TMG + Carte à puce/OTP : coût de l'OTP par personne (disons 100)

    UAG + CAL UAG + Solution d'auth forte X Y ou Z (moins couteuse) :cout de la cal + auth forte (disons 10)

    Dans ce scénario le coût par user à la fin est inférieur sur UAG, et vous avez tous les services de sécurité.

    Encore une fois, TMG et UAG sont de très bonnes options.. mon gros conseil est de connaitre la différence, le périmètre couvert par chaque application.. en fonction des risques exposés par les votres.

    A dispo si besoin (si besoin de la pres des TD en avance, me pousser un mail ;-)

    Salutations.


    Frederic (MSFT)
    mardi 15 février 2011 23:37
  • Bonjour Frédéric,

    Merci pour vos explications sur les 2 produits TMG / UAG ; je comprends bien votre avis qu'il faut mettre sur papier les différences, avantages, inconvénients entre les 2, car, en fonction des besoins ; j'avais même préparé une machine avec UAG d'installé quand le consultant (que vous connaissez :-)) est venu sur site. Et nous avons trouvé pour l'instant notre bonheur avec TMG, pour info.

    J'avais néanmois vu la video du techdays2010 sur le produit UAG et c'est le rêve de tout IT :-)

    Personnellement, je ne ferme pas la porte à UAG, mais en veille, le temps de démarrer le projet de l'ERP, qui est stratégique pour l'entreprise.

    Merci Frédéric pour votre proposition sur les prez, mais je ne vais pas vous embêter, je vais attendre la prez (SEC2302) quand elle sera dispo sur le site :-)

     

    Merci encore, et bonjour à Jérôme :-)

     

    mercredi 16 février 2011 14:06