Windows 10 im Unternehmensumfeld - SSO, "Hybrid" und andere Mysterien (Teil 1)

Wenn man sich mit Windows 10 und seinem Einsatz in Enterprise-Umgebungen beschäftigt, stellen sich viele Fragen - u.a. zur Verwaltbarkeit und Cloud-Anbindung. Beim Versuch, diese Fragen zu klären, wird man mit einer Vielzahl von Begriffen konfrontiert. Vermutlich haben Sie von Azure AD Join und Workplace Join gehört. Hinzu kamen dann vermutlich recht bald Single Sign On, ADFS, DirSync/AADConnect, MDM Autoenrollment, Intune, SCCM und noch vieles mehr. Ein weites Feld…

Letzten Endes geht es darum, Windows 10 unternehmenstauglich einzusetzen und zu verwalten. Aber wie geht das und was heißt das eigentlich? Es herrscht teils große Verunsicherung, wie einige neue Entwicklungen einzuordnen sind und manche Veranstaltungen oder Kommentare von Leuten, die es eigentlich wissen sollten, schüren diese Verunsicherung noch. Wie etwa: Wird Domain Join bald abgeschafft? Heißt die Zukunft Azure AD Join? Ist die klassische Verwaltung mit Tools wie SCCM tot und läuft künftig alles über MDM wie z.B. Intune?

Ich kann sie beruhigen. Ich bin zwar kein Orakel, aber bin mir mittlerweile (das war nicht immer so!) sehr sicher, dass all diese zugegebenermaßen überspitzt formulierten Fragen für die absehbare Zukunft mit "Nein" beantwortet werden können. Denn: Mit kleinen Einschränkungen ist alles da und es passt alles zusammen (auch das war nicht immer so!). Man muss nur die richtigen Teile miteinander kombinieren. Aber welche sind das, für welches Szenario?

Dieser und zukünftige Artikel rund um Windows 10 sollen etwas Licht ins Dunkel bringen. Zunächst greifen wir einen wichtigen Teilaspekt auf, der im Zusammenhang mit dem Thema "Cloud-Anbindung" steht.

Ein Beispielszenario, der Aufhänger für diesen Beitrag: Ihr Unternehmen möchte gewappnet sein für etwaige Anfragen der Benutzer à la "Ich bin viel mit meinem Surface Pro 4 unterwegs und benötige für Präsentationen die PowerPoint App aus dem Windows Store".

Eine häufige Antwort der IT-Verantwortlichen: "Windows Store? Den haben wir gesperrt. Das ist eine auf Privatpersonen zugeschnittene Geschichte, die wir im Unternehmensumfeld nicht unterstützen."

Und das ist dann das Ende vom Lied - so war es oft mit Windows 8.1.

Nun gibt es aber seit einiger Zeit den Windows Store for Business (WSfB), mit dem sich ein unternehmensspezifischer Bereich innerhalb des Windows Store definieren lässt, der allen Mitarbeitern offen steht. Der Zugriff auf diesen "Private Store" erfolgt mit denjenigen Anmeldedaten, mit denen die Benutzer bereits am Rechner angemeldet sind - sofern einige Voraussetzungen erfüllt sind. Welche dies konkret sind und welche Möglichkeiten WSfB bietet, ist genug Stoff für einen eigenen Blog-Beitrag… an dieser Stelle deshalb nur eine Zusammenfassung - Sie brauchen:

  • Einen konfigurierten WSfB Private Store mit den gewünschten Apps, die den Benutzern zur Verfügung stehen bzw. zur Installation angeboten werden sollen. Das Resultat sieht z.B. so aus:
2016-11-04_22h29_13
  • Eine Instanz von Dirsync (d.h. AADConnect) zur Synchronisation der Benutzerobjekte zwischen dem eigenen AD und Azure AD
  • Optional (aber in aller Regel dringend empfohlen) ADFS und eine Federation zu Microsoft, damit Anmeldedaten ihr Unternehmen nicht verlassen.

Anmerkung: Da die Mehrzahl unserer Kunden der o.a. Empfehlung folgt, liegt der Fokus dieses Beitrags auf dem Szenario inkl. ADFS und Federation zu Microsoft.

