[MOSS 2007 SP2] Webapp en Kerberos

Le
Emmanuel Issaly
Bonjour à tous, cela faisait longtemps :)

J'étudie, pour des questions de bande passante WAN uniquement,
l'activation de kerberos plutôt que NTLM sur une webapp intranet.
Quelques p'tites questions :

- Si je veux juste une authentification des end users sur une zone de
l'intranet, basculer le ssp en kerb me parait inutile. J'aurais pensé
que l'on pouvait juste créer des spn pour la compte et le portail,
comme une appli .net classique. Enfin, je me demande? (activer la
délegation et les permissions DCOM me parait aussi overkill, mais ca
servira pour reporting / excel services à l'avenir )

- on conseille de créer la clef "KerberosSpnFormat"=1, si j'ai bien
compris, cela permet de déclarer des spn pour le SSP, de la forme MSSP/
WFEx:56737/, ou bien ? :)

- la doc MS conseille de declarer des SPN pour le crawl et le query,
mais ces services sont sur mon serveur d'index. Je vois donc rien de
plus à déclarer?

Bref, dans ma checklist actuelle, j'en suis (sur la ferme de test),
à :

- ajouter la clef KerberosSpnFormat sur les noeuds, rebooter.
- autoriser la delegation non contrainte pour le compte de ferme et
les noeuds.
- creer les spn SQL sur l'instance de conf sharepoint et l'instance du
portail
- créer le spn pour le portail et le compte de ferme (c'est le compte
du pool portail, aussi)
- créer les spn pour les webapps CA et SSP (mysite non utilisé)
- créer les spn pour les services du ssp : 56737 et 56738
- basculer le SSP en auth Kerb
- basculer la zone intranet du portail en auth Kerb
- bruler un cierge

Est ce que cela vous parait correct? :D

Emmanuel ISSALY.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Marc Lognoul [MVP]
Le #19948141
Bonjour,

"Emmanuel Issaly" news:
Bonjour à tous, cela faisait longtemps :)


Oui, il fait clame ces temps-ci ;)

J'étudie, pour des questions de bande passante WAN uniquement,
l'activation de kerberos plutôt que NTLM sur une webapp intranet.


Et bien cela peut paraitre étonnant mais kerberos est le plus mauvais choix
dans le cas d'un WAN. Cela s'explique par le fait que l'en-tête HTTP
utilisée pour transporter les information de sécurité ne contient pas
uniquement les informations d'authentification (comme en NTLM ou Basic) mais
également les informations d'autorisation (group membership etc...). La
taille de l'en-tête est donc directement proportionnelle au nombre de groupe
dont l'utilisateur est membre (san parler de son SID History etc...) et est
dans tous les cas bien plus important qu'avec du NTLM.

Quelques p'tites questions :

- Si je veux juste une authentification des end users sur une zone de
l'intranet, basculer le ssp en kerb me parait inutile.


Complètement en effet.
Il faut bien scinder l'authentification "client vers servers" et "servers
vers servers". Les deux ne vont pas obligatoirement de pair.

J'aurais pensé
que l'on pouvait juste créer des spn pour la compte et le portail,
comme une appli .net classique. Enfin, je me demande? (activer la
délegation et les permissions DCOM me parait aussi overkill, mais ca
servira pour reporting / excel services à l'avenir )


En effet, on peut créer des SPN uniquement pour le portail et donc utiliser
kerberos exlcusivement entre les client et les serveur frontaux.
Dans le cas d'excel calculation services, si les fichiers se trouvent en
dehors de sharepoint (trusted lcoations), il faut activer la délégation afin
de passer l'authentication vers ces "trusted locations".

--
Marc Lognoul [MCSE, MCTS, MVP]
Heureux celui qui a pu pénétrer les causes secrètes des choses
Happy is the one who could enter the secret causes of things
Blog EN: http://www.marc-antho-etc.net/blog/
Blog FR: http://www.marc-antho-etc.net/blogfr/
Emmanuel Issaly
Le #19948281
Merci beaucoup de la réponse!

Et bien cela peut paraitre étonnant mais kerberos est le plus mauvais c hoix
dans le cas d'un WAN. Cela s'explique par le fait que l'en-tête HTTP
utilisée pour transporter les information de sécurité ne contient p as
uniquement les informations d'authentification (comme en NTLM ou Basic) m ais
également les informations d'autorisation (group membership etc...). La
taille de l'en-tête est donc directement proportionnelle au nombre de g roupe
dont l'utilisateur est membre (san parler de son SID History etc...) et e st
dans tous les cas bien plus important qu'avec du NTLM.
¨



Mais le facteur impactant pour un WAN éloigné (ici Paris <-> Boston)
me parait être le nombre de rounds trips. Même si la taille de
l'entête augmente, je vais gagner un max avec un seul round trip ou
lieu de plusieurs, particulièrement pour une page moss ou il y a des
dizaines d'items? (partie authentifiée)


Complètement en effet.
Il faut bien scinder l'authentification "client vers servers" et "servers
vers servers". Les deux ne vont pas obligatoirement de pair.




ah, je me disais bien! :)


