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
 

ATA Gateways

ATA Gateways | Tipps & Tricks
Im letzten Artikel haben wir gesehen wie die Installationen von ATA Center und ATA (Lightweight) Gateway durchgeführt werden. Inzwischen ist die Version 1.7 von ATA erschienen, mehr dazu findet ihr hier: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/31/introducing-advanced-threat-analytics-v1-7/.
Ich spule in der Zeit aber noch ein wenig zurück, nämlich vor den Installationszeitpunkt des ATA Gateways. Im letzten Artikel erwähnte ich das ein ATA Gateway dualhomed (zwei NICs) aufgebaut wird. Dies trifft nach wie vor für das “klassische” ATA Gateway zu, aber nicht für das ATA Lightweight Gateway. Das ATA Lightweight Gateway wird direkt auf den DCs der bisher nicht für ATA Gateway geeigneten Strukturen (Cloud, Filiale, …) installiert. Dazu später mehr.
Das “klassische” ATA Gateway besitzt nun zwei NICs, eine davon wird als Capture-Adapter eingesetzt. Der zweite Adapter wird ganz normal im Netzwerk etabliert. An den Capture-Adapter wird der DC-Traffic via Mirror-Port gespiegelt. Dies kann in virtualisierten Umgebungen, wie auch in realen Umgebungen (Hardware) umgesetzt werden – ja nach Szenario: https://blogs.technet.microsoft.com/pfesweplat/2015/12/23/port-mirroring-for-advanced-threat-analytics/
In einer Hyper-V-basierten Umgebung wie bei der iteracon sieht die Konfiguration wie folgt aus. Auf Hyper-V wird “Microsoft NDIS Capture” installiert und auf dem betroffenen virtuellen Switch aktiviert:
image
Daraufhin werden die Quellen (DCs) und Ziele (Gateways) definiert. Hier wird z.B. auf einem unserer DCs als Mirroring mode “Source” eingestellt:
image
Auf der Gegenüberseite (Capture-NIC auf ATA Gateway) die “Destination”:
image
Im Anschluss daran empfiehlt sich die Kontrolle ob auch die gewünschten Datenpakete via Mirror-Port auf dem Gateway ankommen. Hierzu installiert man einfach den Microsoft Network Monitor 3.4 https://www.microsoft.com/en-us/download/details.aspx?id=4865 (Achtung, keinen anderen Sniffer verwenden, dies ist kontraindiziert für das ATA Gateway). Den Network Monitor starten, “P-Mode” anklicken und die Capture NIC per Checkbox auswählen:
image
New Capture auswählen und nach KerberosV5 OR LDAP filtern (Apply nicht vergessen!):
image
Daraufhin sollte LDAP-Traffic angezeigt werden:
image
Et voilà, es kommen LDAP-Daten auf dem ATA Gateway an und diese können nun vom Gateway analysiert werden. Bitte beachtet die Kapazitätsplanungen für die Gateways und plant die ATA Gateways passend in eure Umgebungen ein (https://docs.microsoft.com/en-us/advanced-threat-analytics/plan-design/ata-capacity-planning). Eine kleine Anregung für die Planungen: was passiert wenn z.B. ein DC innerhalb eines Hyper-V-Clusters auf einen anderen Knoten umzieht? Dann sollte das ATA Gateway mit rüber wandern!
Kommen wir noch abschließend zum ATA Lightweight Gateway. Dieses wird ja wie oben bereits erwähnt direkt auf einem DC installiert. Installationsgrundvoraussetzung ist übrigens das .NET 4.6.1, dies kann je nach Firmenpolitik ein No-Go sein. Als Installationsquelle werden die gleichen Gateway-Bits verwendet, wie beim ATA Gateway auch. Falls .NET noch nicht anliegt hilft die Installationsroutine nach:
image
Los geht der Spaß:
image
Nicht genug CPU und/oder RAM? Dann wird gemeckert:
image
Wo und wer:
image
Und wieder: rufen Sie nicht uns an, wir rufen Sie an:
image
image
Nach der Installation erscheint ein ATA Lightweight Gateway mit einem kleine “Zelt-Symbol” in der ATA Konfiguration:
image
 
Sobald die ATA Gateways etabliert sind und die DCs komplett “eingefangen” wurden kann über die Thematik Windows Event Forwarding (WEF) zur Verbesserung der Pass-the-Hash Attacken nachgedacht werden. Dazu mehr im nächsten Blogartikel zum Thema ATA.
Gruß und bis dahin,
Karsten Hentrup

ATA Installation

Hallo Allerseits,

wie bereits angekündigt hier nun ein Blogeintrag zum Thema ATA Installation. Die zu installierenden Komponenten sind ja ATA Center, ATA Gateway und ATA Lightweight Gateway.
Die Komponenten werden in einer produktiven Installation idealerweise voneinander getrennt aufgebaut.

Das ATA Center wird unihomed erstellt (eine NIC), aber idealerweise mit zwei IPs. Das ATA Gateway wird dualhomed (zwei NICs) aufgebaut, jede NIC bekommt eine IP. Da eine NIC beim Gateway “nur” als Capture-Adapter aufgebaut wird kann hier auch eine IP verwendet werden, welche nicht in den LAN-IP-Bereichen verwendet wird. Das ATA Lightweight Gateway wird AUF einem DC installiert und benötigt somit keine eigene Serverstruktur. Allerdings muss der betroffene DC über die geforderten Leistungsdaten verfügen, hierzu ist die Kapazitätsplanung das A und O (https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-capacity-planning)!

Zuerst wird das ATA-Center installiert, dann die Gateways. Zur weiteren Orientierung ist folgender Technet-Artikel interessant: https://docs.microsoft.com/de-de/advanced-threat-analytics/deploy-use/install-ata-step1

Center Installation:

clip_image001

Hier seht ihr, wie ich auf meiner Testinstanz für das ATA Center doch nur eine IP, aber unterschiedliche Sockets etabliert habe (443 + 444). Bei den Installationspfaden kann darüber nachgedacht werden die DB auf andere Partitionen zu legen und diese aus dem AV auszuschließen.

clip_image002

Rufen Sie nicht uns an, wir rufen Sie an:

clip_image003

Fertig:

clip_image004

Nach der Installation kann auf das Webfrontend des ATA Centers zugegriffen werden. Es wird sich entweder mit einem lokalen Admin authentifiziert (Workgroup-Szenario) oder mit einem Admin aus dem AD (Domain-Szenario):

clip_image005

Die Installation ist zunächst zeitlich limitiert, bis eine passende Seriennummer eingegeben worden ist.

clip_image006

Unter Configuration wird ein Benutzeraccount für einen AD-Connector angeben, hier reicht ein normaler Domain-User aus.

Danach führt ein beherzter Klick auf "Download ATA Gateway Setup" zu den ATA Gateway Installationsdateien. In dem heruntergeladenen Zip-Archiv befindet sich eine personalsierte .json-Datei, insofern ist die Installation nur für das jeweilige Center als Backend geeignet:

clip_image007

Gateway Installation:

clip_image008

Für die Gateway Registrierung wird ein Admin-Account benötigt. Neben Self-signed Zertifikaten können auch Zertifikate der internen PKI verwendet werden, so vorhanden. Weitere Informationen dazu findet ihr hier: https://technet.microsoft.com/de-de/library/mt429319.aspx

clip_image009

Und wieder geht die Installation auf die Reise:

clip_image010

rdy:

clip_image011

Nach der ATA Gateway Installation meldet man sich im ATA Center an, um dann den zu überwachenden DC anzugeben, sowie die Capture-NIC definieren:

clip_image012

Speichern und Synchronisation abwarten bis:

clip_image013

Kontrolle ob folgende Dienste auf den jeweiligen Servern gestartet sind (hier ist zu Testzwecken das Center + Gateway auf einem Server installiert):

clip_image015

Wenn die AD Anbindung sauber läuft, dann sollte in der ATA Center Konsole eine Suche etwas zutage fördern:

clip_image016

Oder:

clip_image018

Schick, ATA lernt:

clip_image019

Lightweight Gateway Installation:

Seit der ATA Version 1.6 gibt es neuerdings sogenannte ATA Lightweight Gateways. Diese werden verwendet, wenn die Infrastruktur z.B. nicht die Möglichkeit bietet Spiegelports zu verwenden. Dies ist unter anderem in Cloud-Umgebungen wie Azure der Fall. Ein ATA Lightweight Gateway wird direkt auf den betroffenen DCs installiert. Voraussetzung hierfür ist das .Net Framework in der Version 4.6.1 (oder höher).

Die ATA Setup-Routine installiert das Framework selbständig, falls fehlend:

clip_image001[1]

Die Installation des ATA Lightweight Gateways ist recht einfach:

clip_image002[1]

Im Vorfeld genügend Ressourcen besorgen (Stichwort: Kapazitätsplanung, s.o.!), ansonsten kommt eine Hinweismeldung:

clip_image003[1]
clip_image004[1]
clip_image005[1]
clip_image006[1]

Nach der Installation sieht man das Lightweight Gateway natürlich auch in der ATA-Konfiguration:

image

Damit ATA aber einwandfrei lernen kann sind noch ein paar Basiskonfigurationen nötig. Dazu mehr im nächsten Artikel.

Gruß,

Karsten Hentrup aka Jens Mander…

<j-j>

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
 

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

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 oder auch jene.

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