Sie kommen also zu dem Entschluss, dass der WSfB eine sehr nützliche Sache ist und beginnen mit der Einrichtung von ADFS, Dirsync und konfigurieren WSfB. Diese Einrichtung ist nicht ganz trivial, aber nach einiger Zeit haben Sie es geschafft. Ein Testzugriff auf SharePoint Online oder OneDrive for Business läuft für den Benutzer so, wie man es sich wünscht: Keine Authentifizierungsdialoge - Drin! Das war ja einfach… (kennt jemand noch den alten AOL Spot mit Boris Becker? Ein Klassiker :-)) OK, nun zum Store… Schade, wie kommt man denn nun an den Private Store? Antwort: Hierzu muss der Work Account hinzugefügt werden, was auch als "Workplace Join" gezeichnet wird.

Standardmäßig passiert dies nicht automatisch. Was nun?

Es gibt an dieser Stelle eigentlich nur eine offensichtliche Möglichkeit:

  • Benutzer fügen Ihren Work Account selbst hinzu. Hierzu starten sie die "Einstellungen" App, wählen dort "Auf Arbeits- oder Schulkonto zugreifen", klicken auf "Verbinden", geben ihren UPN (in der Regel ist dieser identisch mit der Email-Adresse) ein. Daraufhin erfolgt eine Umleitung zu ADFS. Im darauf folgenden Formular muss der Benutzer zum Abschluss noch sein Kennwort eingeben. Nun kann der Benutzer die Store App starten und sein Work Account ist bereits dort hinterlegt. Der Zugriff erfolgt also im Kontext des Work Account und der Private Store wird angezeigt. Ziel erreicht.

Aber ist das unternehmenstauglich?

Vermutlich antworten Sie reflexartig "Nein, ganz bestimmt nicht" oder "Also bei uns nicht" und damit sind Sie in bester Gesellschaft. Tatsächlich wird auch Microsoft dies so unterschreiben. Denn "Workplace Join" ist nicht für Unternehmens-PCs gedacht, sondern für BYOD Szenarien. Was aber tun bei Unternehmens-PCs?

Unternehmens-PCs (Corporate owned devices) mit Windows 10 werden in 2 Klassen unterteilt:

  • Domain-joined Computer. Das sind die klassischen PCs, Notebooks, Tablets oder Hybrid-Geräte, die z.B. mit SCCM oder einem Tool ihrer Wahl aufgesetzt und verwaltet werden. Sie sind Mitglied des on-premises AD und werden üblicherweise ganz klassisch mit SCCM und Group Policies konfiguriert.
  • Azure AD-joined Computer. Für Benutzer, die hauptsächlich mit Cloud Ressourcen arbeiten und Ihren Arbeitsplatz nicht im Unternehmen haben, kann dies eine interessante Alternative sein. Azure AD-joined Computer können im Anschluss an den AAD-join automatisch in die bestehende MDM-Lösung eingebucht werden (z.B. Intune oder SCCM/Intune hybrid) und über diese verwaltet werden. Dieses Feature wird als "MDM Autoenrollment" bezeichnet. Im Vergleich zur Verwaltung von Domain-joined Computern mit SCCM (via installiertem SCCM-Client) und Group Policies wird hier oft von "MDM Channel" und "Lightweight Management" gesprochen.

Nochmal zum Festhalten: Nein, Domain-join wird nicht durch Azure AD Join abgelöst. Zumindest nicht heute und auch nicht morgen. Die Zielgruppen für die Join-Arten sind verschieden. Und SCCM und GPOs sind weiterhin die Mittel der Wahl zur Verwaltung für Domain-joined Computer! Über den MDM Channel wird Lightweight Management gemacht - und zwar für Smartphones generell, für BYOD-Computer oder für heavy-Cloud-User, die ihren Computer ggf. von der Stange kaufen (Kosten übernimmt der Arbeitgeber) und via Self Service zu Azure AD hinzufügen (Azure AD Join) - dies ist ein Beispiel für den sog. COPE-Ansatz (Corporated Owned, Personally Enabled).