En effet, on peut créer des SPN uniquement pour le portail et donc util iser
kerberos exlcusivement entre les client et les serveur frontaux.
Dans le cas d'excel calculation services, si les fichiers se trouvent en
dehors de sharepoint (trusted lcoations), il faut activer la délégati on afin
de passer l'authentication vers ces "trusted locations".



Donc pour uniquement tester kerberos sur mon portail, je me retrouve
avec :

- ajouter la clef KerberosSpnFormat sur les noeuds, rebooter.
- creer les spn SQL sur l'instance de conf sharepoint et l'instance du
portail
- créer le spn pour le portail et le compte de ferme
- basculer la zone intranet du portail en auth Kerb

Qu'en penses tu?

Sinon, très intéressant ton article sur le PAC, mais qu'est ce qui
fait que cela ne s'applique pas à MOSS?
à cause de l'utilisation de comptes de service?

Emmanuel.
Marc Lognoul [MVP]
Le #19948551
> Mais le facteur impactant pour un WAN éloigné (ici Paris <-> Boston)
me parait être le nombre de rounds trips. Même si la taille de
l'entête augmente, je vais gagner un max avec un seul round trip ou
lieu de plusieurs, particulièrement pour une page moss ou il y a des
dizaines d'items? (partie authentifiée)


Cela veut donc dire que tes utilisateurs distants appartiennent à un domaine
liée par une relation d'approbation au domain hébergeant SharePoint et non
au même domain, exact?
Dans ce cas, si tu veux éviter les roundtrips il faut que:
1) L'authentification soit kerberos
2) Le setting du registre soit à 1
3) l'identité de l'application pool qui tourne le portail soit
NetworkService (ou LocalSystem). Cela signifie donc pas de load balancing
entre frontaux.



- ajouter la clef KerberosSpnFormat sur les noeuds, rebooter.


Non, pas besoin de cela

- creer les spn SQL sur l'instance de conf sharepoint et l'instance du
portail


Pas besoin de cela non plus

- créer le spn pour le portail et le compte de ferme


créer le SPN pour le portail uniquement
- basculer la zone intranet du portail en auth Kerb


Oui c'est ça

Accessoirement, si tu utilise ECS, activer la délégation sur le compte sous
lequel tourne le portail.

+ beaucoup de patience et d'IISRESET ;)

--
Marc Lognoul [MCSE, MCTS, MVP]
Heureux celui qui a pu pénétrer les causes secrètes des choses
Happy is the one who could enter the secret causes of things
Blog EN: http://www.marc-antho-etc.net/blog/
Blog FR: http://www.marc-antho-etc.net/blogfr/
Emmanuel Issaly
Le #19948541
> Cela veut donc dire que tes utilisateurs distants appartiennent un domaine
li e par une relation d'approbation au domain h bergeant SharePoint et non
au m me domain, exact?



Exact. Et je suppose que les gremlins viennent de manger ton
codepage :P

Dans ce cas, si tu veux viter les roundtrips il faut que:
1) L'authentification soit kerberos



OK ;)

2) Le setting du registre soit 1



euh lequel?

3) l'identit de l'application pool qui tourne le portail soit
NetworkService (ou LocalSystem). Cela signifie donc pas de load balancing
entre frontaux.



NO WAY :D
mais pourquoi??


> - ajouter la clef KerberosSpnFormat sur les noeuds, rebooter.

Non, pas besoin de cela



ca sert a quoi, en faite?

Merci 1000x, c'est pas facile de s'en sortir quand on a jamais vu une
formation de sa vie :-)
Marc Lognoul [MVP]
Le #19948941
>
2) Le setting du registre soit 1



euh lequel?


Celui-ci: http://support.microsoft.com/default.aspx?scid=kb;EN-US;906736

3) l'identit de l'application pool qui tourne le portail soit
NetworkService (ou LocalSystem). Cela signifie donc pas de load balancing
entre frontaux.



NO WAY :D
mais pourquoi??


