Whistleblower

Damit meinte ich, dass nur seine eigene IP (10.10.1.3, vorher localhost) als DNS-Server angegeben ist - weitere DCs gibt es bisher nicht, dass soll sich ja zukünftig ändern. Ich habe jetzt aber auch das DNS-Problem gelöst: Einfach den vorhandenen CNAME-Eintrag in der Forward Lookup_Zone unter _msdcs.firma.lokal gelöscht und durch ein Neustarten des Anmeldedienstes wieder erstellen lassen. Jetzt scheint das DNS-Problem behoben zu sein, obwohl vorher genau dieselbe GUID drin stand :confused: Allerdings bekomme ich immer noch die Fehlermeldung für die Root-Server - ist das zu ignorieren?

IP-Adressen sind auf 10.10.1.3 geändert, registerdns ist ausgeführt und den Anmeldedienst habe ich neu gestartet... Bisher aber leider keine Änderung

Steht nur der Server selbst drin (jetzt nicht mehr über localhost), da keine weiteren internen DNS-Server vorhanden sind: ipconfig /all Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : domcon Primäres DNS-Suffix . . . . . . . : firma.lokal Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Ja DNS-Suffixsuchliste . . . . . . . : firma.lokal Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physikalische Adresse . . . . . . : 00-0C-29-25-EC-4B DHCP aktiviert . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 10.10.1.3 Subnetzmaske . . . . . . . . . . : 255.255.0.0 Standardgateway . . . . . . . . . : 10.10.1.1 DNS-Server . . . . . . . . . . . : 10.10.1.3 Primärer WINS-Server . . . . . . : 10.10.1.3 – Gibt folgenden Fehler aus: "netdiag /fix" und "dcdiag /fix" konnten den Fehler scheinbar nicht beheben "dnslint /ad /s localhost" wirft übrigens den gleichen Fehler raus Wie kann ich den CNAME Eintrag manuell vornehmen?

So, ich habe das Ereignisprotokoll und die Logs von dcdiag und netdiag mal durchforstet. Sieht nach einem DNS-Problem aus, was ich momentan aber noch nicht genau qualifizieren kann: Auszug netdiag /test:dns Global results: Domain membership test . . . . . . : Passed NetBT transports test. . . . . . . : Passed List of NetBt transports currently configured: NetBT_Tcpip_{D6E02AFC-30ED-42DA-BB29-94E20FD306EC} 1 NetBt transport currently configured. DNS test . . . . . . . . . . . . . : Failed [WARNING] The DNS entries for this DC are not registered correctly on DNS se rver '127.0.0.1'. Please wait for 30 minutes for DNS server replication. [FATAL] No DNS servers have the DNS records for this DC registered. The command completed successfully Desweiteren in dcdiag /c /v: (kommt für jeden Root-Server und die DNS-Server vom Provider vor) DNS server: 198.41.0.4 (a.root-servers.net.) 1 test failure on this DNS server This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 198.41.0.4 [Error details: 9003 (Type: Win32 - Description: Der DNS-Name ist nicht vorhanden.)]

Ich hab's ja befürchtet... Kein Quick&Dirty :D Werde also nochmal alles im Altsystem durchchecken, um dann evtl. zu migrieren. Was mir nur wichtig ist: Ich will keinen unnötigen Ballast vom Altsystem mitschleppen. Nicht mehr vorhandene User sind dabei das geringste Problem, aber u.A. wurde auch mal Exchange auf dem DC genutzt (ist mittlerweile deinstalliert). Zukünftig wird mittelfristig wohl auch wieder Exchange zum Einsatz kommen (auf eigenem Server), daher würde ich eine saubere Neuinstallation bevorzugen. Im Grunde brauche ich höchstens die User und Gruppen und Hosts aus dem ADS, weitere Funktionen wie z.B. servergespeicherte Profile o.ä. werden bisher eh nicht eingesetzt. Angenommen, die Migration klappt, nachdem ich die Fehler auf dem alten DC gefunden und beseitigt habe - wie stehen die Chancen, das das neue System danach so frisch und aufgeräumt ist, wie nach einer Neuinstallation?

