Jump to content

IThome

Members
  • Gesamte Inhalte

    17.751
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von IThome

  1. Mit den Angaben kann man nicht viel sagen. Wie stellt der Server die Verbindung ins Internet her ? Wen hat er als Gateway ? Wen haben die internen Clients als Gateway ? Welchen Adressbereich bekommen die VPN-Clients ? Routet der RRAS auch nach innen ?
  2. Dann erzeuge Dir eine neue Richtlinie, die Du in die Domain Controllers OU linkst und nach oben schiebst. In diesem GPO stellst Du die Loopbackverarbeitung ein und die Benutzereinstellungen. In der Sicherheitsfilterung verweigerst Du den Domänenadmins "Gruppenrichtlinie übernehmen". Weiterhin muss auf dem DC das Benutzerrecht "Anmelden über Terminaldienste zulassen" angepasst werden, so dass die Remotedesktopbenutzer und Administratoren dieses Recht gewährt wird. Für diese Änderung auch ein GPO erzeugen und dieses GPO über die Default Domain Controllers Policy platzieren. Sicher ist es nicht, die Benutzer melden sich am DC an ...
  3. HAst Du einen DC oder mehrere ?
  4. Nach endloser Snifferei und Rumprobierei hier die (hoffentlich richtige) Lösung für das genannte Verhalten: Die Domäne XYZ.AT ist eine offizielle Domäne im Internet, intern wurde eine Zone ABC.XYZ.AT erstellt, obwohl die externe Domäne nichts mit der Firma zu tun hat. In den Clienteigenschaften ist für das Auflösen unvollständiger Namen der Haken "Primäre und verbindungsspezifische DNS-Suffixe anhängen" und "Übergeordnete Suffixe des primären DNS-Suffix anhängen" ausgewählt. Der Client hat kein Verbindungssuffix, nur den primären Suffix ABC.XYZ.AT. Wenn ein Name wie -WWW.GOOGLE.DE- im Browser eingegeben wird, prüft der Resolver, ob es sich um einen FQDN handelt. In diesem Fall handelt es sich nicht um einen FQDN, da kein abschliessender Punkt vorhanden ist. Es handelt sich also um einen Multiple-Label Unqualified Domain Name. Der Resolver hängt an diesen Namen den Punkt an und macht ihn so zu einem FQDN. Diese ANfrage wird an den lokalen DNS-Server geschickt, der die Anfrage weiterleitet und von einem DNS-Server im Internet eine richtige Antwort bekommt. So weit, so gut ... Was aber passiert, wenn man im Browser einen falschen Namen wie -www.irgendwas.at- angibt ? Der Resolver prüft wieder den Namen, stellt fest, dass es ein Multiple-Label Unqualified Domain Name ist und hängt einen Punkt an, um ihn zum FQDN zu machen. Diese ANfrage wird zum DNS-Server geschickt, der ist nicht zuständig und leitet es weiter, bekommt vom externen DNS-Server eine negative Antwort und leitet sie zum Client. Da das Anfügen eines Punktes nicht zum Erfolg geführt hat, behandelt der Resolver den Multiple-Label Unqualified Domain Name wie einen SIngle-Label Unqualified Domain Name, also einen Namen, der gar keinen Punkt enthält. In diesem Falle wirken die Einstellungen der Auflösung unvollständiger Namen. Da die Clients wie oben beschrieben eingestellt waren, hängt der Resolver den primären DNS-Suffix an und schickt dann die Abfrage -WWW.IRGENDWAS.DE.ABC.XYZ.AT- zu seinem lokalen DNS-Server. Dieser ist für die Zone ABC.XYZ.AT zuständig, kennt aber die Domäne DE nicht und liefert eine negative Antwort zurück. Nach Fehlschlagen dieser Anfrage führt der Client Devolution aus, er hängt also den übergeordneten Suffix des primären Suffixes an, danach wieder den übergeordneten usw. , bis entweder aufgelöst wurde oder 2 Labels überbleiben (also XYZ.AT in diesem Fall). Die Anfrage lautet also -WWW.IRGENDWAS.DE.XYZ.AT- und wird zum lokalen DNS-Server geschickt. DIeser ist nicht zuständig und schickt sie zum DNS-Server im Internet. Jetzt kommt der DNS-Server von XYZ.AT ins Spiel, der die Unterdomäne DE nicht kennt und eine Adresse einer Seite zurückliefert (die "falsche" Seite, die der interne Client angezeigt bekommt, wenn er sich vertippt hat). Wird am Client jetzt entweder der Haken "Übergeordnete Suffixe des primären DNS-Suffix anhängen" entfernt oder es wird eine benutzerdefinierte Suchliste mit dem Namen des primären DNS-Suffixes erstellt, wird der übergeordnete DNS-Suffix nicht mehr angehängt, die Anfrage landet also nicht mehr beim DNS-Server von XYZ.AT im Internet und wird negativ beantwortet. Ebenso, wenn an die falsche Anfrage ein Punkt angehängt wird, es also ein FQDN ist, an den kein Suffix mehr angehängt wird. Entweder ist das jetzt korrekt so oder es ist absolut daneben recherchiert, daher möchte ich Euch bitten, es zu berichtigen, falls es fehlerhaft sein sollte , Danke :)
  5. NETDIAG /FIX schon durchgeführt ?
  6. Eröffne einen eigenen Thread und übernehme keinen anderen ...
  7. Bist Du sicher, dass das die 37 und nicht die 32 war ? Wenn eine 0 vorangestellt wird, ist das eine Oktalzahl, 040 oktal ist 32 dezimal ...
  8. Wie ist der Domänenname ? Domäne ? Oder hast Du das Log abgeändert ?
  9. Hehe, Guru :D Ich weiss nicht, warum sich das Clientsystem bei Einstellung des Standards ohne den Haken "übergeordnete Suffixe des primären DNS-Suffixes anhängen" anders verhält, als wenn man das primäre Suffix in die benutzerdefinierte Suchliste schreibt. Warum hängt er das übergeordnete Suffix nach Fehlschlagen der Auflösung (wenn man einen nicht existenten FQDN angibt) an den FQDN und warum funktioniert die Auflösung, wenn an den FQDN ein Punkt angehängt wird. Beides verhält sich "normal", wenn eine benutzerdefinierte Suffuxsuchliste erzeugt wird, falsche Adressen werden nicht aufgelöst, existente URLs werden aufgelöst, ohne einen Punkt hinten anzustellen. Naja, nochmal den Sniffer anstellen, vielleicht ist ja noch was zu finden ...
  10. Wieso 12 Minuten, ich dachte immer, ne halbe Stunde ...
  11. Kann dieses Programm mit deaktivierter Firewall zugreifen ? Wenn nicht, könnte es am aktiven FTP-Zugriff liegen, welcher entweder im Programm auf passiv gestellt wird oder die Firewall der Firma muss aktives FTP erlauben ...
  12. So lange man die zwischengespeicherten Kopien der servergespeicherten Profile nicht löschen lässt und Cached Credentials nicht abgeschaltet werden, klappt das ja auch sehr gut ...
  13. Er hängt die Suffixe eigentlich erst dann an, wenn ein unvollständiger Name aufgelöst werden soll, wenn Du beispielsweise nur \\SERVER eingibst und nicht \\SERVER.DOMAIN.DE. Per Default wird dann der primäre DNS-Suffix bzw. der verbindungsspezifische Suffix (z.B. über DHCP verteilt) an den unvollständigen Namen gehängt und diese Anfrage zum Server geschickt. Ist diese Anfrage erfolglos, wird der übergeordnete Suffix des primären Suffixes angehängt. Wird ein FQDN angegeben, wird eigentlich nichts angehängt (wozu auch, der Name ist ja nicht unvollständig). Der DNS-Server des 2003-Servers bekommt nun so eine Anfrage nach einem jetzt vollständigen Namen und weiss, welcher Host welcher Domäne aufgelöst werden soll. Ist er authoritativ für den Domänennamen, der abgefragt wird, schaut er in seiner Zonendatei nach. Wenn nicht, leitet er es weiter (unterschiedlich, je nach Konfiguration). Kann er es nicht finden, wie auch immer, bekommt der Client eine negative ANtwort und für den Server ist die Sache erledigt. Ich stelle das mal nach, was sehen, was passiert ... edit: Normalerweise benutzt man intern keinen öffentlichen Adressbereich, der einem nicht selbst gehört. Wenn einem ein externer Bereich gehört, kann man z.B. intern eine Unterdomäne des externen Bereiches erstellen und mit Weiterleitungen und Delegierungen arbeiten ...
  14. Die einfache Dateifreigabe nicht aktiv lassen, also Haken entfernen ...
  15. Der Server hängt eigentlich gar nix dran, das macht der Client, nach den Regeln zur Auflösung unvollständiger Namen (hast Du beim Sniffen doch schon gesehen) ...
  16. Was macht das für einen Unterschied ?
  17. Übreprüfe auf dem Prof-Rechner mal folgendes: 1. Einfache Dateifreigabe (laut Deiner Aussage nicht aktiv) 2. Deaktiviere das Gastkonto 3. öffne SECPOL.MSC auf der Prof-Maschine und stelle den Wert unter Lokale Richtlinien - Sicherheitsoptionen - "Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten" auf Klassisch ein (falls es nicht so eingestellt ist, danach neu starten) 4. Überprüfe mit REGEDIT.EXE auf der Prof-Maschine den folgenden Wert : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\"ForceGuest" , den auf 0, falls er auf steht und dann neu starten
  18. Nein, bei der Standardlizenz muss kein Schlüssel bei sein. Bei Small Business Server Lizenzen steht der Zweck der Lizenzen in der Beschreibung auf dem Aufkleber, es taucht also Small Business in der Beschreibung auf ...
  19. Das kann man zwar ändern, aber trotzdem auf der Prof-MAschine lieber ein neues Kennwort vergeben ... Vielleicht auch mal mit folgender Syntax probieren : <Name des Prof-Rechners>\Administrator ...
  20. Ist auf dem XP-Prof die einfache Dateifreigabe aktiviert ?
  21. IThome

    rdp problem

    :D ...
  22. So langsam glaube ich, dass das eine NSLOOKUP Eigenart ist, die Namensauflösung erfolgt doch korrekt ...
  23. IThome

    rdp problem

    Welche Meldung ist das, der Anhang wird wahrscheinlich eh nicht freigeschaltet ...
  24. Genau dafür gibt es die Ordnerumleitung via Gruppenrichtlinie, darüber findest Du eine Menge bei einem grossen Suchdienstanbieter ...
  25. Was passiert denn, wenn Du IPCONFIG /FLUSHDNS ausführst und dann PING Google eingibst. Was sagt der Sniffer dann ?
×
×
  • Neu erstellen...