Bei der ITERACON wurde seit der Firmengründung eine eigene IT-Umgebung mit verschiedenen Systemen wie File-/Print-Server, Exchange, Client-Management (SCCM), Skype-for-Business etc. betrieben. Traditionell wuchs die Menge der Server etwa genauso stark wie die Menge der Mitarbeiter, was für ein IT-Systemhaus vielleicht auch gar nicht so ungewöhnlich ist. Vor allem für Tests wurden immer wieder Server aufgesetzt und nach Test-Abschluss nicht unbedingt wieder zurückgebaut. So entstand über die Jahre ein solider „Gordischer Doppelknoten“ von fast 60 Servern, die alle irgendwie wichtig und alle irgendwie voneinander abhängig waren. Dabei war es gelungen, auch noch Azure, Exchange-Online und OneDrive als Cloud-Dienste in unser informationstechnisches Kunstwerk mit einzuweben. “hmm…?” sagte da der Chef, den scheinbar der hohe technische Anspruch unserer Leistung nicht recht begeistern wollte.

Als wir Anfang 2018 in die Planungen für ein neues Firmengebäude einstiegen, wurde irgendwann klar, dass der Umzug dieser IT-„Lösung“ recht aufwändig würde, weil für alle Server entsprechende Migrationsüberlegungen unter Berücksichtigung der Abhängigkeiten und Netzanbindungen anzustellen wären. Da auch die vorhandenen Computing-Ressourcen schon älter waren, wurde vom Chef die Parole ausgegeben, möglichst alles in die Cloud zu verlagern, den Umzug lokaler Systeme auf ein Minimum zu reduzieren und Investitionen in neue lokale Hardware zu vermeiden. Vor allem sollte die Verwaltung der Systeme zukünftig einfacher werden, so dass später ein standardisierter IT-Betrieb nach einfachen Regeln die frühere Verwaltung einzelner Systeme durch die jeweils dafür zuständigen Experten ersetzen würde.

Probleme? Lösungen!

Wir starteten also ein Cloud-Projekt und suchten Lösungen für unsere vorhandenen „Schätzchen“. Aus File-Server wurde SharePoint Online, aber geht das auch für alle Dateitypen? Im Prinzip ja. Die befürchteten Probleme mit nicht Cloud-fähigen Dateitypen blieben aus. Zudem haben wir Home-Shares in OneDrive abgebildet. Dank des aktuellen OneDrive Sync-Clients binden sich SharePoint und OneDrive elegant in den Explorer ein und können auch von Laien leicht bedient werden. Mobiles Arbeiten wird kinderleicht.

Aus Exchange on-premises wurde Exchange Online, wobei wir Exchange Online schon seit mehreren Jahren nutzten und im Hybrid-Modus betrieben. Das war also eigentlich nicht mehr neu. Durch den Umstieg auf einen reinen Exchange Online konnten wir jedoch nun auf alle lokalen Lösungen zum Internet-Publishing (Reverse-Proxy, split-brain DNS, Jonglieren mit öffentlichen Zertifikaten) verzichten. Es war ein befreiendes Gefühl, all diese komplexen Teillösungen inkl. der dazugehörenden Firewall-Regeln einfach abzuschalten. Zudem brauchen wir neue Mailboxen nun nicht mehr lokal anzulegen und in die Cloud zu schieben, alles geschieht online.

Wir hatten uns aus akademischem Ehrgeiz früher eine klassische Software-Verteilung mit dem MS SystemCenter Configuration Manager (SCCM) geleistet. Über diese installierten wir Windows, verteilten einige Client-Applikationen und hielten die Client-Betriebssysteme inklusive ihren Virenscannern (MS Defender) aktuell. Hier heißen die neuen Lösungen Microsoft Intune und Autopilot. Über Autopilot werden heute die Windows-Betriebssysteme selbst bereitgestellt und in einen definierten Grundzustand gebracht. Über Intune werden die Systeme dann verwaltet und abgesichert. Die Unternehmens Portal App von Intune wird als Store für die Verteilung von Software genutzt. AV- und Patchmanagement kommen direkt online von Microsoft.

