Azure AD Connect oder UCS Microsoft Office 365 Konnektor

Hallo zusammen,

wir haben ein Problem. Seit letztem Jahr nutzt unsere Schule das kostenlose Office 365 von Microsoft. Intern verwenden wir UCS@school in der Version 4.1 und werden in den kommenden Sommerferien das Update auf Version 4.2 versuchen.

Wir haben im letzten Jahr unseren alten Zarafa Server durch Office 365 ausgetauscht. Da wir selbst und unser unterstützender Supporter keine Erfahrung mit der Microsoft Cloud hatten, haben wir einen externen Dienstleister mit der Migration beauftragt. Dieser hat uns einen extra Windows 2012 R2 Server mit dem Azure AD Connect von Microsoft installiert und die Migration der Postfächer betreut. Der derzeitige Stand ist, dass wir ein fertiges Office 365 haben, welches mittels des Azure AD Connect zu unserem intern UCS synchronisiert wird. Der Dienstleister wird uns demnächst in die Betreuung dieses Sync-Severs einweisen. Mal sehn.

Wir als Administratoren sind nicht besonders zufrieden damit, dass wir extra einen Windows Server betreuen müssen, da doch alle unsere anderen Server UCS-Server oder Ubuntu Linux Server sind. Desweiteren würden wir gerne die Steuerung, wer einen Office 365 Account bekommt, über LDAP steuern, über den UCS Microsoft Office 365 Konnektor eben.

Jetzt steht folgende Aussage des Dienstleister im Raum:
“Ob man einen AD-Server durch UCS ersetzen kann bezweifle ich, da die AD Attribute, gerade für Exchange, vielfältiger sind. Grundsätzlich laufen aber alle Admin-Skripte mit PowerShell und da werdet ihr ohne einen AD Windows Server nicht weiterkommen. Der OfficeConnector hatte ja als Restriktion ein Single-Sign-On, das ggf. über Remote/Telefon Probleme bereiten kann.” In dieser Frage sind wir völlig aufgeschmissen.

Desweiteren haben wir jetzt eine fertig konfiguriertes Office 365. Was wird passieren, wenn wir doch den UCS Microsoft Office 365 Konnektor auf dem Master aus dem App Center installieren? Was ist mit den bereits synchronisierten Usern, die bereits mit Office 365 arbeiten?

Unser Traum, weg mit diesem Windows Server und nur noch über die App UCS Microsoft Office 365 Konnektor arbeiten.

Liebe Grüße, Gerhard Prade

Das ist etwas schwer im Forum zu beantworten, dazu sollte man eigentlich ein Projekt mit unserem Service-Team besprechen.

Ob man einen AD-Server durch UCS ersetzen kann bezweifle ich, da die AD Attribute, gerade für Exchange, vielfältiger sind

Ja, das haben wir gemerkt - das ist der Grund warum wir Exchange momentan nur unterstützen wenn der UCS in die Windowsdomäne (quasi als Member) gejoint ist (also die DC Arbeit vom AD übernommen wird), und nicht wenn der Windows Server als Member in die UCS Domäne gejoint ist (also der UCS alle Attribute und LDAP Controls bereitstellen muss).

Grundsätzlich laufen aber alle Admin-Skripte mit PowerShell und da werdet ihr ohne einen AD Windows Server nicht weiterkommen.

Da weiss ich jetzt nicht was das für Scripte sind. Falls damit Exchange Scripte gemeint sind, laufen die wahrscheinlich auf dem Exchange Server und da Exchange nur auf Windows installiert werden kann, kann man diese Scripte nicht auf dem UCS ausführen.

Wenn damit aber Funktionen oder Steuerungen des Exchange Servers gemeint sind, kann es durchaus sein, dass das mit Bash Scripten abzubilden ist. Wenn es also nicht um das Script an sich, sondern um die Funktion geht müsste man das mal evaluieren.

Der OfficeConnector hatte ja als Restriktion ein Single-Sign-On, das ggf. über Remote/Telefon Probleme bereiten kann.

Das kann ich leider nicht beantworten, da ich nicht weiss was gemeint ist.

Was wird passieren, wenn wir doch den UCS Microsoft Office 365 Konnektor auf dem Master aus dem App Center installieren? Was ist mit den bereits synchronisierten Usern, die bereits mit Office 365 arbeiten?

Das fällt mir schwer vorauszusagen. Im besten Fall: Da die sich mit einem bestehenden Account (in dem die Daten gepflegt wurden, wenn ich das richtig verstanden habe) synchronisieren sollte sich da eigentlich nichts ändern. Das sollte man aber vorher dringend testen.