Wir wollen uns an dieser Stelle auf Domain-joined Computer konzentrieren, da diese für viele deutlich relevanter sind - schließlich existieren etliche Millionen davon auf der Welt. Microsoft hat seit einiger Zeit ein Verfahren etabliert, das auf Deutsch ungefähr "Automatische Azure AD Registrierung" (Kurzform im Folgenden: "AAD Auto-Registrierung") heißt. Hierdurch wird ermöglicht, dass Domain-joined Computer automatisch in Azure AD registriert werden. Dies bietet u.a. die folgenden Vorteile:

  • Für den Benutzer ist der Vorgang komplett transparent, es ist keinerlei Benutzer(inter)aktion notwendig
  • Die Registrierung passiert automatisch, sobald sich Benutzer an den Computer anmelden
  • Work Accounts der sich anmeldenden Benutzer werden automatisch hinzugefügt

     

  • Die Store App ist fertig vorkonfiguriert und zeigt den Private Store
  • "Enhanced" SSO beim Zugriff auf Ressourcen

"Normales" SSO versus "Enhanced" SSO

Work Accounts werden automatisch hinzugefügt? Keinerlei Benutzerinteraktion, alles vollautomatisch… klingt schon mal super! Aber was ist mit "Enhanced" SSO gemeint? Vorweg: Den Begriff haben wir uns selbst ausgedacht - um diese besondere Form von SSO abzugrenzen zu dem, was wir üblicherweise unter SSO verstehen. Eine Beschreibung des Ablaufs von "normalem" SSO am Beispiel von SharePoint Online können Sie hier finden: http://iteracon.de/sso#a4

Um bei diesem Beispiel zu bleiben: Greift ein Benutzer also im LAN auf SharePoint Online zu, geschieht die "Magie" unter Mitwirkung von ADFS normalerweise vollautomatisch im Hintergrund. Wenn der Benutzer aufmerksam die Adresszeile des Browsers beobachtet, sieht er lediglich die verschiedenen URLs durch die Umleitungen aufblitzen und ist im nächsten Moment schon authentifiziert bei der Zielressource angelangt.

Wir halten aber fest: Bei "normalem" SSO ist zwingend ADFS involviert.

Das heißt umgekehrt auch: Wenn ADFS gerade nicht verfügbar ist (Ausfall, Wartung, etc.), ist kein Zugriff auf MS Online Ressourcen möglich!

Das ist bei "Enhanced SSO" anders:

  • Nur beim ersten Zugriff läuft alles "normal"
  • Anschließend wird ein Primary Refresh Token (PRT) und darauf aufbauend Access Tokens zur Authentifizierung verwendet
  • ADFS wird fortan umgangen. Die Authentifizierung erfolgt mithilfe der o.a. Tokens direkt gegen Azure AD

Die Vorteile des erweiterten SSO liegen auf der Hand:

  • Der Zugriff auf MS Online Ressourcen funktioniert auch unabhängig von ADFS und dessen Verfügbarkeit
  • Es ist keine Eingabe von Anmeldedaten erforderlich, egal ob der Client im LAN steht oder im Internet
  • Die Authentifizierung erfolgt mit weniger Umwegen und läuft daher noch schneller

Einige weitere Vorteile der AAD Auto-Registrierung (Store App mit dem Work Account vorkonfiguriert, WSfB zeigt Private Store an, etc.) habe ich ja bereits oben erwähnt.

Darüber hinaus ist die AAD (Auto-)Registrierung übrigens die Grundlage für weitere interessante Features wie Windows Hello for Business, Enterprise State Roaming und Conditional Access - Details hierzu folgen in zukünftigen Blog-Einträgen.

Damit erst einmal genug für heute… In Teil 2 klären wir, welche Voraussetzungen für die AAD Auto-Registrierung erfüllt sein müssen und es gibt einen Überblick über den Ablauf. Ein paar Tipps zur Implementierung sind auch noch mit dabei, also: "Stay tuned" :-)

Viele Grüße

Alexander Zarenko

ATA Planung

Hier nun wie angedroht ein weiterer Artikel zum Microsoft Advanced Threat Analytics (ATA).

Die Idee: zu ATA werden die Active Directory Daten gespiegelt, ausgewertet und auf möglichen Missbrauch bzw. Auffälligkeiten hin untersucht. Hierzu ist ein Setup von sogenannten ATA (Lightweight) Gateways nötig, welche die gespiegelten AD-Daten aufnehmen. ATA lernt nun die Umgebung kennen, wertet diese aus und meldet sicherheitsrelevante Informationen über das ATA Center. Auf dem ATA Center ist eine Timeline von Alarmen einsehbar, inklusive erster Empfehlungen der weiteren Vorgehensweise.

