Jump to content

Problem beim Authentifizieren gegen AD mit 2008 R2


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
  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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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>

Link zu diesem Kommentar

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>

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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?

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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?

Link zu diesem Kommentar
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...

Link zu diesem Kommentar
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. ;)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...