von Redaktion IT-A…
Lesezeit
2 Minuten
Azure AD Connect einrichten und betreiben (1)
Azure- und Office365-Angebote bieten sich an, um zusätzliche IT-Ressourcen aus der Cloud zu beziehen. Jedoch bleiben sensible Dienste wie das Active Directory meist am heimischen Campus. Aus diesem Grund kommt hybriden Szenarien große Bedeutung zu. In Bezug auf das Active Directory bedeutet dies, Objekte aus dem Verzeichnisdienst mit der Cloud zu synchronisieren. Azure AD Connect baut die Brücke zwischen lokaler IT und der Cloud. Im ersten Teil des Workshops gehen wir auf die Grundlagen von Azure AD Connect ein und erklären, welche Vorbereitungen Sie vor der ersten Synchronisation mit dem lokalen Directory treffen sollten.
Für Netzwerke egal welcher Größe ergibt es durchaus Sinn, den einen oder anderen Dienst in Richtung Azure oder Office 365 auszulagern. Die On-Premise-Landschaft, wie die lokale Infrastruktur im Microsoft-Jargon auch genannt wird, lässt sich dadurch erweitern. Und zumindest für diese Services sind dann die Zeiten von Hardwarebeschaffung und Ausbau des lokalen Rechenzentrums vorüber. Damit rücken aber andere Themen und Aspekte in den Fokus. Beispielsweise: Wie lassen sich in einem hybriden Szenario beide Welten verbinden? Diesbezüglich beschäftigen wir uns in diesem Beitrag mit Identitäten der Active Directory Domain Services (ADDS) und wie diese zu Office 365 gelangen, damit die Objekte in beiden Welten nutzbar sind.
Eigenes Active Directory für Office 365
Office 365 verwendet mit dem Azure Active Directory (Azure AD) einen eigenen Verzeichnisdienst, der dem lokalen Active Directory ähnelt. Jeder Benutzer, der Office 365 nutzt, benötigt ein Benutzerkonto in dem Cloud-Verzeichnisdienst. In kleineren Netzwerken ergibt es vielleicht noch Sinn, diese Benutzer von Hand anzulegen. Dies stößt aber in umfangreichen Umgebungen schnell an Grenzen. Das gilt auch dann, wenn der Administrator mehr Komfort für seine Anwender möchte. In diesem Zusammenhang tauchen immer wieder zwei Begriffe auf, die es zu unterscheiden gilt: "Same Sign-On" und "Single Sign-On".
Ersteres ist gemeint, wenn die Benutzer sich mit denselben Kontoinformationen in der Cloud anmelden wie im lokalen Netzwerk. Die Identitäten liegen dann quasi an zwei Orten. Bei Single Sign-On kommen die ADFS (Federation Services oder zu Deutsch: Verbunddienste) ins Spiel und der Zugriff der Anwender auf Office-365-Dienste vollzieht sich, bezogen auf die Authentifizierung, transparent. Egal, wie die Authentifizierung vonstattengeht, Benutzerkonten müssen immer im Azure AD vorliegen, nur so lassen sie sich lizensieren. Die Verbunddienste sind mittlerweile übrigens auch Teil des Installationspaketes von Azure AD Connect. Die sollen uns aber hier nicht weiter beschäftigen.
Automatisierung ist gefragt
Sie machen sich das Leben als Administrators deutlich leichter, wenn Sie das lokale AD mit dem Azure AD koppeln und über eine Synchronisation neu angelegte Benutzer turnusmäßig automatisch im Azure AD auftauchen. Änderungen und Löschungen werden natürlich genauso synchron gehalten. Microsoft bietet hier seit längerem ein Tool an, das bereits diverse Produktzyklen durchlaufen hat. Aktuell trägt es den Namen Azure AD Connect. Etwas verwirrend an dieser Stelle ist es, das Microsoft recht schnelle Produktwechsel vornahm beziehungsweise die Namen der Synchronisationstools häufig änderte.
Die erste Version hieß DirSync und wurde Ende 2014 durch den Nachfolger Azure AD Sync abgelöst. Knapp ein Jahr später war auch dieser wieder obsolet und Azure AD Connect war im Juni 2015 geboren, ohne das Microsoft das Rad der Synchronisation neu erfunden hat. Unter der Haube von Azure AD Connect läuft immer eine angepasste Version des Synchronisationsdienstes FIM (Forefront Identity Manager). Die Serverkomponente dürfte Ihnen bekannt vorkommen, sofern Sie in Ihrem lokalen AD Identitäten synchronisieren – zum Beispiel mit SQL-Datenbanken – oder zwischen AD-Strukturen, wenn Exchange in einem Ressource-Forest-Konstrukt zum Einsatz kommt.
Seite 1: Eigenes Active Directory für Office 365
Seite 2: Erst aufräumen, dann synchronisieren
dr/ln/Klaus Bierschenk
[1] www.microsoft.com/en-us/microsoft-365/enterprise-mobility-security
Eigenes Active Directory für Office 365
Office 365 verwendet mit dem Azure Active Directory (Azure AD) einen eigenen Verzeichnisdienst, der dem lokalen Active Directory ähnelt. Jeder Benutzer, der Office 365 nutzt, benötigt ein Benutzerkonto in dem Cloud-Verzeichnisdienst. In kleineren Netzwerken ergibt es vielleicht noch Sinn, diese Benutzer von Hand anzulegen. Dies stößt aber in umfangreichen Umgebungen schnell an Grenzen. Das gilt auch dann, wenn der Administrator mehr Komfort für seine Anwender möchte. In diesem Zusammenhang tauchen immer wieder zwei Begriffe auf, die es zu unterscheiden gilt: "Same Sign-On" und "Single Sign-On".
Ersteres ist gemeint, wenn die Benutzer sich mit denselben Kontoinformationen in der Cloud anmelden wie im lokalen Netzwerk. Die Identitäten liegen dann quasi an zwei Orten. Bei Single Sign-On kommen die ADFS (Federation Services oder zu Deutsch: Verbunddienste) ins Spiel und der Zugriff der Anwender auf Office-365-Dienste vollzieht sich, bezogen auf die Authentifizierung, transparent. Egal, wie die Authentifizierung vonstattengeht, Benutzerkonten müssen immer im Azure AD vorliegen, nur so lassen sie sich lizensieren. Die Verbunddienste sind mittlerweile übrigens auch Teil des Installationspaketes von Azure AD Connect. Die sollen uns aber hier nicht weiter beschäftigen.
Automatisierung ist gefragt
Sie machen sich das Leben als Administrators deutlich leichter, wenn Sie das lokale AD mit dem Azure AD koppeln und über eine Synchronisation neu angelegte Benutzer turnusmäßig automatisch im Azure AD auftauchen. Änderungen und Löschungen werden natürlich genauso synchron gehalten. Microsoft bietet hier seit längerem ein Tool an, das bereits diverse Produktzyklen durchlaufen hat. Aktuell trägt es den Namen Azure AD Connect. Etwas verwirrend an dieser Stelle ist es, das Microsoft recht schnelle Produktwechsel vornahm beziehungsweise die Namen der Synchronisationstools häufig änderte.
Die erste Version hieß DirSync und wurde Ende 2014 durch den Nachfolger Azure AD Sync abgelöst. Knapp ein Jahr später war auch dieser wieder obsolet und Azure AD Connect war im Juni 2015 geboren, ohne das Microsoft das Rad der Synchronisation neu erfunden hat. Unter der Haube von Azure AD Connect läuft immer eine angepasste Version des Synchronisationsdienstes FIM (Forefront Identity Manager). Die Serverkomponente dürfte Ihnen bekannt vorkommen, sofern Sie in Ihrem lokalen AD Identitäten synchronisieren – zum Beispiel mit SQL-Datenbanken – oder zwischen AD-Strukturen, wenn Exchange in einem Ressource-Forest-Konstrukt zum Einsatz kommt.
Auch hierbei macht der Microsoft-Wandel nicht Halt und FIM heißt seit geraumer Zeit MIM (Microsoft Identity Manager). Bei FIM beziehungsweise MIM handelt es sich um eine ganze Produktpalette [1]. Dies sei an dieser Stelle erwähnt, da sich in Bezug auf MIM die Synchronisation als Teil der Palette nicht wirklich geändert hat. In diversen Dokumentationen ist historisch bedingt immer noch von FIM die Rede. Diese Beschreibungen lassen sich für MIM gleichfalls umsetzen und somit in weiten Teilen auch für Azure AD Connect.
Seite 2: Erst aufräumen, dann synchronisieren
| Seite 1 von 2 | Nächste Seite >> |
dr/ln/Klaus Bierschenk
[1] www.microsoft.com/en-us/microsoft-365/enterprise-mobility-security
