none
Problème d'accès à mon site web en architecutre 3 tiers RRS feed

  • Question

  • Bonjour,

    Je suis en architecture 3 tiers et rencontre des problèmes d'accès à mon site web ( VS2008 II7.0 sql server 2008 ).

    J'ai crée un groupe d'utilisateurs gr1 avec 2 utilisateurs du domaine ( user1 et user2 ). Au niveau de IIS,

    Si j' active l'identification windows et l'emprunt d'identité, j'ai l'erreur suivante : "Echec de l'ouverture de session de l'utilisateur 'AUTORITE NT\ANONYMOUS LOGON'.

    Si je désactive l'emprunt d'identité, j'ai l'erreur suivante "Echec de l'ouverture de session utilisateur 'Domaine\NomServeur$'".

    Si dans mon groupe gr1, je rajoute comme utilisateur Domaine\NomServeur$ cela fonctionne mais pour tous les utilisateurs !! Donc, en résumé, ou ça fonctionne pour personne ou pour tout le monde, alors que le but est que le site soit accessible à user1 et user2.

    Auriez-vous des suggestions à me faire ? Merci
    mercredi 8 décembre 2010 09:03

Réponses

  • Bon c'est déjà un gros pas de fait!

    Pour le message "l'utilisation d'une section inscrite comme allowDefinition="MachineToApplication" au delà du niveau d'application est une erreur" ceci est du au fait que vous utilisez un noeud dans un web.config "fils" qui ne peut être présent que dans un niveau plus haut.

    Le site map a priori doit être au minimum dans un web.config de niveau applicatif. En effet d'après msdn (Site Map) les niveaux autorisés sont :  Machine.config, Root-level Web.config, Application-level Web.config

    L'utilisation du noeud authorisation est lui accepté dans les repertoires fils : Machine.config, Root-level Web.config, Application-level Web.config, Virtual or physical directory–level Web.config

    Cordialement

    mardi 14 décembre 2010 17:35
    Modérateur

