SharePoint (WSS), l'Authentification dans Plusieurs Domaines

Tout d'abord, un petit retour en arrière: Nous avons un site intranet basé sur WSS 3.0 qui est hébergé sur un serveur dans DOMAIN_A.LOCAL et configuré pour utiliser l'Authentification Windows Intégrée pour authentifier les utilisateurs à l'encontre de comptes d'utilisateur Active Directory de DOMAIN_A.LOCAL.

Cette configuration fonctionne très bien pour les utilisateurs qui sont connectés à Windows à l'aide d'un compte d'ANNONCE de DOMAIN_A.LOCAL, mais lorsque les utilisateurs tentent d'accéder au site à partir d'un PC connecté à Windows en utilisant un compte active directory à partir d'un autre domaine (c'est à dire DOMAIN_B.LOCAL), les problèmes suivants se produisent:

L'utilisateur doit manuellement entrer leurs informations d'identification en tant que DOMAIN_A\nom d'utilisateur plutôt que de simplement nom d'utilisateur parce que sinon, Internet Explorer insère automatiquement DOMAIN_B et les causes d'échec de l'authentification.
Une fois connecté, si l'utilisateur fait quelque chose qui nécessite le navigateur pour passer leur authentification par le biais d'une application cliente, comme le clic sur un document Microsoft Office dans une bibliothèque de documents afin de l'ouvrir pour le modifier, il apparaît que les informations d'identification non valides (sans doute DOMAIN_B) sont transmis automatiquement, le contraignant ainsi à l'utilisateur de saisir manuellement leurs DOMAIN_A informations d'identification.

Ma question, est-ce:

Est-il possible de mettre en œuvre un "domaine par défaut" type de comportement lors de l'utilisation de l'Authentification Windows Intégrée (de la même manière que lors de l'utilisation de Base de l'authentification en texte clair), de sorte que si un utilisateur sur DOMAIN_B ne pas entrer dans un domaine avant de leur nom d'utilisateur, DOMAIN_A est inséré automatiquement pour eux?

Bien sûr, je me rends compte de ce déploiement peut être viciée, donc je suis également ouvert à toutes les suggestions pour une mise en œuvre différente.

En résumé, le principal problème provient de deux types différents d'utilisateurs ayant besoin d'accéder au même contenu sur un site SharePoint. Les utilisateurs DOMAIN_A tous ont leur propre temps plein postes de travail où ils se connectent à Windows en tant qu'eux-mêmes. Les utilisateurs DOMAIN_B malheureusement pour utiliser les ordinateurs qui sont connectés à l'aide de générique de "kiosque" type de comptes qui n'ont pas d'autorisations dans SharePoint -- ainsi, l'exigence que le DOMAIN_B les utilisateurs doivent fournir leurs informations d'identification sur demande lors de l'accès à une page donnée dans SharePoint. Je tiens à préserver la commodité de l'Authentification Windows Intégrée pour le "statique" des utilisateurs de DOMAIN_A tout en minimisant la quantité de manuel d'authentification que le "kiosque" utilisateurs DOMAIN_B avoir à endurer.

OriginalL'auteur Tim Lara | 2009-04-20

4

DOMAIN_A.LOCAL doit faire confiance à DOMAIN_B.LOCAL, sinon les utilisateurs de DOMAIN_B.LOCAL sera receivie invite d'informations d'identification depuis leur DOMAIN_B.LOCAL compte est inconnu dans DOMAIN_A.LOCAL.

Étant donné que DOMAIN_B.LOCAL est pour kisok les utilisateurs, vous ne voulez probablement pas à faire confiance à ce domaine.

Vous aurez besoin d'étendre l'application web dans une nouvelle zone et à les mettre en œuvre authentification basée sur les formulaires, ou utiliser l'Authentification Windows avec un serveur proxy inverse comme ISA server.

L'autre raison, je ne peux pas résoudre le problème en faisant confiance à la DOMAIN_B, c'est que ces comptes n'ont pas d'autorisations dans SharePoint. Le DOMAIN_B comptes sont juste génériques connexions qui permettent d'identifier le kiosque de la station de travail, mais pas les utilisateurs individuels. Lorsque vous suggérons d'étendre l'application dans une nouvelle zone, voulez-vous dire qu'il est possible d'avoir le même contenu utiliser différentes méthodes d'authentification via zones distinctes? Si oui, c'est peut être juste ce dont j'ai besoin...
Oui, c'est exactement ce que je veux dire. Voici l'article technet sur les zones de planification, et de la façon de les étendre et de les publier avec ISA: technet.microsoft.com/en-us/library/cc288609.aspx
Merci, Jason-C'est juste ce dont j'avais besoin. Je vais tester cette config maintenant.

OriginalL'auteur shufler
2

J'étais à la recherche de l'internet pour les comptes d'utilisateurs SharePoint avec plusieurs domaines et suis tombé sur un outil intéressant appelé Microsoft Avant la Fin Identity Manager. Avez-vous entendu parler?

... Donc Si votre utilisation d'un multi forêt de déploiement où les comptes d'utilisateur sont répartis sur deux ou plus de forêts. C'est souvent lorsque deux organisations de fusion et ont besoin d'accéder à des domaines de ces deux organisations. Vous pouvez utiliser le nom unique (ms-ds-Source-Objet-DN) de l'attribut dans l'objet utilisateur à créer une association entre les comptes d'utilisateur. Dans cette association, un compte est considéré comme le compte principal et les autres sont les suppléants du compte principal. Il existe un outil appelé Microsoft Avant la Fin Identity Manager pour créer cette relation entre les objets de compte d'utilisateur. Une fonctionnalité de Microsoft Avant la Fin de l'Identité du Gestionnaire, SharePoint server peut maintenir une liste d'autres comptes par lequel le profil est identifié. Lorsque vous utilisez un compte afin de trouver le profil d'un utilisateur, SharePoint server renvoie la primaire profil de compte de l'exemple (domaine\nom d'utilisateur).

OriginalL'auteur Todd
0

Probablement pas ce que vous voulez entendre, mais vous pouvez recourir à l'authentification basée sur les formulaires.

Oui, il est possible que. Le compromis, bien sûr, serait que le flux de travail serait moins pratique pour le DOMAIN_A utilisateurs, mais au moins tout devrait fonctionner pour tout le monde.

OriginalL'auteur Kirk Liemohn
0

Malheureusement, si vous souhaitez conserver l'intégration de Microsoft Office (qui est ce qu'il semble que vous voulez), vous devez coller avec l'Authentification Windows. À l'aide de l'Authentification par Formulaires permet d'enlever la plupart des fonctionnalités que vous semblez soucieux de les préserver, il n'y a plus d'informations ici.

Idéalement, vous voulez utiliser la suggestion que Jason a mentionné, qui serait une sorte de reverse proxy. Cependant, il n'y aurait probablement un coût implication si vous ne l'avez pas déjà quelque chose comme ISA server, donc en réalité, il est probablement le meilleur pour la DOMAIN_B pour apprendre à taper DOMAIN_B\ avant de leur nom d'utilisateur.

Vous pouvez toujours obtenir beaucoup (la plupart?) de l'Office des fonctionnalités d'intégration avec FBA. Il ya quelques mises en garde, comme vous devez vous connecter avec l'authentification par formulaire et l'avoir rappeler qui vous êtes (stocker le cookie) peut être utilisé par les applications Office.
En fait, quand je suis allé à regarder pour vérifier les choses, j'ai réalisé que je n'avais pas expliqué correctement. Vous avez évidemment raison sur FBA, c'est juste le commutateur de FBA de WA désactive l'intégration du client, qui peut être tourné le dos par la suite.

OriginalL'auteur Joe Swan

Vous devez vous connecter pour publier un commentaire.