Schon recht komplex war unsere frühere Lync Infrastruktur mit ihrem Session Border Controller, Frond-End- und Edge-Server, Office WebApp Server und einigen Sonderlösungen für Fax und Co. Troubleshooting am Call-Routing war im hybriden Zustand ein Albtraum. Regelmäßig suchten wir an den Firewalls nach möglichen Ursachen für abgebrochene Sessions oder einseitige Voice-Verbindungen. Das alles konnten wir über einige Zwischenschritte inklusive unseres Amtskopfes (+49-2451-9434) nach Teams Online überführen. Wir waren skeptisch, ob Microsoft wirklich die von klassischen Providern wie der Telekom gewohnte Qualität liefern kann. Die Antwort lautet hier: ja – und die klassischen Provider werden weiter für die Bereitstellung von zuverlässigen Netzen / Internet-Zugängen benötigt. Allerdings bedarf es wohl bei Microsoft noch einiger liebevoller Arbeit am Teams-Client, um ihn bezüglich der Telefonie wirklich business-tauglich zu bekommen. Das kommt dann hoffentlich als nächstes.

Die meisten unserer Unternehmens-Applikationen waren von vorneherein als Cloud-Lösungen implementiert (CRM, Lohnbuchhaltung, Antragswesen etc.) und konnten bleiben, wie sie sind. In MS Azure haben wir dann zusätzlich noch 4 Server für besondere Zwecke eingerichtet und angebunden. Hier wurden die z.B. WLAN-Authentisierung und ein Ticket-System angesiedelt. Es findet sich auch ein Remote-Desktop-Server als Ausgangspunkt für den gesicherten Übergang in von uns betreute Kundenumgebunden. Diese Systeme sind allesamt in die Azure AD Domain-Services eingebunden und erzeugen damit das etwas nostalgisches Flair eines internen und sicheren Netzbereichs. Test-Maschinen laufen nun auch in Azure, aber natürlich nicht mehr in unserer primären Subscription. Die Consultants bauen sich in Azure ihre Testumgebungen nach Bedarf und reißen sie angesichts der fortlaufenden Mietkosten nach Testende auch wieder ab.

Das Azure-AD war natürlich von Anfang an mit unserem lokalen AD synchronisiert. Das aufwändige ADFS konnten wir zunächst durch PTA ablösen. Die Aufgabenstellung für die Cloud-Migration war aber, diesen Sync vollständig abzuschneiden und das AAD als reine Cloud-Instanz zu betreiben. Dies war nach der Client-Umstellung auf Autopilot/Intune der letzte Schritt im gesamten Migrationsablauf. So konnten sukzessiv alle lokalen Server inklusive der Domain-Controller des alten on-premises AD ausgeknipst werden, bis wir schließlich nur noch ein Blech für die Datensicherung von O365-Daten übrigbehielten. Das verlagern wir dann zukünftig einmal in die Cloud.

Was hat uns diese Umstellung nun insgesamt gebracht?

Für den Umzug in unser neues Gebäude müssen wir nun nur noch einen lokalen Datensicherungs-Server und das Thema Netzwerk berücksichtigen. Die ca. 60 ursprünglichen Server sind aus und werden nicht mehr benötigt. Die Mitarbeiter können relativ unabhängig vom Unternehmensnetz von überall sicher arbeiten; eine VPN-Einwahl wird nur noch für Sonderaufgaben benötigt. Die früher für lokale Systeme über Firewalls und Reverse-Proxies erreichte Zugangssicherheit ist heute im Wesentlichen auf die Applikationsebene verschoben – der Zugriff auf Online-Daten erfordert immer zwei Faktoren wie z.B. Username/Password + regelkonformes Firmenendgerät.

Insbesondere sind wir im Tagesbetrieb deutlich unabhängiger von allen komplexen Abhängigkeiten der ursprünglichen lokalen Server, der per Firewall isolierten Netzbereiche und dem über etliche Consultants verteiltem Know-how. Der größte Teil der Administration findet heute in den Verwaltungsportalen von Microsoft Azure und Office365 statt, ist dort deutlich kompakter und damit einfacher an die zuständigen Administratoren delegierbar. Auch bringen uns Ausfälle in der lokalen Basis-Infrastruktur (Strom / Klima) nicht mehr so sehr ins Schwitzen: wir können notfalls ins Home-Office umziehen und dort ohne funktionelle Einschränkungen weiterarbeiten.

Schließlich konnte der anstehende Ersatz der veralteten Server- und Storage-Systeme zugunsten der Online- und IAAS-Dienste von Microsoft entfallen. Die Erneuerung der Virtualisierungs-Hardware allein hätte voraussichtlich wieder mehrere 10 Tausend Euro verschlungen. Dem gegenüber stehen heute Mietkosten im dreistelligen Bereich pro Monat für Azure-IAAS Dienste (virtuelle Server inkl. Lizenzen). Die im Wesentlichen genutzten Office-365 Online-Dienste Exchange, SharePoint mit OneDrive etc. sowie Security Services wie Intune und Advanced Threat Protection waren von vorneherein über die Microsoft Online Lizenzen abgedeckt – wir haben sie früher nur nicht in letzter Konsequenz genutzt oder auch nutzen können.