Die wichtigsten Infos vorab:

- ATA wird größtenteils on-premises aufgebaut. DCs in Azure oder anderen public Clouds werden mittels ATA Lightweight Gateways eingefangen (ab ATA V1.6).
- Idealerweise werden sämtliche DCs eines AD überwacht, dies erfordert sicherlich den Aufbau mehrerer ATA (Lightweight) Gateways.
- Den ATA Gateways werden die AD-Daten mittels Spiegelports von Switchen (real, virtuell) übermittelt. Die Platzierung der ATA Gateways stellt somit die erste (und größte) Herausforderung dar.
- Eine Alternative ist seit Version 1.6 das sogenannte ATA Lightweight Gateway. Dieses wird auf einem DC installiert und insofern ist kein dediziertes Gateway erforderlich. Bei beiden Gateway-Varianten sind die Systemanforderungen zu beachten!
- Sind die ATA (Lightweight) Gateways einmal platziert, dann beginnt automatisch ein Selbstlernprozess. Es ist NICHT erforderlich eine aufwendige Baseline zu erstellen, das System startet nach Positionierung vollkommen autark los.
- ATA kann in einem Workgroup Szenario aufgebaut werden.
- Die Auswertung/Interpretation der von ATA angezeigten Vorkommnisse stellt die zweite Herausforderung dar, da hierfür ggf. “Personen Tage” reserviert werden müssen.
- ATA kann unter anderem durch EMS (Microsoft Enterprise Mobility Suite) lizenziert werden. EMS ist im Vergleich zu den einzelnen Produkten recht günstig, fragt hierzu einen Cloud Solution Provider. Zur Not kann ich einen CSP empfehlen Smiley http://iteracon.de/public-site/news/show?e=19

ATA Topologie:

image
https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-prerequisites

ATA Kapazitätsplanung:

Für ATA kann je nach Umgebung einiges an Ressourcen gefordert sein:

https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-capacity-planning

ATA Test:

ATA Center und ATA Gateway kann zu Test- oder Laborzwecken auf einem Server installiert werden. Für den produktiven Einsatz sei eine Trennung aber empfohlen. Einen ersten Eindruck erhält man sicherlich auch, wenn nur ein DC überwacht wird. Für den produktiven Einsatz dürfte diese Sichtweise aber zu eingeschränkt sein.

Im nächsten Artikel zeige ich die Installation von ATA Center + (Lightweight) Gateways, stay tuned.

Gruß,

Karsten Hentrup…

>>

Wartungsfenster und Geschäftszeiten in SCCM

Ich wurde kürzlich von einem meiner Kunden gefragt, wie denn in SCCM der Zusammenhang zwischen einem Wartungsfenster und den Geschäftszeiten sei und ob sich diese Bereiche beeinflussen. Geschäftszeiten können von jedem Benutzer über das Software Center in gewissen Grenzen frei definiert werden und bringen zum Ausdruck, wann ein Benutzer nicht mit Software- oder Update-Installationen belästigt werden möchte oder positiv ausgedrückt, in welchem Zeitraum Wartungsaktionen bevorzugt stattfinden sollen. Meiner Erfahrung nach ist dies zwar ein Feature, das kaum jemand wahrnimmt oder gar aktiv benutzt, aber man sollte als SCCM-Administrator natürlich wissen, was es mit den Geschäftszeiten auf sich hat und wie diese z. B. die Installation von Software Updates beeinflussen.

Wartungsfenster

Ein Wartungsfenster bzw. Maintenance Window dient im SCCM-Umfeld dazu, den Zeitpunkt von Software- oder Update-Installationen zeitlich kontrollierbarer zu gestalten.

Ein Wartungsfenster wird im SCCM über Collections definiert, d. h. das Wartungsfenster ist eine Eigenschaft der Collection:

1
clip_image001

Das Wartungsfenster bestimmt sich über eine frei definierbare Startzeit, eine Dauer und ggf. ein Wiederholungsintervall. Außerdem kann festgelegt werden, ob das Wartungsfenster für alle Arten von Deployments, nur für Updates oder nur für Task Sequenzen gelten soll.

clip_image002