Hallo zusammen, wir haben ein kleine Domäne über zwei Standorte (ca. 20 Clients und 4 W2k3-Server), die wir aufgrund von zu viel Altlasten (der Domänencontroller exitsterte schon vor 5-6 Jahren unter Windows Server 2000, und wurde irgendwann mal auf 2003 hochgezogen) komplett ersetzen wollen. Mein bevorzugter Weg wäre: - Vorbereitung zweier neuer DCs (zwei Standorte) (vorerst in isoliertem Netz) - Beibehaltung des Domänennamens - Anmeldung der Clients in temp. Workgroup - Abschaltung alter DC - Inbetriebnahme neue DCs - Anmeldung der Clients an der Domäne Ursprünglich wollte ich den Domänennamen ändern, um beide Domänen temporär parallel betreiben zu können, aber dann müsste ich hinterher auf allen Clients die Profile sichern und wiederherstellen, was bei Beibehaltung des Domänennames ja entfallen dürfte... Wird das so tatsächlich klappen, oder mache ich irgendwo einen Denkfehler? Bin für alle Vorschläge offen! :) Der übliche Weg über dcpromo entfällt, da das alte ADS nicht mehr wirklich konsistent ist. Dcdiag hat mir schon diverse Fehler ausgeworfen, und auch dcpromo der Maschine in einer virtuellen Umgebung hat nur Probleme aufgeworfen - daher ist es Zeit für einen Neuanfang... :D

War eine Anforderung vom Kunden -> kein Einsatz des Cisco-VPN-Clients. Habe das ganze dann aber über einen 1751 nachgebildet. (Und den Kunden anschließend doch vom VPN-Client überzeugen können) Der PDM (in der alten Version) begeistert mich übrigens auch nicht. Der SDM beispielsweise ist auch deutlich weiter entwickelt, reicht mir i.d.R. aber auch nicht. Mehrere dynamische Crypto-Maps parallel (z.B. ein oder mehrere L2L-VPN mit dyn. IP und VPN-Clients) gehen auch nur über Keyrings, und die werden im SDM nicht unterstützt.

Hat sich eigentlich nichts geändert: ip inspect name ethernet_0 tcp router-traffic ip inspect name ethernet_0 ftp ip inspect name ethernet_0 udp ip inspect name ethernet_0 realaudio ip inspect name ethernet_0 h323 ip inspect name ethernet_0 h323callsigalt ip inspect name ethernet_0 h323gatestat ip inspect name ethernet_0 sip ip inspect name ethernet_0 sip-tls ip inspect name ethernet_0 fragment maximum 256 timeout 1 ip inspect name ethernet_0 pptp interface Ethernet0/0 no ip address ip nat outside no ip virtual-reassembly half-duplex pppoe enable group global pppoe-client dial-pool-number 1 end interface FastEthernet0/0 description LAN_inside$FW_INSIDE$ ip address 10.50.1.1 255.255.255.0 ip access-group inside_rule out no ip redirects no ip unreachables no ip proxy-arp ip inspect ethernet_0 in ip nat inside ip virtual-reassembly ip tcp adjust-mss 1300 no ip mroute-cache speed auto end interface Dialer1 description dsl_flat$FW_OUTSIDE$ bandwidth 6000 ip address negotiated ip access-group outside_rule in no ip redirects no ip proxy-arp ip mtu 1492 ip nat outside no ip virtual-reassembly encapsulation ppp no ip route-cache cef no ip route-cache no ip mroute-cache dialer pool 1 dialer-group 1 no cdp enable ppp authentication chap pap callin ppp chap hostname xxx ppp chap password xxx crypto map staticmap end und noch mal die ACLs: ip access-list extended NAT_rule remark Alles andere natten permit ip 10.50.0.0 0.0.255.255 any ip access-list extended inside_rule permit udp any eq domain any deny ip any any ip access-list extended mgmt_rule remark VTY Access-class list permit ip 10.50.0.0 0.0.255.255 any log deny ip any any ip access-list extended outside_rule permit udp host 194.25.2.129 eq domain any remark ### NTP-Server ### permit udp host 192.53.103.104 eq ntp host 80.153.147.221 eq ntp permit udp host 192.53.103.108 eq ntp host 80.153.147.221 eq ntp deny ip any any log Reboot bringt keine Änderung. show ip inspect sessions sieht dann z.B. so aus: sh ip inspect sessions Established Sessions Session 82A56C1C (10.50.1.50:1154)=>(74.125.39.164:80) tcp SIS_OPEN Session 82A5739C (10.50.1.50:61488)=>(194.25.2.129:53) udp SIS_OPEN Session 82A56E9C (10.50.1.50:57253)=>(194.25.2.129:53) udp SIS_OPEN Also einmal die http-Session und zwei DNS-Anfragen...