Lt. unserem Chef erfüllen wir jetzt unser Credo, dass IT einfach, flexibel und sicher sein muss, perfekt und leben das vor, was wir vermarkten.

Let´s encryp-Zertifikate autmatisieren

Sparfüchse aufgepasst! :) Sicher hat der ein oder andere schon von Let´s encrypt gehört: Eine tolle Sache! Kostenlose SSL-Zertifikate, die von allen gängigen Browsern als vertrauenswürdig angesehen werden, SAN support…

Ab 01/2018 sollen sogar Wildcard-Zertifikate unterstützt werden. Über z.B. SSLforFree lässt sich recht bequem arbeiten und man erhält vor Ablauf der Zertifikate eine Erinnerungsmail, praktisch. Mindestens mal für Test- und Entwicklungssysteme sehr interessant!

Nicht ganz so trivial ist dabei aber die Erbringung des Nachweises, dass man Besitzer der jeweiligen öffentlichen Domänen ist. Es stehen 3 Überprüfungsmethoden zur Verfügung: Upload von Infos zu einem FTP-Server (noch keine Erfahrung), Upload zu einem HTTP-Server oder Upload zum öffentlichen DNS. Wir schauen uns kurz die letzten beiden an.

• DNS: Wenn ich ein Zertifikat für "sub.domain.com" beantragen möchte, muss ich für diesen Namen im öffentlichen DNS einen speziellen TXT-Eintrag mit kryptischem Inhalt erstellen. Soweit, so gut. Wenn ich eine Reihe von SANs benötige, wird das schon etwas aufwändig und mühselig – je nach DNS-Provider und Güte des Tools kann es auch nervtötend werden.
• HTTP: Wenn ich ein Zertifikat für "sub.domain.com" beantragen möchte, muss ich einen unter diesem Namen per HTTP (ohne "s") erreichbaren Web-Server bereitstellen (!) und dort im WWW-Root ein Verzeichnis namens ".well-known" sowie einen Unterordner "acme-challenge" anlegen. Dort hinein kommen spezielle Dateien mit kryptischen Namen. Klingt kompliziert? Ist es auch. Mal eben einen Web-Server für jeden Namen bereitstellen ist schon eine Herausforderung. Hier ist es ja nicht nur damit getan, z.B. ein zusätzliches Binding im IIS zu konfigurieren (wenn denn überhaupt IIS zum Einsatz kommt). HTTP-Anfragen müssen auch von extern hereinkommen können und an die richtige Stelle gelangen - ein geeignetes HTTP-Publishing ist also Pflicht. Wenn ich auch noch eine Reihe von SANs benötige, brauche ich für alle Namen auch jeweils ein Publishing. Dieses muss jeweils zu einem Web-Server zeigen, in dessen WWW-Root ein Ordner ".well-known" existiert, usw.

Übrigens: Einmal präpariert, sind die Nachweise nicht von Dauer. Nach 90 Tagen verlieren sie ihre Gültigkeit und müssen erneuert werden.

Das wäre alles halb so schlimm, wenn die eigentlichen Zertifikate länger gültig wären. Sind sie aber leider nicht: Nach 3 Monaten ist auch hier Schluss und sie müssen erneuert werden. Dies gilt auch für die o.g. Autorisierungsnachweise. Und dann wäre da noch eine Kleinigkeit: Die neuen Zertifikate müssen ja auch noch den anhängigen Diensten wie z.B. Exchange, ADFS, WAP, RDS oder IIS bekannt gemacht werden, das war ja Ziel des Spiels. Natürlich kann man all das manuell machen. Mit einer guten Doku kann das sogar gut funktionieren. Aber bequem ist anders und wenn viele Dienste aktualisiert werden müssen, artet das in eine Menge Arbeit aus. Nun gut - ohne Herausforderungen wird es schnell langweilig. Es muss also eine bessere Lösung her…

Kann man das nicht irgendwie automatisieren?

Einige findige Leute haben sich diese Frage auch schon gestellt und bemerkenswerte Lösungen auf Powershell-Basis (ACMESharp Modul) entwickelt. Diese sind jeweils auf bestimmte Zielsysteme zugeschnitten, z.B.