Vielleicht noch eine Anmerkung zum Thema Power-Shell Skripte für O365. Normale Verwaltungsaktionen können durchaus von einem PS-fähigen Windows-Client ausgeführt werden. Dazu gibt es ausreichend Dokumentation im Netz und ich bin mir sicher, dass wir das auch schon mal in einem Projekt gemacht haben. Einschränkend wäre zu erwähnen, dass ich nicht weiß, ob die Domäne damals über AD-Connect angebunden war.

Noch eine Anmerkung von mir: Seit einiger Zeit gibt es die PowerShell von Microsoft auch als Open Source Projekt und läuft seit dem auch unter Linux:
https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/

Ich habe damit jetzt wenig konkrete Erfahrung, kann mir aber gut vorstellen, dass man dann sogar ganz ohne Windows auskommen könnte.

[quote=“gprade, post:1, topic:6103”]
Was wird passieren, wenn wir doch den UCS Microsoft Office 365 Konnektor auf dem Master aus dem App Center installieren? Was ist mit den bereits synchronisierten Usern, die bereits mit Office 365 arbeiten?
[/quote]Da passiert erst mal nichts. Der UCS-o365 Konnektor synchronisiert einen Benutzer nur, man es bei diesen in der UMC explizit aktiviert. Dies kann für viele User gleichzeitig per multi-edit gemacht werden. Aber per Default wird erstmal kein Account synchronisiert (Kostet ja Lizenzen).

Zu erst muss ein Einrichtungsassistent durchlaufen werden, um die für den Betrieb nötigen Berechtigungen und Schlüssel einzurichten. Danach können Benutzer für die Synchronisation aktiviert werden.

Wenn das Einrichten geklappt hat, kann man einen Test-User anlegen, der eine Email-Adresse hat, deren lokaler Teil (vor dem @) nicht in einem existierenden o365-Accountnamen (upn, User Principal Name) vorkommt. Ein Benutzer mit der Email-Adresse testuser@intern.univention.de würde zu einem o365-User testuser@univention.de synchronisiert (univention.de sei die validierte Domain).
So könnten Sie schon mal gefahrlos mit der Konnektor-App experimentieren.

Um existierende o365-Accounts und existierende UCS-Accounts zu verbinden, muss eine ID errechnet und an beiden Accounts eingetragen werden. Dafür gibt es keinen Automatismus. Im Rahmen eines Projektes könnte eine solche Software aber geschrieben werden.

Beste Grüße
Daniel Tröder

Aber in UCS Office365 issue schreiben Sie das die UniventionOffice365ObjectID und die Azure objectId gleich sein müssen.

Ja, das ist denke ich auch schon alles was getan werden muss, um den UCS-Account mit dem existierenden Azure-Account zu verbinden.

Nach dem Schreiben der Azure objectId in das UniventionOffice365ObjectID Attribut sollte eine Änderung, an eines der zu synchronisierenden Attribute am UCS-User, sofort zu einer Synchronisationsaktion führen.

Fall es ein Attribut an UCS-Usern und Azure-Usern gibt, dass geeignet ist diese miteinander eindeutig in Verbindung zu bringen, sollte ein automatisches Finden und Eintragen der IDs kein Problem sein.

Bezüglich des Exchange-Servers stellt sich mir die Frage welche Rolle dieser spielt. Hält er die E-Mails lokal vor, oder ist er nur zur o365-Benutzerverwaltung da? Eine Eigenschaft könnte auch sein, Outlook-Clients zu provisionieren bzw. Policies für sie zu setzen.
Ob er abgeschafft bzw. ersetzt werden kann, hängt von seinen Aufgaben ab.

Hallo Herr Tröder,

ich habe heute versucht den Konnektor auf einem Test UCS Master an ein Test Office 365 anzubinden. Dabei ist mir aufgefallen, dass der Master ja von aussen erreichbar sein muss? Kann man das irgendwie anders lösen?
Desweiteren hab ich dann auch den Hinweis gefunden, dass vom UCS zum Office 365 keine Passwörte gesynct werden und das es Probleme bei Multiserver Umgebungen gibt.
Unser Traum war es den derzeitigen Azure AD Connect von Microsoft, der bei uns auf einem extra Windows Server 2012 R2 läuft, durch den UCS Microsoft Office 365 Konnektor zu ersetzen. Wenn ich das jetzt einschätze ist dieser Traum geplatzt und wir müssen den Windows Sever weiter pflegen. Das bedeutet für uns jeden User nochmals in dem Windows Server zu konfigurieren und da wir keine Windows Server Experten sind, müssen wir dafür immer (jedes Jahr wahrscheinlich zweimal zum Halbjahres- und Schuljahreswechsel) einen externen Supporter beauftragen. Besonders da wir jetzt planen die Schüler ins Office 365 aufzunehmen, wird das viel Arbeit.
Kann man den Code bei Ihnen nicht einfach anpassen, dass er die UCS Werte ins Azure AD schreibt? Ohne sich dann mit SAML/Single Sign on am UCS anmelden zu müssen? Die Lehrer und Schüler sollen sich dann am Besten direkt auf https://login.microsoftonline.com anmelden können ohne die Rückkopplung an die UMC auf einem UCS.
Oder geht das technisch gar nicht und wir sind auf den Azur AD Connect von Microsoft angewiesen?