Hm, stimmt, da war ich wieder auf allen Augen blind... :rolleyes: War mir eigentlich sicher, dass in der ursprünglichen Konfig ip inspect nicht auf dem Dialer aktiv war ... Kein Wunder - hab auch zuletzt nur die Konfig von eth0/0 überprüft, und nicht den Dialer... Ich brauch Urlaub! ;-) Trotzdem danke!!! Eine Ungereimtheit habe ich allerdings noch - Downloads dauern über die letzte Konfig ewig (ca. ISDN-Tempo am 6 MBit-Anschluss). Werde mir da aber die Konfig erst nochmal genauer anschauen, evtl. liegts auch wieder am alten Ethernet-IF, was nicht so befriedigend an Autosense Modems läuft... UPDATE: Okay, der Fehler lag wie vermutet an der 10MB/FD-Einstellung des Ethernet0 Interfaces... Mit Half-Duplex habe ich jetzt keine CRC-Fehler mehr, dafür massenhaft Collisions, aber es ist erstmal schneller... Habe aber jetzt dennoch eine Frage zum Thema Ip Inspect: Die Regeln ip inspect name ethernet_0 tcp router-traffic ip inspect name ethernet_0 ftp ip inspect name ethernet_0 udp ip inspect name ethernet_0 realaudio ip inspect name ethernet_0 h323 ip inspect name ethernet_0 h323callsigalt ip inspect name ethernet_0 h323gatestat ip inspect name ethernet_0 fragment maximum 256 timeout 1 ip inspect name ethernet_0 sip-tls ip inspect name ethernet_0 sip ip inspect name ethernet_0 pptp Beinhalten doch nicht explizit http-Verkehr (oder tcp), warum wird er dennoch durchgelassen?

