Authentification Kerberos sur SQL

Ca :

Code:

---

1 2 3 4 5 6 7

<Authentication> <AuthenticationTypes> <RSWindowsNegotiate/> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> </Authentication>

---

C'est bon : (encore que je me demande si EnableAuthPersistence ne doit pas être égale à False parce que j'utilisateur un proxy, mais bon dans le deux cas ça ne marche pas)

- le spn pour le serveur SQL (compte de service sql)
La commande suivante a été saisie

Code:

---

1 2	SetSPN -S MSSQLSvc/srv1.dmn.fr dmn\svc-sql

---

- le spn pour le serveur SSRS (compte de service ssrs)
La commande suivante a été saisie

Code:

---

1 2	SetSPN -S http/srv2.dmn.fr dmn\svc-sql

---

Résulte avec la commande :

Code:

---

1 2	SetSPN -l dmn\svc-sql

---

J'ai bien

Citation:

---

MSSQLSvc/srv1.dmn.fr
http/srv2
http/srv2.dmn.fr

---

- autoriser la délégation pour le serveur qui héberge ssrs dans l'AD
Les deux serveurs srv1 et srv2 autorise la délégation

- autoriser la délégation pour le compte de service ssrs vers MSSQLSvc/xxx
Grace à toi j'ai activé la délégation de contrainte http et MSSQLSvc pour le compte dmn\srv-svc

- Vérifier que internet explorer utilise bien Kerberos
Je n'ai pas encore regardé je vais vérifier mais je ne pense pas que le problème vienne de là.

Remarque tout de même :
Dans le journal d'évènement : à chaque fois que je redémarre leservice Report Services j'ai une erreur de type : KDB_ERR_PREAUTH_REQUIRED. (rappel : le service est lancé avec le compte svc-sql).

De plus en lançant la requête depuis srv2 ou le client sur le serveur SQL de srv1 :

Code:

---

1 2	select auth_scheme from sys.dm_exec_connections where session_id = @@SPID;

---

j'ai toujours NTLM et non KERBEROS

Pour cette erreur KDB_ERR_PREAUTH_REQUIRED, c'est normal on va dire. Dans un domaine Windows la phase de pré authentifcation n'est en général jamais faite mais cela ne gène pas.

Tu as essayé de faire un reboot de tes serveurs (si c'est possible bien sûr). Bien souvent les serveurs utilisent les tickets en cache même après un changement de configuration. Un KLIST PURGE pourrait t'aider mais j'ai souvent dû redémarrer les serveurs malgré cela.

++

Autre chose aussi pour éviter certaines erreurs en fonction de comment sont appelés les services :

Tu peux rajouter pour chaque service le SPN avec le nom NETBIOS :

Code:

---

1 2	SetSPN -S MSSQLSvc/srv1 dmn\svc-sql SetSPN -S http/srv2 dmn\svc-sql

---

Tu auras ainsi 2 SPN associés à chaque service avec le nom netbios et le FQDN

++

Comme tu me l'as suggéré j'ai bien ajouté les deux SPN correspondant et j'ai redémarré les serveurs (c'est des machines virtuelles de test ça ne craint pas !!!) sans résultat toujours 'AUTORITE NT\ANONYMOUS LOGON'
avec les deux erreurs :
KRB5KDC_ERR_BADOPTION NT Status
et
KRB5_ERR_S_PRINCIPAL_UNKNOWN

Dans le journal d'evenement j'ai :

Citation:

---

Réception d’un message d’erreur Kerberos*:
lors de l’ouverture de session
Heure du client*:
Heure du serveur*: 11:5:45.0000 12/18/2013 Z
Code d’erreur*: 0xd KDC_ERR_BADOPTION
Erreur étendue*: 0xc0000272 KLIN(0)
Client du domaine Kerberos*:
Nom du client*:
Serveur du domaine Kerberos*: DMN.FR
Nom du serveur*: MSSQLSvc/srv1.dmn.fr:1433
Nom cible*: MSSQLSvc/srv1.dmn.fr:1433@SOGETREL.FR
Texte d’erreur*:
Fichier*: 9
Ligne*: 12c4
Les données d’erreur sont dans les données d’enregistrement.

---

Ce qui m'inquiète c'est qu'on ne voit pas le nom du client.

Je ne sais pas si ça un impact mais quand je vais dans les stratélie local des mes serveurs (srv1 et srv2) dans Options de sécurité, l'option Sécurité Réseau : Configurér les types de chiffrement autorisés pour Kerberos est Non défini

-Ok

