none
Clients registrieren sich nicht in DNS auf SBS2008 RRS feed

  • Frage

  • Hallo zusammen,

    Da ich bei der DNS-Auflösung zur Integration eines per VPN-angebundenen Subnetzes in eine SBS-2008-Domäne langsam ratlos werde, wende ich mich an Euch. Es schaut grundsätzlich wie folgt aus:

    a) Subnetz 192.168.7/24, darin:
    - 192.168.7.2 ist eine SBS2008 der Domäne firma.local und arbeitet auch als DNS-Server
    - 192.168.7.1 als Router und VPN-Gegenstelle auf Basis von pfSense
    - kein DHCP

    b) Subnetz 192.168.178/24, darin:
    - 192.168.178.1 als Router auf Basis einer Fritz!Box
    - VPN-Tunnel zu a)
    - Clients, welche 192.168.7.2 als DNS-Server verwenden

    c) Subnetz 192.168.0/24, darin:
    - 192.168.0.1 als Router auf Basis eines Lancom 1821n
    - VPN-Tunnel zu a), benannt als VPN.FIRMA
    - Router führt DNS-Forward für firma.local nach 192.168.7.2 durch
    - Router leistet NetBIOS über IP
    - Clients, Konfiguration siehe unten

    Problem in Kurzfassung: Die Nutzung der Domäne von Clients aus c) funktioniert noch nicht so recht, Anmeldung dauert ewig und DNS-Einträge auf 192.168.7.2 werden nicht aktualisiert. Aus b) hingegen klappt (mit den gleichen Clients/Laptops) alles bestens.

    Die beiden VPN-Tunnel sind ok, auf dem Lancom-Router (192.168.0.1) habe ich Folgendes mit Blick auf die Domain konfiguriert (auf der Fritz!Box wohl alles nicht notwendig ;-)):

    - In "IP-Parameter" einen Eintrag für VPN.FIRMA eingerichtet, dort 192.168.7.2 als ersten DNS und ersten NBNS hinterlegt.
    - In "DNS" die Domäne firma.local als eigene Domäne eingetragen, als weiteren Checkboxen aktiv.
    - In "DNS-Weiterleitungen" für firma.local, *.firma.local und *.7.168.192.in-addr.arpa auf die Gegenstelle VPN.FIRMA verwiesen.
    - In "NetBIOS" ist "NetBIOS über IP Routing aktiviert" eingeschaltet.
    - In der zugehörigen Routing-Tabelle ist VPN.FIRMA als "Einzelne Station" definiert.
    - Auf dem 1821n läuft die letzte Fassung des Firmware (RU2)

    Auflösung von Anfragen *.firma.local per DNS und NetBIOS von den Clients aus c) funktioniert, wenn diese 192.168.0.1 als Router verwenden, tadellos, auch rückwärts. Dies habe ich ein wenig per DNS-Trace auf dem Router verfolgt. Nun bestehen zwei Möglichkeiten, die Clients in c) zu konfigurieren: 1) DNS direkt auf 192.168.7.2 legen oder 2) DNS- und WINS-Weiterleitungen über 192.168.0.1 nutzen.

    Wenn die Clients in b) genutzt werden, habe ich Variante 1) eingestellt und es funktioniert, inklusive Update des DNS-Eintrags auf dem Domänen-Controller (obwohl 192.168.178/24) dort nicht gesondert als Subnetz innerhalb der Site definiert ist. Versuche ich die gleiche Konfiguration in c), so erfolgt keine Aktualisierung des DNS-Eintrags, "ipconfig /registerdns" läuft zwar als UDP-Paket bis zu 192.168.7.2, dort erscheint der Client aber nicht in der Forwardzone des DNS. Debug-Modus des DNS sagt:

    <!-- [if gte mso 10]> <mce:style>

    19.11.2010 08:48:20 025C PACKET  0000000003A62250 UDP Rcv 192.168.0.22    6ecf   Q [0001   D   NOERROR] SOA   (8)LAPTOP22(9)firma(5)local(0)

    19.11.2010 08:48:20 025C PACKET  0000000003A62250 UDP Snd 192.168.0.22    6ecf R Q [8385 A DR NXDOMAIN] SOA   (8)LAPTOP22(9)firma(5)local(0)

    19.11.2010 08:48:20 025C PACKET  0000000003510910 UDP Rcv 192.168.0.22    46d6   U [0028       NOERROR] SOA   (9)firma(5)local(0)

    19.11.2010 08:48:20 06C0 PACKET  0000000003510910 UDP Snd 192.168.0.22    46d6 R U [05a8       REFUSED] SOA   (9)firma(5)local(0)

    ("firma" ist ein Platzhalter) Der SBS weiß also nie, wo sich der Client befindet, ich vermute, dies ist die Ursache für die schlechte Nutzbarkeit der Domäne von den Clients aus c).

    Verwende ich als DNS- und WINS-Server in c) den lokalen Router (192.168.0.1) gemäß Variante 2), so wird die Registrierung der Clients in dessen DNS auch vorgenommen, es erfolgt aber kein Weiterleiten des Updates auf den Domänen-Controller. Da die Zone firma.local im DNS des SBS hinterlegt ist, kann ich für diese keine zusätzliche bedingte Weiterleitung nach 192.168.0.1 einrichten. Wenn ich eine "vollständige" Weiterleitung im DNS auf dem SBS definiere, sehen die Anfragen, welche auf 192.168.0.1 eingehen, so (Lancom-Trace) aus:

    [DNS] 2010/11/19 08:45:04,290
    DNS Rx (VPN.FIRMA): Src-IP 192.168.7.2
    Query Request: STD PTR for 6.d.3.8.d.f.7.5.4.8.1.d.6.2.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa
    Bad coded request

    Ist das eine reine IPv6-Anfrage, welche der lokale Router nicht versteht? Außerdem würde ich mit dieser Konfiguration einen Loop definieren, da der SBS ja zugleich als Forward in 192.168.0.1 eingetragen ist.

    Kurzum, in beiden Fällen ist die Domänen-Nutzung sehr zäh, weil der Client nicht im DNS des Domänen-Controllers eingetragen ist. Aber: Warum funktioniert das Ganze, wenn ich aus dem Netz b) über die Fritz!Box ansonsten identisch vorgehe? Hat jemand eine Idee, welche Konfiguration ich noch im Lancom-Router oder auf dem SBS vornehmen muss?

    Danke!

    viele Grüße,

      Thorsten

    Freitag, 19. November 2010 08:11