Hier folgt die Konfig (gekürzt): hostname router ! boot-start-marker boot-end-marker ! no logging buffered logging console critical enable secret xxx enable password xxx ! aaa new-model ! ! aaa authentication login default local aaa authentication login remoteaccess local aaa authorization exec default local ! aaa session-id common memory-size iomem 15 clock timezone CET 1 clock summer-time CEST recurring clock save interval 24 no ip source-route ip cef ! ! ip inspect name internet http ip inspect name internet https ip inspect name internet ftp ip tcp synwait-time 10 ! ! ip tftp source-interface FastEthernet0/0 no ip bootp server ip name-server 194.25.2.129 ip name-server 217.237.149.205 ip name-server 217.237.151.51 ip ssh authentication-retries 2 vpdn enable ! ! ! username xyz privilege 15 secret xyz ! ! ! ! interface Null0 no ip unreachables ! interface Ethernet0/0 no ip address ip nat outside no ip virtual-reassembly full-duplex pppoe enable group global pppoe-client dial-pool-number 1 ! interface FastEthernet0/0 description LAN_inside$FW_INSIDE$ ip address 10.50.1.1 255.255.255.0 ip access-group inside_rule out no ip redirects no ip unreachables no ip proxy-arp ip inspect internet in ip nat inside ip virtual-reassembly ip tcp adjust-mss 1300 no ip mroute-cache speed auto ! interface Dialer1 description dsl_flat$FW_OUTSIDE$ bandwidth 16000 ip address negotiated ip access-group outside_rule in no ip redirects no ip proxy-arp ip mtu 1492 ip nat outside no ip virtual-reassembly encapsulation ppp no ip route-cache cef no ip route-cache no ip mroute-cache dialer pool 1 dialer-group 1 no cdp enable ppp authentication chap pap callin ppp chap hostname xxxxx ppp chap password xxxxx crypto map staticmap ! ip route 0.0.0.0 0.0.0.0 Dialer1 ! no ip http server no ip http secure-server ip http secure-port 50443 ip nat inside source route-map SDM_RMAP_1 interface Dialer1 overload ! ip access-list extended NAT_rule remark Alles andere natten permit ip 10.50.0.0 0.0.255.255 any ip access-list extended inside_rule permit udp any eq domain any deny ip any any ip access-list extended mgmt_rule remark VTY Access-class list permit ip 10.50.0.0 0.0.255.255 any log deny ip any any ip access-list extended outside_rule permit udp host 194.25.2.129 eq domain any remark ### NTP-Server ### permit udp host 192.53.103.104 eq ntp host 80.153.147.221 eq ntp permit udp host 192.53.103.108 eq ntp host 80.153.147.221 eq ntp deny ip any any log ! kron occurrence Zwangstrennung at 6:00 recurring policy-list Zwangstrennung ! kron policy-list Zwangstrennung cli clear interface dialer1 cli clear crypto sa cli clear crypto session ! access-list 1 remark INSIDE_IF=FastEthernet0/0 access-list 1 remark SDM_ACL Category=2 access-list 1 permit 10.50.0.0 0.0.255.255 access-list 2 remark SDM_ACL Category=2 access-list 2 permit 10.50.0.0 0.0.255.255 no cdp run route-map SDM_RMAP_1 permit 1 match ip address NAT_rule ! ! control-plane ! ! line con 0 logging synchronous transport output telnet line aux 0 transport output telnet line vty 0 4 session-timeout 60 access-class mgmt_rule in logging synchronous transport input ssh ! scheduler max-task-time 5000 scheduler allocate 4000 1000 scheduler interval 500 ntp clock-period 17180133 ntp server 192.53.103.108 source Dialer1 ntp server 192.53.103.104 source Dialer1 end Vielleicht bin ich auch nur grad zu blind und hab mir irgendnen Fehler wieder eingebaut... :rolleyes:

Hi, ich teste derzeit IP Inspect auf einem 1751 auf Praxistauglichkeit mit neuen Anwendungen... Dabei ist mir aufgefallen, dass es scheinbar nicht so ohne weiteres möglich ist, CBAC einfach wieder zu deaktivieren. Begonnen habe ich mit einer recht übersichtlichen Konfig in der über erweiterte ACLs der Zugriff von Clients aufs Internet möglich war. Anschließend habe ich IP-inspect Regeln erstellt: ip inspect name internet http ip inspect name internet https ip inspect name internet ftp ... und diese auf das interne Interface gebunden: interface FastEth 0/0 ip inspect internet in Soweit ging auch noch alles. Wenn ich jetzt anschließend ip inspect auf dem Interface wieder deaktiviere, komme ich nicht mehr ins Netz, selbst dann nicht, wenn ich einen Reload mache. Auch das komplette Löschen des Regelsatzes bringt keine Besserung. Schreibt sich der Router die dynamisch erstellen ACLs irgendwo permanent weg, dass sie selbst nach Reboot noch erhalten sind? Wenn ich sie nach Reboot wieder erstelle und aufs IF binde, geht auch wieder alles.... :confused:

Je mehr ich drüber nachdenke, desto mehr sehe ich die Lösung nur durch Spoofing, und das ist nicht das was ich eigentlich will... :suspect: Höchstens noch eine Möglichkeit über normales outbound NAT, sprich, alle drei 192.168.1.0-Clients werden z.B. auf 172.16.1.1 genattet... Soweit die Theorie...