Dans le journal de sécurité Windows sur le serveur Web ou éventuellement sur le serveur SSRS tu peux voir les entrées concernant les logins et le protocole utilisé : AUTHENTICATION PACKAGE = XXX

Est-ce que tes logins utilisent bien le protocole KERBEROS à ce stade ?

Vérifie dans internet explorer pour être sûr que tu autorises bien l'authentification Kerberos (internet explorer > Internet Options > Section Advanced > Section security settings > Enable Kerberos authentication)

Je réfléchis en attendant à une autre piste mais à distance ce n'est pas simple :-)

++

Citation:

---

Je réfléchis en attendant à une autre piste mais à distance ce n'est pas simple :-)

---

C'est déjà très sympa de ta part de m'avoir aidé jusque là !!
D'accord je n'ai pas résolu mon pb mais j'ai qd même l'impression d'avoir avancé.

Citation:

---

Dans le journal de sécurité Windows sur le serveur Web ou éventuellement sur le serveur SSRS tu peux voir les entrées concernant les logins et le protocole utilisé : AUTHENTICATION PACKAGE = XXX

---

Ca s'est pas simple parce que SSRS n'utilise pas IIS et comme configuration de SSRS je ne connais que le Gestionnaire de configuration de Report Services et dans cet utilitaire il n'y a pas de consultation de journal d'évênement mais bon je vais voir ce que je peux trouver avec celui de Windows.

Citation:

---

Vérifie dans internet explorer pour être sûr que tu autorises bien l'authentification Kerberos (internet explorer > Internet Options > Section Advanced > Section security settings > Enable Kerberos authentication)

---

Bon moi je l'ai en Français et comme la traduction n'est pas littéral je suppose que c'est
Option Internet -> Onglet Avancé -> Section sécurité -> Activé l'authentification Windows Intégrée et dans ce cas oui c'est coché

Dans l'audit de sécurité de Windows j'ai bien le package donnée = kerberos : je te transmets le résultat de l'audit :

Citation:

---

L’ouverture de session d’un compte s’est correctement déroulée.

Sujet :
ID de sécurité : NULL SID
Nom du compte : -
Domaine du compte : -
ID d’ouverture de session : 0x0

Type d’ouverture de session : 3

Niveau d’emprunt d’identité : Emprunt d’identité

Nouvelle ouverture de session :
ID de sécurité : dmn\moi
Nom du compte : moi
Domaine du compte : dmn
ID d’ouverture de session : 0x717E35
GUID d’ouverture de session : {85a6f8a1-332f-fbc9-c089-173ea59aa5a4}

Informations sur le processus :
ID du processus : 0x0
Nom du processus : -

Informations sur le réseau :
Nom de la station de travail :
Adresse du réseau source : -
Port source : -

Informations détaillées sur l’authentification :
Processus d’ouverture de session : Kerberos
Package d’authentification : Kerberos
Services en transit : -
Nom du package (NTLM uniquement) : -
Longueur de la clé : 0

Cet événement est généré lors de la création d’une ouverture de session. Il est généré sur l’ordinateur sur lequel l’ouverture de session a été effectuée.

Le champ Objet indique le compte sur le système local qui a demandé l’ouverture de session. Il s’agit le plus souvent d’un service, comme le service Serveur, ou un processus local tel que Winlogon.exe ou Services.exe.

Le champ Type d’ouverture de session indique le type d’ouverture de session qui s’est produit. Les types les plus courants sont 2 (interactif) et 3 (réseau).

Le champ Nouvelle ouverture de session indique le compte pour lequel la nouvelle ouverture de session a été créée, par exemple, le compte qui s’est connecté.

Les champs relatifs au réseau indiquent la provenance d’une demande d’ouverture de session à distance. Le nom de la station de travail n’étant pas toujours disponible, peut être laissé vide dans certains cas.

Le champ du niveau d’emprunt d’identité indique la portée de l’emprunt d’identité que peut prendre un processus dans la session d’ouverture de session.

Les champs relatifs aux informations d’authentification fournissent des détails sur cette demande d’ouverture de session spécifique.
- Le GUID d’ouverture de session est un identificateur unique pouvant servir à associer cet événement à un événement KDC .
- Les services en transit indiquent les services intermédiaires qui ont participé à cette demande d’ouverture de session.
- Nom du package indique quel est le sous-protocole qui a été utilisé parmi les protocoles NTLM.
- La longueur de la clé indique la longueur de la clé de session générée. Elle a la valeur 0 si aucune clé de session n’a été demandée.

---

Ok c'est déjà pas mal.

Autres questions que j'ai omis de te poser :