Wenn für ein Device ein Wartungsfenster definiert ist, werden Deployments (auch nach Erreichen der Deadline) so lange verzögert, bis der Startzeitpunkt des Wartungsfensters erreicht ist. Es gibt darüber hinaus einige weitere Faktoren, die das Installationsverhalten beeinflussen. Wenn, z. B. die Dauer des Wartungsfensters kürzer als die maximal erlaubte Installationsdauer ist, findet die Installation nicht statt, obwohl das Wartungsfenster erreicht worden ist. Die maximal erlaubte Installationsdauer kann bei einer Application im Deployment Type angegeben werden:

clip_image004

Bei einem Software Update Package gibt es diese Einstellmöglichkeit ebenfalls:

clip_image005

Mehrere Wartungsfenster

Was passiert nun, wenn für ein Device mehrere Wartungsfenster definiert sind? Dies kann vorkommen, wenn der Computer Mitglied einer Collection ist, für die mehrere Wartungsfenster definiert sind, oder wenn der Computer Mitglied in mehreren Collections ist, für die jeweils Wartungsfenster vorhanden sind. Hierbei muss man unterscheiden, ob sich die Wartungsfenster zeitlich überschneiden oder nicht. Falls sich die Wartungsfenster nicht überschneiden, gilt jedes Wartungsfenster unabhängig für sich betrachtet. Bei Überschneidungen wird ein einzelnes Wartungsfenster gebildet, das der Schnittmenge aller definierten Wartungsfenster entspricht, d. h. es wird das größtmögliche zeitliche Fenster definiert, dass allen Wartungsfenstern gerecht wird.

Wartungsfenster ignorieren beim Deployment?

Bei jedem Deployment kann sich der SCCM Administrator nochmals individuell entscheiden, ob er evtl. vorhandene Wartungsfenster überhaupt berücksichtigen möchte, oder nicht. Dies kann auf der Seite User Experience im Deployment Wizard bestimmt werden. Wenn, wie hier zu sehen, die Checkbox für Software update installation aktiviert ist, erfolgt nach Erreichen der Deadline die Update Installation auch außerhalb eines evtl. definierten Wartungsfensters. Mit dieser Einstellung lassen sich Wartungsfenster also de facto umgehen.

clip_image007

Geschäftszeiten / Business Hours

Was hat es nun mit den Geschäftszeiten auf sich, die jeder Benutzer auf seinem Gerät über das Software Center frei definieren kann?

clip_image009

Handelt es sich hierbei auch um ein Wartungsfenster? Die Antwort lautet: Ja, in gewisser Weise schon, allerdings hat dieses Wartungsfenster lediglich eine Bedeutung für den Zeitraum vor dem Erreichen der Deployment Deadline. Beim Erstellen eines Deployments kann der SCCM Administrator angeben, ab wann die Software auf dem Client erkennbar, also „Available“ sein soll, hier am Beispiel eines Update Deployments gezeigt:

clip_image011

Ab diesem Zeitpunkt bekommt der Benutzer die Installation der Software über Software Center angeboten und evtl. erscheint auch ein Meldungsfenster mit einer entsprechenden Ankündigung. Ob diese zusätzliche Meldung erscheinen soll oder nicht, wird auf der nächsten Seite des oben gezeigten Wizard festgelegt.

Ob nun die definierten Geschäftszeiten berücksichtigt werden oder nicht, hängt von der Wahl des Benutzers in dieser Benachrichtigung ab. Der Benutzer kann sich hier diesbezüglich entscheiden. Diese Wahlmöglichkeit ist allerdings nur solange gegeben, bis die Deployment Deadline erreicht ist. Der Zeitpunkt der Deployment Deadline wird vom SCCM-Administrator ebenfalls bei der Erstellung des Deployments festgelegt:

clip_image014

Mit Erreichen der Deadline finden die vom Benutzer definierten Geschäftszeiten keine Berücksichtigung mehr, wohl jedoch evtl. vorhandene Wartungsfenster, die über Collections definiert worden sind.

Der wichtigste Unterschied zwischen einem Wartungsfenster und den Geschäftszeiten eines Benutzers ist also der Zeitraum, in dem entweder das eine oder das andere seine Anwendbarkeit findet. Geschäftszeiten blockieren eine Installation vor Erreichen der Deadline, ein Wartungsfenster nach Erreichen der Deadline.

Gruß, Thomas Froitzheim…

