locked
Authentifizierungsproblem IE und TMG - leidiges Thema schon seit ISA 2000 RRS feed

  • Frage

  • Hallo NG,

    ich kämpfe mal wieder mit einem schon über 10 Jahre aktiven Problem:
    Die Clients sind (zwischenzeitlich Windows7 und wir nutzen den IE8 bzw. IE9.)
    Das Gateway zum Internet ist zwischenzeitlich ein TMG, nachdem wir die ganzen ISA-Versionen schon mitgemacht hatten.

    Mein Problem:
    Aufgrund der fortschreitenden Globalisierung kommen immer mehr Notebooks zum Einsatz und unsere Mitarbeiter pendeln immer öfters zwischen den Standorten.
    Früher hatte ich die Proxa-Einstellungen via GPO verteilt, was aber dann zu Problemen in Hotels geführt hatte.
    Heute arbeiten wir mit dem automatischen Beziehen der Settings durch WPAD (über DHCP).

    Wenn das automatische Beziehen aktiviert ist, dann sehe ich im Trace am TMG, dass alle Anfragen anonym kommen.
    Nach 5-10 Sekunden kommt dann (mit Glück) eine Authentifizierung und der User kann durch die entsprechende Regel surfen.
    Stelle ich um, sodass die Proxy-Einstellungen fest im IE hinterlegt sind, so kommt die Anfrage SOFORT authentifiziert und der User hat keine Wartezeiten,
    bzw. es funktioniert halt einfach immer...

    Früher gab es da schon mal einen Patch: 305204.
    Dieser ist allerdings nur für den ISA 2000 und XP-Clients.
    Er beschreibt aber GENAU mein Problem.

    Das Problem haben wir sowohl beim Versuch mit IE wie auch mit Firefox.
    Den IE habe ich so konfiguriert, dass IMMER Benutzername und Kennwort übermittelt werden.
    Der TMG fordert keine generelle Authentifizierung, sondern nur in den entsprechenden Regeln.
    (Man könnte auch sagen, alle 100.000-Artikel zu diesem Thema habe ich durchgearbeitet...)

    Kann es sein, dass es hier seit so vielen Jahren immer noch dieselben Probleme mit der Autokonfig gibt oder habe ich "nur" einen generellen Denkfehler?

    Noch was: wpad kann ich NICHT über DNS bereitstellen, da die Zentrale hier in Deutschland und eine Niederlassung in Frankreich 1 Domäne sind.
    D.h. zwar unterschiedliche IP-Adressen, aber 1 DNS-Zone.
    Würde wpad hier hinterlegt werden, dann könnte nicht zwischen DE und FRA unterschieden werden.
    Daher im DHCP der entsprechende Eintrag...

    Danke

    Ralf

    Freitag, 20. Mai 2011 08:56

