NilsK

Moin, das dürfte eher eine Frage des Netzwerks sein als eine von Hyper-V. Der Teaming-Funktion von Windows Server dürfte das egal sein. Da würde ich aber auch überlegen, ob ein Team aus drei 10-GbE-Adaptern wirklich sinnvoll ist, da entsteht ja auch CPU-Last, die nicht zu unterschätzen ist. Wie gesagt: Gesamtkonzept. Gruß, Nils

Moin, ah, also eine 2-Port-Karte, die insgesamt ausgefallen ist? In der Tat, dann wird es mit der Redundanz nichts. Theoretisch könnte man "auf Vorrat" aus den beiden 1-GbE-Ports auch ein Team bilden und einen vSwitch daran hängen. Auf den könnte man dann in so einem Fall die VMs umkonfigurieren. Die könnte man dann aber nicht mehr per Live-Migration oder Failover auf einen anderen Host bringen, weil dann der Switchname unterschiedlich wäre. Eher würde ich dann darüber nachdenken, zwei separate 10-GbE-Karten einzubauen statt einer Dualport-Karte. Allerdings müsste man dann auch in Betracht ziehen, wie wahrscheinlich solche Ausfälle denn sind und ob man nicht noch andere SPoFs im Gesamtsystem hat. Als dritte Variante könnte man auch den vSwitch in so einem Fall löschen und auf Basis des 1-GbE-Teams neu anlegen. Das wiederum würde ich nur tun, wenn es Skripte dafür gibt. Oder um es zusammenfassend zu sagen: Das ist ein Thema für ein Gesamtkonzept. Gruß, Nils

Moin, was ich seit einiger Zeit feststelle: Die Hintergrundfarbe des Boards scheint bei bestimmten Monitoren problematisch zu sein. Auf meinem Notebook-Display flimmert der Hintergrund immer leicht. Das ist bei anderen Webseiten im selben Browser nicht so, daher vermute ich die Farbe als Grund. Das Phänomen habe ich sowohl mit Chrome als auch mit dem Firefox. OS ist Windows 10, aktueller Stand 1803 (war aber mit 1709 schon so). Kennt das jemand? Gruß, Nils

Moin, ja, schau mal, was ich mal alles wusste. Aber wie dort schon geschrieben, ist das eigentlich auch nur ein halbgarer Workaround. Da man den Telefonen wohl kaum sagen kann, dass sie die Vendor-ID mitsenden sollen, müsste man das umgekehrt den Clients sagen. Klingt nicht unbedingt nach einem sinnvollen Aufbau. Gruß, Nils

Moin, wenn eine Netzwerkkarte im Team ausfällt, soll die andere natürlich weiterarbeiten. Das ist ja der Witz daran, noch eher als die Bandbreitenerhöhung (die bei 10 GbE gar nicht so die große Rolle spielt). Also würde ich dem Problem bzw. der möglichen Fehlkonfiguration nachgehen und keine Workarounds schaffen. Gruß, Nils

Moin, Workarounds gäbe es mehrere, man könnte auch mit Reservierungen arbeiten und an diese individuelle Optionen binden. Ein sauberer Aufbau wird daraus aber nicht. Genau für sowas sind VLANs mal erfunden worden. Gruß, Nils

Moin, die einzige saubere Lösung besteht darin, das Netz aufzuteilen, am einfachsten durch VLANs. Dann kommen die PCs in ein VLAN und die Telefone in das andere. Jedes VLAN wird dann durch DHCP mit einem eindeutigen Scope versorgt. Gruß, Nils

Moin, aha. Und was ist der Nutzen dahinter? Was meinst du mit "DHCP-Bereich"? Handelt es sich dabei um getrennte Netze? Um dasselbe Netz, aber verschiedene IP-Adressbereiche? Um dasselbe Netz und denselben Adressbereich, aber nur verschiedene Gateways? Es wäre ganz gut, ein bisschen mehr preiszugeben, sonst kann das hier eine längere, aber fruchtlose Veranstaltung werden. Gruß, Nils