Steht die Fax-Technologie vor dem Aus?

Als sich das Telefonnetz gegen Ende des 19. Jahrhunderts in Deutschland ausbreitete, war  dies zunächst eine „analoge“ Revolution. Analoge Gesprächskanäle wurden über dedizierte Drähte (später auch frequenz-modulierte Multiplexerleitungen) geschaltet. Die Qualität der Gesprächskanäle war oft gering. Sie litten an Übersprechen, Echo und externen Störspannungen; oft wurde der Kanal mit zunehmender Länge immer schlechter. Einen wesentlichen Durchbruch stellte die Digitalisierung der Telekommunikation dar, die in Deutschland etwa ab den 1980er Jahren mit dem Aufbau des ISDN-Netzes vollzogen wurde. Gesprächskanäle konnten nun dank der Digitaltechnik quasi „störungsfrei“ geschaltet werden, so dass selbst bei Gesprächen über große Entfernungen eine hohe Verbindungsqualität erreicht wurde. Wie zuvor das analoge Telekommunikationsnetz wurde auch das ISDN-Netz unter dem Monopol der Deutschen Bundespost aufgebaut und betrieben.
Seit Ende der 1990er Jahre vollzieht sich nun ein nächster Evolutionsschritt: digitale Telekommunikation wird zunehmend über paketbasierte Netze (IP-Netze / Internet / VoIP) abgewickelt. Diese Entwicklung ist wirtschaftlich konsequent, da Datenverbindungen allgegenwärtig sind und die geringen Bandbreiten der Telekommunikation ohne weiteres mit übertragen können. Gleichzeitig geht das ursprüngliche Provider-Monopol der Deutschen Bundespost / Telekom in einen offenen Markt mit einer Vielzahl an Dienstanbietern über.
Werbetext Deutsche Telekom (Quelle geschaeftskunden.telekom.de)

Faxübertragung über das Telefonnetz: ein alter Hut.
Techniken, die Schriftstücke über das Telekommunikationsnetz übertragen, wurden zeitlich fast parallel mit der eigentlichen Fernsprechtechnik entwickelt, die Marktreife dauerte jedoch hier deutlich länger. Etwa Mitte der 1960er Jahre setzte Xerox den ersten De-Facto-Standard in Sachen Fax. Waren erste Fax-Geräte noch langsam (Gruppe 1), kam die nächste Generation (Gruppe 2) trotz analoger Übertragungstechnik auf bessere Übertragungsergebnisse (höhere Auflösung) und schnellere Übertragungsraten. Der wahrscheinlich am weitesten verbreitete Fax-Standard wird als Fax Gruppe 3 bezeichnet. Gruppe 3 Geräte setzen eine digitale Kompression und Fehlerkorrektur ein, übertragen dann aber die Daten über analoge Schnittstellen und Netze. Erst Fax-Geräte der Gruppe 4 verwendet durchgängig Digitaltechnik, also auch z.B. digitale ISDN S0-Schnittstellen. Geräte der Gruppe 4 sind trotz der besten Übertragungsqualität und schnellsten Geschwindigkeit eher selten vorzufinden.
 

