14
Einführung MS Teams - Anforderungen ans Netzwerk
Hi,
wir sind gerade dabei M365/Teams zu testen und dann ggf. einzuführen. Anfangs für ca. 70 Nutzer, später bis zu 200 oder mehr denkbar.
In der ersten Phase soll ausschließlich Teams eingesetzt werden. AD und Exchange läuft weiterhin on-premise.
Dafür haben wir einen Tenant eingerichtet und nun geht es ans Einrichten des AADC. Auch das wird wohl kein großen Problem darstellen.
Was uns Sorgen bereitet sind die Aussagen von unserem Dienstleister, welcher uns dazu berät und bei der Ersteinrichtung unterstützt, dass u.a. das EWS veröffentlich werden müsse, damit der Termin-Abgleich zwischen dem Teams und unserem On-Premise-Exchange funktionieren kann. Angeblich würde das nicht mit dem "Modern Hybrid" Modus funktionieren, welcher aber ohne die Veröffentlichung des EWS auskommen würde.
Hat jemand von Euch ähnliches wie o.g. eingerichtet?
E.
wir sind gerade dabei M365/Teams zu testen und dann ggf. einzuführen. Anfangs für ca. 70 Nutzer, später bis zu 200 oder mehr denkbar.
In der ersten Phase soll ausschließlich Teams eingesetzt werden. AD und Exchange läuft weiterhin on-premise.
Dafür haben wir einen Tenant eingerichtet und nun geht es ans Einrichten des AADC. Auch das wird wohl kein großen Problem darstellen.
Was uns Sorgen bereitet sind die Aussagen von unserem Dienstleister, welcher uns dazu berät und bei der Ersteinrichtung unterstützt, dass u.a. das EWS veröffentlich werden müsse, damit der Termin-Abgleich zwischen dem Teams und unserem On-Premise-Exchange funktionieren kann. Angeblich würde das nicht mit dem "Modern Hybrid" Modus funktionieren, welcher aber ohne die Veröffentlichung des EWS auskommen würde.
Hat jemand von Euch ähnliches wie o.g. eingerichtet?
E.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1995402946
Url: https://administrator.de/contentid/1995402946
Printed on: April 25, 2024 at 05:04 o'clock
14 Comments
Latest comment
Moin E,
hilft dir das weiter: https://docs.microsoft.com/de-de/exchange/troubleshoot/send-emails/ews-n ...
Für mich klingt das genau anders rum. Dein Dl sagt ihr müsst EWS veröffentlichen, MS sagt EWS wird nicht unterstützt. Oder versteh ich da was falsch?
Gruß
Doskias
hilft dir das weiter: https://docs.microsoft.com/de-de/exchange/troubleshoot/send-emails/ews-n ...
Für mich klingt das genau anders rum. Dein Dl sagt ihr müsst EWS veröffentlichen, MS sagt EWS wird nicht unterstützt. Oder versteh ich da was falsch?
Gruß
Doskias
Moin,
ich vermute eurer DL bezieht soch auf diesen Artikel:
Troubleshoot Microsoft Teams and Exchange Server interaction issues
Danach ist der Hinweis deines DLs korrekt.
Gruß,
Dani
ich vermute eurer DL bezieht soch auf diesen Artikel:
Troubleshoot Microsoft Teams and Exchange Server interaction issues
Danach ist der Hinweis deines DLs korrekt.
Gruß,
Dani
Ja, in diese Richtung geht das.
Was mich allerdings so zweifeln lässt, auch am Dienstleister, ist die Tastache, dass man keine wirklich klare Aussage darüber bekommt, welchen externen Adressen man den Zugriff auf das EWS gewähren muss. Für "alle" freischalten fällt jedenfalls aus!
In dem von Dir genannten Artikel steht auch nur der - tausend Mal - verlinkte Artikel mit den URL und IP-Adressen im globalen Kontext von "Office 365". Da wird nicht unteschieden zwischen inbound und outbound. Für eine Absender-URL kann man ja nun mal schlecht eine Regel auf der Firewall einrichten, oder? Das ist mir alles zu wischiwaschi.
Was mich allerdings so zweifeln lässt, auch am Dienstleister, ist die Tastache, dass man keine wirklich klare Aussage darüber bekommt, welchen externen Adressen man den Zugriff auf das EWS gewähren muss. Für "alle" freischalten fällt jedenfalls aus!
In dem von Dir genannten Artikel steht auch nur der - tausend Mal - verlinkte Artikel mit den URL und IP-Adressen im globalen Kontext von "Office 365". Da wird nicht unteschieden zwischen inbound und outbound. Für eine Absender-URL kann man ja nun mal schlecht eine Regel auf der Firewall einrichten, oder? Das ist mir alles zu wischiwaschi.
Moin,
Ich kann dir eines Sagen: Seit wir in Microsoft Cloud Welt eingetaucht sind, fluchen unsere Security Teams sehr oft und laut. Denn praktisch durch die Verwendung von LBs und CDN seitens Microsoft kannst du nicht die einen IP-Blöcke ausmachen.
Gruß,
Dani
Was mich allerdings so zweifeln lässt, auch am Dienstleister, ist die Tastache, dass man keine wirklich klare Aussage darüber bekommt, welchen externen Adressen man den Zugriff auf das EWS gewähren muss. Für "alle" freischalten fällt jedenfalls aus!
Willkommen in der Welt von Office 365/Azure. Es gibt natürlich eine Übersicht der Endpunkte: Office 365 URLs and IP address rangesIch kann dir eines Sagen: Seit wir in Microsoft Cloud Welt eingetaucht sind, fluchen unsere Security Teams sehr oft und laut. Denn praktisch durch die Verwendung von LBs und CDN seitens Microsoft kannst du nicht die einen IP-Blöcke ausmachen.
Gruß,
Dani
Zitat von @Dani:
Es gibt natürlich eine Übersicht der Endpunkte: Office 365 URLs and IP address ranges
Das ist genau das, was ich meine. Endpunkte wofür? Outbound oder inbound?Es gibt natürlich eine Übersicht der Endpunkte: Office 365 URLs and IP address ranges
Moin,
es handelt sich dabei um den Weg vom Kunde zum DC von Microsoft.
Die andere Richtung ist unter Other endpoints not included in the Office 365 IP Address and URL Web service dokumentiert.
Ich hab vorher zufällig ein Kollegen beim Kaffee aus dem Bereich getroffen. Wir haben von Anfang an über benutzerdefinierte Firewall Objekte auf Basis der DNS Request vom Microsoft DCs zu uns analyisiert, entsprechende Objekte gebaut und getestet. Funktioniert ganz gut... bis auf eine neue Abm: Du kannst dir vorstellen, dass Microsoft gerade bei den IP bereichen und Domain eine gewisse Dynamik hat. Die Kollegen aktualsieren monatlich (manchmal auch wöchentlich) das Regelwerk und Objekte. Zumal der rDNS und fDNS nicht durchweg sauber gepflegt wird.
Gruß,
Dani
es handelt sich dabei um den Weg vom Kunde zum DC von Microsoft.
Die andere Richtung ist unter Other endpoints not included in the Office 365 IP Address and URL Web service dokumentiert.
Ich hab vorher zufällig ein Kollegen beim Kaffee aus dem Bereich getroffen. Wir haben von Anfang an über benutzerdefinierte Firewall Objekte auf Basis der DNS Request vom Microsoft DCs zu uns analyisiert, entsprechende Objekte gebaut und getestet. Funktioniert ganz gut... bis auf eine neue Abm: Du kannst dir vorstellen, dass Microsoft gerade bei den IP bereichen und Domain eine gewisse Dynamik hat. Die Kollegen aktualsieren monatlich (manchmal auch wöchentlich) das Regelwerk und Objekte. Zumal der rDNS und fDNS nicht durchweg sauber gepflegt wird.
Gruß,
Dani
Zitat von @emeriks:
Zitat von @Dani:
Es gibt natürlich eine Übersicht der Endpunkte: Office 365 URLs and IP address ranges
Das ist genau das, was ich meine. Endpunkte wofür? Outbound oder inbound?Es gibt natürlich eine Übersicht der Endpunkte: Office 365 URLs and IP address ranges
Das steht doch in den Dokumenten:
Endpoint data below lists requirements for connectivity from a user's machine to Office 365. For detail on IP addresses used for network connections from Microsoft into a customer network, sometimes called hybrid or inbound network connections
Hi,
hast du jetzt nur Fragen zur Integration von Teams mit onPremise Exchange Postfächern ?
Die Voraussetzung sind ja klar definiert.
https://docs.microsoft.com/de-de/microsoftteams/exchange-teams-interact
Viele Firewall-Hersteller haben jetzt auch Office 365 Endpoint Gruppen, wo die IP's vom Firewall-Hersteller gepflegt werden. (Fortinet z.B.)
Hast du gar keine Fragen zum VoiceoverIP bei Teams oder habt ihr da alles geprüft ? Latenzen, Jitter usw. ?
Mit freundlichen Grüßen
HG
hast du jetzt nur Fragen zur Integration von Teams mit onPremise Exchange Postfächern ?
Die Voraussetzung sind ja klar definiert.
https://docs.microsoft.com/de-de/microsoftteams/exchange-teams-interact
Viele Firewall-Hersteller haben jetzt auch Office 365 Endpoint Gruppen, wo die IP's vom Firewall-Hersteller gepflegt werden. (Fortinet z.B.)
Hast du gar keine Fragen zum VoiceoverIP bei Teams oder habt ihr da alles geprüft ? Latenzen, Jitter usw. ?
Mit freundlichen Grüßen
HG
Zitat von @7Gizmo7:
Hast du gar keine Fragen zum VoiceoverIP bei Teams oder habt ihr da alles geprüft ? Latenzen, Jitter usw. ?
Nein, noch nicht. Das wird sich im Laufe des Projekts ergeben.Hast du gar keine Fragen zum VoiceoverIP bei Teams oder habt ihr da alles geprüft ? Latenzen, Jitter usw. ?
Viele Firewall-Hersteller haben jetzt auch Office 365 Endpoint Gruppen, wo die IP's vom Firewall-Hersteller gepflegt werden. (Fortinet z.B.)
Ja, das dachte ich mir. Aber das müssen uns dann konkret unsere Netzwerker beantworten.hast du jetzt nur Fragen zur Integration von Teams mit onPremise Exchange Postfächern ?
Mir ging es jetzt speziell um die Frage, ob der Modern Hybrid Mode für dieses Szenario tatsächlich nicht geeignet ist.Die Voraussetzung sind ja klar definiert.
https://docs.microsoft.com/de-de/microsoftteams/exchange-teams-interact
Ja, einer der vielen Artikel, welche ich mir schon in diesem Kontext reingezogen habe.https://docs.microsoft.com/de-de/microsoftteams/exchange-teams-interact
Nochmal ein anderer Punkt: Password Hash Sync
Ich bin ja nun von Geburt an paranoid. Mir ist schon klar, dass es wahrscheinlich viel einfachere Wege gibt, bei uns einzubrechen, als über die Cloud die Hash auszuwerten, um an die Passwörter zu kommen.
Allerdings sitzt MS da an der Quelle. Sie geben ja selbst öffentlich bekannt, dass man mit einer P2-Lizenz eine "leak password" Prüfung und Auswertung bekommen kann. Sprich: Die haben da eine Infrastruktur, welche im großen Stil die Password Hash überprüfen kann. Und zwar nicht nur ein Vergleich mit den bekannten Pappenheimern sondern auch auf Vorkommen von Teilen des jeweiligen Benutzernamens oder anderer Daten aus seinem Konto. D.h. es werden dann gezielt Hashes aus Kombinationen der Kontodaten des Benutzer erstellt und gegengeprüft.
Wie habt Ihr Eure Azure AD dahingehend angebunden?
Ich bin ja nun von Geburt an paranoid. Mir ist schon klar, dass es wahrscheinlich viel einfachere Wege gibt, bei uns einzubrechen, als über die Cloud die Hash auszuwerten, um an die Passwörter zu kommen.
Allerdings sitzt MS da an der Quelle. Sie geben ja selbst öffentlich bekannt, dass man mit einer P2-Lizenz eine "leak password" Prüfung und Auswertung bekommen kann. Sprich: Die haben da eine Infrastruktur, welche im großen Stil die Password Hash überprüfen kann. Und zwar nicht nur ein Vergleich mit den bekannten Pappenheimern sondern auch auf Vorkommen von Teilen des jeweiligen Benutzernamens oder anderer Daten aus seinem Konto. D.h. es werden dann gezielt Hashes aus Kombinationen der Kontodaten des Benutzer erstellt und gegengeprüft.
Wie habt Ihr Eure Azure AD dahingehend angebunden?
- Password Hash
- Authentication Agent
- ADFS
Moin,
Gruß,
Dani
Ich bin ja nun von Geburt an paranoid.
Ich glaube, dass hat der Job dir angetan. Wie habt Ihr Eure Azure AD dahingehend angebunden?
AD FS. Weil DSB, ISB, etc. bis heute keine Freigabe erteilt haben.Gruß,
Dani
Worüber macht Ihr da das NLB?
Moin,
wir haben sowohl in der DMZ (u.a. für die Server mit der WAP Rolle) als auch im LAN (u.a. für die Server mit der ADFS Rolle) jeweils Hardware Loadbalancer zur Verfügung. Micrsoft NLB ist für sowas produktiv nicht zuverlässig nutzbar. Das kann man in einer Spielwiese mal nutzen.
Je nach Gegegebenheit (kein LB Vorhanden, Load Balancing über verschiedene ISP, etc.) könnte für die DMZ auch Azure Traffic Manager eine Lösung sein.
Gruß,
Dani
wir haben sowohl in der DMZ (u.a. für die Server mit der WAP Rolle) als auch im LAN (u.a. für die Server mit der ADFS Rolle) jeweils Hardware Loadbalancer zur Verfügung. Micrsoft NLB ist für sowas produktiv nicht zuverlässig nutzbar. Das kann man in einer Spielwiese mal nutzen.
Je nach Gegegebenheit (kein LB Vorhanden, Load Balancing über verschiedene ISP, etc.) könnte für die DMZ auch Azure Traffic Manager eine Lösung sein.
Gruß,
Dani
Zitat von @emeriks:
Nochmal ein anderer Punkt: Password Hash Sync
Ich bin ja nun von Geburt an paranoid. Mir ist schon klar, dass es wahrscheinlich viel einfachere Wege gibt, bei uns einzubrechen, als über die Cloud die Hash auszuwerten, um an die Passwörter zu kommen.
Allerdings sitzt MS da an der Quelle. Sie geben ja selbst öffentlich bekannt, dass man mit einer P2-Lizenz eine "leak password" Prüfung und Auswertung bekommen kann. Sprich: Die haben da eine Infrastruktur, welche im großen Stil die Password Hash überprüfen kann. Und zwar nicht nur ein Vergleich mit den bekannten Pappenheimern sondern auch auf Vorkommen von Teilen des jeweiligen Benutzernamens oder anderer Daten aus seinem Konto.
Nochmal ein anderer Punkt: Password Hash Sync
Ich bin ja nun von Geburt an paranoid. Mir ist schon klar, dass es wahrscheinlich viel einfachere Wege gibt, bei uns einzubrechen, als über die Cloud die Hash auszuwerten, um an die Passwörter zu kommen.
Allerdings sitzt MS da an der Quelle. Sie geben ja selbst öffentlich bekannt, dass man mit einer P2-Lizenz eine "leak password" Prüfung und Auswertung bekommen kann. Sprich: Die haben da eine Infrastruktur, welche im großen Stil die Password Hash überprüfen kann. Und zwar nicht nur ein Vergleich mit den bekannten Pappenheimern sondern auch auf Vorkommen von Teilen des jeweiligen Benutzernamens oder anderer Daten aus seinem Konto.
* Password Hash
Dieses. Habe ADFS ausprobiert, aber irgendwie erschlägt das den Vorteil, das bei ausfall der lokalen Infrastruktur die User trotzdem über Teams kommunizieren können sollen. Und die Infrastruktur aufzubauen ist auch weit komplizierter als einfach nur einen Sync Client installieren. Funktioniert auch wunderbar.Meiner Meinung nach, wenn du Übelkeit verspürst, wenn Microsoft ein Abbild deines AD für die Logins hostet, solltest du ADFS machen, aber dann ist es auch irgendwie sinnlos, alle anderen Dienste dahin zu verlagern. Entweder bringt man ein gewisses Vertrauen in die Integrität eines Anbieters mit oder man sucht sich einen anderen bei dem man weniger Sorgen hat. Und Username und Passwort sind mit Sicherheit nicht die wichtigsten Daten, die du über Teams senden wirst.
D.h. es werden dann gezielt Hashes aus Kombinationen der Kontodaten des Benutzer erstellt und gegengeprüft.
Selbes Szenario. Entweder du lässt von einem externen Anbieter deine Passwörter prüfen, oder du lässt das von Microsoft machen. Welcher vertrauenswürdiger für diese Aufgabe ist, musst du selbst entscheiden. Aber irgendjemand wirst du die Daten geben müssen, wenn du so eine Funktionalität nutzen willst.Wahlweise kannst du auch komplett die Passwörter vorgeben und durch die IT verwalten lassen und mit Hardware Token arbeiten, dann wäre die Handhabe bei dir. Ändert aber auch nichts daran, das sensible Daten in der Cloud landen, das ist ja die hauptsächliche Funktionalität die genutzt wird.