Hallo, ich habe mal eine Frage zu NAT. Folgender Hintergrund: Bestehende VPN Verbindung zwischen zwei Standorten A und B: A: 172.16.0.0/16 Netz, extern 1 feste IP B: 192.168.1.0/24 Netz, extern 1 feste IP Am Standort A ein Cisco 1751, Hardware am anderen Standort unbekannt. VPN-Aufbau erfolgt NICHT LAN to LAN, sondern Host to Host, im ungünstigen Fall 15 Sessions: 3 Clients 172.16.1.1 - .3 auf 5 Clients am Standort B (Auf die Konstellation habe ich leider keinen Einfluss... :rolleyes:) Am Standort A soll das interne Netz auf ein 10.1.1.0/24 Netz umgestellt werden. Das VPN zwischen den Standorten soll aber vorerst mit den alten Adressen beibehalten werden. Meine Idee: 3 Clients aus dem neuen 192.168.1.0-Netz werden 1:1 auf das 172.16.0.0-Netz genattet: z.B. 192.168.1.11 -> 172.16.1.1 192.168.1.12 -> 172.16.1.2 192.168.1.13 -> 172.16.1.3 Wäre das mit dem 1751 möglich, und wenn ja, welche Schritte sind dafür zu machen? Dazu müsste ich doch mindestens ein virtuelles Interface anlegen, auf dass ich den neuen NAT-Pool binden kann, oder liege ich vollkommen falsch? :confused: Gehört ja eigentlich in die Kategorie Spoofing, oder?

Hi, gibt's irgendeinen akzeptablen Workaround dazu? Beispielsweise SOHO-Router, der das PPPoE übernimmt, und die PIX dahinter? Verkompliziert nur unnötigt die NAT-Konfig... :suspect:

Hi, folgende Releasestände sind drauf: Cisco PIX Firewall Version 6.3(5) Cisco PIX Device Manager Version 3.0(4) Compiled on Thu 04-Aug-05 21:40 by morlee pixfirewall up 18 hours 14 mins Hardware: PIX-501, 16 MB RAM, CPU Am5x86 133 MHz Flash E28F640J3 @ 0x3000000, 8MB BIOS Flash E28F640J3 @ 0xfffd8000, 128KB 0: ethernet0: address is 0008.21e6.96cb, irq 9 1: ethernet1: address is 0008.21e6.96cc, irq 10 Licensed Features: Failover: Disabled VPN-DES: Enabled VPN-3DES-AES: Enabled Maximum Physical Interfaces: 2 Maximum Interfaces: 2 Cut-through Proxy: Enabled Guards: Enabled URL-filtering: Enabled Inside Hosts: 10 Throughput: Unlimited IKE peers: 10 This PIX has a Restricted (R) license. Ich muss mich allerdings korrigieren - Remote-Access über Cisco VPN Client lässt sich einrichten - nur PPTP oder L2TP scheitert!

Hallo, hab mal wieder die kleine PIX für ein paar Tests rausgekramt. Jetzt wollte ich VPN für Remote-Einwahl einrichten (egal ob Cisco, PPTP oder L2TP) und stolpere darüber, dass ich vpnd nicht auf dem gleichen Interface wie pppoe (also outside) einrichten kann? Fehlermeldung: "Can not enable vpdn on the same interface as PPPoE." Ist das tatsächlich eine Beschränkung der PIX 501 oder lediglich eine Beschränkung des PDMs? Feste IP wird in meinem Fall leider erst per PPPoE zugeteilt...

Hi, danke nochmal für die Hinweise. Bin zwischenzeitlich einen großen Schritt weitergekommen - sehe die Laufwerke jetzt in der Datenträgerverwaltung :) :) :) Die Konfiguration von OpenFiler war noch nicht vollständig, hauptsächlich stand die ACL für das Netz noch auf "blocking" und die LUNs waren nicht aufs Target gemappt... :rolleyes: Mal sehen, wie ich jetzt mit dem Aufsetzen des Clusters auf die ganze Geschichte weiter vorankomme... Wenn Interesse hier im Forum besteht, kann ich meine Erfahrungen ja in Form eines kleinen Tutorials wiedergeben.