„Fott damit“. Ausrangiertes Faxgerät, gesehen an einer Straßenecke in Bad Schandau, Sachsen
Der Übergang vom analogen zum  digitalen (ISDN-)Netz bedeutete für Fax-Geräte ein „goldenes Zeitalter“: Selbst  wenn analoge Schnittstellen am Endgerät weiterverwendet wurden (Gruppe 3 Fax), bedeutete die gute Kanalqualität im monopolistischen, digitalen Telekom-Netz, dass Fehlerkorrektur­mechanismen wenig gefordert wurden und hohe Übertragungsraten möglich waren. Gruppe 3 Geräte, die für die Kompensierung von Echos, Rauschen oder anderen externen Störgeräuschen des Analognetzes optimiert waren, übertrugen die Daten im ISDN-Netz der Telekom mit sehr hoher Zuverlässigkeit. Es scheint im Nachhinein, dass die Entwicklung der Faxtechnik in den 1990er Jahren „einschlief“, einfach weil die Technik auf ihrem Zenit angelangt war.
Probleme mit Fax beim Übergang zu Voice-over-IP
Dann jedoch folgt die Ernüchterung: Der Übergang zu Voice-over-IP stellt für Fax-Geräte ganz neue Herausforderungen dar. VoIP ist zunächst auch eine digitale Übertragungstechnik und hat als solche weder mit Leitungsechos, Übersprechen oder externem Rauschen zu kämpfen. Es treten jedoch neue Probleme wie Delay und Jitter oder burstartige Verluste (Paketverluste) auf. Auch ist eine Vielzahl an Codecs entstanden, die zugunsten einer Minimierung der Übertragungsbandbreiten entsprechende Signalverzerrungen mit sich bringen. In Konsequenz arbeiten Fax-Geräte mit analogen Schnittstellen und veralteten Fehlerkorrekturmechanismen in VoIP-Umgebungen nicht mehr zuverlässig. Dokumente benötigen mehrere Anläufe für den Fax-Versand, längere Dokumente gehen teilweise gar nicht mehr ohne Fehler über die Leitung.
Das ITU hat für dieses Problemfeld die Empfehlung T.38 erarbeitet, gemäß der Faxe – also digitale Bilddaten - nicht mehr in Signaltöne gewandelt, digitalisiert und schließlich paketiert übertragen werden. Stattdessen soll eine TCP/IP-Verbindung die vollständig digitale Übertragung ohne Echtzeitcharakter ermöglichen; TCP stellt dabei die hochwertige digitale Fehlerkorrektur sicher.
Soweit so gut, wäre da nicht die Öffnung des Telekommunikations-Provider-Monopols: T.38 wird von SIP-Providern in Deutschland in der Regel nur „intern“ also zwischen Anschlüssen eines Providers angeboten. Provider-übergreifende Verbindungen wandeln beim Übergang dann ggf. doch die Daten wieder in den „analogen“ T.30-Standard um. Die Deutsche Telekom bietet T.38 an IP-Anschlüssen zurzeit gar nicht an. T.38 ist also keinesweigs ein flächendeckender Standard.
Wieso eigentlich Fax-Übertragung?
Noch einmal einen Schritt zurück: Warum liegt uns das Faxen eigentlich so am Herzen? Brauchen wir unsere Fax-Geräte eigentlich noch? Faxe hatten in ihren Glanzzeiten einige recht positive Eigenschaften: Es wurde kollektiv darauf vertraut, dass Abhören oder Manipulationen am Inhalt aufgrund der Echtzeitübertragung und monopolistischen Netzführung nahezu ausgeschlossen waren. Bei ausgeschalteter Rufnummern­unterdrückung konnte die Autentizität der Teilnehmer nachvollzogen werden. Die Empfangsquittung der Zielnummer wurde wie der Rückschein eines Einschreibens betrachtet: Sie schien zu beweisen, dass das Fax inhaltlich korrekt an den gewünschten Empfänger übertragen wurde und nun am Empfangsgerät als Ausdruck vorliegt. In vielen Geschäftsbeziehungen - teilweise aber auch im Umfeld von Behörden - wurden daher Faxe als juristisch bindende Schriftstücke akzeptiert.
Heute müssen wir erkennen, dass diese positiven Eigenschaften des Faxens spätestens mit dem Übergang zu VoIP unwiderbringlich verloren sind. VoIP macht auch Faxe genauso abhörbar und manipulierbar wie alle alle anderen unverschlüsselten Übertragungen in öffentlichen Netzen. T.38 lässt die Verschlüsselung lediglich optional zu. Die Rufnummern haben durch die Öffnung der Netze an „beliebige“ Provider und den Einzug von SIP ihren hohen Vertrauensgehalt verloren. Und eine Empfangsquittung von einem Endgerät mit Zwischenspeicher ist eben nicht mehr als Indiz. Wer kann sicherstellen, dass wirklich ein Ausdruck erfolgt ist? Selbst also wenn T.38 flächendeckend verfügbar wäre: ein juristisch bindender Charakter von Faxen wird auf Dauer nicht (mehr) aufrecht zu halten sein.
Die Zukunft ist digital signiert
Die Deutsche Bundesregierung hat schon in den 1990er Jahren erkannt, dass der klassische Post-Brief als Geschäftsgrundlage für die Wirtschaft (aber auch Behörden) zu langsam ist. Sie erarbeitete daher das Gesetz über Rahmenbedingungen für elektronische Signaturen (SigG, 1997). Dieses Gesetz definiert Verfahren, die ermöglichen, juristisch zweifelsfreie und damit verbindliche Kommunikation über öffentliche Datennetze (z.B. das Internet) abzuwickeln. Den technischen Kern stellen digitale Zertifikate (X.509) und nicht etwa Faxübertragungen dar. Bekannte Spielarten sind z.B. signierte & verschlüsselte E-Mails (SMIME) oder signierte & verschlüsselte Übertragungen von Steuerdaten an die Finanzbehörden (z.B. Elster).
Da die öffentliche Akzeptanz des SigG auch über 10 Jahre nach der Gesetzgebung immer noch sehr gering war, wurde um 2010 das De-Mail-Gesetz nachgeschoben. Dieses Gesetz soll eine konkrete Anwendungsform des SigG – den De-Mail-Dienst – erzwingen. Im De-Mail-Dienst sind alle vom Fax erwarteten Merkmale (Authentizität, Integrität, Vertraulichkeit, Quittungsbetrieb) integriert. Heute, ca. 5 Jahre nach Inkrafttreten des De-Mail-Gesetzes, ist auch für diesen Dienst noch keine wesentliche Marktdurchdringung zu erkennen. Dies mag an den hohen organisatorischen Bedingungen für die Zertifikatsbeantragung/-Ausstellung und die unübersichtliche Lage an zertifizierenden Stellen liegen. Es mag aber auch sein, dass dem Medium Fax immer noch eine führende Position unterstellt wird, so dass die Wirtschaft noch keinen Handlungsdruck sieht, ein neues Übertragungsverfahren zu adaptieren.