C'est un serveur SSRS en mode natif ou intégré avec SharePoint ?
Est-ce que tu utilises des header pour te connecter au serveur de rapport SSRS ?

++

Ce n'est pas intégré à Sharepoint et je n'utilise pas de header.

Je tape juste l'URL :

https://srv2.dmn.fr/Reports/

Et j'ai donné les droits dans dossier racine à dmn\srv-svc et moi même.

Comme c'est une url sécurisé (https) : je me demande si la classe de service à mettre dans le SetSPN est bien http et non https.

Autre précision c'est quand je clique sur mon rapport (et non pas quand je navigue dans le site) que j'ai l'erreur sur la source de connection. Je peux aussi choisir la source de connection sur le site et tester la connexion et j'ai l'erreur :
Échec de l'ouverture de session de l'utilisateur 'AUTORITE NT\ANONYMOUS LOGON'.

Non la classe reste la même pour HTTPS. On doit mettre HTTP/xxx

Citation:

---

Autre précision c'est quand je clique sur mon rapport (et non pas quand je navigue dans le site) que j'ai l'erreur sur la source de connection. Je peux aussi choisir la source de connection sur le site et tester la connexion et j'ai l'erreur :
Échec de l'ouverture de session de l'utilisateur 'AUTORITE NT\ANONYMOUS LOGON'.

---

Oui normal, c'est au moment de la connexion au serveur SQL que la délégation doit se faire. Quand tu navigues sur le site tu restes sur le serveur middle.

Une chose que l'on a pas vérifié :

Citation:

---

The appropriate local policy rights (if you have a native mode deployment). The appropriate local policy rights are: Log on as a service; Access this computer from the network; and Impersonate a client after authentication.

---

++

Je vois de quel document tu as lu ce petit paragraphe : je l'avais lu en diagonal aussi. Cette partie il faut le faire dans la stratégie de sécurité locale dans l'outil d'administration :

Citation:

---

1. On the middle tier computer(s), open Local Security Policy.
2. Click Start, point to Administrative Tools, and then click Local Security Policy.
3. In the tree, expand Local Policies, and then click User Rights Assignment.
4. In the right pane, verify that the Security Setting column includes the service account next to the appropriate policies.

---

Donc je suis allé dans Attribution des droits utilisateurs .

Mais j'ai un peu du mal à trouver la bonne option pour traduire ces 3 options :

Citation:

---

Log on as a service; Access this computer from the network; and Impersonate a client after authentication

---

J'ai conclu sur Impresonnate a client after authentification qu'il s'agissait de Emprunter l'idendité du client après authentification et j'ai ajouté le compte dmn\svc-sql sur les deux serveurs (srv1 et srv2)

J'ai conclu que Access this computer from the network est Accéder à cet ordinateur à partir du réseau et pour les deux seveurs "tout le monde" était choisi (donc mon compte svc-sql aussi) mais Log on as a service je ne trouve pas.

Hmm j'ai que des versions anglaises maintenant et où je travaille ... :D

S'authentifier en tant que service ? Quelque chose dans le genre ? toujours dans Attribution des droits utilisateurs ...

++

C'est bon c'est ouvrir une session en tant que service mais mon utilisateur est dedans.
La seules chose que j'ai modifié c'est Emprunter l'identité du client après authentification.

J'ai relancé mais ça ne fonctionne pas : peut être faut il que je redémarre les serveurs

En général ces options touchent au registre ... tu peux faire un reboot au moins tu seras sûr.

++

Fait!
Mais cela ne fonctionne toujours pas.

Ok bon là part une éventuelle règle de firewall entre les serveurs qui ne laissent pas passer Kerberos je ne vois plus trop.

Il faudrait pouvoir faire une trace wireshark sur le client, sur le serveur ssrs et sur le backend pour voir où se situe le problème en filtrant sur les appels DNS, Kerberos et les IP qui vont bien.

Je vais essayer de mon côté de me refaire rapidement une infrastructure de ce style pour voir si j'ai omis quelque chose d'évident.

++

Juste je suppose que tu dois t'en douter mais je le dis qd même au cas où ça t'aide dans ton analyse : quand je lance le report depuis le serveur srv2 avec IE j'affiche bien le rapport.

C'est depuis un poste client que tt va mal avec toujours la même erreur.
Je pense que c'est qqch de gros au niveau du paramétrage qu'on a pas vu et nn pas un problème de droit ou de pare feu : le message ne serait pas le même.

En lisant la doc, cela correspond vraiment à un problème de SPN ou de délégation dans l'AD mais vraiment là je suis sec.