Liebe Grüße, Gerhard Prade

Hallo Herr Prade,

Sie können einen reverse-proxy für den Zugriff auf den Master konfigurieren: https://www.univention.com/2017/08/cool-solution-squid-as-reverse-ssl-proxy/
Am reverse-proxy können Sie feingranular den Zugriff einstellen.

Das nicht-übertragen des Passworts an Microsoft ist zum einen Teil des Konzepts und zum anderen technisch nicht anders umzusetzen, da UCS selbst nur Hashes speichert und keine Klartextpasswörter.

Ihr Windows-Server könnte in die UCS-Domäne gejoint werden. Dann würden die UCS-Benutzer zu diesem synchronisiert und eine doppelte Pflege wäre nicht nötig.

Tatsächlich ist das Gewöhnen Ihrer Nutzer an das UCS-Portal (als Startseite? portal.schule.de) von Vorteil: wenn Sie dort neue Apps hinzufügen oder zu anderen migrieren, so finden Ihre Nutzer diese sofort von allein. Von dort werden Sie nach dem SSO-Login direkt zu Office365 weitergeleitet.

Bzgl. Office 365 und Schule ist evtl. dieser Blogbeitrag insteressant: https://www.univention.de/2017/09/datenschutzkonforme-einfuehrung-von-office-365-fuer-die-fuldaer-schulen/

Beste Grüße
Daniel Tröder

PS: Wenn Sie einen UCS-Slave als Reverse-Proxy verwenden, so kann dieser auch gleich für das Self-Service-Modul verwendet werden, um den Anwendern ein Passwort-Reset-via-Email/SMS anzubieten.

Hallo Herr Prade,

wir suchen in unserem Unternehmen aktuell eine Lösung um die Benutzer von UCS nach Office365 zu bekommen.

Wir haben dies nun auch per “Office365 Connector” versucht, das mit den Benutzern klappt soweit, nur wollen wir nicht das SSO verwenden, sondern uns mit Username/Passwort bei den Office365 Diensten anmelden können.

Sie hatten die Lösung mit einem Windows Server und Azure AD Connect beschrieben. Nun wollte ich nachfragen ob Sie diesen Windows Server an den UCS-Master gejoined haben und die User-Verwaltung damit funktioniert? Vor allem ob die UCS-Passwörter für den Office365 Login automatisch übernommen werden können?

Dann würde ich das bei uns nämlich auch installieren.

Wäre nett wenn Sie mir darüber kurz Auskunft geben könnten.

Viele Grüße

Kilian Pfeifer

Einfach das SSO wieder deaktivieren bzw. nicht aktivieren.

Eine syncronisation der Passwörter ist nicht möglich, da diese nicht im UCS gespeichert werden.
Genau für diesen Use-Case ist ja das SSO bzw. SAML gedacht :wink:

Hallo Herr Pfeiffer,

entschuldigen Sie bitte die späte Antwort.
Wir sind in einer ähnlichen Situation, wie Sie. In unserem Fall haben wir das Problem so gelöst, dass wir eine Windows Server mit dem Microsoft Azure AD Connector installiert haben. Wir wollten keinen unserer UCS-Server nach aussen freigeben um die von Univention gedachte Lösung mit SAML zu verwenden.
Leider wurde der Windows Server nicht von uns eingerichtet, sondern von einem externen Dienstleister. So richtig verstehe ich das Prinzip nicht, aber dieser Windows Server stellt eine eigene Domäne, die dann über den Azure AD Connector mit Office 365 synchronisiert wird. Man kann dann wohl noch Filter einbauen. Da sind wir noch am Erweitern.

Liebe Grüße, Gerhard Prade

Hallo Herr Prade, Hallo Univnetion Team,

ich habe nun eine Lösung mittels Azure AD Connect gefunden welche bis jetzt gut funktioniert.

Um anderen in dieser Situation zu helfen, sende ich anbei die Dokumentation meiner Schritte. Diese darf gerne mit der Community geteilt werden oder auch ins Univention Wiki aufgenommen werden.

Viele Grüße

Kilian Pfeifer

1 Like

Klasse Dokument - vielen Dank für Arbeit!

Hallo,

ist das Dokument noch irgendwie bzw. irgendwo verfügbar? Wir haben mit dem Azure AD Connect jetzt ebenfalls die Problematik, die auch hier beschrieben ist.

Viele Grüße

Mastodon