Hi, arbeite hier gerade mit einer Testumgebung, die ein SQL-Cluster bereitstellen soll. Um jetzt überhaupt ein Cluster mit 2 Nodes einrichten zu können, brauche ich zentralen Speicherplatz also SAN oder NAS (sonst gibt's Fehler beim Cluster-Assistenten). Mangels "echtem" SAN ist die Wahl auf OpenFiler gefallen, der u.a. ja auch iSCSI beherrscht. Soweit so gut, OpenFiler ist als Target eingerichtet, Volumes vorhanden, alles fein. Der Microsoft iSCSI Initialisator ist installiert und eingerichtet, Verbindung zum OpenFiler ist erfolgreich hergestellt. Über das SAN-Verwaltungs Plugin kann ich aber noch keine LUNs verwalten, weil der VDS-Dienst nicht installiert ist. Wie kann ich das beheben? Ich finde leider nirgends Hinweise, wie man den Dienst manuell installieren kann... :-( Der VDS Hardware-Provider sollte ja bereits durch den Initialisator vorhanden sein... Als System kommen 2k3 R2 SP2 Enterprise zum Einsatz.

Kann das sein, dass VMWare keine Keys mehr rausgibt? Ich habe mich bereits vor Wochen registriert, inzwischen auch "Resend License" geklickt, aber bisher noch keinen Key erhalten... :-(

Nach dem Hotfix konnte ich WSUS wieder deinstallieren und anschließend neu installieren (mit bestehender Datenbank). Einmal neu starten, und jetzt läufts wieder :-) Allerdings noch mit "altem" .NET 2.0 ohne SP1.

Die genaueren EventIDs folgen jetzt... Musste erstmal welche suchen ;-) Das Update erfolgte auf dem Wege "CD rein, starten, und Update durchführen", wobei auf dem DC erstmal das Schema angepasst wurde. Einige Fehler konnte ich bereits mit Deinstallation des letzten Servicepacks für .NET 2.0 und mit dem KB 913384 beheben, so starten jetzt beispielsweise die Update Services wieder: HOTFIX: A .NET Framework 2.0 application that runs under a user account context when no user profile is associated with the user account context may crash, or you may receive an access violation error message Fehler habe ich nun noch folgende: EventId 12002, 12012, 12022, 12032, 12042, die sich alle auf Windows Updates Services beziehen, und vermutlich Berechtigungsprobleme mit den Webdiensten darstellen

Hallo zusammen, ist es bekannt, dass eine WSUS-Installation (3.0 SP1) nach Update auf Server 2k3 R2 SP2 (vorher 2k3 SP2 ohne R2) nicht mehr funktioniert? Bei mir können die Update Services seitdem nicht mehr gestartet werden. Die WSUS-Deinstallation scheitert ebenso... (WSUS ... "wurde aufgrund eines Fehlers nicht entfernt") Kennt jemand das Problem?

Da hab ich ja eine schöne Beschäftigung nach meinem Urlaub ;-) Jetzt muss ich nur mal klären, ob wir problemlos auf R2 upgraden können... Haben nur "alte" Server2003 Enterprise Lizenzen. UPDATE: Okay, lizenzrechtlich konnte ich das klären - wie sieht's technisch aus, kann ich problemlos ein Upgrade eines bestehenden DCs (bisher nur isolierte Testumgebung) auf R2 machen? Oder empfielt sich eher eine Neuinstallation?

Hm, DFS, ... da tun sich ja ganz neue Möglichkeiten auf ;-) Hab ich mich bisher nicht mit befasst (außer mal zu Server2000-Zeiten), aber werde mich in das Thema bald mal einlesen!

Das ist kein Problem, der steht im (abgeschlossenen) Serverraum. Darüber sollte sich dann auch (evtl. über zusätzliche Skripte/Abfragen) erreichen lassen, dass ein User vom Standort A sich automatisch mit den Freigaben von Standort B (werden größtenteils synchronisiert) verbindet, wenn er sich dort befindet, oder?