NullDevice 10 Geschrieben 17. November 2012 Melden Teilen Geschrieben 17. November 2012 Hallo, Ich habe hier ein Testnetzwerk seit einiger Zeit. Ich hab 1 physischen Client (notebook) mit Win7 pro + einen Win2008 R2 server als DC. Seit jeher dauert der Loginvorgang schlicht und ergreifend ewig, je nach User. Insbesondere mit dem Hauptuser den ich als erster erstellt habe und den ich meist verwende. Ewig heisst hier, 10 bis 15 Min, geschätzt. Dabei ist das Profil winzig. Hatte jetzt endlich mal Zeit es mir mal genauer anzusehen, und dabei ist mir am eventlog am Client aufgefallen, dass sowohl Computerkonto als auch Benutzerkonto nicht richtig authentifiziert werden können. Somit hab ich den Client mal entfernt aus der Domäne, rebootet und wieder aufgenommen. Doch jetzt geht gar nix mehr. Die ersten 2x kam die Meldung dass kein Anmeldeserver verfügbar sei, egal mit welchem User ich es versuchte. Wenn man sich mit einem lokalen User anmeldet, kann man rasend schnell auf alle shares zugreifen die am DC selbst liegen. Der client bekommt per DHCP die richtigen settings: Dynamische IP im gleichen Netz wie der DC, und der DC ist auch der (einzige) DNS server der mitgegeben wird. Die Anbindung des clients hab ich auch schon getauscht: Ob per WLAN oder Netzwerkkabel, es ist das gleiche und dauert auch gleich lang, wie gesagt schon seit damals. Daran dürfte es nicht liegen. Jetzt kann ich mich plötzlich anmelden, allerdings mit einem temporären Profil (ohne dass ich etwas geändert hätte). Hier sind ein paar Meldungen, aber es kommen öfter auch andere, neue: Durch die Berechtigungseinstellungen (Anwendungsspezifisch) wird der SID (S-1-5-21-1362269636-4189412954-3939820232-1110) für Benutzer VIALACTEA\ndev von Adresse LocalHost (unter Verwendung von LRPC) keine Berechtigung zum Aktivierung (Lokal) für die COM-Serveranwendung mit CLSID {0C0A3666-30C9-11D0-8F20-00805F2CD064} und APPID {9209B1A6-964A-11D0-9372-00A0C9034910} gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für Komponentendienste geändert werden. Er hat auch schon mal gemeint den RPC server nicht zu finden, wobei ich nicht weiss ob er den lokalen oder den remoten meint. Der Aufruf "ScRegSetValueExW" ist für "FailureActions" aufgrund folgenden Fehlers fehlgeschlagen: Zugriff verweigert Vom "NtpClient" konnte kein Domänenpeer als Zeitquelle festgelegt werden, da keine Vertrauensstellung zwischen diesem Computer und der ""-Domäne zur sicheren Zeitsynchronisierung eingerichtet werden konnte. In 3473457 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt. Fehler: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. (0x8007051F) Der Terminalserver kann den Dienstprinzipalnamen "TERMSRV", der für die Serverauthentifizierung verwendet werden soll, nicht registrieren. Der folgende Fehler ist aufgetreten: Der RPC-Server ist nicht verfügbar. . Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne VIALACTEA aufgrund der folgenden Ursache nicht einrichten: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. Dies kann zu Authentifizierungsproblemen führen. Stellen Sie sicher, dass Der RPC Dienst ist auf beiden, dem Client und dem DC gestartet. Die Windows-Firewall am DC ist auch so eingestellt dass RPC zugelassen wird sowie "RPC Endpunktzuordnung". Eine andere Firewall gibt es nicht, Antivirensoftware gibts ebenfalls nicht am Server. Ich kann den DC per Hostname oder IP solange pingen wie ich will, er hat super Pingzeiten (meist 1ms) und keine verlorenen Pakete. Kann mir mal jemand einen Tipp geben, was ich versuchen könnte? Ich schick' Euch auch gern meint eventlog wenn Ihr wollt. Bin echt ratlos im Moment. Lg, ND Zitieren Link zu diesem Kommentar
jose 10 Geschrieben 17. November 2012 Melden Teilen Geschrieben 17. November 2012 Hallo NullDevice, überprüfe doch mal alle notwendigen Ports: Technet: Portanforderungen für Active Directory Was ergibt dcdiag am Server? Im übrigen nehme ich an, dass Server und Client regulär installiert wurden - also nix geklontes oder so?! Gruß jose Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 17. November 2012 Autor Melden Teilen Geschrieben 17. November 2012 Naja vonwegen Ports, es steht ja nur ein GBit switch dazwischen, sonst nichts. Der wird wohl nix blocken... Wenn ich per WLAN einsteige ist der WLAN Router dazwischen, aber es passiert mit Kabel am Switch halt ebenfalls, also kann der keine Fehlerquelle sein. Nein, client und server wurden nicht geclont. Der Server ist allerdings virtuell (vmware), der Client ist ein normales HP i7 notebook mit Win7 x64 pro DE. Allerdings wurde am Client mal die Festplatte geclont wg. Umstieg auf SSD. Aber Windows war noch immer aktiviert danach, bis jetzt. Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 17. November 2012 Autor Melden Teilen Geschrieben 17. November 2012 C:\Windows\system32>dcdiag Verzeichnisserverdiagnose Anfangssetup wird ausgeführt: Der Homeserver wird gesucht... Homeserver = Helios * Identifizierte AD-Gesamtstruktur. Sammeln der Ausgangsinformationen abgeschlossen. Erforderliche Anfangstests werden ausgeführt. Server wird getestet: BaseOne\HELIOS Starting test: Connectivity ......................... HELIOS hat den Test Connectivity bestanden. Primärtests werden ausgeführt. Server wird getestet: BaseOne\HELIOS Starting test: Advertising ......................... HELIOS hat den Test Advertising bestanden. Starting test: FrsEvent ......................... HELIOS hat den Test FrsEvent bestanden. Starting test: DFSREvent ......................... HELIOS hat den Test DFSREvent bestanden. Starting test: SysVolCheck ......................... HELIOS hat den Test SysVolCheck bestanden. Starting test: KccEvent ......................... HELIOS hat den Test KccEvent bestanden. Starting test: KnowsOfRoleHolders ......................... HELIOS hat den Test KnowsOfRoleHolders bestanden. Starting test: MachineAccount ......................... HELIOS hat den Test MachineAccount bestanden. Starting test: NCSecDesc ......................... HELIOS hat den Test NCSecDesc bestanden. Starting test: NetLogons ......................... HELIOS hat den Test NetLogons bestanden. Starting test: ObjectsReplicated ......................... HELIOS hat den Test ObjectsReplicated bestanden. Starting test: Replications ......................... HELIOS hat den Test Replications bestanden. Starting test: RidManager ......................... HELIOS hat den Test RidManager bestanden. Starting test: Services ......................... HELIOS hat den Test Services bestanden. Starting test: SystemLog ......................... HELIOS hat den Test SystemLog bestanden. Starting test: VerifyReferences ......................... HELIOS hat den Test VerifyReferences bestanden. Partitionstests werden ausgeführt auf: ForestDnsZones Starting test: CheckSDRefDom ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... ForestDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: DomainDnsZones Starting test: CheckSDRefDom ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... DomainDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: Schema Starting test: CheckSDRefDom ......................... Schema hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Schema hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: Configuration Starting test: CheckSDRefDom ......................... Configuration hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Configuration hat den Test CrossRefValidation bestanden. Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 17. November 2012 Autor Melden Teilen Geschrieben 17. November 2012 Partitionstests werden ausgeführt auf: vialactea Starting test: CheckSDRefDom ......................... vialactea hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... vialactea hat den Test CrossRefValidation bestanden. Unternehmenstests werden ausgeführt auf: vialactea.local Starting test: LocatorCheck ......................... vialactea.local hat den Test LocatorCheck bestanden. Starting test: Intersite ......................... vialactea.local hat den Test Intersite bestanden. Zitieren Link zu diesem Kommentar
Sunny61 773 Geschrieben 17. November 2012 Melden Teilen Geschrieben 17. November 2012 Ich habe hier ein Testnetzwerk seit einiger Zeit. Ich hab 1 physischen Client (notebook) mit Win7 pro + einen Win2008 R2 server als DC. Seit jeher dauert der Loginvorgang schlicht und ergreifend ewig, je nach User. Insbesondere mit dem Hauptuser den ich als erster erstellt habe und den ich meist verwende. Ewig heisst hier, 10 bis 15 Min, geschätzt. Dabei ist das Profil winzig. Zeig doch mal ein ipconfig /all vom DC und vom Client. Zusätzlich kannst Du eine GPO mit beiden Einstellungen aus der GPO FAQ No. 36 erstellen und auf die Domain verlinken: FAQ-GPO Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 17. November 2012 Autor Melden Teilen Geschrieben 17. November 2012 DC: C:\Windows\system32>ipconfig /all Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Helios Primäres DNS-Suffix . . . . . . . : vialactea.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : vialactea.local Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller Physikalische Adresse . . . . . . : 50-E5-49-5B-E8-D5 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::ddcf:1291:d801:21c3%12(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 10.23.23.1(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 10.23.23.254 DHCPv6-IAID . . . . . . . . . . . : 256959817 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-74-33-0E-50-E5-49-5B-E8-D5 DNS-Server . . . . . . . . . . . : ::1 127.0.0.1 NetBIOS über TCP/IP . . . . . . . : Aktiviert Ethernet-Adapter VMware Network Adapter VMnet1: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet 1 Physikalische Adresse . . . . . . : 00-50-56-C0-00-01 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::693b:db1:8ef7:10cb%14(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.19.1(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : DHCPv6-IAID . . . . . . . . . . . : 318787670 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-74-33-0E-50-E5-49-5B-E8-D5 DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{0AF76297-B3A8-4833-B5C1-E3D3794F897E}: 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 LAN-Verbindung*: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-Teredo-Tunneling-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{BE5E831C-DAF6-4BF6-969F-FFF03DC8BBE5}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja C:\Windows\system32> Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 17. November 2012 Autor Melden Teilen Geschrieben 17. November 2012 client: Ethernet-Adapter LAN-Verbindung 3: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Fortinet virtual adapter Physikalische Adresse . . . . . . : 00-09-0F-FE-00-01 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung: Verbindungsspezifisches DNS-Suffix: vialactea.local Beschreibung. . . . . . . . . . . : Intel(R) Centrino(R) Ultimate-N 6300 AGN Physikalische Adresse . . . . . . : 00-24-D7-04-1F-50 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IPv4-Adresse . . . . . . . . . . : 10.23.23.52(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Lease erhalten. . . . . . . . . . : Samstag, 17. November 2012 09:03:07 Lease läuft ab. . . . . . . . . . : Samstag, 24. November 2012 07:42:11 Standardgateway . . . . . . . . . : 10.23.23.254 DHCP-Server . . . . . . . . . . . : 10.23.23.254 DNS-Server . . . . . . . . . . . : 10.23.23.1 Primärer WINS-Server. . . . . . . : 10.23.23.1 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.vialactea.local: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: vialactea.local Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{F0FB4F9B-19CC-4D9B-8551-34F640F28BF1}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{C2CFBB0B-3C95-41EB-AD07-31C03A81249A}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5 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 Tunneladapter isatap.{9A6D5E46-28A0-483A-8F65-237BD0B8FF64}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.chello.at: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja C:\Users\Administrator> Zitieren Link zu diesem Kommentar
Sunny61 773 Geschrieben 18. November 2012 Melden Teilen Geschrieben 18. November 2012 DC:C:\Windows\system32>ipconfig /all Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Helios Primäres DNS-Suffix . . . . . . . : vialactea.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : vialactea.local Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller Physikalische Adresse . . . . . . : 50-E5-49-5B-E8-D5 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::ddcf:1291:d801:21c3%12(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 10.23.23.1(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 10.23.23.254 DHCPv6-IAID . . . . . . . . . . . : 256959817 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-74-33-0E-50-E5-49-5B-E8-D5 DNS-Server . . . . . . . . . . . : ::1 127.0.0.1 NetBIOS über TCP/IP . . . . . . . : Aktiviert Ethernet-Adapter VMware Network Adapter VMnet1: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet 1 Physikalische Adresse . . . . . . : 00-50-56-C0-00-01 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::693b:db1:8ef7:10cb%14(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.19.1(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : DHCPv6-IAID . . . . . . . . . . . : 318787670 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-74-33-0E-50-E5-49-5B-E8-D5 DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS über TCP/IP . . . . . . . : Aktiviert Ein DC mit 2 NICs ist schlecht. Multihomed, kannst danach suchen. Probleme sind wohl an der Tagesordnung. Deaktiviere die zweite NIC. Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 18. November 2012 Autor Melden Teilen Geschrieben 18. November 2012 Hab vorher versehentlich gesagt, dass der DC virtuell ist, sorry. Richtig ist jedoch, dass er selbst vmware workstation hostet wo ein paar andere VMs (Win7 clients) zum testen drauf sind. Der DC selbst ist aber ein physischer Rechner ist auf dem Server 2008R2 installiert ist. Ich weiss nicht genau ob es gut ist, wenn ich die VMware NIC (192.168...) deaktiviere. Die normale LAN NIC ist die 10.23.23... Diese virtuelle VMware NIC wird jedoch, nehme ich an, gebraucht für die VMs. Allerdings ist die IP 192.168 etwas selbtsam, da es hier nur das 10er Netz gibt. Was würdet ihr machen? Zitieren Link zu diesem Kommentar
Sunny61 773 Geschrieben 18. November 2012 Melden Teilen Geschrieben 18. November 2012 Hab vorher versehentlich gesagt, dass der DC virtuell ist, sorry. Richtig ist jedoch, dass er selbst vmware workstation hostet wo ein paar andere VMs (Win7 clients) zum testen drauf sind. Der DC selbst ist aber ein physischer Rechner ist auf dem Server 2008R2 installiert ist. Ein DC sollte nur DC spielen, sonst nichts anderes. Ich weiss nicht genau ob es gut ist, wenn ich die VMware NIC (192.168...) deaktiviere. Die normale LAN NIC ist die 10.23.23... Du kannst auch andere Einstellungen in VMWare Workstation vornehmen. Diese virtuelle VMware NIC wird jedoch, nehme ich an, gebraucht für die VMs. Allerdings ist die IP 192.168 etwas selbtsam, da es hier nur das 10er Netz gibt. Ich hab gerade kein VMWare Workstation da, aber Du kannst dort ja auch die NIC vom Host verwenden. Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 19. November 2012 Autor Melden Teilen Geschrieben 19. November 2012 Ich hab diese VMware NIC anscheinend wirklich nicht gebraucht. Ich hab sie deaktiviert und alles lief weiter. Jedoch besserte sich mein Problem immer noch nicht. Dann hab ich endlich herausgefunden was die Ursache war: Die Comodo Personal Firewall am Client. Hatte eher den Server vermutet, dort war aber nur die Windowsfirewall drauf. Comodo Deaktiviert: Klappt wie am Schnürchen. Bin mir aber sicher, dass es eine Konfigurationsmöglichkeit dafür gibt, wenn man weiss was genau geblockt wird. Zitieren Link zu diesem Kommentar
Sunny61 773 Geschrieben 19. November 2012 Melden Teilen Geschrieben 19. November 2012 Die Comodo Personal Firewall am Client. Hatte eher den Server vermutet, dort war aber nur die Windowsfirewall drauf. Comodo Deaktiviert: Klappt wie am Schnürchen. Na wunderbar, Danke für die Rückmeldung. ;) Bin mir aber sicher, dass es eine Konfigurationsmöglichkeit dafür gibt, wenn man weiss was genau geblockt wird. Weshalb will man eine 3rd Party Firewall einsetzen, die man nicht konfigurieren kann? Was spricht gegen die Windows Firewall? Zitieren Link zu diesem Kommentar
NullDevice 10 Geschrieben 19. November 2012 Autor Melden Teilen Geschrieben 19. November 2012 Na wunderbar, Danke für die Rückmeldung. ;) Weshalb will man eine 3rd Party Firewall einsetzen, die man nicht konfigurieren kann? Was spricht gegen die Windows Firewall? Wie gesagt, wahrscheinlich KANN man sie konfigurieren. Werd mich bei Gelegenheit mal damit auseinandersetzen... In einer professionellen/produktiven Umgebung, zB. mit 27 server hätte ich aber wenig Lust überall ständig eine third party Firewall zu konfigurieren, oder in Probleme wie eben zu laufen. Die Windows Firewall blockt das meiste was es soll ohne dass man irgendwas konfiguriert, das ist praktisch. - Ausserdem hat man ja in einer professionellen Umgebung zusätzlich auch eine Hardware-Firewall, normalerweise. Was GEGEN die Windows Firewall spricht, ist das MS anscheinend einen API oä. anbietet, mitdem man automatisiert Regeln für seine eigenen 3rd Party Applikationen erstellen kann. Zumindest findet man in den Regeln meist einen Haufen installierter Drittanbieterapplikationen - Das wäre wohl das erste was ich tun würde, wenn ich einen Trojaner oä. programmieren würde. Wie gesagt, es war nur eine Testumgebung und das Notebook war halt mein privates. - Deshalb die seltsame Firewall... Zitieren Link zu diesem Kommentar
Sunny61 773 Geschrieben 19. November 2012 Melden Teilen Geschrieben 19. November 2012 Wie gesagt, wahrscheinlich KANN man sie konfigurieren. Werd mich bei Gelegenheit mal damit auseinandersetzen... Das sollte man vorher tun. ;) In einer professionellen/produktiven Umgebung, zB. mit 27 server hätte ich aber wenig Lust überall ständig eine third party Firewall zu konfigurieren, oder in Probleme wie eben zu laufen. Wenn man sowas einsetzt, muss man es konfigurieren können, und zwar zentral. Die Windows Firewall blockt das meiste was es soll ohne dass man irgendwas konfiguriert, das ist praktisch. - Ausserdem hat man ja in einer professionellen Umgebung zusätzlich auch eine Hardware-Firewall, normalerweise. Und die Windows FW kannst Du mit Hilfe von Gruppenrichtlinien IMHO sehr gut konfigurieren. Was GEGEN die Windows Firewall spricht, ist das MS anscheinend einen API oä. anbietet, mitdem man automatisiert Regeln für seine eigenen 3rd Party Applikationen erstellen kann. Zumindest findet man in den Regeln meist einen Haufen installierter Drittanbieterapplikationen - Das wäre wohl das erste was ich tun würde, wenn ich einen Trojaner oä. programmieren würde. Um schreiben zu können, benötigt der Trojaner Schreibrechte, die hat er nur wenn der ausführende Benutzer auch Adminrechte hat. Wie gesagt, es war nur eine Testumgebung und das Notebook war halt mein privates. - Deshalb die seltsame Firewall... Auch auf einem privaten NB möchte ich keine 3rd Party FW. Die Nebeneffekte können grausam sein, siehst Du jetzt ja auch. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.