Jump to content

slemke

Newbie
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

10 Neutral

About slemke

  • Rank
    Newbie
  1. Hallo, danke für die beiden Links - habe ich mir gerade durchgelesen. Werde in meinem Lab-Setup mich mal weiter in Richtung ADFS / WAP einarbeiten. Schönen Abend, Sebastian
  2. Hallo Norbert, vielen Dank für deine Antworten. Ich arbeite tatsächlich selber im IT-Bereich. Das letzte Mal, dass ich was mit Exchange gemacht habe, war im SBS2003, also schon eine ganze Weile her. Intention ist, das Produkt kennen zu lernen, vielleicht auch mal eine Schulung zu besuchen. Im ersten Schritt habe ich mir den Exchange aus dem Action-Pack geschnappt und los gelegt. Ich glaube auch, ich habe mich ganz gut durchgearbeitet. Jetzt bin ich an einer Stelle, wo ich einfach nicht weiter gekommen bin. Du bist schon bei dem Reverse Proxy, mir fehlte quasi erst einmal ein Überblick, was überhaupt möglich ist – idealerweise mit Vor- und Nachteilen. Deswegen habe ich einfach meine Ideen mal runter geschrieben - und anscheinend auch einiges falsches mit rein geschrieben ;-) Vielleicht etwas unglücklich von mir ausgedrückt. Was ich bisher gemacht habe: Ich habe im Standard-Hosting für das ECP AdminEnabled auf $False gesetzt. Danach habe ich dem Exchange Server eine weitere IP gegeben, auf der ich ebenfalls ECP & OWA eingerichtet habe. Diese IP ist nur intern erreichbar. Somit sollte man extern im OWA Einstellungen vornehmen können, Administrative aber nur intern über die zweite IP, korrekt? Wie gesagt, war ein Gefühl. Jetzt ist natürlich ohne konkretes Umfeld die „Sicherheitsanforderung“ schwer zu greifen. Deswegen mal die umgekehrte Frage: Wie „unsicher“ ist das, wie groß ist die Angriffsfläche hier? Ich meine über Sicherheitsverwundbarkeiten. Schwache Passwörter lassen wir mal außen vor, eine entsprechende Richtlinie war ja sowieso Vorgabe. Ok, klare Aussage – ich wusste schlichtweg nicht, dass das so nicht supported ist (DC / Firewall / Exchange) [Outing off]. Idee war, dass wenn wirklich jemand auf dem Exchange „einbricht“ zunächst einmal noch eine Firewall den DC schützt (deswegen höhere Sicherheit). Benutzerzahl scheint ja unfug gewesen zu sein. Kurzum: Vergessen wir dieses Szenario, unsupported, fällt raus. Ich habe mich hier tatsächlich ein wenig an der Fortigate orientiert und die wäre hier wohl nicht mit der vollen Funktionalität des WAP-Servers vergleichbar. Man hat hier zwar Loadbalancing und SSL Offloading konfigurieren, aber nicht einzelne Unterverzeichnisse für den Reverse Proxy - nur den kompletten Host. (Alternativ könnte man natürlich eine IPS-Signatur schreiben, die den Zugriff blockt, aber das wäre ein wenig von hinten durch die Brust in die Augen). Dafür hat Fortinet zusätzliche Produkte. Zur Sicherheit: Ich habe das Fragezeichen geschrieben, eben weil das so individuell ist. Vielleicht ist es besser zu schreiben „höher als reines Port Mapping“? Siehe auch Antwort zu Szenario 3 – Mit dem WAP müsste man hier differenziertere Möglichkeiten haben, wenn ich alles richtig verstanden habe. - Szenario 5 - Aufbau eines komplett eigenständigen Domänencontrollers mit Exchange, der dann mit einem der vorherigen Szenarien nach außen geöffnet wird. Du meinst jetzt eine eigene AD-Infrastruktur für Exchange? Wieso ist da die Sicherheit höher? Welche und warum? Gedanke war: Was passiert, wenn auf dem Exchange „eingebrochen“ wird, und jemand in den Besitz von Benutzerdaten kommt. Dann hat er auch Zugriff auf weitere Netzwerkressourcen. Wenn man ein eigenes AD & Exchange hat und die Passwörter anders sind (und womöglich diese Kombination aus DC&Exchange in einem anderen Netzsegment steht), hat sich ein Unbefugter nicht Zugriff auf weitere Ressourcen (z.B. Dateien). Mann kann es auch kompliziert machen ;-) Oder bin ich jetzt völlig paranoid ?! ;-) - Zwei Faktor - Wäre aber ggf. interessant. Nur nicht jede Version von Exchange und jeder Client kann damit umgehen. Danke für den Hinweis! Liege ich mit der Einschätzung der Organisationsgrößen in etwa richtig? Hmm... eher nein. Da habe ich wohl ziemlich daneben gelegen. Gibt es trotzdem Erfahrungswerte? Wird zum Beispiel auch Szenario 1 bei Installationen mit (zum Beispiel) mehr als 70 Usern gemacht? Oder eher nicht? Ich versuche, ein Gefühl dafür zu bekommen. Umgekehrt gefragt: Gibt es Szenarien, die sich bei einer gewissen Organisationsgröße per se verbieten? 2. Wird der WAP-Server zu einem Mitglied der Domäne? Oder steht der außerhalb und fragt „in die Domäne rein“? (Hier wird ja auch der ADFS Proxy mit dem WAP mitinstalliert) Was sagt denn die MS dazu? Ich denke du liest soviel. https://technet.microsoft.com/en-us/library/dn383660.aspx Entweder stehe ich kräftig auf dem Schlauch oder wir reden aneinander vorbei ;-) ? Ich meinte das so: Der ADFS Server steht in der Domäne. Ich installiere einen weiteren Server außerhalb der Domäne, der WAP und den ADFS Proxy installiert hat. Geht das so? Dieser Artikel ließ mich das vermuten: http://www.msxfaq.de/internet/wap.htm Danke, Sebastian
  3. Hallo zusammen, man ruhig mit den jungen Pferden..;-) Es ist so wie oben geschrieben, ich habe nichts im Forum gefunden und „nur“ meine Gedanken zusammengefasst. Auch von einem „Bepreisungsmodell“ für den Vertrieb kann nicht die Rede sein, das war überhaupt nicht die Intention. Die Idee war einfach nur, Ansatzpunkte für die sichere Integration zu diskutieren, nicht mehr und nicht weniger. Das ist offensichtlich so nicht rüber gekommen. Ich habe bei meinen Recherchen nicht viel gefunden, auch hier im Board nicht. Es wäre doch prima, wenn man so auch Newbies Ideen an die Hand geben könnte, wie eine Integration aussehen **kann**. Klar, gibt es auch Beratungsfirmen, keine Frage – aber irgendwie muss man sich doch auch in ein Thema einarbeiten. Auch dass das ganze immer sehr individuell ist, ist mir klar. Hier gibt es aber nur mein Lab-Setup. Gute Güte ;-) Was´n los – war doch nur eine normale Frage…. @NorbertFe: Vielen Dank für den Input – du hast natürlich Recht, Port 80 gehört raus. Ich hatte mit einem weiteren Web-Root „rumgespielt“, der dann einen https-Redirect nach https://www.example.com/ecp macht. Der MS-Artikel https://support.microsoft.com/de-de/kb/975341 ist bekannt, ich habe nur eine Möglichkeit getestet, das auch ohne Änderungen an den Standard-Hostings zu machen. Was die Sicherheitseinschätzung angeht – die wollte ich eigentlich zur Diskussion stellen, das war eine rein subjektive Einschätzung. @DocData: Wie gesagt, ist nicht so, hat mit Vertrieb nichts zu tun. Abgesehen davon, dass ich dir völlig zustimme und man das ganz sicher nicht pauschal bepreisen kann – selbst wenn man das versuchen würde, ab Szenario 4 wird das absolut unmöglich. Außerdem wäre das doch sowieso wiedersinnig. Der Vertrieb wird die Szenarien (wahrscheinlich) nicht aufbauen können, die Technik wird dem Vertrieb von vornherein genau das sagen, was du geschrieben hast!? @magheinz: Sicherheitslevel: Bin ich bei dir, wie gesagt, Intention war, genau das zu diskutieren – wenn das anders angekommen ist, tut´s mir leid. Das mit den Magnettafeln verstehe ich leider nicht, habe dir eine PM geschrieben. Mit den RFCs hast du sicherlich Recht, die Beispiel Domain ist schlecht gewählt. [Edit: Die Beispiel-Domain war ganz schlecht gewählt, ich habe nichts mit der o.g. Domain zu tun, Sorry - das zur Richtigstellung] Ich find´s eigentlich ein wenig schade und verstehe die Reaktionen auch nicht so ganz. Sebastian
  4. Hallo zusammen, ich bin gerade dabei, mich intensiv mit Exchange 2016 zu beschäftigen. Bis jetzt läuft das ganze prima und ich würde gerne ein paar Szenarien zum Öffnen des Exchange Servers nach außen diskutieren. Ich habe auch schon die Forumssuche bemüht und insgesamt 3 Jahre zurück gegangen, aber eine Diskussion über die verschiedenen Möglichkeiten mit Vor- und Nachteilen habe ich nicht gefunden. Stand der Dinge: Domänen-Controller: W2K8R2 Exchange-Server: W2K12R2 mit Exchange 2016 im gleichen Netz Exchange ist unter exchange.organisation.de erreichbar, Split-DNS ist eingerichtet, SSL-SAN Zertifikat ist vorhanden & eingerichtet, Autodiscovery funktioniert, nur intern erreichbar. Die Firma besitzt einen Internetzugang, der über einen Standard-NAT-Router zugänglich gemacht wird sowie eine feste IP-Adresse. Ich habe viel im Internet gelesen und diverse Möglichkeiten gefunden, um den Exchange nach außen zu öffnen. In diesem Fall soll das heißen – „Full-Pull“ – also mit Outlook Anywhere, OWA, mobile Devices. Nur die ECP soll nicht geöffnet werden. Office 365 und/oder Hybrid soll an dieser Stelle unberücksichtigt bleiben. Besonders interessant ist das Verhältnis von Sicherheit / Aufwand / Organisationsgröße – klar ist das immer individuell, aber vielleicht bekommen wir ja einen groben Ansatzpunkt zusammen. Darüber hinaus ist zu sagen, dass das ganze bis jetzt ÜBERLEGUNGEN sind, die kleinen Lösungen habe ich getestet, die großen noch nicht. Die Einschätzungen, Vor- und Nachteile würde ich gerne mal zur Diskussion stellen. Ich versuche mich mal – Ausgangsszenario ist immer der oben beschriebene IST-Stand: Szenario 1: Es wird ein Port-Mapping für Port 80 & 443 auf dem Router mit Ziel Exchange-Server angelegt. Vernünftige Passwort- und Kontosperrrichtlinie. Vorteil: Sehr geringer Aufwand Organisationsgröße: < 5 Benutzer Sicherheit: gering Szenario 2: Es wird ein Port-Mapping für Port 80 & 443 auf dem Router mit Ziel Exchange-Server angelegt. Zusätzlich wird der Exchange Server in ein anderes Netzsegment gestellt; die beiden Netzsegemente werden mittels einer Firewall verbunden, die nur die notwendigen Ports durchlässt. Vernünftige Passwort- und Kontosperrrichtlinie. Vorteil: Geringer Aufwand, höhere Sicherheit als Szenario 1 Nachteil: Organisationsgröße: < 10 Benutzer Sicherheit: mittel (?) Szenario 3: Wie Szenario 1 oder 2 – jedoch wird der Standard-Router durch einen Firewall-Router ersetzt, der auch ein Intrusion-Prevention/-Detection System besitzt (z.B. Fortigate). Hier muss natürlich so etwas wie ein Loadbalancer und/oder SSL-Offloading konfiguriert werden, damit die Firewall die SSL-Pakete aufmachen, scannen und wieder verschlüsseln kann. Vorteil: Firewall kann weitere Dienste bereitstellen (z.B. AV-Gateway) Nachteil: Einarbeitungszeit / Schulungen / Kosten Firewall Organisationsgröße: 10-40 Benutzer Sicherheit: hoch (?) Szenario 4: Aufbau eines Web-Application Proxy-Servers (Bestandteil von W2K12R2), der in einem getrennten Netzwerk steht. Dieser greift durch eine Firewall auf einen (ebenfalls aufzubauenden) ADFS Server sowie auf den Exchange Server zu. DC, Exchange und ADFS Server stehen im internen, vertrauenswürdigen Netz. Vorteil: Weitere Dienste können über ADFS Dienste mit Single Sign-On bedient werden, über den Reverse Proxy des WAP können weitere interne Websites veröffentlicht werden, fein-granulare Konfigurationsmöglichkeiten Nachteil: hoher Implementierungsaufwand Sicherheit: hoch (?) Organisationsgröße: > 40 Benutzer Szenario 5: Aufbau eines komplett eigenständigen Domänencontrollers mit Exchange, der dann mit einem der vorherigen Szenarien nach außen geöffnet wird. Vorteil: Völlige Trennung der Mail & AD Dienste Nachteil: Erhöhter Aufwand in Administration und Einrichtung bei Benutzern Sicherheit: sehr hoch Szenario 6: Hinzufügen von zwei-Faktor Authentifizierungen (das führt hier jetzt vielleicht etwas weit). Wie würdet Ihr die Vor- und Nachteile der Szenarien einschätzen? Liege ich mit der Einschätzung der Organisationsgrößen in etwa richtig? Wie gesagt – auch mir ist klar, dass das sehr individuell ist und das Ganze nur eine grobe Richtschnur sein kann. Zuletzt hätte ich noch zwei Fragen, insbesondere zum vierten Szenario: 1. Outlook Anywhere kann nur als „Passthrough“ auf dem WAP konfiguriert werden (wenn ich mir das richtig angelesen habe) – die Meinungen im Internet sind so, dass das nicht allzu viel bringt, der WAP reicht einfach nur durch. Wäre da nicht Szenario 3 sinnvoller? 2. Wird der WAP-Server zu einem Mitglied der Domäne? Oder steht der ausserhalb und fragt „in die Domäne rein“? (Hier wird ja auch der ADFS Proxy mit dem WAP mitinstalliert) Schönen Sonntag noch, Sebastian
  5. Hallo zusammen, so letztes Update - ich hab´s mir doch noch zu Ende angeschaut :D Problem waren die ACLs im FreeNAS (wie gesagt, FreeBSD mit ZFS). Man muss in der entsprechenden Freigabe mittels "setfacl" die Berechtigungen auf Dateien und Verzeichnisse passend setzen. Hier haben ArcServe wohl vor allem die "Spezialberechtigungen" wie "Ordner auflisten" gefehlt; die Linux-Standard Berechtigungen (r/w/x) werden durch die ACLs mit ZFS deutlich erweitert, vergleichbar mit den Berechtigungen eines Windows-Servers. Das kuriose daran ist, dass es keinerlei Fehlermeldungen bzgl. der Berechtigungen geben hat. Wie dem auch sei - ich hoffe, es hilft vielleicht dem ein oder anderen hier im Forum - auch wenn es inzwischen gar kein Windows-Server Problem mehr ist (wie Anfangs vermutet). @djmaker: Du hast gar nicht so schlecht gelegen mit deiner Vermutung, mit einer Windows-Freigabe wäre das wahrscheinlich nicht passiert..... Grüße, Sebastian
  6. Hallo, der Grund lag / liegt auf dem NAS. Es wird FreeNas mit CIFS (Samba) und als Dateisystem ZFS verwendet. Sobald vfs objects = zfsacl für die Sambafreigabe gesetzt ist, werden die vorhandenen Backup-Files nicht gelöscht (die HEADER-Datei von ArcServe aber neu erzeugt). Das muss mit den ACLs vom ZFS Dateisystem zu tun haben - ich habe versucht, mir das weiter anzuschauen, aber es ist langsam spät ;-) Ich habe jetzt in der Samba-Konfiguration von FreeNAS einfach vfs objects = angeben, damit ist das Modul deaktivert und es funktioniert erst einmal alles wie es soll. Vielleicht kennt sich ja jemand mit ZFS unter FreeBSD (=FreeNAS) aus und kann noch einen Tip geben ? Auf alle Fälle war der erste Beitrag der "Schubs" in die richtige Richtung, Danke ! Sebastian
  7. Hallo, kleines Update - die Spur ist richtig. Auf einem anderen NAS, bzw. lokal passiert es nicht, nur eben auf _diesem_ NAS / Samba Share (ist ein FreeNAS 8). Ich forsche mal weiter (vielleicht hat auch jemand noch eine Idee?).... Grüße, Sebastian
  8. Hallo, da gehe ich mal von aus - aus dem Datenträgerverwaltungshandbuch: Grüße, Sebastian
  9. Hallo zusammen, folgendes Setup: Windows 2003 SBS ArcServe r15 SP1 Sicherung auf NAS per Samba Ich mache eine tägliche Rotationssicherung an 5 Tagen, Montag vollständig, alle anderen Tage Änderunggsicherungen. Alle Tage im Modus "Überschreiben". Des Weiteren habe ich fünf Verzeichnisse auf dem Samba Share, die als Dateisystemgerät alle in einer Gruppe zusammengefasst sind und auch einem Datenträgerbestand zugeordnet sind. Grundsätzlich funktioniert das auch, aber die fünf Verzeichnisse auf dem Share werden immer grösser, d.h. dass immer mehr S00000xxx.CTF Dateien entstehen, aber "alte" nie gelöscht werden. Auch nach dem Formatieren der Bänder sind die Dateien immer noch vorhanden. Kann sich da jemand einen Reim drauf machen ? Grüße, Sebastian Lemke
  10. Hallo zusammen, nachdem wir zu zweit das System einmal komplett durchgesehen haben haben wir uns jetzt ersteinmal entschlossen, den Virenscanner (Etrust) auf dem DC2 zu entfernen (nicht hauen, kommt natürlich sofort wieder drauf nach neuen Erkentnissen) sowie die LAN Verbindung fest auf 1 GBit zu stellen; vorher hat es beim Start des Servers (merkwürdigerweise) immer einen Moment gedauert, bis er erkannt hat, dass er eine Internetverbindung hat (obwohl auch der Switch ein Procurve ist). Ich werde weiter berichten. Schönes WE, Sebastian
  11. Hallo, erledigt (hatte ich vergessen, wollte ich sowieso machen :-)) Kannst du mir auf die Sprünge helfen ? Ich vermute mit repadmin ? DC1: repadmin running command /showrepl against server localhost Default-First-Site\dc1 DC Options: IS_GC Site Options: (none) DC object GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d DC invocationID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d ==== INBOUND NEIGHBORS ====================================== DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 12:41:46 was successful. CN=Configuration,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. CN=Schema,CN=Configuration,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. DC=DomainDnsZones,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 12:41:32 was successful. DC=ForestDnsZones,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. DC2: Repadmin: Befehl "/showrepl" wird für den vollständigen DC "localhost" ausgeführt Default-First-Site\dc2 DSA-Optionen: IS_GC Standortoptionen: (none) DSA-Objekt-GUID: 1a049303-0b27-406e-9caf-5098ea2223dc DSA-Aufrufkennung: 74131738-881c-4b17-adc6-a4bb3fd420b6 ==== EINGEHENDE NACHBARN===================================== DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 12:41:27 war erfolgreich. CN=Configuration,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. CN=Schema,CN=Configuration,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. DC=DomainDnsZones,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 12:41:32 war erfolgreich. DC=ForestDnsZones,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. Nein, keine Bindungen entfernt und sowohl die IP als auch DNS steht auf automatisch beziehen. Bei DNS stand mal ::1 - dann gabs aber beim nslookup Probleme; den Tip mit automatisch Beziehen habe ich hier im Forum gefunden. lg Sebastian
  12. Hallo, bin hier echt am verzweifeln :-) DC1: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : dc1 Primäres DNS-Suffix . . . . . . . : domaene.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : domaene.local Ethernet-Adapter LAN-Verbindung 2: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : HP NC7761 Gigabit Server Adapter Physikalische Adresse . . . . . . : 00-12-79-91-5F-37 DHCP aktiviert . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.1.10 Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DNS-Server . . . . . . . . . . . : 192.168.1.10 Primärer WINS-Server . . . . . . : 192.168.1.11 DC2: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : dc2 Primäres DNS-Suffix . . . . . . . : domaene.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : domaene.local Ethernet-Adapter LAN-Verbindung 1: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter #2 Physikalische Adresse . . . . . . : D8-D3-85-D8-FB-C0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::f8a0:57e7:8fe1:5ce1%13(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.1.11(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DHCPv6-IAID . . . . . . . . . . . : 316199813 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-E4-54-54-D8-D3-85-D8-FB-C3 DNS-Server . . . . . . . . . . . : 192.168.1.10 192.168.1.11 Primärer WINS-Server. . . . . . . : 192.168.1.11 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{A7A63E27-2BA2-49D5-88AB-1D2E5AEFF471}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja lg Sebastian
  13. Hallo zusammen, folgendes Setup: DC1 – w2k3 DC2 – w2k8r2 Die DNS-Zonen sind AD-integriert, der DC2 hat die FSMO Rollen inne. Des weiteren läuft auf DC2 ein WINS Server, alle Clients wie auch die beiden Server haben diesen auch unter WINS in den TCP/IP v4 Eigenschaften eingetragen. Problem ist nun, daß ich nach einigen Stunden von DC2 aus nicht mehr auf DC1 mit \\DC1 zugreifen kann (Fehler 0x80070035, Netzwerkpfad nicht gefunden). Wenn ich statt \\DC1 \\DC1.domaene.local verwende geht´s :confused:. Ein "nbtstat -a DC1" ausgeführt auf DC2 gibt die korrekten Ergebnisse. Wenn ich von DC2 aus einen anderen PC im Netz aufrufe geht das auch. Wenn ich von DC1 aus \\DC2 macht geht es ebenfalls. Im Eventlog sind auf beiden Servern keine Auffäligkeiten; auch Netdiag und dcdiag sind "ohne Befund". Nslookup der Server funktioniert auf beiden Servern einwandfrei. Nach einem Neustart von DC2 gehts ersteinmal wieder. UPDATE von DC2 aus: Ein net view \\DC1 geht nicht ein net view \\<IP> geht Müsste also in der Netbios-Namensauflösung liegen ??? Hat jemand eine Idee ? lg Sebastian
  14. Hallo zusammen, kurzes Update: Im zweiten Anlauf hat alles so geklappt wie es sollte; nach Dcpromo und vor dem Neustart habe ich den DNS-Server Ipv6 - wie beschrieben - auf automatisch beziehen gestellt. Nach dem Neustart gab es absolut keine Probleme :-) Vielen Dank an alle! Sebastian
  15. Hallo, ich muss mich nochmal zurückmelden :-) Ich habe das ganze jetzt mit meiner VM nachgestellt. Ausgangssituation: DC 1 - 192.168.1.10 - GC / FSMO / DNS / DHCP 1. Ich habe den 2k8r2 auf dem zweiten Rechner (VM) installiert, IP 192.168.1.11, DNS auf 192.168.1.10. Nslookup auf DC1 ohne Probleme. 2. Danach habe ich den zweiten Rechner zunächst als normales Mitglied in die Domäne gehoben. Nach Neustart kein Problem mit Nslookup. 3. Mit DCPromo den zweiten PC zum DC gemacht. Nach Neustart sind die DNS-Einstellungen (automatisch) wie folgt: primärer DNS: 192.168.1.10, sekundärer: 127.0.0.1 Problem ist an dieser Stelle, daß ein nslookup auf DC2 ausgeführt folgendes ergibt: C:\Users\Administrator.domaene>nslookup dc1.domaene.local DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: ::1 Name: dc1.domaene.local Address: 192.168.1.10 Den gleichen Befehl auf DC1 ausgeührt liefert korrekte Ergebnisse. Könnte das der Ursprung der Probleme sein, bzw. warum funktioniert der Lookup auf DC1 von DC2 aus nicht ? Nachtrag: Die PTR Einträge in der Reverse-Lookupzone sind für DC1 und DC2 enthalten. Nachtrag2: Ein Ping auf DC2 ausgeführt auf DC2 ergibt folgendes: C:\Users\Administrator.domaene>ping dc2.domaene.local Ping wird ausgeführt für dc2.domaene.local [fe80::8c70:96cf:47ae:8f4e%11] mit 32 Bytes Daten: Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Könnte das Problem doch mit IPv6 zusammenhängen ? Nachtrag 3: Ich habs gefunden... http://www.mcseboard.de/post8-959628.html Sorry - für das unnötige Posting; aber vielleicht hilfts ja mal jemand anderen :-) lg Sebastian
×
×
  • Create New...