Kürzlich habe ich an einer kundenspezifischen Lösung für das Zurücksetzen von Passwörtern (SSPR) gearbeitet, die FIM 2010 R2 nutzt. Die SSPR-Funktionalität, die von FIM 2010 R2 standardmäßig bereitgestellt wird, ist recht umfassend. In den Entwurfssitzungen mit dem Kunden entschied dieser, dass er eine höhere Sicherheitsstufe für Benutzer im Internet verwenden wollte, um ihre Passwörter zurücksetzen zu können. Dies ist sicherlich sinnvoll - eine Schnittstelle, über die Unternehmensbenutzer ihre Passwörter zurücksetzen können, ist ein Segen für den Service Desk, führt aber eine erhebliche Bedrohungsfläche und ein damit verbundenes Sicherheitsrisiko ein.
Wir müssen sicherstellen, dass es sich bei der Person, die das Passwort zurücksetzt, tatsächlich um den Benutzer handelt und nicht um eine böswillige Person oder einen Agenten. Die primäre Authentifizierungsmethode für das Zurücksetzen besteht darin, dass der Benutzer eine Reihe von Fragen beantwortet, auf die nur er die Antwort kennt. Diese Methode wird heutzutage recht häufig verwendet. Damit wird jedoch nur ein Authentifizierungsmechanismus (ein so genannter "Faktor") erfüllt, den der Benutzer kennt. Eine höhere Sicherheit wird erreicht, wenn ein weiterer Faktor hinzugefügt wird: z. B. etwas (Physisches), das der Benutzer in seinem Besitz hat.
Eine ähnliche, aber nicht unbedingt eine Zwei-Faktor-Methode besteht darin, einen "Out-of-Band"-Kanal zu nutzen, um einen Code an den Benutzer zu senden, den er nur einmal, nämlich beim Zurücksetzen des Passworts, eingeben muss. Es überrascht nicht, dass dies als One-Time-Passwort (OTP) bezeichnet wird. Ein naheliegender und bei weitem gängigster Kanal ist das Senden dieses Einmalpassworts an die persönliche E-Mail-Adresse des Benutzers. (Man könnte den "Besitz" einer separaten E-Mail-Adresse und den Zugang zu ihr alszweiten Faktor betrachten, aber das ist nicht dasselbe wie der Besitz einer physischen Smartcard, eines Schlüsselanhängers oder eines Dongles.) Das Mobiltelefon eines Benutzers ist jedoch definitiv ein physischer Faktor, den der Benutzer vermutlich in seinem Besitz behält.
Glücklicherweise ist die SSPR-Funktion von FIM in der Lage, ein OTP zu senden, und kann es auf verschiedene Arten über einen benutzerdefinierten Erweiterungscode senden. Benutzer können ein Einmalpasswort entweder über eine alternative E-Mail-Adresse oder über eine SMS-Nachricht angefordert werden. Wir haben uns für die Textnachricht entschieden, weil sie für das Unternehmen die beste Wahl war.
Wie kann FIM also SMS-Nachrichten versenden? Nun, wir brauchen einen SMS-Dienstanbieter, der die Nachrichten empfangen und entsprechend weiterleiten kann. Ein solcher internetbasierter Anbieter ist Twilio. Twilio bietet einen RESTful-Webdienst und eine veröffentlichte API, die eine einfache Integration in Anwendungen ermöglicht. Ich war sehr beeindruckt von der Einfachheit und Leistung ihrer SMS-API. Auch die Preisgestaltung ist sehr attraktiv. Das würde den Rahmen dieses Beitrags sprengen, aber ich wage zu behaupten, dass es sich jedes Unternehmen dieser Größe leisten kann.
Wie funktioniert das nun mit FIM? Nun, FIM bietet eine Schnittstelle über die in FIM enthaltene Baugruppe Microsoft.IdentityManagement.SmsServiceProviderContract. Der Prozess wird in diesem TechNet-Artikel beschrieben.
Werfen wir also einen Blick auf ein Beispiel für die Verwendung der Twilio-API:
mit Twilio;
Klasse Beispiel
{
static void Main(string[] args)
{
// your Account Sid and Auth Token are found in your account information online
string AccountSid = " BD7eb96075d6bf7377c05f8bcf25a5294b";
string AuthToken = "";
var twilio = new TwilioRestClient(AccountSid, AuthToken);
var message = twilio.SendMessage(“+14158141829”, “+15558675309”, “Jenny please?! I love you <3”, newstring[] {“https://www.example.com/hearts.png”});
Console.WriteLine(Nachricht.Sid);
}
}
Es ist wirklich so einfach, und das ist einer der Gründe, warum wir uns für Twilio und nicht für mehrere andere Optionen entschieden haben.
Für FIM SSPR müssen wir also die SmsServiceProvider dll erstellen, die FIM verwenden und diese API nutzen wird. Der entsprechende Code sieht in etwa so aus:
mit Microsoft.IdentityManagement.SmsServiceProvider;
mit Twilio;
public class SmsServiceProvider : ISmsServiceProvider
{
public void SendSms(string mobileNumber,
string message,
Guid requestId,
Dictionary<string, object> deliveryAttributes)
{
mySMSProvider.SendSms(mobileNummer, Nachricht);
}
}
Klasse mySMSProvider
{
static string AccountSid = "BD7eb96075d6bf7377c05f8bcf25a5294b";
static string AuthToken = "58a93f5d342e842dc572ab131af83757";
mySMSProvider()
{
}
public static int SendSms(string userMobileNumber, string message)
{
Int32 Ergebnis;
String-Fehler;
// instantiate a new Twilio Rest Client
var client = new TwilioRestClient(AccountSid, AuthToken);
var transaction = client.SendMessage(
"678-967-4113", // "Von"-Nummer, muss eine SMS-fähige Twilio-Nummer sein
userMobileNumber, // "To"-Nummer, bei Verwendung von Sandbox siehe Hinweis oben
// message content, passed in as a parameter from FIM
Nachricht);
}
...
Außerdem müssen wir einen Workflow zum Zurücksetzen des Kennworts erstellen, der das OTP-Gate verwendet, und natürlich einige andere Konfigurationsdetails behandeln.
Wir wissen, dass es angesichts der Raffinesse automatisierter Angriffe, der Techniken zum Knacken von Passwörtern und der Häufigkeit solcher Angriffe auf hochrangige Ziele für eine Organisation wichtiger denn je ist, effiziente Abläufe mit angemessenen Sicherheitsmaßnahmen in Einklang zu bringen. Die Häufigkeit der Sicherheitsverletzungen, die in letzter Zeit zu beobachten waren, verdeutlicht die Notwendigkeit einer starken Authentifizierung, z. B. durch Einmalpasswörter in SSPR.