Bild: Leistungsmerkmale von De-Mail (Quelle: www.cio.bund.de)
Fazit zur Problematik mit Fax-over-IP
Aus Sicht des Autors wird der Abbau des digitalen Telefonnetzes (ISDN) und der Übergang zu IP-basierten Telefonanschlüssen die Zuverlässigkeit der Übermittlung von Faxdokumenten in Zukunft deutlich einschränken. Technische Lösungen für dieses Problem sind innerhalb der Fax-Technologie selbst nicht in Sicht, zumindest nicht, solange T.38 nicht Ende-zu-Ende verfügbar ist. Es scheint heute keine Patentrezept für die juristisch belastbare Übertragung von Fax-over-IP zu geben, zumindest nicht wenn weiterhin Gruppe 3 Fax-Geräte ohne Signaturoptionen und Verschlüsselung eingesetzt werden. Es scheint daher nicht unwahrscheinlich, dass die Fax-Technologie mit dem IP-Umbau des Telefonnetzes ihren Rückzug aus dem Weltgeschehen antreten wird.
Dies bedeutet für viele Privatpersonen und Firmen, dass für die verbindliche Kommunikation, insbesondere für eilige, vertrauliche Nachrichten oder für Nachrichten, die mit Garantie (Empfangsquittung) und unverändert zugestellt werden sollen, andere Übermittlungsformen als das Fax gesucht werden müssen.
Zu beobachten ist, dass für viele Anwender E-Mails die Funktion von Faxen übernommen haben. Einer E-Mail wird instinktiv unterstellt, dass sie zuverlässig und verbindlich Informationen austauscht. Bedenkt man jedoch die Defizite von unverschlüsselten & unsignierten E-Mails hinsichtlich Authentizität, Vertraulichkeit und Integrität, kann eine solche E-Mail-Übertragung keinen juristisch verbindlichen Charakter haben. Verbindlich wird die E-Mail erst durch z.B. SMIME-Techniken (Verschlüsselung und Signatur) und einen Quittungsbetrieb – aber wer setzt diese Optionen schon ein (ausgenommen ggf. automatisierte Verfahren im EDI-Umfeld)?
Innerhalb von Deutschland könnte De-Mail ggf. zukünftig eine Alternative darstellen. Technisch sind die Voraussetzungen dafür gegeben, es müssten aber erheblich mehr Teilnehmer dieses Verfahren annehmen. In globalisierten Märkten müssen zudem wohl auch internationale Lösungen gesucht werden. Es bleibt abzuwarten, welche Verfahren sich in Zukunft durchsetzen. Über das Ende des Faxes nachdenken sollte man aber schon heute.
Beste Grüße, Harald Krause