Parceque visiblement (d'après mes testes), le système ne désactivera le
round-trip (validation de la signature du PAC) que si les conditions
suivantes sont rencontrées (en plus d'utiliser Kerberos):
1) le settings dans le registre est mis à 1
2) le compte du service (soit dans ce cas-ci le worker process d'IIS de
l'application pool sous lequel fonctionne sharepoint) possède le SID
"SERVICE" (logon as a service) dans son token

Si l'application pool d'IIS tourne sous un autre contexte (compte du domaine
par ex, tel que requis si on veut utiliser kerberos et du load balancing),
son token reçoit le SID "BATCH" (Logon as batch) et non logon as service...


--
Marc Lognoul [MCSE, MCTS, MVP]
Heureux celui qui a pu pénétrer les causes secrètes des choses
Happy is the one who could enter the secret causes of things
Blog EN: http://www.marc-antho-etc.net/blog/
Blog FR: http://www.marc-antho-etc.net/blogfr/
Emmanuel Issaly
Le #19949261
>
Si l'application pool d'IIS tourne sous un autre contexte (compte du doma ine
par ex, tel que requis si on veut utiliser kerberos et du load balancing) ,
son token reçoit le SID "BATCH" (Logon as batch) et non logon as servic e...




mmmh... je te suis maintenant, cela va induire un deuxieme round trip
pour le PAC. Avec un temps de 110 ms, bah.
Je vais quand même essayer et faire des benchs si possible cette
semaine.
Malgré tout, j'espère que ce sera valable, actuellement le DC est
_Bombardé_ de requetes NTLM.

Au point que j'ai mis Boston sur la zone anonyme ^^

Sinon, je ne suis pas sur pour le SPN du portail.
Comme il y a equilibrage, on a (l'url du portail) --(CNAME)-> NLB --
(Forward)-> WFE 1 + 2
J'ai lu que dans ce cas, ca ne marcherais pas ?

parce que setspn -a HTTP/portail.tralala domainecompte de ferme, ca
me plaisait bien. ^^
Marc Lognoul [MVP]
Le #19951471
Bonjour Emmanuel,

mmmh... je te suis maintenant, cela va induire un deuxieme round trip
pour le PAC. Avec un temps de 110 ms, bah.
Je vais quand même essayer et faire des benchs si possible cette
semaine.
Malgré tout, j'espère que ce sera valable, actuellement le DC est
_Bombardé_ de requetes NTLM.


2 roundtrips? non, si tu configure kerberos et que la vérification du PAC
est désactivée c'est zéro round-trip, exception fait du get anonyme
évidemment qui dépend du HTTP et non des protocole d'authentification MS.

Au point que j'ai mis Boston sur la zone anonyme ^^


Sage décision si c'est tenable

De manière générale et comme dit le dicton, on ne peut pas faire un cheval
de course d'un âne, même en le dopant ;)
Toutes les configurations que tu pourras mettre en place te procurerons un
résultat marginal par rapport à une augmentation réelle de la bande passante
et une réduction de la latence (aussi importante selon moi)

Sinon, je ne suis pas sur pour le SPN du portail.
Comme il y a equilibrage, on a (l'url du portail) --(CNAME)-> NLB --
(Forward)-> WFE 1 + 2
J'ai lu que dans ce cas, ca ne marcherais pas ?

parce que setspn -a HTTP/portail.tralala domainecompte de ferme, ca
me plaisait bien. ^^



Ce qui ne marchera pas dans ce cas, c'est la désactivation de la
vérification du PAC.

J'espère que c'est un peu plus limpide pour toi...

--
Marc Lognoul [MCSE, MCTS, MVP]
Heureux celui qui a pu pénétrer les causes secrètes des choses
Happy is the one who could enter the secret causes of things
Blog EN: http://www.marc-antho-etc.net/blog/
Blog FR: http://www.marc-antho-etc.net/blogfr/
Emmanuel Issaly
Le #19952301
>
J'espère que c'est un peu plus limpide pour toi...




ca commence :)

Bon, aucune difficulté pour le SPN, je vois bien le package kerberos
et mon ticket quand je me connecte au portail maintenant (security log
+ kerbtray).

Par contre, si je lance fiddler, je ne vois rien qui change... WWW-
Authenticate Header is present: NTLM

On dirait donc que j'obtient bien mon ticket, mais que IIS ne me
renvoie pas de header Kerberos ^^

Je creuse avec ma pelle.
Emmanuel Issaly
Le #19952431
> J'espère que c'est un peu plus limpide pour toi...



ca commence :)

Bon, aucune difficulté pour le SPN, je vois bien le package kerberos
et mon ticket quand je me connecte au portail maintenant (security
log
+ kerbtray).

si je lance fiddler, je vois un seul :

401
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

200
WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply

Si j'ai pigé, on gagne _UN_ round trip challenge / response, car le
ticket est validé coté serveur.

je relis ton article sur le PAC maintenant, parce que j'ai pas tout
compris :)
Marc Lognoul [MVP]
Le #19952901
Hello

Bon, aucune difficulté pour le SPN, je vois bien le package kerberos
et mon ticket quand je me connecte au portail maintenant (security
log
+ kerbtray).


Alors, c'est que c'est bon, sinon tu ne verrais pas de ticket pour le
service correspondant au portail (HTTP/monportail.mondomaine.local par ex)


si je lance fiddler, je vois un seul :

401
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM


Ce sont les en-têtes renvoyées par le serveur afin de signler au client les
protocoles d'authentification supportés.

200
WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply


Regarde dans l'event log "sécurité" des WFE, tu devrait voir des événements
"Success" pour des ouvertures de ssion de type 3 (réseau) utilisant le
ptocole "Kerberos" (pas Negotiate dans ce cas)

--
Marc Lognoul [MCSE, MCTS, MVP]
Heureux celui qui a pu pénétrer les causes secrètes des choses
Happy is the one who could enter the secret causes of things
Blog EN: http://www.marc-antho-etc.net/blog/
Blog FR: http://www.marc-antho-etc.net/blogfr/
Publicité
Poster une réponse
Anonyme