Toutes les réponses

  • Bonsoir,

    Comment votre application se connecte à la base de données : authentification windows, sql server ?

    Pour donner des droits d'accès à un groupe windows à une application asp.net voir le noeud authorization ( allow role ) dans le web.config

    Cordialement

    mercredi 8 décembre 2010 17:06
    Modérateur
  • Bonjour,

             On accède à l'application web par authentification windows et le but est que cette authentification "se propage" pour accéder à la base sql server ( située sur un autre serveur, mais dans le même domaine ).

    Cordialement

     

     

    jeudi 9 décembre 2010 09:31
  • Bonjour,

    il convient de séparer 2 aspects

    - 1 - l'authentification windows pour gérer l'accès à vos utilisateurs à l'application asp.net

    - 2 -  l'authentification windows pour gérer l'accès à votre base

    Pour le point 1 :

    voir le nooeud authorization du web.config

    Il suffit de donner les droits au gr1 qui contiendra vos utilisateurs

     

    Pour le point 2 :

    en utilisant l'emprunt d'identité, chacun de vos utilisateurs devra donc posséder un login sur votre base sql serveur.

    Il est en général plus simple qu'un seul utilisateur ( en général un compte technique dédié ) accède à la base.

    Pour cela ce compte doit remplacer le compte par défaut d'un pool d'application IIS.

    Ce compte est utilisé pour faire tourner le pool d'application et c'est donc lui qui effectue les connexions à la base de données

    Ce compte :

    - doit posséder les accès à la base

    - être utilisé pour faire tourner le pool d'application IIS ( il doit appartenir au groupe IIS_IUSRS avec IIS 7 ). Le pool d'application ainsi défini doit être affecté à votre application

    Cordialement

     

     

     

     

    jeudi 9 décembre 2010 10:23
    Modérateur
  • Bonjour,

    Avez-vous activé l'emprunt d'identité au niveau d'ASP .NET ? (http://msdn.microsoft.com/en-us/library/xh507fc5.aspx)

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte .NET/Consultant/Formateur chez Winwise
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5
    jeudi 9 décembre 2010 10:26
    Modérateur
  • Le problème du compte technique dédié c'est au niveau sécurité. Il suffit qu'un seul utilisateur ait connaissance du mot de passe de ce compte pour qu'il puisse accéder à la base.

     

    Cordialement,

    jeudi 9 décembre 2010 10:36
  • Bonjour,

       Oui, oui, je décris dans mon post initial, les différents résultats que j'ai obtenus en activant ou non l'emprunt d'identité.

     

    Cordialement,

     

    jeudi 9 décembre 2010 10:37
  • Le problème du compte technique dédié c'est au niveau sécurité. Il suffit qu'un seul utilisateur ait connaissance du mot de passe de ce compte pour qu'il puisse accéder à la base.

     

    Ce compte sera l'unique compte à avoir accès à la base. Ce compte est un compte windows dont le mot de passe ne doit être connu que d'un administrateur.

    Un utilisateur n'a pas à connaitre ce compte  ( tout comme le compte d'admin du domaine par exemeple )

    Cette solution est plus sécurisé que via l'emprunt d'identité car avec l'emprunt d'identité  tous vos utilisateurs doivent posséder l'accès à la base avec leur compte windows utilisé pour se loguer au domaine.

    Cordialement

    jeudi 9 décembre 2010 10:49
    Modérateur
  • Bonjour,

    Cette solution est plus sécurisé que via l'emprunt d'identité car avec l'emprunt d'identité  tous vos utilisateurs doivent posséder l'accès à la base avec leur compte windows utilisé pour se loguer au domaine.
    Pour moi c'est beaucoup moins sécurisé... Car vous ne pouvez appliquer le principes du moindre privilège.

    En effet, on suppose qu'un utilisateur U1 doit seulement lire dans la base de données et U2 lire et écrire. Le fait d'autoriser le compte de service S de l'application Web à accéder en lecture et écriture au niveau de la base de données, implique que U1 et U2 peuvent lire et écrire dans la base de données.

    Il faut donc préférer de définir les droits spécifique à U1 et à U2 au niveau de la base de données et non au niveau du compte de service S.

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte .NET/Consultant/Formateur chez Winwise
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5
    jeudi 9 décembre 2010 13:00
    Modérateur
  • Pour ma part,

    Je préfère que les droits de U1 et U2 soient gérées via l'application. Dans tous les cas il faudra donner les droits d'écriture à un compte. Je préfère donc que ce soit un compte de service et non un compte utilisateur.

    Je trouve moins sécurisé de devoir gérer les n utilisateurs au niveau de la base de donnés. Cela nécessite une réelle tache d'administration au niveau de la base de donnée en dehors de tout contexte applicatif.  On se retrouve souvent une avec une base contenant alors des centaines d'utilisateur qui potentielement doivent posséder des droits d'accès sur telle ou telle base.

    Par ailleurs à la gestion de droits sur la base s'ajoute de toute façon une gestion au niveau applicatif, soit parce que les droits à gérer ne sont pas aussi simple que des droits de lecture, écriture mais sont des droits fonctionnels ou tout simplement parce qu'on ne souhaite pas afficher le bouton modifier à un utilisateur qui n'en a de toute façon pas le droit

    Par ailleurs gérer les droits directement sur la base fait que les utilisateurs peuvent accéder à la base de données en dehors du contexte applicatif ce qui me semble également plus dangereux ( il est alors potentiellement facile à un utilisateur d'accéder à la base via Excel par exemple )

    Cordialement

     

     

     

     

     

    jeudi 9 décembre 2010 14:18
    Modérateur
  • Merci pour cette discussion fort intéressante. Cependant, j'ai toujours un autre soucis de taille, même si je crée un compte technique dédié à l'accès de la BDD. Je n'arrive pas à "filtrer" les utilisateurs pouvant accèder au site ou non. Comme je l'ai écrit dans le post initial, si j'active l'emprunt d'identité, j'ai une erreur, si je le désactive j'ai une autre erreur, et si je rajoute un utilisateur Domaine/NomDuServeur$ dans le groupe, alors tous les utilisateurs du domaine peuvent accèder au site. Donc, je me retrouve dans une situation où soit personne accède soit tout le monde, mais en aucun cas, seulement U1 et U2

    En fouinant sur le net, il semblerait que je sois en situation de "double hope" et que la seule solution passe par l'authentification Kerberos, mais tout ça reste fort nébuleux pour moi !!!!

    Cordialement,

     

    jeudi 9 décembre 2010 14:58
  • Si vous remplacer comme indiqué le compte du pool d'application et que vous ne vous connecter pas avec l'emprunt d'identité vous ne serez plus  dans une situation possible de double hops : en effet dans ces cas il n'y aura plus de problème de délégation car ce sera le copte du pool d'application qui se connectera à la base.

    Mettre en place Kerberos et autoriser la délègation est en effet une solution pour ces problèmes de double hops. Néanmoins ceci est une tâche d'administration au niveau de l'active directory qui dépasse la simple mise en place d'une application asp.net.

    Pour avancer sur votre problème il faut que vous choisissiez l'une des 2 solutions

    Cordialement

    vendredi 10 décembre 2010 10:28
    Modérateur
  • Bonjour,

         Je me permets de poser une dernière question ( j'abuse un peu, mais vous maitrisez le sujet !! ). En appliquant la 1ère solution, si j'ai tout compris ( bon, ça, c'est pas sûr ), ça veut dire que tous les utilisateurs du domaine dans lequel sont les serveurs ( web et BDD ) auront accès à l'applicatif ? Si oui, comment n'autoriser que certains utilisateurs du domaine ? J'ai essayé de recréer un groupe qu'avec ces utilisateurs, mais, il n'est pas connu du domaine et .....ça ne fonctionne pas. De plus, pour des contraintes indépendantes de ma volonté, je ne peux pas faire tout et n'importe quoi sur l'administration réseau.

    Auriez-vous une suggestion ? ( Après promis, je ne vous embête plus... ou presque ). Merci.

    Cordialement,

     

    vendredi 10 décembre 2010 14:28
  • Non tous les utilisateur n'auront pas accés. C'est à vous de donner les droits d'accès asp.net via par exemple le noeud authorization du web.config de votre application. Vous pouvez donner les droits à un groupe local au serveur IIS ou du domaine en fonction de ce qui vous arrange.

    Avez vous configurer le pool d'application comme indiqué  ?

    Poster votre web.config également si cela ne fonctionne pas .

    Cordialement

    vendredi 10 décembre 2010 17:28
    Modérateur
  • <system.web>
          <authorisation>
               <allow roles="MonDomaine\Mon Groupe" />
               <deny users="*" />
          </authorisation>
    </system.web>

    Encore et toujours des problèmes, personne ne peut se connecter ( Erreur 401 : accès refusé .... ). Pour rappel, je suis en authentification windows. ( NB : ça fonctionne si j'enlève la section <deny>, ce qui est logique ... mais c'était juste pour vérifier !! ).

    Peut-il y avoir des espaces dans le nom du groupe ? Si oui, y a t'il une syntaxe particulière ?

    Doit-on indique le nom du groupe ou son cn ?

    Que dois-je vérifier ?

    Dois-je vérifier quelque part si les droits de ce groupe ?

    Cordialement,

     

     

     

     

    lundi 13 décembre 2010 16:48
  • Bonjour,

    La syntaxe du noeud authorisation semble correcte.

    La syntaxe pour le groupe est correcte. Essayer avec un groupe sans espace mais je ne pense pas que ce soit le problème. Evidemment on suppose que les utilisateurs autorisés à accéder à l'application son bien ajoutés dans ce groupe.

    - dans le web.config avez vous bien <authentication mode="Windows"/> ?

    - sur IIS 7, sur votre application, dans le menu authentification, vérifiez que seule "Authentification Windows" est activée.

    - Pour avoir plus de détail sur l'erreur 401 pouvez vous aller dans le répertoire C:\inetpub\logs\LogFiles ( si vous avez gardé le répertoire par défaut ) et nous précisez ce qui est loguer pour vos appels. (erreur 401.x)

    Cordialement

     

     

    mardi 14 décembre 2010 10:01
    Modérateur
  • Bonjour,

             Je progresse ( doucement, mais je progresse ... ). Le problème venait d'un conflit entre la gestion des droits windows et la gestion des mêmes droits via aspNetXmlSiteProvider . Donc maintenant, l'accès au site avec authentification windows et contrôle par rapport à un groupe du domaine fonctionne.

    Maintenant, ce que je souhaiterais, c'est qu'au niveau du web.config de la racine, je contrôle l'accès ou non à l'applicatif (ça, ça fonctionne ) , puis que pour les niveaux en dessous, je puisse gérer les rôles et utilisateurs via aspNetXmlSiteProvider et là, j'ai l'erreur  :" l'utilisation d'une section inscrite comme allowDefinition="MachineToApplication" au delà du niveau d'application est une erreur".

    Voici l'arborescence ( en gras les répertoires ) :

    Root

    -- web.config                                      ( contrôle de l'autorisation ou non d'accèder au site )

    -- default.asx

    -- MasterPage

    -- Admin ( rép. avec les applis réservés aux administrateurs )

    ---------- web.config                            (  avec <siteMap defaultProvider ="AspNetxmlsiteMapProvider enabled="true">

                                                                                    <roleManager ="AspNetxmlsiteMapProvider enabled="true">  )

    ---------- Appli1

    --------------------- Appli1.aspx

    --------------------- Appli2.aspx

    --------------------- Web.config               ( avec   <system.web>
                                                                                 <authorisation>
                                                                                           <allow roles="MonDomaine\Mon Groupe" />
                                                                                           <deny users="*" />
                                                                                  </authorisation>
                                                                           </system.web> )

    J'ai commencé à regarder sur le web, la notion de hiérarchie et d'héritage ( dommage, ça me semblait pas mal ce que j'avais fait !! ), mais je vais creuser un peu plus !

    Cordialement,

    mardi 14 décembre 2010 16:49
  • Bon c'est déjà un gros pas de fait!

    Pour le message "l'utilisation d'une section inscrite comme allowDefinition="MachineToApplication" au delà du niveau d'application est une erreur" ceci est du au fait que vous utilisez un noeud dans un web.config "fils" qui ne peut être présent que dans un niveau plus haut.

    Le site map a priori doit être au minimum dans un web.config de niveau applicatif. En effet d'après msdn (Site Map) les niveaux autorisés sont :  Machine.config, Root-level Web.config, Application-level Web.config

    L'utilisation du noeud authorisation est lui accepté dans les repertoires fils : Machine.config, Root-level Web.config, Application-level Web.config, Virtual or physical directory–level Web.config

    Cordialement

    mardi 14 décembre 2010 17:35
    Modérateur
  • Finalement, je n'ai pas réussi à mettre en application ce dont je parlais dans mon dernier post et ai géré dans l'application les accès aux différents éléments du menu. En tout cas, merci pour réponses éclairées et qui m'ont été fort utiles pour avancer !!

    Cordialement,

    jeudi 16 décembre 2010 08:45