a) für Exchange von Frank Zoechling,

b) für RDS-Server von Daniel Melanchthon oder

c) für IIS-WebServer von Marc Durdin.

Wohlgemerkt sind alle Lösungen auf exakt einen Server geeicht - also für jeden Server ein eigenes Zertifikat. Hat man mehr als 1 Exchange Server (z.B. in einer DAG) oder eine aus mehreren Servern bestehende RDS-Farm, muss man die Skripte nachfeilen.

Das Prinzip bei allen:

1. Autorisierungsinfos für die öffentlichen Domänen erstellen
   • Der eine (b) favorisiert DNS , weil es simpler ist und weniger Anpassungen in der Infrastruktur erfordert. Allerdings ist hier die Automatisierung schwierig - je nach DNS-Provider mal mehr, mal weniger. Eine Standardlösung für alle DNS-Provider ist nur schwer vorstellbar.
   • Die anderen (a, c) favorisieren HTTP, weil es tatsächlich vollständig automatisierbar ist. Diverse Publishings mit geschickten Umleitungen etc. sind aufwändig und komplex, der Aufwand fällt aber bei gleichbleibenden Domänen nur einmal an.
2. Anfordern des Zertifikats, dabei Überprüfung der in Schritt 1 erstellten Autorisierungsinfos
3. Export des Zertifikats ins PFX-Format
4. Einbinden des Zertifikats in die jeweiligen Dienste

Sofern man kein Problem mit der HTTP-Variante und ihren Nachteilen hat (und sich alles um Single-Server-Deployments dreht), lassen sich die Skripte a) für Exchange Server und c) für IIS-WebServer schon mal prima einsetzen. Gleiches gilt für RDS und b) wenn man mit einer Halbautomatik erst einmal zufrieden ist.

Ich für meinen Teil hatte für meine Testumgebung etwas speziellere Wünsche. Da ich dort nur eine öffentliche IP habe und einen großen Fuhrpark von Servern, Diensten und (sub-)domains versorgen muss, benötige ich ein SAN-Zertifikat mit sämtlichen DNS-Namen, das auf viele verschiedene Server zum Einsatz kommt. D.h. ich musste dafür sorgen, dass Autorisierungsinfos für alle Domänen zugreifbar sind. Nach einigen Modifikationen war das Skript von Frank Zoechling soweit, dass es im WWW-Root eines Web-Servers die Infos für alle Domänen ablegte.

Nun noch eine Veröffentlichungsregel auf dem guten alten TMG, die incoming HTTP an diese Domänen zum obigen Web-Server leitet.

Damit war Punkt 1 erledigt, Punkt 2 und 3 funktionierten ohne weitere Modifikationen.

Punkt 4 sind eigene, separate Skripte auf den jeweiligen Zielservern (Exchange, ADFS, usw.), bislang noch nicht vollständig automatisiert. Bis hierhin zu kommen war schon eine Menge Arbeit, aber es hat sich gelohnt!

Es folgt eine Liste von Befehlen, die ich auf den jeweiligen Systemen abfeuere sowie ggf. weiterführende Infos.

Exchange 2016

• Import-ExchangeCertificate -FileName \\centralserver\share\certnewest.pfx -FriendlyName "SAN domain.com" -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force) -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services "SMTP, IMAP, POP, IIS" -force

Exchange 2010

• $ex=Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path \\centralserver\share\certnewest.pfx -Encoding byte -ReadCount 0)) -FriendlyName $ExchangeSubject -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force) -PrivateKeyExportable:$true
• Enable-ExchangeCertificate -Services "SMTP, IMAP, POP, IIS" -force -thumbprint $ex.Thumbprint

IIS

• Teile bei Marc Durdin geklaut und angepasst.

RDS

• Hier habe ich ein Skript von Ryan Mangan angepasst und um Teile von Daniel Melanchthon ergänzt

ADFS

• Die Funktion "Set-CertificatePermission" stammt auch aus den Tiefen des WWW
• $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
• $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
• Set-AdfsSslCertificate -Thumbprint $installedcert.Thumbprint
• Get-AdfsSslCertificate
• Set-CertificatePermission -pfxThumbPrint $installedcert.Thumbprint -serviceAccount "s_adfs"
• Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $certresult.Thumbprint
• Restart-Service adfssrv

WAP