Antworten

  • So, das hat geholfen. Ich fasse nachfolgend zusammen, falls andere Nutzer über das gleiche Problem per Suchfunktion stolpern. Der LANCOM-Router war ingesamt also recht "unschuldig", um die Domänenanmeldung (bei üblichen MTU) von WinXP-Clients sinnvoll über einen VPN-Tunnel durchführen zu können, war Folgendes notwendig:

    - Hotfix von KB-Artikel 816045 anwendungen und PingBufferSize auf 1024 Byte herabsetzen.

    - Autosensing der Netzwerkkarten abschalten.

    - Anmeldung per Kerberos per UDP unterbinden, dazu KB-Artikel 244474 nutzen.

    Die fehlende Registrierung der Clients im DNS des SBS lag vermutlich daran, dass diese nicht vollständig authentifizert waren.

    Tobias, nochmals vielen Dank für Deine hilfreichen Denkanstösse!

    viele Grüße,

      Thorsten

    Montag, 22. November 2010 10:20

Alle Antworten

  • Hi Thorsten,
     
    > Da ich bei der DNS-Auflösung zur Integration eines per VPN-angebundenen
    > Subnetzes in
    > eine SBS-2008-Domäne langsam ratlos werde, wende ich mich an Euch. Es
    > schaut grundsätzlich
    > wie folgt aus:
    >
    > a) Subnetz 192.168.7/24, darin:
    > - 192.168.7.2 ist eine SBS2008 der Domäne firma.local und arbeitet auch
    > als DNS-Server
    > - 192.168.7.1 als Router und VPN-Gegenstelle auf Basis von pfSense
    > - kein DHCP
    >
    > b) Subnetz 192.168.178/24, darin:
    > - 192.168.178.1 als Router auf Basis einer Fritz!Box
    > - VPN-Tunnel zu a)
    > - Clients, welche 192.168.7.2 als DNS-Server verwenden
    >
    > c) Subnetz 192.168.0/24, darin:
    > - 192.168.0.1 als Router auf Basis eines Lancom 1821n
    > - VPN-Tunnel zu a), benannt als VPN.FIRMA
    > - Router führt DNS-Forward für firma.local nach 192.168.7.2 durch
    > - Router leistet NetBIOS über IP
    > - Clients, Konfiguration siehe unten
    >
    > Problem in Kurzfassung: Die Nutzung der Domäne von Clients aus c)
    > funktioniert noch nicht so
    > recht, Anmeldung dauert ewig und DNS-Einträge auf 192.168.7.2 werden nicht
    > aktualisiert.
    > Aus b) hingegen klappt (mit den gleichen Clients/Laptops) alles bestens.
     
    ohne mir jetzt den Rest (der zwar sehr detailliert, in diesem Fall jedoch
    eher verwirrend denn zielführend für eine Erstanfrage in einem Forum ist)
    genauer angesehen zu haben vermute ich genau darin Dein Problem:
     
    > - Router führt DNS-Forward für firma.local nach 192.168.7.2 durch
     
    Stell bei den Clients (die sich ja am DNS-SERVER und nicht am Router mit
    dessen - womöglich fehlerhaften implementierten - DNS-PROXY) als DNS-Server
    die IP des AD-integriertem DNS Server deren Domäne ein (hier: 192.168.7.2)
    und es sollte (wie eben auch im Subnet b) funktionieren, WENN der LANCOM
    nicht noch etwas vor dem VPN-Tunnel filtert (diesbzgl. musst Du dessen
    Handbuch und/oder Support-Hotline in Anspruch nehmen).
     
    Auch wenn Du diese Konstellation schon einmal genau so umgesetzt hast, ist
    meines Erachtens nur diese richtig und es liegen evtl. zusätzliche Fehler
    (z.B. Firewall-Funktion des LANCOM-Routers) vor.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Freitag, 19. November 2010 09:22
    Moderator
  • Hallo Tobias,

     

    Danke für die schnelle Antwort! Nachdem die alternative Variante mit dem DNS-Forward auch nicht zum gewünschten Ziel führte, habe ich nochmal die Aufnahme eines Clients unter Verwendung von DNS-Server 192.168.7.2 (der SBS) versucht. Parallel habe ich verfolgt, was sich im Paketfilter des LANCOM-Routers und der VPN-Gegenstelle abspielte und was der AD-integrierte DNS so loggte.

    Zwischen den beiden Subnetzen (nach oben gewählter Nomenklatur von c) nach a)) bleiben nur NetBIOS-Anfragen hängen. Diese dürften ja für das betrachtete Problem irrelevant sein, oder? Ansonsten läuft alles zwischen Client ("LAPTOP22", 192.168.0.22) und dem Server durch. Die Anmeldung an der Domäne meldet auch Erfolg, benutzt habe ich diesmal die launcher.exe, die über http://connect bereitgestellt wird.

    Interessant ist ggf., was auf den Registrierungsversuch des Clients im DNS folgt:

    19.11.2010 12:35:54 025C PACKET 00000000030C7C70 UDP Rcv 192.168.0.22  537d  Q [0001  D  NOERROR] SOA  (8)LAPTOP22(9)firma(5)local(0)
    UDP question info
    Socket = 380
    Remote addr 192.168.0.22, port 52398
    Time Query=2050915, Queued=0, Expire=0
    Buf length = 0x0500 (1280)
    Msg length = 0x002a (42)
    Message:
    XID 0x537d
    Flags 0x0100
    QR 0 (QUESTION)
    OPCODE 0 (QUERY)
    AA 0
    TC 0
    RD 1
    RA 0
    Z 0
    RCODE 0 (NOERROR)
    QCOUNT 1
    ACOUNT 0
    NSCOUNT 0
    ARCOUNT 0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name "(8)LAPTOP22(9)firma(5)local(0)"
    QTYPE SOA (6)
    QCLASS 1
    ANSWER SECTION:
    empty
    AUTHORITY SECTION:
    empty
    ADDITIONAL SECTION:
    empty

    19.11.2010 12:35:54 025C PACKET 00000000030C7C70 UDP Snd 192.168.0.22 537d R Q [8385 A DR NXDOMAIN] SOA (8)LAPTOP22(9)firma(5)local(0)
    UDP response info
    Socket = 380
    Remote addr 192.168.0.22, port 52398
    Time Query=2050915, Queued=0, Expire=0
    Buf length = 0x0200 (512)
    Msg length = 0x0072 (114)
    Message:
    XID 0x537d
    Flags 0x8583
    QR 1 (RESPONSE)
    OPCODE 0 (QUERY)
    AA 1
    TC 0
    RD 1
    RA 1
    Z 0
    RCODE 3 (NXDOMAIN)
    QCOUNT 1
    ACOUNT 0
    NSCOUNT 1
    ARCOUNT 1
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name "(8)LAPTOP22(9)firma(5)local(0)"
    QTYPE SOA (6)
    QCLASS 1
    ANSWER SECTION:
    empty
    AUTHORITY SECTION:
    Offset = 0x002a, RR count = 0
    Name "[C015](9)firma(5)local(0)"
    TYPE SOA (6)
    CLASS 1
    TTL 3600
    DLEN 44
    DATA
    PrimaryServer: (8)gotthard[C015](9)firma(5)local(0)
    Administrator: (10)hostmaster[C015](9)firma(5)local(0)
    SerialNo = 416
    Refresh = 900
    Retry = 600
    Expire = 86400
    MinimumTTL = 3600
    ADDITIONAL SECTION:
    Offset = 0x0062, RR count = 0
    Name "[C036](8)gotthard[C015](9)firma(5)local(0)"
    TYPE A (1)
    CLASS 1
    TTL 3600
    DLEN 4
    DATA 192.168.7.2

    19.11.2010 12:35:54 025C PACKET 0000000003AE92D0 UDP Rcv 192.168.0.22 5bf2 U [0028 NOERROR] SOA (9)firma(5)local(0)
    UDP question info
    Socket = 380
    Remote addr 192.168.0.22, port 57321
    Time Query=2050915, Queued=0, Expire=0
    Buf length = 0x0500 (1280)
    Msg length = 0x0061 (97)
    Message:
    XID 0x5bf2
    Flags 0x2800
    QR 0 (QUESTION)
    OPCODE 5 (UPDATE)
    AA 0
    TC 0
    RD 0
    RA 0
    Z 0
    RCODE 0 (NOERROR)
    ZCOUNT 1
    PRECOUNT 1
    UPCOUNT 2
    ARCOUNT 0
    ZONE SECTION:
    Offset = 0x000c, RR count = 0
    Name "(9)firma(5)local(0)"
    ZTYPE SOA (6)
    ZCLASS 1
    PREREQUISITE SECTION:
    Offset = 0x0021, RR count = 0
    Name "(8)LAPTOP22(9)firma(5)local(0)"
    TYPE CNAME (5)
    CLASS 254
    TTL 0
    DLEN 0
    DATA (none)
    UPDATE SECTION:
    Offset = 0x0045, RR count = 0
    Name "[C021](8)LAPTOP22(9)firma(5)local(0)"
    TYPE A (1)
    CLASS 255
    TTL 0
    DLEN 0
    DATA (none)
    Offset = 0x0051, RR count = 1
    Name "[C021](8)LAPTOP22(9)firma(5)local(0)"
    TYPE A (1)
    CLASS 1
    TTL 1200
    DLEN 4
    DATA 192.168.0.22
    ADDITIONAL SECTION:
    empty

    19.11.2010 12:35:54 06C0 PACKET 0000000003AE92D0 UDP Snd 192.168.0.22 5bf2 R U [05a8 REFUSED] SOA (9)firma(5)local(0)
    UDP response info
    Socket = 380
    Remote addr 192.168.0.22, port 57321
    Time Query=2050915, Queued=0, Expire=0
    Buf length = 0x0500 (1280)
    Msg length = 0x0061 (97)
    Message:
    XID 0x5bf2
    Flags 0xa805
    QR 1 (RESPONSE)
    OPCODE 5 (UPDATE)
    AA 0
    TC 0
    RD 0
    RA 0
    Z 0
    RCODE 5 (REFUSED)
    ZCOUNT 1
    PRECOUNT 1
    UPCOUNT 2
    ARCOUNT 0
    ZONE SECTION:
    Offset = 0x000c, RR count = 0
    Name "(9)firma(5)local(0)"
    ZTYPE SOA (6)
    ZCLASS 1
    PREREQUISITE SECTION:
    Offset = 0x0021, RR count = 0
    Name "(8)LAPTOP22(9)firma(5)local(0)"
    TYPE CNAME (5)
    CLASS 254
    TTL 0
    DLEN 0
    DATA (none)
    UPDATE SECTION:
    Offset = 0x0045, RR count = 0
    Name "[C021](8)LAPTOP22(9)firma(5)local(0)"
    TYPE A (1)
    CLASS 255
    TTL 0
    DLEN 0
    DATA (none)
    Offset = 0x0051, RR count = 1
    Name "[C021](8)LAPTOP22(9)firma(5)local(0)"
    TYPE A (1)
    CLASS 1
    TTL 1200
    DLEN 4
    DATA 192.168.0.22
    ADDITIONAL SECTION:
    empty

    Warum wird mit NXDOMAIN geantwortet? Die Zone firma.local ist vorhanden und Clients aus dem Subnetz b) hinterlassen dort auch wie gewünscht ihre Spuren. Dynamische Updates sind für die Zone auf "nur sichere" Quellen gestellt.

    Zur Vervollständigung noch die Netzwerkkonfiguration des Clients:

    Windows-IP-Konfiguration

    Hostname. . . . . . . . . . . . . : LAPTOP22
    Primäres DNS-Suffix . . . . . . . : firma.local
    Knotentyp . . . . . . . . . . . . : Gemischt
    IP-Routing aktiviert. . . . . . . : Nein
    WINS-Proxy aktiviert. . . . . . . : Nein
    DNS-Suffixsuchliste . . . . . . . : firma.local
    firma.local

    Ethernetadapter Drahtlose Netzwerkverbindung:

    Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
    Beschreibung. . . . . . . . . . . : Intel(R) PRO/Wireless 3945ABG Networ
    k Connection
    Physikalische Adresse . . . . . . : 00-13-02-99-94-D3

    Ethernetadapter LAN-Verbindung:

    Verbindungsspezifisches DNS-Suffix: firma.local
    Beschreibung. . . . . . . . . . . : Intel(R) PRO/1000 PL Network Connect
    ion
    Physikalische Adresse . . . . . . : 00-16-41-E0-2B-39
    DHCP aktiviert. . . . . . . . . . : Nein
    IP-Adresse. . . . . . . . . . . . : 192.168.0.22
    Subnetzmaske. . . . . . . . . . . : 255.255.255.0
    Standardgateway . . . . . . . . . : 192.168.0.1
    DNS-Server. . . . . . . . . . . . : 192.168.7.2
    Liegt's tatsächlich am NetBIOS? Ratlos... ;-)

     

    schöne Grüße,

      Thorsten

    Freitag, 19. November 2010 11:51
  • Hi Thorsten,
     
    > Nachdem die alternative Variante mit dem DNS-Forward auch nicht zum
    > gewünschten Ziel
    > führte, habe ich nochmal die Aufnahme eines Clients unter Verwendung von
    > DNS-Server
    > 192.168.7.2 (der SBS) versucht. Parallel habe ich verfolgt, was sich im
    > Paketfilter des
    > LANCOM-Routers und der VPN-Gegenstelle abspielte und was der
    > AD-integrierte DNS so loggte.
    >
    > Zwischen den beiden Subnetzen (nach oben gewählter Nomenklatur von c) nach
    > a)) bleiben
    > nur NetBIOS-Anfragen hängen. Diese dürften ja für das betrachtete Problem
    > irrelevant sein, oder?
    > Ansonsten läuft alles zwischen Client ("LAPTOP22", 192.168.0.22) und dem
    > Server durch. Die
    > Anmeldung an der Domäne meldet auch Erfolg, benutzt habe ich diesmal die
    > launcher.exe, die über
    > http://connect bereitgestellt wird.
    >
    > Interessant ist ggf., was auf den Registrierungsversuch des Clients im DNS
    > folgt:
    [..]
    > Warum wird mit NXDOMAIN geantwortet? Die Zone firma.local ist vorhanden
    > und Clients
    > aus dem Subnetz b) hinterlassen dort auch wie gewünscht ihre Spuren.
    > Dynamische Updates
    > sind für die Zone auf "nur sichere" Quellen gestellt.
     
    spontan fällt mir dazu das Verhalten "DNS-Rewrite" ein, dass z.B. u.a. bei
    einer Cisco Router konfigurierbar ist:
     
    PIX/ASA: Perform DNS Doctoring [rewrite DNS records] with the static Command
    and Two NAT Interfaces Configuration Example
    http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml
     
    Evtl. macht der zugehörige ("intelligente") LANCOM hier etwas ähnliches, was
    in diesem Fall jedoch ein Fehlverhalten ist.
     
    Das es dann evtl. an der Konfiguration des LANCOMs liegen MUSS, kannst Du
    einfach testen, indem Du, bei sonst identischer Netzwerktopologie, den
    ("intelligente") LANCOM testweise durch einen ("dummen") Billig-Router
    ersetzt.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Freitag, 19. November 2010 14:18
    Moderator
  • Hallo Tobias,
     
    > Evtl. macht der zugehörige ("intelligente") LANCOM hier etwas ähnliches, was
    > in diesem Fall jedoch ein Fehlverhalten ist.
     
    Beim DNS tut er es wohl nicht, der angestrebte Eintrag schaut ok aus. Zwischenzeitlich habe ich dem LANCOM mittels Neustart (bei unveränderter Konfiguration, super ;-)) beigebracht, dass über den VPN-Tunnel auch NetBIOS-Anfragen zulässig sind. Ein Neustart des DNS auf dem SBS und eine abermalige Neuaufnahme des Clients half, dass nun auch die Registrierung im DNS durch den Client funktioniert. Reicht aber offensichtlich noch immer nicht...
     
    > Das es dann evtl. an der Konfiguration des LANCOMs liegen MUSS, kannst Du
    > einfach testen, indem Du, bei sonst identischer Netzwerktopologie, den
    > ("intelligente") LANCOM testweise durch einen ("dummen") Billig-Router
    > ersetzt.
     
    Offensichtlich denkt ein Gerät auf der Strecke zu stark über die größe von ICMP-Paketen nach, denn im Event-Log finde ich bei Anmeldung auf allen Clients die Meldungen
    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1054
    Date: 19.11.2010
    Time: 19:05:47
    User: NT AUTHORITY\SYSTEM
    Computer: DESKTOP21
    Description:
    Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    und
    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1054
    Date:  19.11.2010
    Time:  19:06:21
    User:  NT AUTHORITY\SYSTEM
    Computer: DESKTOP21
    Description:
    Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Nach bisherigem Ergebnis bei Google ist dies auf eine unterstellte zu geringe Geschwindigkeit der Verbindung zum DC zurückzuführen. Pakete mit mehr als 1400 Bytes laufen auch tatsächlich in keine Richtung durch. Bisherige Versuche, dies über den Registry-Eintrag zu fixen, haben nichts gebracht. Und die Installation des Hotfixes auf der KnowledgeBase hat einen anderen Rechner beim Anmelden nun ziemlich lahmgelegt ;-)
    Suche ich an der richtigen Stelle oder kommen für die Meldungen noch andere Ursachen in Frage?
    schöne Grüße,
      Thorsten
    Freitag, 19. November 2010 18:22
  • Hi Thorsten,
     
    > Offensichtlich denkt ein Gerät auf der Strecke zu stark über die größe von
    > ICMP-Paketen nach,
    > denn im Event-Log finde ich bei Anmeldung auf allen Clients die Meldungen
    >
    > Event Type: Error
    > Event Source: Userenv
    > Event Category: None
    > Event ID: 1054
    > Date: 19.11.2010
    > Time: 19:05:47
    > User: NT AUTHORITY\SYSTEM
    > Computer: DESKTOP21
    > Description:
    > Windows cannot obtain the domain controller name for your computer
    > network. (An unexpected
    > network error occurred. ). Group Policy processing aborted.
    >
    > For more information, see Help and Support Center at
    > http://go.microsoft.com/fwlink/events.asp.
    >
    > und
    > Event Type: Error
    > Event Source: Userenv
    > Event Category: None
    > Event ID: 1054
    > Date: 19.11.2010
    > Time: 19:06:21
    > User: NT AUTHORITY\SYSTEM
    > Computer: DESKTOP21
    > Description:
    > Windows cannot obtain the domain controller name for your computer
    > network. (An unexpected
    > network error occurred. ). Group Policy processing aborted.
    > For more information, see Help and Support Center at
    > http://go.microsoft.com/fwlink/events.asp.
    >
    > Nach bisherigem Ergebnis bei Google ist dies auf eine unterstellte zu
    > geringe Geschwindigkeit der
    > Verbindung zum DC zurückzuführen. Pakete mit mehr als 1400 Bytes laufen
    > auch tatsächlich in
    > keine Richtung durch. Bisherige Versuche, dies über den Registry-Eintrag
    > zu fixen, haben nichts
    > gebracht. Und die Installation des Hotfixes auf der KnowledgeBase hat
    > einen anderen Rechner
    > beim Anmelden nun ziemlich lahmgelegt ;-)
    >
    > Suche ich an der richtigen Stelle oder kommen für die Meldungen noch
    > andere Ursachen in Frage?
     
    wie sind denn die Latenzen zwischen Client im Subnetz c.) und der Zentrale
    mit DC im Subnetz a.)?
     
    RPC-Anfragen sind diesbzgl. ziemlich empfindlich, wenn es sich um
    Verzögerungen >200ms (roundtrip) handelt.
     
     
    S.a.:
    http://www.eventid.net/display.asp?eventid=1054&eventno=1393&source=Userenv&phase=1
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Samstag, 20. November 2010 11:59
    Moderator
  • Hallo Tobias,

    Danke für Deine abermalige Antwort!

    > wie sind denn die Latenzen zwischen Client im Subnetz c.) und der Zentrale
    > mit DC im Subnetz a.)?
    >
    > RPC-Anfragen sind diesbzgl. ziemlich empfindlich, wenn es sich um
    > Verzögerungen >200ms (roundtrip) handelt.

    Die sollten klein genug sein. Über die Event-ID 1054 war ich zwischenzeitlich auch etwas weiter gekommen:

    Ich habe den Hotfix KB816045 angewendet und die Größe der ICMP-Pakete zur Feststellung der Verbindungsgeschwindigkeit auf 1024 Byte heruntergesetzt. Das hat's gefühlt schon etwas besser gemacht. Ein wenig Stöbern über die MTU der VPN-Verbindung seitens beider Router zeigte, dass die eigentlich ordentlich gesetzt sein sollten (1392 für die VPN-Verbindung). Gemäß den Tipps auf evendit.net half es, das Autosensing der GBit-Netzwerkkarte abzuschalten und diese manuell auf MBit und VollDuplex zu stellen. Eine Event-ID 1054 habe ich seitdem nicht mehr gesehen.

    Ein "gpudate /force" läuft, zumindest wenn man das Timeout über die sechs Minuten erhöht, ordentlich durch. (Die Verbindung ist eigentlich ordentlich schnell.) In der SBS-Konsole wird der Client nun auch endlich vollständig angezeigt, inklusive Online-Status und Systeminformationen. Ich werde nun bei folgenden verbleibenden Meldungen für die weitere Fehlereingrenzung ansetzen:

    - Event-ID 1053 "Der Benutzer oder der Computername kann nicht ermittelt werden. [...] Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.".
    - LsaSrv 40961 "Das Sicherheitssystem konnte keine sichere Verbindung mit dem Server cifs/NAMEdesDC herstellen. Es war kein Authentifizierungsprotokoll verfügbar" und
    - LsaSrv 40960 "Das Sicherheitssystem hat einen versuchten Herunterstufungsangriff für den Server cifs/NamedesDB festgestellt. Der Fehlercode des Authentifizierungsprotokolls Kerberos war 'Es stehen momentan keine Anmeldeserver zur Verfügung, um die Anmeldeanforderung zu verarbeiten.".
    - Kerberos 10 "Das Kerberos-Subsystem kann die Tickets vom Domänencontroller mit dem UDP-Netzwerkprotokoll nicht abrufen. Häufige Ursache hierfür sind Netzwerkprobleme. Wenden Sie sich an den Systemadministrator."

    Zum Zeitpunkt, wenn 1053 auftritt, steht die Netzwerkverbindung (ich greife gegenwärtig von außerhalb per RDP auf den Client zu). Paketfilter auf dem Client ist gegenwärtig völlig abgeschaltet. Auf dem SBS ist im Paketfilter "Anmeldedienst" nicht aktiv (war er dann auch nie, habe ich nicht verändert.) Letzteres belasse ich zunächst so (oder?), schaue, ob etwas Verdächtiges im Logfile auftritt und habe gerade KB244474 angewendet. Ich vermute, dass die großen UDP-Pakete auch nicht sauber durch den VPN-Tunnel laufen.

    Mal schauen, was nun passiert ;-)

    viele Grüße,
      Thorsten

    Sonntag, 21. November 2010 12:57
  • So, das hat geholfen. Ich fasse nachfolgend zusammen, falls andere Nutzer über das gleiche Problem per Suchfunktion stolpern. Der LANCOM-Router war ingesamt also recht "unschuldig", um die Domänenanmeldung (bei üblichen MTU) von WinXP-Clients sinnvoll über einen VPN-Tunnel durchführen zu können, war Folgendes notwendig:

    - Hotfix von KB-Artikel 816045 anwendungen und PingBufferSize auf 1024 Byte herabsetzen.

    - Autosensing der Netzwerkkarten abschalten.

    - Anmeldung per Kerberos per UDP unterbinden, dazu KB-Artikel 244474 nutzen.

    Die fehlende Registrierung der Clients im DNS des SBS lag vermutlich daran, dass diese nicht vollständig authentifizert waren.

    Tobias, nochmals vielen Dank für Deine hilfreichen Denkanstösse!

    viele Grüße,

      Thorsten

    Montag, 22. November 2010 10:20
  • Hi Thorsten,
     
    > So, das hat geholfen. Ich fasse nachfolgend zusammen, falls andere Nutzer
    > über das gleiche
    > Problem per Suchfunktion stolpern. Der LANCOM-Router war ingesamt also
    > recht "unschuldig",
    > um die Domänenanmeldung (bei üblichen MTU) von WinXP-Clients sinnvoll über
    > einen
    > VPN-Tunnel durchführen zu können, war Folgendes notwendig:
    >
    > - Hotfix von KB-Artikel 816045 anwendungen und PingBufferSize auf 1024
    > Byte herabsetzen.
    >
    > - Autosensing der Netzwerkkarten abschalten.
    >
    > - Anmeldung per Kerberos per UDP unterbinden, dazu KB-Artikel 244474
    > nutzen.
    >
    > Die fehlende Registrierung der Clients im DNS des SBS lag vermutlich
    > daran, dass diese nicht
    > vollständig authentifizert waren.
     
    Danke für's sehr aufschlussreiche Feedback. Auch wir haben wieder etwas dazu
    gelernt :)
     
     
    > Tobias, nochmals vielen Dank für Deine hilfreichen Denkanstösse!
     
    Man ist immer gern zu Diensten :)
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Montag, 22. November 2010 11:32
    Moderator