Exceptionfault

In größeren Firmen mit komplexen Netzwerkinfrastrukturen ist das ActiveDirectory nicht wegzudenken. Oftmals sind sogar mehr als nur eine Domain vorzufinden. So auch in meiner Firma, die für jedes Land in dem die Firma vertreten ist eine eigene Domain aufgebaut hat. Eine alltägliche Anforderung an Entwickler ist daher eine Authentifizierung der Benutzer über das ActiveDirectory der entsprechenden Domain.

Mit keiner Programmiersprache sollte dies leichter sein als mit .NET. So dachten wir zumindest als wir uns den ActiveDirectoryMembershipProvider näher ansahen. Allein die Methode ValidateUser sollte uns genügen und als Einzeiler viele Sorgen ersparen, doch…

So ein bisschen Konfigurationsarbeit ist selbstverständlich notwendig und so erweitert man die app.conf Datei kurzerhand um einen ConnectionString und einen Provider.

<configuration>
<connectionStrings>
<add name="ADService" connectionString="LDAP://ldapServer/" />
</connectionStrings>
<system.web>
<membership defaultProvider="AspNetActiveDirectoryMembershipProvider">
<providers>
<add name="AspNetActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider,
System.Web, Version=2.0.3600, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
</system.web>
</configuration>

Zunächst ist die Begeisterung groß, denn im Code genügt tatsächlich eine einzelne Zeilt zur Authentifizierung eines Benutzers:

IF Membership.ValidateUser( "username", "password", "domain" ) = true THEN

Ungeschickt ist nur, dass am Provider ein fester ConnectionString hängt, der wiederum auf einen fixen DomainController zeigt. Alle Versuche den ConnectionString zur Laufzeit z.B. von “de.firma.net” zu “gb.firma.net” zu ändern scheiterten kläglich.

Der Vorschlag von Microsoft: Für jede Domain einen eigenen Provider mit einem eigenen ConnectionString anlegen. Nagut, das ist nicht schön und bedeutet bei einem neuen Land einen internationalen Rollout der neuen App.config. Der jeweilige Provider benötigt dann einen generischen Namen, der irgendwie die Domain enthält und der somit dynamisch aus der Applikation angesprochen werden kann.

In unserer App.config befanden sich nun also ca. 30 MembershipProvider und 30 unterschiedliche ConnectionStrings. Leider tat dies allerdings unserem Login Dialog nicht gut. Beim ersten Versuch auf die Provider Collection der Membership Klasse zuzugreifen wurden offenbar alle aufgelisteten Provider initialisiert. Noch viel schlimmer: .NET versuchte eine Verbindung über jeden einzelnen ConnectionString herzustellen. In unserem Fall bedeutet dies, dass sicher der Client an den Primary Domaincontroller jedes Landes verbinden wollte was letztendlich zu einem Timeout führte.

Somit ist der MembershipProvider für uns leider gestorben, kopfschüttelnd über so manche “Features” die uns Microsoft anbietet.