Discussion :

[Bal1n]

Bonjour à tous.

Voilà, je fais quelques test sur SQL serveur 2005 en vu d'une migration prochaine de SQL 2000 --> SQL 2005

Donc je me suis monté un serveur Test SQL Serveur 2005 sur lequel j'ai installé IIS.
L'installation de SQL serveur 2005 a été effectuée en Authentification Windows uniquement.

J'ai créé une page Web toute bidon pour simplement requeter sur une base spécifiée.

Ça c'est pour l'environnement technique.


Mon problème :

L'idée étant d'être Full Windows authentication.
Donc j'utilise une chaine de connexion en conséquence.

Je lance ma page et j'effectue un simple Select * sur une table et j'obtiens le message d'erreur suivant :

Echec de l'ouverture de session de l'utilisateur 'AUTHORITE NT\SERVICE RESEAU'

Bizarre quand même... Je suis en authentification windows et on dirait que IIS tente de se connecter à la BDD via ce user...

Du coup je joues le jeu et je donne les droits qui vont bien sur ma base pour ce user. Et là Hop ca fonctionne !

Mais ca ne me va pas du tout !!!!
Pourquoi il y a cette perte d'authentification entre mon appli ASP et le serveur SQL ? Pourquoi est-ce ce compte qui est utilisé ?

Y a t'il quelque chose de mal configuré sur IIS ? Sur SQL SERVER ?

Pour info voici mon code effectuant la connexion SQL (fonctionne bien):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
            'ouverture connection
            Dim cs As String
            Dim cnSQL As SqlConnection
 
            If Me.CheckBox1.Checked = True Then
                'Windows Auth
                cs = "Data Source=" & Me.TxtSRVSQL.Text & ";Initial Catalog=" & Me.TxtBDD.Text & ";Integrated Security=SSPI;"
            Else
                'SQL Auth
                cs = "Data Source=" & Me.TxtSRVSQL.Text & ";Initial Catalog=" & Me.TxtBDD.Text & ";User Id=" & Me.TxtID.Text & ";Password=" & Me.TxtMDP.Text & ";"
            End If
 
            cnSQL = New SqlConnection
            cnSQL.ConnectionString = cs
            cnSQL.Open()
 
 
            If Me.CheckBox2.Checked = True Then
                'Lecture
                Dim SDA As SqlDataAdapter = New SqlDataAdapter(Me.TxtRQ.Text, cnSQL)
                Dim DSRetour As DataSet = New DataSet()
                SDA.Fill(DSRetour)
                Me.GridView1.DataSource = DSRetour
                Me.GridView1.DataBind()
 
            Else
                'execution
                Dim Command As New SqlClient.SqlCommand(Me.TxtRQ.Text, cnSQL)
                Command.ExecuteNonQuery()
                Command.Dispose()
                Command = Nothing
            End If

Merci d'avance pour votre aide !

[cybermaxs]

Sur quel environnement travailles - tu ? xp, vista/7, windows server ?
En gros, IIS tourne sous un user spécifique : donc si tu as mis dans la connecetionString une sécurité intégré, il va utiliser ce compte, qui n'est pas ouvert pas défaut (et ne doit pas l'être !)

Il ne faut pas confondre l'accès à la base et l'authentification IIS/ASPNEt de ton site. Le plus souvent le site accède à la base via un user déterminé, c'est pas le compte NT qui va directement faire les requêtes. L'authentification IIS/ASPNET te permet de sécuriser les pages/répertoire de ton site (et même un peu plus) en fonction de ce que tu veux : Compte NT ou mécanisme personnalisé.

Bon courage,

[Bal1n]

Pouah mais c'est complètement fou !

(je suis sur du SQL Serveur 2005 - Windows server 2003 / client en XP Et site Web en .net 2.0)

Autrement dis, il n'existe aucune façon de lier mon utilisateur qui utilise intranet avec ma Base de donnée ? N'existe t'il pas une sorte de délégation permettant de le faire ?

Je ne trouve pas ça extraordinaire en terme de sécurité ...
Parceque ça veut dire que toute requête venant de IIS est exécuté par le compte Authorite NT / service réseau et que je dois donc en conséquence donner accès à ce compte aux différentes bases susceptible d'être attaquées par IIS, autrement dis, quasiment toute !

[cybermaxs]

Tu n'as pas bien lu entre les lignes de mon post. IIS tournant sur un compte volontairement restreint ne veut pas dire qu'il faut faut donner tous les droits à ce compte, bien au contraire.

Tes requêtes sont exécutées sur le compte 'AUTHORITE NT\SERVICE RESEAU' parce que TU as choisis de faire une connexion à la base en sécurité intégrée.

Dans ta chaîne de connexion il est possible (et presque toujours fait) de mettre un user/mdp pour la connexion à la base SQL. Sinon comment procéder, ton dba va se taper la création des connexions des N users sur ta base ?

Dernièrement, il possible de faire de faire de limpersonation, c'est à dire de faire tourner IIS ou ton site ASPNET sous un login spécifique.

Voilà pour la connexion à la base.

Si ton appli web nécessite maintenant une authentification type intranet, il faut intervenir sur un autre aspect qui n'affectera pas ta connexion à la base SQL mais uniquement les droits des utilisateurs sur ton site (afficher/interdire une page par exemple).

[Bal1n]

Ok compris

Mais bon, j'ai beau y réfléchir dans tout les sens ça me parait vraiment pas fiable en terme de sécurité ...

Dans ta chaîne de connexion il est possible (et presque toujours fait) de mettre un user/mdp pour la connexion à la base SQL.

Se qui revient à effecuer une authentification SQL et non plus intégrée. Ce que je ne souhaite pas à la base car cela fait mettre en clair les Id et mdp dans la chaine de connexion. De même une solution full windows me semblait plus saine.

Sinon comment procéder, ton dba va se taper la création des connexions des N users sur ta base ?

Oui, ou d'un groupe AD.
Est-ce si différent que de créer des comptes spécifiques SQL pour en donner l'accès ?

L'avantage étant que seul les utilisateurs désignés du réseau aurait accès à la BDD. Alors que là n'importe qui ayant accès à la page Web peut exécuter les fonctions et mettre le bronx.
Et puis cela permet de gérer l'accès au base directement depuis l'AD et la gestion de groupe.

On en vient donc à ton dernier point. Gérer les accès au niveau du site Web Ce qui est déjà fait actuellement sur l'ensembble de notre intranet je te rassure

En tout cas merci pour tout ces éclaircissements. Ca me permet de plus naviguer dans le brouillard et je vais pouvoir définir sereinement d'une politique sécurité (qui finalement passera probablement par une authentification SQL comme aujourd'hui)

C'est quand même dommage tout ça
@++