2010-05-28 7 views
3

J'utilise le fournisseur d'appartenances Active Directory avec la configuration suivante:Authentifier à plusieurs unités d'organisation dans Active Directory

<connectionStrings> 
     <add name="MyConnString" connectionString="LDAP://domaincontroller/OU=Product Users,DC=my,DC=domain,DC=com" /> 
    </connectionStrings> 

    <membership defaultProvider="MyProvider"> 
    <providers> 
     <clear /> 
     <add name="MyProvider" connectionStringName="MyConnString" 
      connectionUsername="my.domain.com\service_account" 
      connectionPassword="biguglypassword" 
      type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
    </providers> 
    </membership> 

Cela fonctionne parfaitement, sauf qu'il exige que tous mes utilisateurs d'être dans les « utilisateurs du produit » OU quand j'aimerais réellement que tous mes utilisateurs soient organisés en plusieurs unités d'organisation enfants sous notre unité d'organisation "Product Users". Est-ce possible?

(Notez que ceci est une republication partielle de this question, mais la question que je pose ici n'a jamais été répondue.)

+0

Cela ne répond pas à votre question, mais envisagez-vous de le faire par programme? –

+0

@Rising Star: Vous voulez créer N connexions LDAP différentes et faire une boucle sur chacune d'elles pour valider un utilisateur? Cela semble/semble être une mauvaise idée. Mais non, je n'ai pas essayé ça. – Jaxidian

+0

Intéressant. Je ne l'ai pas essayé mais MSDN http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx dit qu'il devrait inclure tous les utilisateurs sous l'OU. –

Répondre

1

authentification contre AD se fait fonction de la portée de connexion que j'undetstand il. Essentiellement ce que cela signifie est que everyhting dans le contexte de la chaîne de connexion est considérée comme ...

si vous avez votre connexion comme:

LDAP: // domaincontroller/OU = Utilisateurs de domaine, DC = my, DC = domaine, DC = com

tout utilisateur sera alors authentifié qui est un membre du domaine.

à partir de là, vous devez ajouter le fournisseur de rôle basé sur les jetons Windows et configurer quelque chose comme ça ...

<!-- use windows authentication --> 
<authentication mode="Windows" /> 

<!-- use the Windows role provider -->  
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" /> 

<!-- global authorization rules --> 
<authorization> 
    <allow roles="Domain Admins, Product Users"/> 
    <deny users="*" /> 
</authorization> 

Ce verrouille l'application pour être uniquement utilisé par les administrateurs de domaine et les utilisateurs dans l'unité d'organisation « Les utilisateurs du produit "Et tous ses enfants récursivement. À partir de là, vous pouvez effectuer d'autres vérifications "contextuelles" pour d'autres fonctions, par ex. ...

If(User.IsInRole("Product Admins")) 
{ 
    // do something groovy 
} 
else 
    throw new SecurityException(); 

Qu'est-ce que cela signifie ...

Cela signifie que vous avez un contrôle précis à grain de la sécurité de votre logique applicative basée sur l'appartenance à un groupe d'utilisateurs de domaine, si un utilisateur est dans votre domaine ce les authentifiera, mais il ne les autorisera peut-être pas (ceci dépend de la configuration de votre fournisseur de rôle). Authentifier: Identifier l'utilisateur. Autoriser: accorder des autorisations/accès à l'utilisateur.

+0

"tout utilisateur sera alors authentifié membre du domaine" - ceci est incorrect. Cela authentifie uniquement les utilisateurs dans l'unité d'organisation "Utilisateurs du domaine". – Jaxidian

+0

Je pense que tous les utilisateurs sont pris en compte mais seuls les groupes/OU qui sont enfants de la portée de connexion peuvent être "vérifiés"/utilisés dans les règles d'évaluation de l'adhésion (je pense ... été un tout depuis que je l'ai fait) Il suffit de se connecter à la racine du répertoire LDAP du serveur d'annuaire pour éviter la confusion. – War

+0

L'utilisation de l'approche que j'ai suggérée ci-dessus empêchera tous les utilisateurs d'accepter ceux des rôles Admins du domaine et Utilisateurs du produit, tout le monde sera "authentifié" mais pas " autorisé "à utiliser l'application. – War