• Hier fehlt noch die vernünftige Speicherung des "FederationServiceTrustCredential", bislang nur interaktiv
• $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
• $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
• Install-WebApplicationProxy -FederationServiceTrustCredential (Get-Credential) -CertificateThumbprint $installedcert.Thumbprint -FederationServiceName 'adfs.domain.com'

Work Folders

• $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
• cmd /c netsh http delete sslcert ipport=0.0.0.0:443
• cmd /c netsh http add sslcert ipport=0.0.0.0:443 certhash=$certresult.Thumbprint appid="{CE66697B-3AA0-49D1-BDBD-A25C8359FD5D}" certstorename=MY

Kemp VLM, SharePoint

• Offen: Hier muss ich mir noch etwas überlegen/auf die Suche gehen

Fazit: Das Ganze ist noch eine offene Baustelle, von einer vollständigen Automatisierung bin ich noch ein Stück entfernt. Nichtsdestotrotz ist auch der aktuelle Stand mehr als nützlich und vereinfacht die Angelegenheit enorm. Let´s encrypt-Zertifikate sind eine tolle Sache. Aller Automatisierung zum Trotz sollten diese jedoch meiner Meinung nach Stand heute besser nicht in produktiven Umgebungen eingesetzt werden. Dann lieber ein paar Euro in ein 3 Jahre gültiges Zertifikat investieren. Für Test- und Entwicklungsumgebungen eignet sich das Ganze aber sehr gut!

Ich hoffe, diese Infos sind für den ein oder anderen nützlich.

Vermutlich denken Sie jetzt - mit eingeschränkter Begeisterung, dass hier schon wieder jemand einen Artikel über die theoretischen Vorteile von IPv6 schreibt und damit das lesende Volk verunsichern will. Naja, im Prinzip richtig. Tatsächlich möchte ich hier ein Ergebnis zusammenfassen, dass wir in unserer eigenen iteracon-Infrastruktur erlebt haben. Wir sahen uns tatsächlich gezwungen, IPv6 selektiv einzuführen. Vielleicht ist ja dieser Bericht für den einen oder anderen Leser eine Unterstützung bei eigenen Überlegungen.

Wie also kam es dazu, dass wir (unfreiwillig) gezwungen wurden, IPv6 einzusetzen?
Ausgangspunkt ist die Verwendung von Skype for Business (S4B). Wir setzen als Microsoft Gold Partner natürlich S4B ein und ermöglichen unseren Mitarbeitern damit auch eine komfortable Erreichbarkeit an Heimarbeitsplätzen. Microsoft empfiehlt, in diesen Szenarien den S4B Verkehr nicht zusätzlich per VPN zu verschlüsseln, da hierdurch zusätzliches Delay und Jitter entsteht und die Sprachqualität entsprechend abnehmen kann. S4B verschlüsselt die übertragenen Daten bereits von Hause aus und unterstützt sichere Verfahren für die Authentisierung. Es besteht also keine unmittelbare Notwendigkeit S4B via VPN zu implementieren.

Wenn man dieser Microsoft-Empfehlung folgt, werden beim entfernten Teilnehmer (z.B. Heimarbeitsplatz) einige TCP-/UDP-Ports für die Verbindung benötigt und zwar auch in Richtung des Teilnehmers. Diese Ports werden teilweise dynamisch ausgehandelt und sind nicht im Vorfeld bekannt. Das STUN-Protokoll unterstützt hierbei den Verbindungsaufbau durch Firewalls und über NAT Devices. Sofern man über einen Anschluss mit (z.B. einer festen) IPv4-Adresse verfügt, der bezüglich der nutzbaren Ports nicht eingeschränkt ist, ist alles gut. Allerdings ist dies kaum der Standard; viele Heimarbeitsplätze verwenden dynamisch vom Provider vergebene IPv4-Adressen und bei diesen setzen immer mehr Provider Carrier Grade NAT Verfahren ein (CGN), um die Menge der zur Verfügung stehenden öffentlichen IPv4-Adressen optimal nutzen zu können. Es geschieht gelegentlich eine recht hohe Überbuchung der öffentlichen IPv4-Adressen der Provider. Es ist absehbar, dass mit solchen CGN-Verfahren S4B in Probleme laufen kann, wenn die öffentlichen IPv4-Adressen stark in Nutzung sind und damit die freien TCP/UDP Ports knapp werden.

