WSS 3.0 : Quel active directory donne ses informations à WSS
4 réponses
Java
Bonjour,
Un de mes clients a un active directory "racine", p.ex. ABC et des
directory "fils", p.ex. CH.ABC (d=E9sol=E9, je ne connais pas les termes
"officiels")
Le probl=E8me est que les utilisateurs d=E9finis dans CH.ABC ont bien une
adresse mail dans leur profil mais lorsqu'on les d=E9clare dans WSS:
1- avec la fonction de recherche de WSS depuis la case d'ajout
d'utilisateur (le bouton avec le petit livre), sharepoint ne les
trouve pas
2- si on tape directement leur login (p.ex. bob.sinclar) dans l'ajout
d'utilisateurs, WSS le retrouve bien dans l'AD et les montre avec leur
login compl=E9t=E9 du domaine
3- il les rapatrie bien et les gpre ensuite correctement mais ne
rapatrie PAS les adresses mails.
Comment peut-on savoir vers quel serveur AD sharepoint va chercher ces
informations ?
Comment le pr=E9ciser/modifier ?
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
Lognoul, Marc \(Private\)
Bonjour,
"Java" wrote in message news:
Bonjour, Un de mes clients a un active directory "racine", p.ex. ABC et des directory "fils", p.ex. CH.ABC (désolé, je ne connais pas les termes "officiels")
Le problème est que les utilisateurs définis dans CH.ABC ont bien une adresse mail dans leur profil mais lorsqu'on les déclare dans WSS: 1- avec la fonction de recherche de WSS depuis la case d'ajout d'utilisateur (le bouton avec le petit livre), sharepoint ne les trouve pas
En théorie, cela devrait fonctionner. Le "people picker" devrait fonctionner sans limitation dans la même forêt. Toutefois j'ai remarqué que: - Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité - Si ce n'est pas un problème de "trust", un hardening "trop" poussé d'AD peut également bloquer ces requête - Cela peut également résulter d'un problème de résolution des nom DNS pour trouver le domaine et un DC de ce domaine (NSLOOKUP à partir du serveur WFE) - Enfin, dans certains cas, je n'ai pas eu d'autres chois que utiliser la commande suivante pour solutionner: STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv <domain(s)/forests(s)> -url http://<webapp> . <domain(s)/forests(s)> étant une liste de Domaines AD (noms DNS) séparés par des ";". Exemples: STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:foo.corp.com;domain:bar.foo.corp.com" -url http://monportal. Ne pas oublier de référencer le domaine original.
2- si on tape directement leur login (p.ex. bob.sinclar) dans l'ajout d'utilisateurs, WSS le retrouve bien dans l'AD et les montre avec leur login complété du domaine
En effet, la méthode pour résoudre un nom dans ce semble différente de celles du "people picker" (Trace réseau à l'appui). Mais je n'ai jamais eu l'occasion de pousser l'investigation jusqu'à trouver les raison exacte.
3- il les rapatrie bien et les gpre ensuite correctement mais ne rapatrie PAS les adresses mails.
En effet, il faut passer par la méthode 1. ou par MOSS et la fonctionnalité d'importation de profile pour y pallier. Je n'ai à ce jour pas trouvé d'autre solution.
... Mais je suis très intéressé par votre feedback.
Marc
Bonjour,
"Java" <gilbert.nicolet@blancconsultants.com> wrote in message
news:467cda10-bbc1-4723-a892-cca16b84a67c@p25g2000hsf.googlegroups.com...
Bonjour,
Un de mes clients a un active directory "racine", p.ex. ABC et des
directory "fils", p.ex. CH.ABC (désolé, je ne connais pas les termes
"officiels")
Le problème est que les utilisateurs définis dans CH.ABC ont bien une
adresse mail dans leur profil mais lorsqu'on les déclare dans WSS:
1- avec la fonction de recherche de WSS depuis la case d'ajout
d'utilisateur (le bouton avec le petit livre), sharepoint ne les
trouve pas
En théorie, cela devrait fonctionner. Le "people picker" devrait fonctionner
sans limitation dans la même forêt. Toutefois j'ai remarqué que:
- Etant donné que c'est avec identité de l'application pool de l'application
qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent
survenir et bloquer cette fonctionnalité
- Si ce n'est pas un problème de "trust", un hardening "trop" poussé d'AD
peut également bloquer ces requête
- Cela peut également résulter d'un problème de résolution des nom DNS pour
trouver le domaine et un DC de ce domaine (NSLOOKUP à partir du serveur WFE)
- Enfin, dans certains cas, je n'ai pas eu d'autres chois que utiliser la
commande suivante pour solutionner:
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv
<domain(s)/forests(s)> -url http://<webapp> . <domain(s)/forests(s)> étant
une liste de Domaines AD (noms DNS) séparés par des ";". Exemples:
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv
"forest:foo.corp.com;domain:bar.foo.corp.com" -url http://monportal. Ne pas
oublier de référencer le domaine original.
2- si on tape directement leur login (p.ex. bob.sinclar) dans l'ajout
d'utilisateurs, WSS le retrouve bien dans l'AD et les montre avec leur
login complété du domaine
En effet, la méthode pour résoudre un nom dans ce semble différente de
celles du "people picker" (Trace réseau à l'appui). Mais je n'ai jamais eu
l'occasion de pousser l'investigation jusqu'à trouver les raison exacte.
3- il les rapatrie bien et les gpre ensuite correctement mais ne
rapatrie PAS les adresses mails.
En effet, il faut passer par la méthode 1. ou par MOSS et la fonctionnalité
d'importation de profile pour y pallier. Je n'ai à ce jour pas trouvé
d'autre solution.
... Mais je suis très intéressé par votre feedback.
Bonjour, Un de mes clients a un active directory "racine", p.ex. ABC et des directory "fils", p.ex. CH.ABC (désolé, je ne connais pas les termes "officiels")
Le problème est que les utilisateurs définis dans CH.ABC ont bien une adresse mail dans leur profil mais lorsqu'on les déclare dans WSS: 1- avec la fonction de recherche de WSS depuis la case d'ajout d'utilisateur (le bouton avec le petit livre), sharepoint ne les trouve pas
En théorie, cela devrait fonctionner. Le "people picker" devrait fonctionner sans limitation dans la même forêt. Toutefois j'ai remarqué que: - Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité - Si ce n'est pas un problème de "trust", un hardening "trop" poussé d'AD peut également bloquer ces requête - Cela peut également résulter d'un problème de résolution des nom DNS pour trouver le domaine et un DC de ce domaine (NSLOOKUP à partir du serveur WFE) - Enfin, dans certains cas, je n'ai pas eu d'autres chois que utiliser la commande suivante pour solutionner: STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv <domain(s)/forests(s)> -url http://<webapp> . <domain(s)/forests(s)> étant une liste de Domaines AD (noms DNS) séparés par des ";". Exemples: STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:foo.corp.com;domain:bar.foo.corp.com" -url http://monportal. Ne pas oublier de référencer le domaine original.
2- si on tape directement leur login (p.ex. bob.sinclar) dans l'ajout d'utilisateurs, WSS le retrouve bien dans l'AD et les montre avec leur login complété du domaine
En effet, la méthode pour résoudre un nom dans ce semble différente de celles du "people picker" (Trace réseau à l'appui). Mais je n'ai jamais eu l'occasion de pousser l'investigation jusqu'à trouver les raison exacte.
3- il les rapatrie bien et les gpre ensuite correctement mais ne rapatrie PAS les adresses mails.
En effet, il faut passer par la méthode 1. ou par MOSS et la fonctionnalité d'importation de profile pour y pallier. Je n'ai à ce jour pas trouvé d'autre solution.
... Mais je suis très intéressé par votre feedback.
Marc
Java
Merci. Je vais voir tout cela et te donne un feed-back !
Merci.
Je vais voir tout cela et te donne un feed-back !
Merci. Je vais voir tout cela et te donne un feed-back !
Java
Voilà, ça marche. Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
MERCI !
Voilà, ça marche.
Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de
l'application
qu'il s'authentifie vers les autres domaines des problèmes de trust
peuvent
survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
Voilà, ça marche. Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
MERCI !
Lognoul, Marc \(Private\)
Merci à toi pour le feedback.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses]
"Java" wrote in message news:
Voilà, ça marche. Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
MERCI !
Merci à toi pour le feedback.
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
"Java" <gilbert.nicolet@blancconsultants.com> wrote in message
news:7c82cfa5-aa60-4ef5-b299-c0c892851d67@f36g2000hsa.googlegroups.com...
Voilà, ça marche.
Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de
l'application
qu'il s'authentifie vers les autres domaines des problèmes de trust
peuvent
survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses]
"Java" wrote in message news:
Voilà, ça marche. Tu avais bien trouvé le problème:
- Etant donné que c'est avec identité de l'application pool de l'application qu'il s'authentifie vers les autres domaines des problèmes de trust peuvent survenir et bloquer cette fonctionnalité
Nous avons augmenté les droits de ce compte et ça fonctionne impecc !!
