Active Directory (AD) ist eine wichtige Funktion von Windows Server. Wenn ich mich recht zurückerinnere, wurde AD mit Windows 2000 eingeführt… AD ist ein Identity Management System, welches beispielsweise Single Sign On (SSO) ermöglicht und Zugriff auf Ressourcen steuert. AD vereinfacht und steuert somit die komplette Benutzerverwaltung und den Informationsaustausch, in großen wie in kleinen Unternehmen.
Moment, mein Unternehmens-AD läuft doch lokal, auf meinen eigenen Servern, oder?
Ja. In den meisten Fällen ist das so. Aber in vielen (fast allen Unternehmens-) Szenarien ist es erforderlich, sinnvoll oder einfach bequem, die eigene Identität zu verwenden, um einen Benutzer in Anwendungen oder Webs zu authentifizieren. Genau das ermöglicht Windows Azure Active Directory.
Damit funktioniert AD sozusagen in der Cloud! Windows Azure Active Directory ist ein stabiles Identity und Zugriffssteuerungs-System für Microsoft Office 365 und Windows Azure Applikationen. Es handelt sich dabei nicht um eine Kopie des eigenen AD, sondern es ist das eigene AD (das in die Cloud erweitert wird)!
Tipp: Weitere Informationen über AD in der Cloud sind in Reimagining Active Directory for the Social Enterprise (Part 1)und in Identity Management As A Service zu finden.
AD für andere Cloud-Services!
Die Microsoft Cloud Dienste Microsoft Office 365, Microsoft Dynamics CRM und Windows Intune arbeiten bereits mit Windows Azure Active Directory. Jedesmal, wenn beispielsweise eine neue Organisation in Office 365 angelegt wird, erstellt Microsoft ein neues Windows Azure Active Directory dafür. Dieses wird mit dem Account (der LiveId) verknüpft. Alle Office 365 Benutzer werden somit in dem AD angelegt und vordefinierten Rollen zugewiesen. Als Vorteil können alle Dienste in Office 365 – wie die Exchange Mailbox, SharePoint Online, Lync, etc. mit einem Benutzerkonto verwendet werden (“ease of use”).
Wenn ein Unternehmen sein eigenes AD betreibt, kann dieses mit der Cloud verbunden werden. Das erfolgt per Identity Federation und Directory Synchronisation. Solche Szenarien sind allerdings mit einigem Aufwand verbunden: Das AD muss vorbereitet und “sauber” sein, die Federation Server müssen redundant vorhanden sein und von der IT betrieben werden und natürlich benötigt man das entsprechende Know How für die Durchführung der Federation. Aus meiner Sicht bedarf es doch einer gewissen Unternehmensgröße, damit dieser Aufwand Sinn macht, das ist nichts für Firmen mit einer Handvoll Benutzern. Für Interessierte empfehle ich unser Schwesternblog blogs.technet.com/austria mit einer Vielzahl an Artikeln über Office 365 und Federation von Office 365 MVP Martina Grom.
Und zurück zu Azure.
Windows Azure Active Directory dient vor allem zur Verwendung von SSO und “shared context” von Applikationen. Das Azure AD bietet Software Developern die Möglichkeit, all diese Funktionen in eigenen Applikationen zu nutzen.
Hierfür möchte ich auch auf einen coolen Artikel von Max Knor hier im Blog verweisen, wo sehr schön erklärt wird, wie man selbst SSO mit Azure Access Control Service (ACS) verwenden kann:
Single-Sign on mit Facebook, Live ID, Google ID,... für die eigene Webseite mit Azure Access Con
ACS ist ein Feature von Windows Azure Active Directory. Windows Azure Active Directory baut auf Industrie-Standards auf und ermöglicht OAuth 2.0, WS-Trust, WS-Federation protocols und SAML 1.1, SAML 2.0, sowie Simple Web Token (SWT) token formats. ACS ist in den Azure Subscription-Angeboten und in den Pay-As-You-Go Angeboten enthalten (siehe Pricing and Metering for Access Control service).
Die Ankündigung zu Windows Azure Active Directory findet ihr im Windows Azure Blog:
Reimagining Active Directory for the Social Enterprise (Part 1)
Teil 2 (noch nicht erschienen) wird dann auf das How To für Developer eingehen – stay tuned!
PS: Viel Know How und Code gibt es bereits in Social.TechNet:
Windows Azure Active Directory Solutions For Developers
Autor: Toni Pohl