J'=E9tudie, pour des questions de bande passante WAN uniquement,
l'activation de kerberos plut=F4t 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=E9
que l'on pouvait juste cr=E9er des spn pour la compte et le portail,
comme une appli .net classique. Enfin, je me demande? (activer la
d=E9legation et les permissions DCOM me parait aussi overkill, mais ca
servira pour reporting / excel services =E0 l'avenir )
- on conseille de cr=E9er la clef "KerberosSpnFormat"=3D1, si j'ai bien
compris, cela permet de d=E9clarer 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 =E0 d=E9clarer?
Bref, dans ma checklist actuelle, j'en suis (sur la ferme de test),
=E0 :
- 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=E9er le spn pour le portail et le compte de ferme (c'est le compte
du pool portail, aussi)
- cr=E9er les spn pour les webapps CA et SSP (mysite non utilis=E9)
- cr=E9er 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
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/
Bonjour,
"Emmanuel Issaly" <e.issaly@gmail.com> wrote in message
news:173505f9-c45c-43d1-962c-3c3babcaac5d@a13g2000yqc.googlegroups.com...
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/
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
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.
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?
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]
> 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/
> 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/
> 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
> 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 :-)
> 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 :-)
> 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 :-)
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/
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/
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
> 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. ^^
>
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. ^^
> 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]
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/
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/
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
> 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.
>
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 ^^
> 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
> 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 :)
> 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 :)
> 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]
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/
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/
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/