Alle Antworten

  • Hi,

    du kannst schon WPAD über DNS nutzen, da du sicherlich in Frankreich einen anderen IP-Adressbereich als in Deutschland hast. Anhand des jeweiligen Subnetzes wird dann automatisch der richtige WPAD-Eintrag verwendet.

    Forderst du am TMG generell Authentifizierung für jeden Benutzer am Proxy des Netzwerkobjekts Intern oder ausschließlich in den Regeln?

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 09:02
  • Hi,

    nein, Du hast keinen Denkfehler. Die erste Anfrage des Browsers kommt am TMG/ISA immer als Anonymous an, dann sagt ISA/TMG das AUthentifizierung erforderlich ist und der Browser sendet dann die Authentication zum ISA/TMG und wird dann anhand des Regelwerks evaluiert.
    IMHO kommt es immer zu einer zeitlichen Verzoegerung beim Einsatz von WPAD (DHCP/DNS) und danach funktioniert es. Ich habe schon Systeme gesehen, wo es wenige Sekunden dauert, teilweise aber auch laenger als die bei Dir geschilderten 5-10 Sekunden.
    Mit TMG gibt es aber als Abhilfe/alternative den AD Marker:
    http://technet.microsoft.com/de-de/library/ee658142.aspx
    Dann brauchst Du aber den TMG client (ehemals ISA Firewallclient)


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Freitag, 20. Mai 2011 09:05
  • moin ralf,

    hast du es schonmal alternativ mit einem selbstgeschriebenen pac-file ausprobiert, welches standortspezifisch arbeitet? sprich in good old france würde man einen anderen proxy verwendent als wie in duitsland. ich habe sowas mal für einen kunden gebastelt und es läuft seitdem ganz gut. wenn ich mich noch recht entsinne, dann funzt die auto-suche via dhcp nur mit ie und nicht mit anderen browsersn?!

    http://de.wikipedia.org/wiki/Proxy_Auto-Config

    http://www.findproxyforurl.com/

     

    hier ein schnipsel meiner oben erwähnten proxy.pac - welches sicherlich noch ein stück weit angepasst werden müsste:

     

     

    function FindProxyForURL(url, host) {

     

          if (shExpMatch(url, "*.intern/*"))                           return "DIRECT";

          if (shExpMatch(url, "*.intern:*/*"))                         return "DIRECT";

          if (isPlainHostName(host))                           return "DIRECT";

          if (localHostOrDomainIs(host, "localhost"))                  return "DIRECT";

          if (isInNet(host, "127.0.0.1", "255.255.255.255"))           return "DIRECT";

          if (isInNet(host, "10.0.0.0", "255.0.0.0"))                  return "DIRECT";

          if (isInNet(host, "192.168.0.0", "255.255.0.0"))             return "DIRECT";

          if (isInNet(host, "172.16.0.0", "255.255.0.0"))              return "DIRECT";

     

          return "PROXY deinproxy.intern:8080; DIRECT";

       }


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 09:16
  • Hallo Christian,

    ich kann den WPAD nicht zweimal anlegen, da der Eintrag im DNS eben einmal auf den deutschen TMG und einmal auf den französischen TMG zeigen müsste.
    Zweimal "WPAD", indem 1x DE-TMG und 1x FRA-TMG hinterlegt ist geht halt nunmal nicht...
    (Das AD inkl. DNS-Server wird zwischen den beiden Standorten repliziert...)

    Ich fordere KEINE generelle Authentifizierung, sondern ausschließlich über die Regeln

    Gruß

    Ralf

    Freitag, 20. Mai 2011 09:16
  • Hi Ralf,

    doch das geht, das hab ich bei mri auch so am laufen. Es gibt bei mir zwei WPAD einträge unter meiner AD-Zone einer zeigt auf die 192.168.1.1 und der andere auf die 192.168.2.1. Jenachdem in welchem Netzwerk sich der Client befindet wird anhand des Subnetzes der richtige Eintrag verwendet.

    Wenn du dann noch das Caching des wpad-Files am Client deaktivierts laut http://forums.isaserver.org/m_2002077934/mpage_1/key_/tm.htm#2002077984, dann sollte es eigentlich keine Probleme mehr geben.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 09:20
  • Hi Ralf,

    doch das geht, das hab ich bei mri auch so am laufen. Es gibt bei mir zwei WPAD einträge unter meiner AD-Zone einer zeigt auf die 192.168.1.1 und der andere auf die 192.168.2.1. Jenachdem in welchem Netzwerk sich der Client befindet wird anhand des Subnetzes der richtige Eintrag verwendet.

    Gruß

    Christian


    Christian Groebner MVP Forefront


    Wow. Das wäre ja unglaublich einfach. Das werde ich gleich mal testen.
    (Ein simpler ping auf "wpad" sollte ja dann von DE aus ausgeführt den deutschen TMG zurückliefern und von FRA aus ausgeführt den französischen, oder?)
    Was würde ich im DNS anlegen, einen CNAME oder einen simplen Host?
    und:
    Ich habe die dnsblocklist bereinigt. Ich denke das ist OK, oder?

    Danke

    Ralf

    Freitag, 20. Mai 2011 09:33
  • Hi,

    nein, Du hast keinen Denkfehler. Die erste Anfrage des Browsers kommt am TMG/ISA immer als Anonymous an, dann sagt ISA/TMG das AUthentifizierung erforderlich ist und der Browser sendet dann die Authentication zum ISA/TMG und wird dann anhand des Regelwerks evaluiert.
    IMHO kommt es immer zu einer zeitlichen Verzoegerung beim Einsatz von WPAD (DHCP/DNS) und danach funktioniert es. Ich habe schon Systeme gesehen, wo es wenige Sekunden dauert, teilweise aber auch laenger als die bei Dir geschilderten 5-10 Sekunden.
    Mit TMG gibt es aber als Abhilfe/alternative den AD Marker:
    http://technet.microsoft.com/de-de/library/ee658142.aspx
    Dann brauchst Du aber den TMG client (ehemals ISA Firewallclient)


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

    Hallo Marc,

    das hört sich gut an.
    Allerdings würde ich sehr gerne auf die Client-Installation verzichten.
    Mal schauen was sonst noch für Lösungen angeboten werden.

    Schon mal Danke

    Ralf

    Freitag, 20. Mai 2011 09:34
  • moin ralf,

    hast du es schonmal alternativ mit einem selbstgeschriebenen pac-file ausprobiert, welches standortspezifisch arbeitet? sprich in good old france würde man einen anderen proxy verwendent als wie in duitsland. ich habe sowas mal für einen kunden gebastelt und es läuft seitdem ganz gut. wenn ich mich noch recht entsinne, dann funzt die auto-suche via dhcp nur mit ie und nicht mit anderen browsersn?!

    http://de.wikipedia.org/wiki/Proxy_Auto-Config

    http://www.findproxyforurl.com/

     

    hier ein schnipsel meiner oben erwähnten proxy.pac - welches sicherlich noch ein stück weit angepasst werden müsste:

     

     

     

    function FindProxyForURL(url, host) {

     

          if (shExpMatch(url, "*.intern/*"))                           return "DIRECT";

          if (shExpMatch(url, "*.intern:*/*"))                         return "DIRECT";

          if (isPlainHostName(host))                           return "DIRECT";

          if (localHostOrDomainIs(host, "localhost"))                  return "DIRECT";

          if (isInNet(host, "127.0.0.1", "255.255.255.255"))           return "DIRECT";

          if (isInNet(host, "10.0.0.0", "255.0.0.0"))                  return "DIRECT";

          if (isInNet(host, "192.168.0.0", "255.255.0.0"))             return "DIRECT";

          if (isInNet(host, "172.16.0.0", "255.255.0.0"))              return "DIRECT";

     

          return "PROXY deinproxy.intern:8080; DIRECT";

       }

     


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|


    Hallo Jens,

    auch diese Lösung hört sich nicht schlecht an.
    Muss die proxy.pac dann analog zur wpad.dat veröffentlicht werden?
    (Über eine Webseite, der ich den mimetyp anpasse und über die Option 252 oder wie würde ich das den Clients mitteilen?)

    Danke

    Ralf

    Freitag, 20. Mai 2011 09:37
  • servus ralf,

    yo die proxy.pac müsste idealerweise auf einem internen webserver liegen. im übrigen, proxy.pac und wpad.dat sind letztendlich dasselbe nur anders "benamst".

    ;-)


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 09:41
  • Hi Ralf,

    ich habe bei mir zwei HOST A-Einträge. Wenn du dann noch das Caching der WPAD.dat am Client deaktivierst, sollte es funzen.

    Was meinst du damit: Ich habe die dnsblocklist bereinigt. Ich denke das ist OK, oder?

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 09:50
  • die dnsblocklist sollte wpad zulassen, sonst kanns gar nicht gehen!

    ralf meint sicherlich dies hier:

    http://technet.microsoft.com/en-us/library/cc995158.aspx


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 10:58
  • Hi Ralf,

    ich habe bei mir zwei HOST A-Einträge. Wenn du dann noch das Caching der WPAD.dat am Client deaktivierst, sollte es funzen.

    Was meinst du damit: Ich habe die dnsblocklist bereinigt. Ich denke das ist OK, oder?

    Gruß

    Christian


    Christian Groebner MVP Forefront


    HOST-A => Das ist die Lösung. CNAME kann es nur 1 geben...

    dnsblocklist: Jens hat einen Volltreffer gelandet und genau den richtigen Link notiert. Wie in diesem Artikel beschrieben wird wpad bei uns NICHT blockiert..


    Den Cache deaktivieren? Es funzt scheinbar auch so und wenn ich das richtig lese ist der Cache eigentlich keine schlechte Sache, oder?
    Freitag, 20. Mai 2011 11:02
  • Hi,

    und funktioniert es jetzt so wie es soll?

    Ah, die Blocklist :-)

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 11:05
  • zum cache: ich habe das caching der wpad.dat aka proxy.pac sonst auch via webserver "verboten" - via http-header.

    habe ich schon erwähnt, das ich neuerdings geo-cacher bin?

    hihi...


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 11:13
  • zum cache: ich habe das caching der wpad.dat aka proxy.pac sonst auch via webserver "verboten" - via http-header.

    habe ich schon erwähnt, das ich neuerdings geo-cacher bin?

    hihi...


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|


    Was mir auffällt ist, dass der Browser SOWOHL in DE wie auch in FRA richtig schön schnell reagiert, wenn er einmal offen war.
    Schliesst man ihn dann und öffnet ihn ca. 2 Minuten später wieder, dann dauert es doch wieder bis zu 5 Sekunden, bis der gute google kommt...

    geo-cacher: LOL.
    Was meinst du mit "über den http-header verboten?"

    Freitag, 20. Mai 2011 11:21
  • Hi,

    und funktioniert es jetzt so wie es soll?

    Ah, die Blocklist :-)

    Gruß

    Christian


    Christian Groebner MVP Forefront


    gib mir noch ein bisschen zum Testen.
    So wie es ausschaut werde ich noch heute die Lösung markieren...

    Freitag, 20. Mai 2011 11:21
  • geo-cacher nix LOL sondern 1337!!!

    ;-)

    ich meine dem hier: http://technet.microsoft.com/de-de/library/cc732442(WS.10).aspx


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 11:29
  • Hi,

    das geht aber nur, wenn du die wpad.dat auf einem IIS auslagerst. Wenn TMG die WPAD.dat generiert, dann ist nur folgendes möglich:

    http://forums.isaserver.org/m_2002077934/mpage_1/key_/tm.htm#2002077984

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 11:44
  • geo-cacher nix LOL sondern 1337!!!

    ;-)

    ich meine dem hier: http://technet.microsoft.com/de-de/library/cc732442(WS.10).aspx


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|

    mit LOL meinte ich die Synergie zwischen "Cache deaktivieren" und "...schon erwähnt: geo-cacher..."
    Danke für den Link, dann hat sich die Frage mit dem http-header auch erübrigt...
    Freitag, 20. Mai 2011 12:17
  • Hi,

    und funktioniert es jetzt so wie es soll?

    Ah, die Blocklist :-)

    Gruß

    Christian


    Christian Groebner MVP Forefront


    gib mir noch ein bisschen zum Testen.
    So wie es ausschaut werde ich noch heute die Lösung markieren...


    Also: Es scheint, als ob zumindest die Auto-Konfig jetzt funktioniert.
    Endgültig wird sich das erst im Laufe der kommenden Tage zeigen, wenn die User sich beschweren (oder halt auch nicht...)

    Aber:
    Das Kernproblem ist noch nicht behoben.
    Ich habe eine Regel "Serverzugriffe: Authentifiziertes Surfen". In dieser sind die ganzen Server hingerlegt.
    Hier lasse ich alles zu, insofern der User authentifiziert ist. (IT´ler ist).
    Nach Start des IE kommt die Fehlermeldung, dass der TMG verweigert.
    Das TMG-Protokoll sagt dabei aus, dass eben unauthentifiziert kommt:
























    Verweigerte
    Verbindung
    TMG 20.05.2011 14:37:52
    Protokolltyp: Webproxy (Forward)
    Status:
    12202 Die angegebene URL wurde von Forefront TMG abgelehnt.
    Regel: Serverzugriffe: Authentifiziertes
    Surfen
    Quelle: Intern (10.1.100.3:64685)
    Ziel: Lokaler Host
    (10.1.110.254:80)
    Anforderung: GET
    http://10.1.110.254/wpad.dat
    Filterinformationen: Req ID: 0ff74308;
    Compression: client=No, server=No, compress rate=0% decompress rate=0%
    Protokoll: http
    Benutzer: anonymous

     

    D.h. Das Kernproblem, dass der Benutzername nicht übermittelt wird scheine ich nach wie vor noch zu haben...
    (Stelle ich den IE um auf statischen Proxy, dann wird authentifiziert und ich kann surfen...)

    • Objektquelle: (Es sind
      keine Quellinformationen verfügbar.)
    • Cacheinformationen: 0x0
    • Verarbeitungszeit: 0 MIME type:
    Freitag, 20. Mai 2011 12:40
  • Hi,

    und funktioniert es jetzt so wie es soll?

    Ah, die Blocklist :-)

    Gruß

    Christian


    Christian Groebner MVP Forefront


    gib mir noch ein bisschen zum Testen.
    So wie es ausschaut werde ich noch heute die Lösung markieren...


    Also: Es scheint, als ob zumindest die Auto-Konfig jetzt funktioniert.
    Endgültig wird sich das erst im Laufe der kommenden Tage zeigen, wenn die User sich beschweren (oder halt auch nicht...)

    Aber:
    Das Kernproblem ist noch nicht behoben.
    Ich habe eine Regel "Serverzugriffe: Authentifiziertes Surfen". In dieser sind die ganzen Server hingerlegt.
    Hier lasse ich alles zu, insofern der User authentifiziert ist. (IT´ler ist).
    Nach Start des IE kommt die Fehlermeldung, dass der TMG verweigert.
    Das TMG-Protokoll sagt dabei aus, dass eben unauthentifiziert kommt:
























    Verweigerte
    Verbindung
    TMG 20.05.2011 14:37:52
    Protokolltyp: Webproxy (Forward)
    Status:
    12202 Die angegebene URL wurde von Forefront TMG abgelehnt.
    Regel: Serverzugriffe: Authentifiziertes
    Surfen
    Quelle: Intern (10.1.100.3:64685)
    Ziel: Lokaler Host
    (10.1.110.254:80)
    Anforderung: GET
    http://10.1.110.254/wpad.dat
    Filterinformationen: Req ID: 0ff74308;
    Compression: client=No, server=No, compress rate=0% decompress rate=0%
    Protokoll: http
    Benutzer: anonymous

     

    D.h. Das Kernproblem, dass der Benutzername nicht übermittelt wird scheine ich nach wie vor noch zu haben...
    (Stelle ich den IE um auf statischen Proxy, dann wird authentifiziert und ich kann surfen...)

    • Objektquelle: (Es sind
      keine Quellinformationen verfügbar.)
    • Cacheinformationen: 0x0
    • Verarbeitungszeit: 0 MIME type:

    und jetzt wird es noch etwas übler:























    Fehlgeschlagener
    Verbindungsversuch
    TMG 20.05.2011
    14:47:19
    Protokolltyp: Webproxy (Forward)
    Status:
    10060 Ein Verbindungsversuch ist fehlgeschlagen, da die
    Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder
    die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht
    reagiert hat.
    Regel: Serverzugriffe: Anonymes Surfen
    Quelle: Intern (10.1.100.3:64701)
    Ziel: Extern (fra-isa.ernst.intra
    10.2.110.254:80)
    Anforderung: GET
    http://10.2.110.254/wpad.dat
    Filterinformationen: Req ID: 0ff74589;
    Compression: client=No, server=No, compress rate=0% decompress rate=0%
    Protokoll: http

    Benutzer: anonymous

     

    Das heißt im Klartext: Jetzt will der deutsche Fileserver wpad auflösen und versucht den französischen wpad zu nehmen.
    Ob das mit dem doppelten wpad-Eintrag sooooo clever ist?

    Freitag, 20. Mai 2011 12:50
  • Hi,

    dieses Problem erhält man eigentlich nur, wenn man unter Vernetzung -> Intern -> Webproxy -> Authentifizierung den Haken bei Authentifizierung ist für alle Benutzer erforderlich setzt. Ansonsten könnte ich mir noch vorstellen, dass die Zugriffsregel für Server auch für das Netzwerk Lokaler Host gilt und somit authentifizierung auch für den Abruf der wpad.dat will.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 12:58
  • Hi,

    das könnte aber auch durch einen vorigen Fehlschlag zu erklären sein, da er den lokalen WPAD ja nicht erreicht hat.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Freitag, 20. Mai 2011 13:00
  • yop - die interferenz war beabsichtigt. und das lol ist schon o.k. - war ja eh ein 1337-lol.

    *ggg*


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 16:56
  • hast du auf allen dns-servern die blocklist gehackt? an allen standorten?

    hm - 2 a-records - das müsste doch dann roundrobin also tischtennisrundlauf ergeben oder?


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 20. Mai 2011 16:58
  • hast du auf allen dns-servern die blocklist gehackt? an allen standorten?

    hm - 2 a-records - das müsste doch dann roundrobin also tischtennisrundlauf ergeben oder?


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|


    dns-blocklist: JA. An Allen Standorten ist der Eintrag entfernt!

    2x A-Records: Das ist auch mein Eindruck. Zumindest beim pingen erhalte ich mal den einen und mal den anderen...

    Das Problem ist, dass Surfen nur sporadisch an allen Standorten will.
    Neben dem round-robin-problem habe ich auch noch das Problem, dass bei aktivierter Einstellung "Automatische Erkennung" KEIN Benutzername übergeben wird.
    Aktiviere ich statt dessen den Proxy, dann wird der Name sauber an den TMG uebermittelt und surfen funktioniert problemlos...

    Ralf

    Dienstag, 24. Mai 2011 06:29
  • Hi,

    damit du den richtigen WPAD-Eintrag erhälst muss im DNS-Server die Option "Netzwerkmaskenanforderung aktivieren" aktiviert sein, welcher eigentlich standardmäßig aktiv ist. Dadurch wird automatisch die dazugehörige IP-Adresse für das entspr. Subnetz geliefert.

    Ich vermute, wie ich schon geschrieben habe, dass du irgendwo eine Regel hast die Authentifizeriung von Intern nach Lokaler Host fordert und somit der WPAD-eintrag auch authentifiziert gelesen werden muss, was dann zwangsläufig zu Problemen führt.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Dienstag, 24. Mai 2011 07:31
  • Hi,

    damit du den richtigen WPAD-Eintrag erhälst muss im DNS-Server die Option "Netzwerkmaskenanforderung aktivieren" aktiviert sein, welcher eigentlich standardmäßig aktiv ist. Dadurch wird automatisch die dazugehörige IP-Adresse für das entspr. Subnetz geliefert.

    Ich vermute, wie ich schon geschrieben habe, dass du irgendwo eine Regel hast die Authentifizeriung von Intern nach Lokaler Host fordert und somit der WPAD-eintrag auch authentifiziert gelesen werden muss, was dann zwangsläufig zu Problemen führt.

    Gruß

    Christian


    Christian Groebner MVP Forefront

    die Option des DNS-Servers ist an allen Standorten aktiv.
    In der Tat hatte ich Regeln, die auth fordern und Ziel "Beliebig" hatten.
    Diese habe ich gerade eben abgeändert. Jetzt heisst es wieder testen...
    Dienstag, 24. Mai 2011 14:15
  • Zwischenstand:

    Ich habe ALLE Regeln so abgeändert, dass KEINE mehr auf "Lokaler Host", (also den TMG) Authentifizierung erfordert.
    Das ist zwischenzeitlich mehrfach kontrolliert und verifiziert.

    Dennoch:
    Beim Aufruf einer Webseite erhalte ich sofort die Fehlermeldung, dass der TMG blockiert.
    Am TMG sehe ich ausschließlich "anonymous"-Anmeldungen.

    UND: Der ping gibt mir (eigentlich) immer den französischen TMG zurück...
    Interessant: In Frankreich scheint es aktuell zu funktionieren.
    ABER: wpad als Eintrag in meiner hosts-Datei hat auch nicht geholfen...

    Ralf


    Donnerstag, 26. Mai 2011 11:14
  • Hallo Ralf,

    hmm sehr seltsam. Irgendwo ist da der Wurm oder ein Denkfehler drin. Hast du schon mal einen Case deswegen beim CSS auf gemacht? Ich glaube so wirst du am schnellsten zu einer Lösung kommen.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Donnerstag, 26. Mai 2011 22:13
  • Hallo Christian,

    ich habe soeben einen Case eröffnet.
    Wenn es neue Erkenntnisse gibt werde ich diese hier im Thread veröffentlichen.

    Danke

    Ralf

    Freitag, 27. Mai 2011 08:16
  • Hallo zusammen,

    es scheint als ob wir dieses Problem zusammen mit dem MS-Support lösen konnten.

    - wir hatten folgende Schritte unternommen:
    1. mittels "netstat -ano" geschaut, was auf dem Port 80 des TMG so los ist. Dort haben wir gesehen, dass der "RPC over HTTP Proxy" wohl den Port 80 belegt hatte.
    (ACHTUNG: Ich habe ja geschrieben, dass wir dieses Problem schon seit über 10 Jahre haben. Damals war es der GFI-WebMonitor, den wir auf dem ISA installiert hatten. Vermutlich hatte der zu diesem Zeitpunkt den Port blockiert... - UND: In der USA ist der TMG ein DELL-Server. Dort blockierte (wie sich hier in der Analyse gezeigt hatte) der DELL-IT-Assistant den Port 80...)

    2. die Variante den wpad-Eintrag zweimal im DNS zu veröffentlichen war total daneben. Der ping gab hier einmal den französischen und das andere mal den deutschen wpad zurück. Ergo war dies Fehlerquelle Nr. 2

    3. wir haben uns für die Variante mittels Option 252 des DHCP-Servers entschieden. (Für die Server mit fester IP habe ich später einen WMI-Filter in den GPOs angelegt. Das funzt jetzt auch hervorragend...)

    4. der vierte Fehler war, dass ich im wpad-Eintrag die // vergessen hatte.

    Lokalisiert hatten wir das alles, indem ich zusammen mit dem MS-Supporter eine „eigene“ wpad.dat auf einem Webserver veröffentlicht hatte.
    Diese wpad.dat hatte die Aufgabe Rückmeldungen an meinen Client zu senden, sobald der Browser aktiv wird.
    Dazu hatte ich vor ca. 2 Wochen die Option 252 kurzfristig umgestellt zur URL: http://IrgendeinInternerWebserver:80/wpad.dat und an meinem PC nach ipconfig/relase und renew getestet.
    Der Test war damals nicht erfolgreich! (D.h. ich bekam keine Rückmeldung vom IE).

    - Gestern gegen 13:30 Uhr erhielt ich dann auf einmal zig „Proxy script request for…“ Meldungen.
    - Der erste Check war mittels ipconfig/all zu überprüfen ob ich gerade ein neues Lease erhalten hatte. Dem war auch so.
    - Allerdings war komisch, dass ich den o.g. Eintrag zurück erhalten hatte, denn dieser war damals nur für ein paar Minuten in der Option 252 hinterlegt, bevor ich diese zu http://tmg:80/wpad.dat geändert und den DHCP-Server neu gestartet hatte.
    - Geholfen hat hier das zurücksetzen des RegKeys: „MigrateProxy“ (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings MigrateProxy auf DWORD:0 )
    - Es war dann zu sehen, dass ich die richtige URL zurückbekomme, aber die Funktion war leider immer noch nicht wie gewünscht gegeben.

    Nun der letzte Lösungsschritt:
    - Im internet-Explorer ALLE Häkchen in den Verbindungseinstellungen entfernen
    - Browser schließen und neu starten
    - NUR das Häkchen bei „Automatische Suche der Einstellungen“ setzen
    - Browser neu starten
    - Voila: Funktion i.O. !!!

    Wir haben im Anschluß daran an einigen Rechnern die Leases mit ipconfig/release und anschließendem Renew erneuert.
    Anschließend immer wieder die Funktion getestet, bis die „Lösungsschritte“ durchlaufen waren.
    IMMER nach dem das Häkchen einmal entfernt und nach dem Neustart wieder gesetzt wurde, hat es funktioniert!

    Heute haben wir dieses Spiel an ca. 100 Clients mit vollem Erfolg wiederholt!

     

    Danke an alle Beteiligten für eure Mithilfe!

    Ralf Wiedemer

    Dienstag, 5. Juli 2011 14:37