So geschehen: Wir hatten bei einigen Mitarbeitern das Problem, dass sie nicht immer von zu Hause telefonieren oder Konferenzen nutzen konnten. Die Fehlersuche gestaltete sich schwierig, da keine offensichtlichen Fehler in der Infrastruktur gefunden werden konnten. Die Probleme traten zudem nicht konstant auf, sondern eher sporadisch. Nach einigen Analyse haben wir dann das Carrier-Grade-NAT in Verdacht gehabt und unterstellt, dass notwendige Ports beim entfernten Teilnehmer nicht immer frei waren / genutzt werden konnten.

Unsere Infrastruktur verwendet einen S4B Edge-Server in einer DMZ für die Kommunikation mit Teilnehmern außerhalb des Firmennetzes. Dieser Edge-Server authentisiert die Teilnehmer und bündelt die Kommunikation in Richtung S4B Front-End-Server im LAN. Um Probleme mit NAT auszuloten, haben wir folgende Änderungen durchgeführt:

• Der Edge-Server hat eine zusätzliche IPv6-Adresse bekommen (Dual-Stack).
• Wir haben auf der Firewall IPv6 in Richtung des Internets für den Edge-Server freigeschaltet.
• Wir haben auf der Firewall auch eingehende S4B-Kommunikation über IPv6 zugelassen.
• Schließlich haben wir im öffentlichen DNS einen zusätzliche aaaa-Record mit gleichem Namen wie beim vorhandenen a-Record gesetzt und diesen auf die IPv6-Adressee des Edge-Servers auflösen lassen.

Das Ergebnis: mit diesen Änderungen funktioniert die Telefonie nun auch bei allen Teilnehmern wieder zuverlässig. Insbesondere profitieren die Teilnehmer, deren Internet-Zugänge bereits IPv6 sprechen (also die meisten). Eine Analyse mit Wireshark zeigt: Hat ein S4B-Client eine IPv4- und IPv6-Konfiguration, versucht er, den Verbindungsaufbau über aaaa/IPv6 zu initiieren. Gelingt dies, ist IPv6 hier sogar der präferierte Weg! Eine Überbuchung von IPv6-Adressen bzgl. NAT ist bisher nicht in Sicht. IPv6 ist also in diesem Szenario die Lösung des Problems!

Das Szenario scheint mir deshalb akzeptabel, weil es mit relativ geringen Änderungen in der Infrastruktur umsetzbar ist. Wir setzen IPv6 nur bis in die DMZ ein, danach geht es per IPv4 weiter. Gegen eine weiter reichende Einführung von IPv6 (IPv6 bis zum Front-End-Server in unser lokales Netzwerk) hätte ich deutliche Vorbehalte, weil dies alle vorhandenen Kommunikationsregeln (Firewall, DNS, Routing) in Frage gestellt hätte und sich der übliche Aufwand für Fehlersuchen im Netz damit relativ schnell verdoppeln würde.

Unser Fazit: Es ist absehbar, dass uns an einigen Stellen IPv6 unerwartet begegnen wird und dass wir uns dann zwangsweise damit anfreunden müssen. Es scheint aus heutiger Sicht ratsam, diese Szenarien vorzubereiten und IPv6 bis an die Grenze des Unternehmensnetzes (Firewall, DMZ) schon einmal zu durchdenken und nutzbar zu machen.

Es grüßt, Harald Krause
 

Hallo Allerseits,

in 4 verschiedenen DirectAccess-Umgebungen haben wir Probleme von internen Windows 10 Clients festgestellt welche externe DirectAccess Clients via Manage Out (Stichwort: ISATAP) verwalten wollen. Die Problematik lässt sich auf das Nicht-Funktionieren der Namensauflösung einschränken. Wenn z.B. von einer der betroffenen internen Maschinen ein Ping (oder RDP oder sonstiges Protokoll) auf den NetBios-Namen des externen DA-Clients abgesetzt wird kommt ein “Host unbekannt” zurück – und das obwohl der externe Client sich korrekt (mit seiner v6-IP) am internen DNS registriert hat.

Richard Hicks hat über dieses Verhalten/Phänomen bereits im November 2015 berichtet und auch einen Workaround in Form von Registry-Hacks online gestellt:
https://directaccess.richardhicks.com/2015/11/10/directaccess-manage-out-from-windows-10-does-not-work/

Einer unserer Kunden hat nun ein Ticket bei Microsoft geöffnet um eine Aussage des Herstellers dazu zu erhalten. Dort wurde uns signalisiert das dieser Case nun als Bug klassifiziert wurde.
Im übrigen kann das Verhalten als Workaround auch mit einem einzelnen Registry-Key gelöst werden und zwar wie folgt, hier ein Ausschnitt aus der Ticket-Konversation:

***********************************************
Hallo Herr Hentrup,
ich habe weitere Informationen.
Für das von mir in der vorigen Email angesprochene Verhalten (der Client sendet keine AAAA Queries) ist die aktuelle Lösung diesen Registry Key zu setzten.
HKLM\System\CCS\Services\DNSCACHE\Parameters
REG_DWORD "AddrConfigControl "
Value: 0
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType dword -Value 0 -Force
Die anderen beiden Registry Keys können somit auf Ihren Standartwerten bleiben. Wenn Sie sie zurücksetzten wollen:
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 0 -Force
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 0 -Force
Testen Sie das doch bitte.
Wenn es auch so funktioniert haben wir sicherlich das Problem. Dieses Verhalten zeigt auch Win10 1511.

Haben wir getestet – funktioniert!

Gruß,
Karsten Hentrup
 

Hier folgt nun die versprochene Fortsetzung. Im 1. Teil haben wir uns über das Szenario "Windows Store for Business" (WSfB) dem Thema "Automatische Azure AD-Registrierung (für domain-joined Computer)" genähert. Man kann festhalten, dass diese der Schlüssel für den bequemen und unternehmenstauglichen Zugriff auf Microsoft Online Ressourcen ist. Durch die AAD Auto-Registrierung wird echtes SSO ermöglicht und sie läuft für den User vollkommen transparent (d.h. ohne jegliche Interaktion) ab.

Aber was ist nun konkret zu tun, um die Automatische Azure AD Registrierung zu etablieren?

Voraussetzungen für die AAD Auto-Registrierung

Microsoft stellt eine Vielzahl von Anleitungen zur Verfügung wie z.B. diese.

In der Praxis hat sich aber gezeigt, dass es oftmals im Detail hapert - mal fehlt in der einen Anleitung dieser Punkt, mal in der anderen jener… hier eine Zusammenfassung der wichtigsten Schritte:

1. Sofern noch nicht geschehen, AADConnect und ADFS implementieren, öffentliche Domäne in AAD registrieren, Federation herstellen, UPN der Benutzer im on-premises AD sollte gleich der SMTP-Adresse sein
2. Alle Benutzer, die Cloud Ressourcen nutzen, müssen ins AAD synchronisiert werden
3. Zusätzlich: Alle (relevanten) Windows 10 Computer-Objekte müssen ebenfalls ins AAD synchronisiert werden
4. Erstellen eines Service Connection Point im on-premises AD, damit Windows 10 Computer ermitteln können, wohin sie sich wenden müssen, um zum AAD zu gelangen. Dieser SCP wird in der Configuration Partition per Skript angelegt, es sind Enterprise Admin Rechte erforderlich
5. Aktivieren des sog. ADFS Endpoint namens "windowstransport". Dieser wird benötigt, damit Windows 10 Computer sich bei ADFS authentifizieren können
6. Mindestens drei neue Claim Rules (ohne "SupportMultipleDomains") in der Relying Party Konfiguration für "Microsoft Office 365 Identity Platform", mit denen die on-premises objectGuid, accounttype ("DJ" = domain joined) und die primarysid via ADFS an AAD übermittelt werden
7. Aktivieren von Windows Integrated Authentication als Alternative zu MFA in der o.a. Relying Party

Ablauf der AAD Auto-Registrierung

Auf allen domain-joined Windows 10 Computern existiert ein Scheduled Task unter \Microsoft\Windows\Workplace Join namens "Automatic-Device-Join". Dieser Task läuft im SYSTEM-Kontext und wird bei jedem Anmelden eines Benutzers gestartet. Bei Windows 10 (Build 1511) war dieser Task noch deaktiviert und musste z.B. per GPO aktiviert werden. Bei Windows 10 (Build 1607) ist er hingegen out-of-the-box aktiviert. Wenn alle o.g. Punkte erledigt sind, bewirkt der Task eine Vielzahl von Aktionen. Die genaue Beschreibung würde den Rahmen dieses Beitrags definitiv sprengen - es werden Schlüsselpaare erstellt, der TPM Chip zum Schutz der Schlüssel verwendet, Zertifikate von Azure AD ausgestellt, der Computer erstellt ein Device Object, AAD Connect korreliert dieses mit dem on-premises Computer-Objekt, etc. Genug Stoff für einen zukünftigen separaten Blog Beitrag :-)

Hier der vereinfachte Ablauf:

1. Computer identifiziert über den SCP den passenden AAD Tenant und baut eine dorthin Verbindung auf. Achtung: Damit dies funktionieren kann, benötigt der Computer uneingeschränkten Zugriff auf mehrere URLs!
2. Computer wird umgeleitet zu ADFS und authentifiziert sich. Dabei erhält er von ADFS die oben erwähnten Claims
3. Mit diesen Claims im Gepäck erstellt der Computer nun ein neues Device Object für sich in AAD. Die Werte aus den Claims werden in Attribute des neuen Objekts übertragen
4. AAD stellt ein Zertifikat für den Computer aus, mit dem dieser sich künftig authentifiziert
5. Das PRT findet ebenso seinen Weg auf den Computer
6. AADConnect verknüpft das neue Device Object beim nächsten Lauf mit dem existierenden Computer-Objekt im on-premises AD. Hierdurch wird das on-premises Computer-Objekt autoritativ - d.h. wenn es z.B. gelöscht wird, wird auch das Device Object in AAD gelöscht!

Greift der Benutzer nun auf z.B. Sharepoint Online oder OneDrive for Business zu, werden mithilfe des PRT die Access Tokens beantragt. Falls Sie Kerberos kennen: Im Prinzip kann man sich das PRT ein wenig wie ein Ticket Granting Ticket vorstellen und Access Tokens wie Session Tickets.

Mithilfe der Tokens erfolgt nun die Authentifizierung bei der Zielressource.

Tipps

• Nutzen Sie beim Erstellen der Federation (convert-MsolDomainToFederated) möglichst nicht die Option "SupportMultipleDomains", sofern kein akuter Bedarf besteht. Hierdurch werden zusätzliche Claim Rules erforderlich und deren Konfiguration ist in diesem Fall alles andere als trivial
• Sie wollen nicht alle Windows 10 Computerobjekte ins AAD synchronisieren? Keine Sorge, das passiert auch gar nicht. Selbst, wenn Sie keine Filter konfigurieren, erstellt AADConnect für die on-premises AD Computer-Objekte keine neuen Device Objects in AAD, sondern korreliert nur bereits existierende zwecks Life cycle management. Nicht AADConnect erstellt neue Device Objects - sondern das machen die Computer selbst während der Auto-Registrierung!
• Achten Sie darauf, dass alle Claims auch tatsächlich in ADFS definiert sind, für die Sie Claim Rules erstellen. Eine Claim Rule macht noch keinen Claim ;-)
• Falls Sie einen Forward Proxy mit User Authentifizierung einsetzen: Machen Sie sich auf Probleme gefasst… Der Zugriff des Computers auf das AAD zwecks Registrierung erfordert Zugriff auf mindestens diese URLs:
  • enterpriseregistration.windows.net und
  • login.microsoftonline.com

Und zwar erfolgt der Zugriff im Kontext des Computerkontos, da der Scheduled Task als SYSTEM läuft. Oftmals empfiehlt es sich, den Zugriff auf diese URLs auf der Firewall (nicht authentifiziert) zu erlauben oder einen geeigneten ggf. transparenten Proxy ohne Authentifizierung zu verwenden. Das Thema Proxy & Authentifizierung holt einen übrigens spätestens beim Windows Store for Business wieder ein, soviel sei schon mal verraten.

Fazit

Wenn Sie Windows 10 und Cloud-Ressourcen wie Office 365 oder Windows Store for Business unternehmenstauglich einsetzen und verwalten wollen, dann sollten Sie definitiv die automatische Azure AD Registrierung ihrer Domain-joined Computer etablieren. Diese ist der Schlüssel zum bequemen und sicheren Zugriff auf Microsoft Online Ressourcen. Sie schaffen hierdurch die Grundlage für echtes SSO und weitere interessante Enterprise Features. Eine saubere und adäquate Einrichtung von ADFS und DirSync/AADConnect ist die Basis für SSO, die Sie entweder selber betreiben oder bei Bedarf auch als Komplettpaket bzw. Managed Service bei iteracon buchen können. Wie man unschwer erkennen kann, ist die gesamte Thematik alles andere als simpel und die Einrichtung nicht trivial. Das Ergebnis kann sich allerdings mehr als sehen lassen! Aus Sicht des Endanwenders könnte es kaum simpler sein: An Windows anmelden, auf Ressourcen Zugreifen, fertig! :)

Und das gilt sogar auch für die Store App mit dem Windows Store for Business. Aber dazu wie gesagt später mehr.

Viele Grüße

Alexander Zarenko