Moin, wenn du Gruppenmitgliedschaften änderst, muss der betreffende User sich neu anmelden. Die tatsächlichen Gruppenmitgliedschaften kannst du am Client prüfen, wenn du, angemeldet als der betreffende User, in ein CMD- Fenster eingibst: whoami /groups | clip && notepad In dem Notepad-Fenster, das sich dann öffnet, Strg-V drücken. Nun siehst du alle direkten und indirekten Mitgliedschaften des Users. Sind die passenden Gruppen dabei? Dann könnte es natürlich sein, dass der User Mitglied einer Gruppe ist, der der Zugriff verweigert wird. Oder der User greift von einem Client aus zu, dessen Systemzeit sich von der Zeit der Domäne um mehr als fünf Minuten unterscheidet. Oder dieser Zeitunterschied tritt auf dem Dateiserver auf. In großen Umgebungen könnte es zu "Token Bloat" kommen, der User ist dann Mitglied in zu vielen Gruppen. Und das sind nur die Dinge, die mir spontan einfallen ... Gruß, Nils

Moin, dafür müsste man jetzt wissen, was du denn da erreichen willst. Was meinst du mit "zweiter DHCP-Bereich"? Und was soll am Ende dabei rauskommen? Gruß, Nils

Moin, schon seit zehn Jahren reicht es aus, einen verwaisten DC im ADUC zu löschen. Danach noch im Standorte und Dienste sowie im DNS entfernen. Gruß, Nils

Moin, jaja, so ein Backup ist immer eine praktische Sache. Schön, hier auch mal zu lesen, dass jemand sowas hat. Die defekte SSD solltest du reklamieren können. Gruß, Nils

Moin, dann war das Zertifikat sehr wahrscheinlich nicht "sofort da", sondern eher "nie weg". Müßig. Für mich ist hier Schluss. Gruß, Nils

Moin, was genau würde das an dem Problem ändern? Dass der Standby das Problem verursacht, ist praktisch ausgeschlossen. Gruß, Nils

Moin, prima, danke für die Rückmeldung. Gruß, Nils

Moin, wenn auch nur das Risiko besteht, dass die Tombstone Lifetime überschritten ist (die durchaus auch bei 60 Tagen liegen kann, je nachdem, wann und wie das AD mal installiert wurde), dann schalte den DC nicht wieder online. Es geht ja ganz offenkundig auch ohne ihn, was gäbe es da zu "retten"? Gruß, Nils

Moin, da es sich um Berechtigungseinträge handelt, wirst du das über die Manipulation der ACL regeln müssen. Dafür gibt es kein GPO-Cmdlet. Man bekommt das per PowerShell hin, aber Berechtigungen sind damit immer sehr aufwändig und fehlerträchtig. Gruß, Nils

Moin, ein Zertifikat erscheint nicht einfach von selbst, das muss irgendwo herkommen. Aus deiner Beschreibung lässt sich kaum ablesen, wie das auf die Rechner kommen könnte. Was ich aber nicht verstanden habe: Hast du die Domäne auch gelöscht und komplett neu eingerichtet? Oder nur die Server plattgemacht? So ein Fall dürfte in der Praxis kaum auftreten, daher würde ich an deiner Stelle keine weitere Energie in die Forschung stecken, sondern die ganze Umgebung komplett neu machen. Der Zeitaufwand dürfte geringer sein. Gruß, Nils

Moin, ein AD-Konto sperrt sich nicht einfach so, sondern nur, wenn jemand versucht, sich mit einem falschen Kennwort anzumelden. Als erstes könntest du also mal rausfinden, bei wie vielen Fehlanmeldungen diese Schwelle in eurer Domäne liegt. Da deiner Beschreibung nach die "ordentliche" Anmeldung funktioniert, der Chef also sein richtiges Kennwort kennt und eingibt, kommen typischerweise nur andere Prozesse in Frage, die mit einem falschen Kennwort eine Anmeldung versuchen. Das ist meist ein ehemaliges Kennwort, was Norbert mit "veralteten Credentials" meint (Credentials = Anmeldeinformationen). Meist sind solche Prozesse Dienste oder Anwendungen, die mit dem Konto des betreffenden Users konfiguriert sind, oder Tasks ("Geplante Aufgaben"), in denen das falsche Kennwort hinterlegt ist. Sowas bekommt man nur heraus, wenn man sich den betreffenden Rechner genauer ansieht. Gruß, Nils

