J'ai configur=E9 Kerberos avec succ=E8s pour mon portail d'utilisateurs,
essentiellement pour pouvoir utiliser la "visionneuse RSS" pointant
vers des sources internes MOSS. Tout va bien merci :)
Par contre, je soup=E7onne des effets de bord sur le moteur de
recherche, en effet, seul mon portail est configur=E9 en Kerberos: les
SharedServices (dont MySites) et la CentralAdmin sont encore en NTLM.
=3D> Faut-il permettre quelque part au "compte d'acc=E8s de la recherche"
de s'authentifier en Kerberos, ou est-il cens=E9 le faire nativement ?
=3D> Plus g=E9n=E9ralement, recommandez vous d'activer Kerberos sur toutes
les webapps, y compris sp=E9cifiques MOSS (SharedServices,
CentralAdmin) ? Dans ce cas, cela m'imposerait des host headers, vu
que les SPN ne tiennent pas compte du port...
Merci pour vos retours d'exp=E9rience sur ce sujet.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romelard Fabrice [MVP]
Bonjour,
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
-- Cordialement
Romelard Fabrice [MVP]
"TG2K" a écrit dans le message de groupe de discussion :
Bonjour,
J'ai configuré Kerberos avec succès pour mon portail d'utilisateurs, essentiellement pour pouvoir utiliser la "visionneuse RSS" pointant vers des sources internes MOSS. Tout va bien merci :)
Par contre, je soupçonne des effets de bord sur le moteur de recherche, en effet, seul mon portail est configuré en Kerberos: les SharedServices (dont MySites) et la CentralAdmin sont encore en NTLM.
=> Faut-il permettre quelque part au "compte d'accès de la recherche" de s'authentifier en Kerberos, ou est-il censé le faire nativement ?
=> Plus généralement, recommandez vous d'activer Kerberos sur toutes les webapps, y compris spécifiques MOSS (SharedServices, CentralAdmin) ? Dans ce cas, cela m'imposerait des host headers, vu que les SPN ne tiennent pas compte du port...
Merci pour vos retours d'expérience sur ce sujet.
Bonjour,
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
--
Cordialement
Romelard Fabrice [MVP]
"TG2K" <ElGibs@gmail.com> a écrit dans le message de groupe de discussion :
1191422385.769895.303450@y42g2000hsy.googlegroups.com...
Bonjour,
J'ai configuré Kerberos avec succès pour mon portail d'utilisateurs,
essentiellement pour pouvoir utiliser la "visionneuse RSS" pointant
vers des sources internes MOSS. Tout va bien merci :)
Par contre, je soupçonne des effets de bord sur le moteur de
recherche, en effet, seul mon portail est configuré en Kerberos: les
SharedServices (dont MySites) et la CentralAdmin sont encore en NTLM.
=> Faut-il permettre quelque part au "compte d'accès de la recherche"
de s'authentifier en Kerberos, ou est-il censé le faire nativement ?
=> Plus généralement, recommandez vous d'activer Kerberos sur toutes
les webapps, y compris spécifiques MOSS (SharedServices,
CentralAdmin) ? Dans ce cas, cela m'imposerait des host headers, vu
que les SPN ne tiennent pas compte du port...
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
-- Cordialement
Romelard Fabrice [MVP]
"TG2K" a écrit dans le message de groupe de discussion :
Bonjour,
J'ai configuré Kerberos avec succès pour mon portail d'utilisateurs, essentiellement pour pouvoir utiliser la "visionneuse RSS" pointant vers des sources internes MOSS. Tout va bien merci :)
Par contre, je soupçonne des effets de bord sur le moteur de recherche, en effet, seul mon portail est configuré en Kerberos: les SharedServices (dont MySites) et la CentralAdmin sont encore en NTLM.
=> Faut-il permettre quelque part au "compte d'accès de la recherche" de s'authentifier en Kerberos, ou est-il censé le faire nativement ?
=> Plus généralement, recommandez vous d'activer Kerberos sur toutes les webapps, y compris spécifiques MOSS (SharedServices, CentralAdmin) ? Dans ce cas, cela m'imposerait des host headers, vu que les SPN ne tiennent pas compte du port...
Merci pour vos retours d'expérience sur ce sujet.
TG2K
Bonjour,
On 4 oct, 10:38, "Romelard Fabrice [MVP]" wrote:
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les Identités d'application pools ne sont pas les mêmes, et l'URL est commune...
Je détaille pour ceux que l'expérience Kerberos intéresse: Exemple: POOLS: 1-CentralAdminAppPool: MondomaineMoncompteAdmin 2-SharedServicesAppPool: MondomaineMoncompteSHS 3-MySitesAppPool:MondomaineMoncompteSHS 4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même hostname, des ports différents, et des identités différentes. Il faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car un SPN ne tient pas compte du port: SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les identités, dans l'AD, en "Trusted for Delegation" dans l'onglet Delegation, qui apparaît une fois les SPN associés, et à faire de la constrained delegation pour que n'importe qui ne discute pas avec n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai beaucoup d'events indiquant un échec d'authentification *NTLM* du compte de recherche sur mon portail en *Kerberos*... A croire que le crawler ne tient pas compte du mode d'authentification proposé, ou que le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le troubleshooting :-)
Bonjour,
On 4 oct, 10:38, "Romelard Fabrice [MVP]" <fromel...@hotmail.com>
wrote:
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les
Identités d'application pools ne sont pas les mêmes, et l'URL est
commune...
Je détaille pour ceux que l'expérience Kerberos intéresse:
Exemple:
POOLS:
1-CentralAdminAppPool: MondomaineMoncompteAdmin
2-SharedServicesAppPool: MondomaineMoncompteSHS
3-MySitesAppPool:MondomaineMoncompteSHS
4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même
hostname, des ports différents, et des identités différentes. Il
faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car
un SPN ne tient pas compte du port:
SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les
identités, dans l'AD, en "Trusted for Delegation" dans l'onglet
Delegation, qui apparaît une fois les SPN associés, et à faire de la
constrained delegation pour que n'importe qui ne discute pas avec
n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une
identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le
SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes
nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai
beaucoup d'events indiquant un échec d'authentification *NTLM* du
compte de recherche sur mon portail en *Kerberos*... A croire que le
crawler ne tient pas compte du mode d'authentification proposé, ou que
le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos
échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le
troubleshooting :-)
A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les Identités d'application pools ne sont pas les mêmes, et l'URL est commune...
Je détaille pour ceux que l'expérience Kerberos intéresse: Exemple: POOLS: 1-CentralAdminAppPool: MondomaineMoncompteAdmin 2-SharedServicesAppPool: MondomaineMoncompteSHS 3-MySitesAppPool:MondomaineMoncompteSHS 4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même hostname, des ports différents, et des identités différentes. Il faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car un SPN ne tient pas compte du port: SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les identités, dans l'AD, en "Trusted for Delegation" dans l'onglet Delegation, qui apparaît une fois les SPN associés, et à faire de la constrained delegation pour que n'importe qui ne discute pas avec n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai beaucoup d'events indiquant un échec d'authentification *NTLM* du compte de recherche sur mon portail en *Kerberos*... A croire que le crawler ne tient pas compte du mode d'authentification proposé, ou que le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le troubleshooting :-)
Sébastien PICAMELOT
Lorsque Kerberos est configuré sur un site, tous les comptes y accédant doivent passer en Kerberos. Pour qu'un compte n'y parvienne pas lorsque Kerberos est bien configuré, c'est que le client tentant d'y accéder ne parvienne pas à utiliser Kerberos... auquel cas il passe en NTLM et on retouve une erreur dans l'EventLog. Quel est le compte utilisé pour l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environnement est-il en load balancing ? les setSPN ont-ils été fait sur le nom netbios et sur le FQDN ?
Je conseille aussi de passer toutes les WebApps en Kerberos (pour des raisons de performances et de sécurité). Dans ce cas en effet, il faudra définir des alias et des host headers, faire les setSPN qui vont bien et bien définir la délégation. De manière générale, Kerberos est indispensable à la bonne intégration d'outils tiers avec le portail (NTLM n'est pas toujours supporté).
On 4 oct, 10:38, "Romelard Fabrice [MVP]" wrote: > A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les Identités d'application pools ne sont pas les mêmes, et l'URL est commune...
Je détaille pour ceux que l'expérience Kerberos intéresse: Exemple: POOLS: 1-CentralAdminAppPool: MondomaineMoncompteAdmin 2-SharedServicesAppPool: MondomaineMoncompteSHS 3-MySitesAppPool:MondomaineMoncompteSHS 4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même hostname, des ports différents, et des identités différentes. Il faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car un SPN ne tient pas compte du port: SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les identités, dans l'AD, en "Trusted for Delegation" dans l'onglet Delegation, qui apparaît une fois les SPN associés, et à faire de la constrained delegation pour que n'importe qui ne discute pas avec n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai beaucoup d'events indiquant un échec d'authentification *NTLM* du compte de recherche sur mon portail en *Kerberos*... A croire que le crawler ne tient pas compte du mode d'authentification proposé, ou que le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le troubleshooting :-)
Lorsque Kerberos est configuré sur un site, tous les comptes y accédant
doivent passer en Kerberos. Pour qu'un compte n'y parvienne pas lorsque
Kerberos est bien configuré, c'est que le client tentant d'y accéder ne
parvienne pas à utiliser Kerberos... auquel cas il passe en NTLM et on
retouve une erreur dans l'EventLog. Quel est le compte utilisé pour
l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environnement
est-il en load balancing ? les setSPN ont-ils été fait sur le nom netbios et
sur le FQDN ?
Je conseille aussi de passer toutes les WebApps en Kerberos (pour des
raisons de performances et de sécurité). Dans ce cas en effet, il faudra
définir des alias et des host headers, faire les setSPN qui vont bien et bien
définir la délégation. De manière générale, Kerberos est indispensable à la
bonne intégration d'outils tiers avec le portail (NTLM n'est pas toujours
supporté).
On 4 oct, 10:38, "Romelard Fabrice [MVP]" <fromel...@hotmail.com>
wrote:
> A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les
Identités d'application pools ne sont pas les mêmes, et l'URL est
commune...
Je détaille pour ceux que l'expérience Kerberos intéresse:
Exemple:
POOLS:
1-CentralAdminAppPool: MondomaineMoncompteAdmin
2-SharedServicesAppPool: MondomaineMoncompteSHS
3-MySitesAppPool:MondomaineMoncompteSHS
4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même
hostname, des ports différents, et des identités différentes. Il
faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car
un SPN ne tient pas compte du port:
SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les
identités, dans l'AD, en "Trusted for Delegation" dans l'onglet
Delegation, qui apparaît une fois les SPN associés, et à faire de la
constrained delegation pour que n'importe qui ne discute pas avec
n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une
identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le
SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes
nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai
beaucoup d'events indiquant un échec d'authentification *NTLM* du
compte de recherche sur mon portail en *Kerberos*... A croire que le
crawler ne tient pas compte du mode d'authentification proposé, ou que
le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos
échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le
troubleshooting :-)
Lorsque Kerberos est configuré sur un site, tous les comptes y accédant doivent passer en Kerberos. Pour qu'un compte n'y parvienne pas lorsque Kerberos est bien configuré, c'est que le client tentant d'y accéder ne parvienne pas à utiliser Kerberos... auquel cas il passe en NTLM et on retouve une erreur dans l'EventLog. Quel est le compte utilisé pour l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environnement est-il en load balancing ? les setSPN ont-ils été fait sur le nom netbios et sur le FQDN ?
Je conseille aussi de passer toutes les WebApps en Kerberos (pour des raisons de performances et de sécurité). Dans ce cas en effet, il faudra définir des alias et des host headers, faire les setSPN qui vont bien et bien définir la délégation. De manière générale, Kerberos est indispensable à la bonne intégration d'outils tiers avec le portail (NTLM n'est pas toujours supporté).
On 4 oct, 10:38, "Romelard Fabrice [MVP]" wrote: > A mon sens Kerberos doit être mis en place sur toutes les WebApp.
C'est bien ce que je crains, mais cela devient très gênant car les Identités d'application pools ne sont pas les mêmes, et l'URL est commune...
Je détaille pour ceux que l'expérience Kerberos intéresse: Exemple: POOLS: 1-CentralAdminAppPool: MondomaineMoncompteAdmin 2-SharedServicesAppPool: MondomaineMoncompteSHS 3-MySitesAppPool:MondomaineMoncompteSHS 4-PortailAppPool: MondomaineMoncomptePortail
Comme on peut le constater, les webapps 1, 2 et 3 ont le même hostname, des ports différents, et des identités différentes. Il faudrait donc 3 SPN Kerberos (1 par identité)... mais impossible car un SPN ne tient pas compte du port: SETSPN -A http/monserveur MondomaineMoncompteAdmin
(pour la petite histoire, n'oubliez pas non plus de passer les identités, dans l'AD, en "Trusted for Delegation" dans l'onglet Delegation, qui apparaît une fois les SPN associés, et à faire de la constrained delegation pour que n'importe qui ne discute pas avec n'importe quoi).
Et bien sûr, il est interdit de définir le même SPN pour plus d'une identité simultanée.
Pour la 4e par contre pas de problème, puisque le hostname (et donc le SPN http/aliasDNSportail) est unique.
BREF: passer le tout en Kerberos pour des identités distinctes nécessite alors N alias différents, afin d'assurer l'unicité des SPN.
Le problème que j'évoquais dans mon premier message, c'est que j'ai beaucoup d'events indiquant un échec d'authentification *NTLM* du compte de recherche sur mon portail en *Kerberos*... A croire que le crawler ne tient pas compte du mode d'authentification proposé, ou que le portail refuse le NTLM, les deux m'étonnent (pour moi, si Kerberos échoue on passe en NTLM sans problème ???).
Merci , si cela peut déclencher des vocations pour m'aider dans le troubleshooting :-)
TG2K
Bonjour,
On 7 oct, 17:20, Sébastien PICAMELOT wrote:
auquel cas il passe en NTLM et on retouve une erreur dans l'EventLog. Quel est le compte utilisé pour l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environne ment est-il en load balancing ? les setSPN ont-ils été fait sur le nom net bios et sur le FQDN ?
Le compte d'accès au contenu pour l'indexation est un compte indépendant des autres. Il dispose des droits "lecture" portant sur la totalité des fonds (droits donnés automatiquement lorsque j'ai provisionné les WSS Search et Office Search).
Restrictions, pas à ma connaissance (rien de manuellement effectué en tout cas), si ce n'est que le compte n'est pas user ni admin local du front-end.
Load balancing... pas encore, mais j'ai vu pas mal de buzz sur le sujet avec Kerberos+MOSS. Mon dernier test en maquette a fonctionné ok (SPN ok, FQDN ok, etc.)
SetSPN en effet sur le nom court non pas netbios, mais alias DNS + sur le FQDN alias. Peut-être faut-il le faire aussi sur le nom netbios/ fqdn machine, c'est une piste (accès local au contenu, why not ?)
Merci !
Bonjour,
On 7 oct, 17:20, Sébastien PICAMELOT
<SbastienPICAME...@discussions.microsoft.com> wrote:
auquel cas il passe en NTLM et on
retouve une erreur dans l'EventLog. Quel est le compte utilisé pour
l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environne ment
est-il en load balancing ? les setSPN ont-ils été fait sur le nom net bios et
sur le FQDN ?
Le compte d'accès au contenu pour l'indexation est un compte
indépendant des autres. Il dispose des droits "lecture" portant sur la
totalité des fonds (droits donnés automatiquement lorsque j'ai
provisionné les WSS Search et Office Search).
Restrictions, pas à ma connaissance (rien de manuellement effectué en
tout cas), si ce n'est que le compte n'est pas user ni admin local du
front-end.
Load balancing... pas encore, mais j'ai vu pas mal de buzz sur le
sujet avec Kerberos+MOSS. Mon dernier test en maquette a fonctionné ok
(SPN ok, FQDN ok, etc.)
SetSPN en effet sur le nom court non pas netbios, mais alias DNS + sur
le FQDN alias. Peut-être faut-il le faire aussi sur le nom netbios/
fqdn machine, c'est une piste (accès local au contenu, why not ?)
auquel cas il passe en NTLM et on retouve une erreur dans l'EventLog. Quel est le compte utilisé pour l'indexation ? N'y a t-il pas de restrictions sur ce compte ? L'environne ment est-il en load balancing ? les setSPN ont-ils été fait sur le nom net bios et sur le FQDN ?
Le compte d'accès au contenu pour l'indexation est un compte indépendant des autres. Il dispose des droits "lecture" portant sur la totalité des fonds (droits donnés automatiquement lorsque j'ai provisionné les WSS Search et Office Search).
Restrictions, pas à ma connaissance (rien de manuellement effectué en tout cas), si ce n'est que le compte n'est pas user ni admin local du front-end.
Load balancing... pas encore, mais j'ai vu pas mal de buzz sur le sujet avec Kerberos+MOSS. Mon dernier test en maquette a fonctionné ok (SPN ok, FQDN ok, etc.)
SetSPN en effet sur le nom court non pas netbios, mais alias DNS + sur le FQDN alias. Peut-être faut-il le faire aussi sur le nom netbios/ fqdn machine, c'est une piste (accès local au contenu, why not ?)
