Vor kurzem habe ich an einem Projekt gearbeitet, bei dem der Kunde einige Benutzer hatte, die sich möglicherweise seit sechs Monaten oder länger nicht mehr in ihre Konten eingeloggt haben, aber die Unternehmensrichtlinie sah vor, Konten zu deaktivieren, die seit mehr als drei Monaten inaktiv waren.
Um diesen Benutzern die Anmeldung zu ermöglichen, brauchte man einen Mechanismus, mit dem die Benutzer die Konten selbst auf sichere Weise wieder aktivieren konnten. Um dieses Problem zu lösen, beschlossen wir, dass ein Benutzer, der die Sicherheitsfragen im Self-Service-Portal zum Zurücksetzen von Passwörtern erfolgreich beantwortet, nicht nur sein Passwort zurücksetzen können sollte, sondern dass diese Aktion das Konto im AD wieder aktivieren sollte.
Um dies zu erreichen, haben wir eine benutzerdefinierte Workflow-Aktivität geschrieben, die immer dann aufgerufen wird, wenn die Gate-Daten im Gate-Registrierungsobjekt geändert werden.
Der Entwurf der benutzerdefinierten Workflow-Aktivität sieht wie folgt aus:
Wenn ein Passwort zurückgesetzt wird, ist das Ziel der eingehenden Anfrage das Gate-Registrierungsobjekt. Dieses enthält einen Wert "UserID", der die Ressourcen-ID des Benutzers darstellt.
Um den Benutzer im AD über einen LDAP-Aufruf zu aktualisieren, benötigen wir den sAMAccountName des Benutzers. Die erste Leseaktivität dient also dazu, die UserID des Benutzers aus dem Gate-Registrierungsobjekt zu lesen, und diese wird an die zweite Leseaktivität weitergegeben, um den sAMAccountName des Benutzers zu ermitteln.
Hier ist der Code zum Abrufen der UserID:
In unserem System verfügt das Portalobjekt über ein Attribut "EmployeeStatus", mit dem wir prüfen können, ob ein Benutzer gekündigt wurde, bevor wir versuchen, den LDAP-Aufruf zur Aktualisierung des userAccountControl des Benutzers im AD zu tätigen.
Um den LDAP-Aufruf durchzuführen, verfügt diese Aktivität über konfigurierbare Eigenschaften für den LDAP-Pfad, den ADMA-Kontonamen und das verschlüsselte Passwort. Diese werden in dem LDAP-Aufruf wie folgt verwendet:
