none
Direct Access 2012 / TMG RRS feed

  • Frage

  • Hallo,

    im Server-Forum konnte man mir leider nicht weiterhelfen...evtl. aber einer der Kollegen hier ? :-)

    Aktuell prüfen wir die Möglichkeiten, mit Win8 Enterprise / Server 2012 einige Clients per DA mit unserem Netzwerk (2008R2-Domäne, IPv4, TMG) zu verbinden.

    Mit dem 2012er DA benötigt man ja kein natives IPv6 mehr, so dass unsere IPv4-Ziele erreichbar wären. Über eine Port443-Veröffentlichung mit TMG2010 würden wir den DA-Server von außen erreichbar machen. Da Smartcards Voraussetzung sind würden wir virtuelle Smartcards über TPM einsetzen.

    Nun haben sich noch ein paar Fragen aufgetan:

    • Sind die Remote-Clients aus dem internen IPv4-Netzwerk erreichbar, z.B. Zugriff aufs Dateisystem / RemoteDesktop / usw. ?
    • Ist eine Verwaltung dieser Clients über System Center Essentials 2010 möglich?
    • Kann man Softwareverteilung über GPO / Loginscripts / WSUS nutzen?

    Insgesamt ist oft zu lesen, dass DA mit Win8 / Server 2012 eine ganz tolle Sache ist ;-) Gibt es eigentlich auch negative Erfahrungen?

    Gruß


    Mittwoch, 27. Februar 2013 06:40

Antworten

  • Hi,

    ja, alles ohne Probleme. Grundsaetzlich verhaelt sich DA in WS2012 so wie DA in Forefront UAG:
    http://www.it-training-grote.de/blog/?p=5015
    Nachteile sehe ich nur wenn Du den URA Easy Deployment Assistenten nimmst und das der URA keine ausgewachsene Firewall (TMG) mehr an Board hat. Man muss also schauen wo man einen URA Server platziert. Ausserdem sind viele der Funktionen nur fuer Windows 8 verfuegbar.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    • Als Antwort markiert trcc Donnerstag, 28. Februar 2013 07:40
    • Tag als Antwort aufgehoben trcc Dienstag, 26. März 2013 06:12
    • Als Antwort markiert trcc Mittwoch, 17. April 2013 05:36
    Mittwoch, 27. Februar 2013 08:10
    Moderator
  • Hi, 20-30 Sekunden halte ich fuer normal. Damit Du von Intern zu einem DA Client kommst muss der interne Client ISATAP aktiviert haben. Beachte auch die Firewalleinstellungen am DA Client fuer die benoetigten Protokolle


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    • Als Antwort markiert trcc Mittwoch, 17. April 2013 05:35
    Freitag, 12. April 2013 13:03
    Moderator

Alle Antworten

  • Hi,

    ja, alles ohne Probleme. Grundsaetzlich verhaelt sich DA in WS2012 so wie DA in Forefront UAG:
    http://www.it-training-grote.de/blog/?p=5015
    Nachteile sehe ich nur wenn Du den URA Easy Deployment Assistenten nimmst und das der URA keine ausgewachsene Firewall (TMG) mehr an Board hat. Man muss also schauen wo man einen URA Server platziert. Ausserdem sind viele der Funktionen nur fuer Windows 8 verfuegbar.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    • Als Antwort markiert trcc Donnerstag, 28. Februar 2013 07:40
    • Tag als Antwort aufgehoben trcc Dienstag, 26. März 2013 06:12
    • Als Antwort markiert trcc Mittwoch, 17. April 2013 05:36
    Mittwoch, 27. Februar 2013 08:10
    Moderator
  • Hi,

    danke, das hört sich doch schon mal gut an. Da wir ja TMG nutzen haben wir kein Problem mit der Platzierung und wir benötigen das Szenario nur für Windows 8-Clients. VPN soll weiterhin der TMG bereitstellen (wird nur wenig genutzt).

    Welchen Nachteil gibt es denn beim EASY Deployment Assistenten? Ich weiß z.B., dass man bei der Initialkonfig vor dem Abschluss die automatisch gemachten Einstellungen nochmal prüfen und ggf. anpassen sollte.

    Bezüglich Smartcards und dem Funktionsumfang bin ich noch etwas verwirrt, weil ich Folgendes in der Technet-Library (Stand März 2012) gefunden habe:

    Unter Windows Server 2012 bietet das vereinfachte DirectAccess-Modell eine Möglichkeit, DirectAccess über einen einzelnen IPsec-Tunnel bereitzustellen, womit das Problem umgangen werden kann. Jedoch unterstützt das vereinfachte Modell bestimmte Funktionen nicht, die auf die zertifikatbasierte Authentifizierung zurückgreifen. Beispiele hierfür sind die zweistufige Authentifizierung mit Smartcards und die NAP-Integration. Unternehmen, die DirectAccess mit vollständigem Funktionsumfang benötigen, müssen auch weiterhin auf das Modell mit zwei Tunneln zurückgreifen.(...)

    Bedeutet das im Umkehrschluss, dass Smartcards doch nicht genutzt werden müssen, wenn man das vereinfachte Modell nutzt? Müssen wir für Dateisystemzugriff/System Center Essentials usw. zwei Tunnel einsetzen? Bedeutet das dann in der Folge zwei Netzwerkkarten und zwei 443-Veröffentlichungen über TMG?

    Mittwoch, 27. Februar 2013 09:48
  • Hi,

    Easy Deployment Assistent Nachteile aus meiner Sicht:
    Self Signed Certificates
    Self Signed Certificates werden per GPO zu Trusted Root verteilt
    Nicht waehlbare Namen im DNS fuer NLS Test
    Verwendung des KDC Proxy
    Ausschalten des SSL CRL Check
    Nur Win 8 Support
    Kein Multisite Support
    kein Lastenausgleich

    Und ja, fuer "echte" Deployments immer den klassichen DA Assistenten verwenden und zwei Tunnel "bauen": Infrastruktur und Client Tunnel. Zwei Netzwerkkarten brauchst Du natuerlich nicht. Die beiden Tunnel werden auch durch eine NIC aufgebaut, es geht nur darum zwei Tunnel zu haben. Und eine TMG Veroeffentlichung reicht auch. Wenn Du nur IP-HTTPS nimmst reicht HTTPS freizugeben. Fuer die Zwei Tunnel Konfiguration wird zusaetzlich als Downlevel Zugriff 6to4 oder Teredo verwendet und dann brauchst Du noch zusaetzliche Ports:
    http://blogs.technet.com/b/tomshinder/archive/2010/05/06/directaccess-and-firewalls-and-nat.aspx


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Mittwoch, 27. Februar 2013 10:06
    Moderator
  • Hi,

    vielen Dank für die vielen und verständlichen :-) Informationen! Die haben mir sehr weitergeholfen, einem Test steht nun nichts mehr im Wege.

    Donnerstag, 28. Februar 2013 07:39
  • Guten Morgen,

    jetzt hat sich doch noch eine Frage aufgetan...


    Bei deinem UMTS-Fun mit Vodafone bzw. T-Mobile habt ihr festgestellt, dass ihr den T-Mobile-APN ändern müsst, weil im Standard NAT mit privater IP-Adresse genutzt wird. Wenn ich jetzt mit einem DA-Client in einem LAN oder WLAN bin, erhalte ich ja auch eine private IP-Adresse...funktioniert dann DA auch nicht?

    Bislang bin ich davon ausgegangen, dass man egal wie man im Internet (privates WLAN, UMTS, ...) ist, eine DA-Verbindung aufgebaut werden kann. In einem Microsoft-Blog hatte ich gelesen: Direct Access enhances the productivity of mobile workers by connecting their computers automatically and seamlessly to their intranet any time Internet access is available

    Gruß

    Dienstag, 26. März 2013 06:12
  • Hi,

    bei T-Mobile wird es nicht funzen, so lange Du den APN nicht aenderst. Leider verhalten sich da nicht alle Internet Provider gleich. Siehe mein Blog zu Vodafone, T-Mobile etc.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Dienstag, 26. März 2013 06:18
    Moderator
  • Hi,

    das mit den APNs bei Vodafone und T-Mobile hatte ich schon gelesen (Vodafone stellt sich übrigens bei unseren Karten ein bisschen an bezüglich Abrechnung des anderen APN).

    Ich hatte aus dem T-Mobile Problem "NAT/private IP" geschlossen, dass es auch ein Problem bei WLAN mit "NAT/private IP" gibt.

    Gruß

    Dienstag, 26. März 2013 06:33
  • Hi,

    wollte nochmal schnell die Rückmeldung geben, dass die Einrichtung von DA funktioniert hat :-) Dank deiner beiden Anleitungen (http://www.it-training-grote.de/download/isaserver-URA-DA1.pdf und DA2) war das im Grunde kein Problem. Kleine Hürden waren nur die Berechtigung für die Anmeldung als Dienst (für die WID...sonst startet der Remoteservice am DA-Server nicht) und meine Ungeduld, als es nicht gleich beim ersten Versuch klappte.

    Smartcards waren nicht notwendig, der Zugriff vom DA-Client auf z.B. IPv4-Freigaben ist problemlos möglich. Nur Zugriffe von IPv4 intern nach DA-Client funktionieren nicht. Was könnte ich übersehen haben?

    Verbindungen über T-Mobile und WLAN funktionieren bestens - bis auf die Dauer des Verbindungsaufbaus. Sind 20-30 Sekunden normal?

    Freitag, 12. April 2013 12:25
  • Hi, 20-30 Sekunden halte ich fuer normal. Damit Du von Intern zu einem DA Client kommst muss der interne Client ISATAP aktiviert haben. Beachte auch die Firewalleinstellungen am DA Client fuer die benoetigten Protokolle


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    • Als Antwort markiert trcc Mittwoch, 17. April 2013 05:35
    Freitag, 12. April 2013 13:03
    Moderator
  • Hi,

    ok, danke! Ein Schnellversuch (hosts-Eintrag IPv4-DA-Server ISATAP) hatte nicht funktioniert, ich werde mich dann bei nächster Gelegenheit ausführlicher damit beschäftigen.

    Mittwoch, 17. April 2013 05:35
  • Hi,

    check mal ob der IP Helper Dienst auf dem Client laeuft und schau mit NETSH nach ob das ISATAP Interface aktiviert ist und der Client eine IPv6 Adresse bekommen hat.
    ich vermute mal das es daran liegt das der DA Server nur DNS64 Adressen verteilt und keine ISATAP Adressen. Aender auf dem DA Server das Verhalten mal:
    Set-NetDNSTransitionConfiguration –OnlySendAQuery $false

    Wenn es mit ISATAP nicht funzen sollte, kannst Du einem internen Client auch eine IPv6 Adresse aus dem Adressraum des DA Server verpassen und das Default Gateway oder eine Route auf den DA Server setzen:
    http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Mittwoch, 17. April 2013 07:46
    Moderator