Moin, du kannst das auch für eine passende Gruppe auf "Enroll" (nicht Autoenroll - der Unterschied ist die manuelle vs. automatische Genehmigung) setzen und den Assistenten nehmen. Wenn der mit der CA kommunizieren kann und die richtige Vorlage mit den richtigen Daten anfordert, braucht es ja nicht den Aufwand mit dem CSR. Wichtig ist vor allem, dass du solche Zertifikatsanforderungen immer prüfst und manuell freigibst, sonst kannst du dir den Zirkus gleich ganz sparen. Gruß, Nils

Moin, wenn der Ping mehrere Sekunden zur Ausführung braucht, dann klemmt die Namensauflösung. Vermutlich ist nicht der richtige DNS-Server beim Client eingetragen bzw, mindestens einer, der den Namen nicht auflösen kann. Gruß, Nils

Moin, sieht aus, als sei der eigentliche Zugriff OK. Nun könnte die Liste abgelaufen oder anderweitig ungültig sein. Oder der Dateiname ist nicht der, der im Zertifikat angegeben ist. Gruß, Nils

Moin, solche Zertifikatsvorlagen nie auf Autoenroll stellen. Du gibst damit die Kontrolle ab, wer ein Zertifikat für welchen Namen erhält. Effektiv hast du jetzt dafür gesorgt, dass jeder, der das Autoenroll-Recht hat, ein Zertifikat für einen beliebigen Computernamen anfordern kann, ohne dass dies geprüft wird. Das willst du nicht - Ruck-zuck hat jemand ein Zertifikat auf den Namen eures Mailservers für sich ausgestellt und kann sich als dieser ausgeben, ohne dass Clients eine Chance haben, das zu bemerken. Gruß, Nils PS: Es gibt schon Gründe, warum man eine PKI sorgfältig entwerfen sollte ...

Moin, das Veröffentlichen von Zertifikaten im AD wird weithin missverstanden. Das ist für fast keinen Einsatzzweck interessant; die einzige einigermaßen "übliche" Situation ist interne Mailverschlüsselung: Ein interner User, der einem anderen internen User eine verschlüsselte Mail senden will, kann per AD-Lookup dessen Zertifikat erhalten und muss es nicht erst anfordern (was voraussetzt, dass der Mail-Client das tut). Mehr passiert da nicht, es ist ein reines Datenfeld ohne weitere Logik. Das Zertifikat wird nicht für Logons verwendet, es gibt keine Sperrprozesse, und es wird auch nicht auf den Client übertragen, an dem der User arbeitet. Es gibt auch keine Verbindung von dem AD-Feld zur CA. Die CRL zu verarbeiten ist, wie Norbert schon sagt, Sache des Clients. Die meisten Clients tun das und akzeptieren ein Zertifikat nicht, wenn sie die CRL nicht finden oder diese abgelaufen ist. Das kann eine Stolperstelle in einer PKI sein. Und: Der Client sucht erst dann eine neue CRL, wenn seine lokale Kopie abgelaufen ist - da kommt die CRL-Lifetime ins Spiel, die das Sperren von Zertifikaten für "harte" Sicherheitsanforderungen eigentlich uninteressant macht (weswegen man es aber nicht weglassen darf, es darf nur nicht die einzige Maßnahme sein). Gruß, Nils

Moin, äh - aber per Autoenrollment bekommt doch das Zertifikat den Servernamen, keinen anpassbaren. Oder was genau ist da jetzt die Anforderung? Die certsrv-Webseite ist Uralttechnik und kann nur sehr wenige Zertifikatstypen ausstellen. Im Regelfall sollte man die nicht mehr verwenden. Was manuelle Requests angeht: [Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net] https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/ Gruß, Nils