Dans mon archi j'ai deux serveurs de prod, serveur#1 et serveur#2, et un serveur, serveur#backup, que j'aimerais utiliser pour faire, entre autre, des backups des deux autres.
 
L'idée c'est de ne pas ralentir serveur#1 et serveur#2 et que ce soit serveur#backup qui fasse tout le boulot de backup directement.
 
Les serveurs ne sont pas sur le domaine (pour raisons de sécurité), donc faut bosser en authentification SQL Server.
 
Est-ce que c'est possible un truc comme ça ?

possible : oui
comment : je sais pas
authentification sql server : ça tombe bien, l'autre est absolument déconseillée

C'est bizarre j'ai entendu exactement le contraire du prof de la formation où je suis allé.
Que l'authentification SQL c'est moins sécure que le Cerberos de l'authentification Windows.
 
Pour le comment, ben j'ai pas trouvé

C'est complètement faux ce qu'il t'as dit.
 
C'est grossomodo le même protocole qui est utilisé pour la communication quel que soit le mode d'authentification, premier point.
 
Second point, l'authentification NT implique que :
-> Tout utilisateur qui est créé sur la machine a potentiellement accès aux bases que tu n'as pas explicitement protégées (paramètre par défaut, notamment de la base système !!!)
-> Cela implique que sur un site web par exemple, tu trimbales dans du code, non crypté, un login/pass valide sur le serveur. Porte d'entrée assurée !!!
-> Le seul moyen d'accéder aux protocoles vraiment sécurisé de Windows, c'est d'intégrer SQL Server dans Active Directory. A ce moment, cela implique que tu as un domaine, et que le log/pass utilisé est valable pour tout le domaine (et pas seulement le serveur).
 
Je te laisse faire ton choix.
Avec un log/pass SQL Server, le maximum que tu peux faire, se limite aux droits spécifiés dans SQL Server, ça ne peut en aucun cas toucher un autre service. La seule chose à protéger si tu crains un hack, c'est qu'il faut faire tourner SQL Server non pas avec le droit admin de la machine ou le droit du user "système", mais d'un compte NT spécifique, qui n'a accès qu'à ce dont à besoin SQL Server (style il faut interdire l'accès aux disques, etc.)
 
Parceque sécuriser un max un service, c'est bien.
Seulement, quand ce dernier est en réseau, et que des services qui ne sont pas forcément bien sécurisés (IIS ou même Apache ne peuvent en aucun cas être assimilés à des sources sûres, puisqu'ils sont ouverts aux attaques) il ne faut plus seulement protéger le service, mais faire en sorte que si ce dernier est attaqué, que l'attaque soit cantonnée au service... Avec un log/pass NT ou du domaine, c'est du suicide.
 
En plus, ça t'oblige à activer sur les deux serveurs des services sensibles, tels que "Client Réseau Microsoft" entre autre, qui est censé être totalement protégé derrière un firewall tellement il est sensible, alors certainement pas installé sur un serveur web !

 
Au contraire, en authentification windows t'as aucun pass sauvegardé nul part... En authentification sql par contre oui, tu es obligé de mettre le pass en clair dans ton code.
Soit on s'est mal compris, soit tu confonds

tu veux faire tourner le process de IIS avec un autre compte qu'un compte local
 
vas-y, donne-moi l'adresse de ton formateur, je vais le butter de ce pas !!!

On a pas causé d'IIS alors là il est innocent mais effectivement je fais peut-être une connerie alors, explique moi.
Mon process IIS tourne sous LocalSystem.
 
Moi je te parlais de SQL Server là... Le monsieur tourne sous LocalSystem aussi, et monsieur le formatteur il me dit que dans l'idéal je devrais attaquer, dans mon code, en authentification Vindoze pour éviter d'avoir à mettre des pass en clair dans mon code.

Ah ouais ok... Et avec son système, tu peux pas passer en architecture n tiers donc, puisque localsystem a un scope qui s'arrête à la machine.
 
Deplus, localsystem est un compte extrêment sensible, puis que c'est le compte utilisé carrément par le noyau. La moindre tentative de hack du site peut se solder par des droits accordés au pirate suppérieurs à ceux du compte admin !
 
IIS doit TOUJOURS tourner sous un compte membre uniquement du groupe "anonyme". Ceci afin de restreindre au maximum la portée du code éxécuté depuis l'ASP en cas de hack.
 
PS: et arbitrairement, quand un hacker arrive à lire les mots de pass en clair dans les scripts ASP, c'est que généralement il a trouvé un moyen d'avoir des accès à ton système de fichiers. Y'a de grandes chances pour qu'il aie récupéré en même temps le moyen d'écrire, donc de créer de nouvelles pages, qui vont utiliser les mots de pass lus.
 
Avec la système de ton formateur, c'est encore mieu : à partir du moment où il peut accéder au système de fichier, il a tous les accès qu'il veut à la base, puisqu'il n'a plus besoin de s'y authentifier...

ATTENTION !
-----------
 
Laisse béton, en effet ton formateur à l'air plus au courant des faits que moi
 
Actuellement, M$ recommande en effet l'authentification Windows, faudra que je lire l'article de plus près.
 
Je trouve ce retournement de situation assez bizarre, puisqu'il y a peu (SQL Server 7.0) c'était le contraire, l'authentification Windows ne devait à l'époque servir que pour des application internes au réseau, en aucun cas pour un serveur ayant un accès depuis l'extérieur. Chelou.
 
http://www.microsoft.com/technet/t [...] 3SEC03.ASP