Es war einmal: der Gordische Doppelknoten

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 encrypt-Zertifikate automatisieren

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.

2017-11-20_17h23_20

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

clip_image002

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

clip_image003

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

RDS

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.

 

Entspannte Abwesenheit mit dem Exchange Abwesenheitsassistenten

Endlich Urlaub – abschalten und am Pool entspannen. Wäre da nicht das Handy… Die Mails trudeln im Minuten-Takt ein. Sie werden trotz Abwesenheit an Termine erinnert? Oder Kollegen rufen an, und erkundigen sich, warum Sie nicht am Meeting teilnehmen, dabei liegen Sie krank zu Hause? Wir zeigen Ihnen, wie Sie mit dem Exchange Abwesenheitsassistenten mit nur wenigen Klicks für eine entspannte Abwesenheit sorgen…

Der Online Abwesenheitsassistent von Exchange

Mit dem Online Abwesenheitsassistenten von Exchange können Sie Ihr Postfach und Ihren Kalender urlaubsreif gestalten – und das mit nur wenigen Klicks.  So können Sie auf Knopfdruck einstellen, dass in dem Zeitraum Ihrer Abwesenheit, Ihr Kalender geblockt wird und Termine und Terminanfragen automatisch für Sie abgelehnt oder abgesagt werden.

IPv6 – Eine never ending Story

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. Siehe z.B. folgenden etwas älteren Artikel hierzu: https://blogs.technet.microsoft.com/nexthop/2011/11/14/enabling-lync-media-to-bypass-a-vpn-tunnel/. 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

 

DirectAccess Manage Out | Probleme mit Windows 10

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.

Im folgenden Screenshot kann man erkennen, das ein NSLOOKUP auf einen NetBios-Namen korrekt aufgelöst wird, der direkt folgende Ping auf denselben Namen scheitert:

clip_image002

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

 

LET´S TALK – Willkommen auf dem itracon-BLOG

Liebe Community,

herzlichen willkommen auf unserem neuen LET´S TALK Blog! Hier werden wir künftig über unsere Erfahrungen zu verschiedensten Microsoft-Produkten, deren Implementation und Betrieb berichten.

Unsere aktuellen thematischen Highlights sind:

Managed Services rund um Microsoft Azure und Office 365

Consulting zum modernen effizienten Arbeiten rund um Windows 10 Office 2016 und Skype for Business.

Darüber hinaus beschäftigen wir uns mit einigen Spezialthemen wie Multi-Factor Authentication, DirectAccess und Active Directory Security mit Advanced Threat Analytics.

Natürlich wird sich hier auch das eine oder andere “klassische” Microsoft Thema wiederfinden wie die System Center Suite, Exchange, Active Directory, Hyper-V, PKI, etc.

Wir lesen uns!

Gruß

Karsten Hentrup