Alle Aktivitäten

Hallo zusammen, wir haben aktuell "massive" Probleme mit Anmeldeproblemen, die ich einfach nicht nachvollziehen kann. Ich würde behaupten, dass die Probleme auftreten, seit dem wir einen Windows Server 2025 DC mit im System haben, 12 Jahre davor hatten wir keinerlei diese Probleme. Die Probleme äußern sich wie folgt: Einige Rechner melden bei der Anmeldung "Benutzername oder Kennwort falsch". Wenn wir in dem Moment uns dann lokal Anmelden und Test-SecureComputerChannel machen, bekomme ich ein True. NSLookup hat auch die Domain sowie alle Domaincontroller aufgelöst usw. Zeit passt auch mit den DCs überein. Nach einem Neustart des Clients gehts dann immer wieder. Das Problem haben wir auch im gesperrten Modus, also wenn ein Benutzer seinen Rechner sperrt und wieder entsperren will. Im Log des Clients wird folgendes gemeldet: EventID 4625 MachineName TA-CLPC20005.xxx.local EntryType FailureAudit Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: S-1-5-18 Kontoname: TA-CLPC20005$ Kontodomäne: [DOMAINNAME] Anmelde-ID: 0x3e7 Anmeldetyp: 2 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: S-1-0-0 Kontoname: [Anmeldename] Kontodomäne: [DOMAINNAME] Fehlerinformationen: Fehlerursache: %%2304 Status: 0xc000006d Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x9e8 Aufrufprozessname: C:\Windows\System32\svchost.exe Netzwerkinformationen: Arbeitsstationsname: TA-CLPC20005 Quellnetzwerkadresse: 127.0.0.1 Quellport: 0 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: User32 Authentifizierungspaket: Negotiate ?bertragene Dienste: - Paketname (nur NTLM): - Schl?ssell?nge: 0 zur gleichen Zeit wird auf dem DC folgendes protokolliert: Ein Kerberos-Dienstticket wurde angefordert. Kontoinformationen: Kontoname: [Anmeldename]@[DOMAINNAME] Kontodomäne: [DOMAINNAME] Anmelde- GUID: {8ceb624b-4a79-43d5-9f30-fc3eacf3d33c} MSDS-SupportedEncryptionTypes: 0x0 (N/A) Verfügbare Schlüssel: N/A Dienstinformationen: Dienstname: TA-CLPC20005$ Dienst-ID: [DOMAINNAME]\TA-CLPC20005$ MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53570 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 DES-CBC-CRC RC4-HMAC-NT-EXP RC4-HMAC-OLD-EXP Zusätzliche Informationen: Ticketoptionen: 0x40810000 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Fehlercode: 0x0 Übertragene Dienste: - Ticketinformationen Hash des Anforderungstickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= Hash des Antworttickets: Kd0//U3zlF76OWCXt/dK468UjDOx3yRqjxSDZW6014E= Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert. Kontoinformationen: Kontoname: [Anmeldename] Bereitgestellter Bereichsname: [DOMAINNAME] Benutzer-ID: [DOMAINNAME]\ [Anmeldename] MSDS-SupportedEncryptionTypes: 0x24 (RC4, AES-SK) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Dienstinformationen: Dienstname: krbtgt Dienst-ID: [DOMAINNAME]\krbtgt MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53569 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 Zusätzliche Informationen: Ticketoptionen: 0x40810010 Ergebniscode: 0x0 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Vorauthentifizierungstyp: 2 Vorauthentifizierungsverschlüsselungstyp: 0x12 Zertifikatinformationen: Name des Zertifikatausstellers: Seriennummer des Zertifikats: Fingerabdruck des Zertifikats: Ticketinformationen Hash des Antworttickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= ich weiß leider nicht mehr wo wir ansetzen sollen, es betrifft aktuell nur "wenige" einzelne Rechner, gefühlt werden es aber mehr. Hat jemand Ideen wo ich noch ansetzen könnte? Interessanterweise meldet der Client auch folgendes: 13:15:21 Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne TWSD aufgrund der folgenden Ursache nicht einrichten: Interner Fehler. Was interner Fehler hier bedeutet weiß ich nicht - ABER, dieser Fehler kommt erst eine ganze Weile nach den Meldungen oben. Auch finde ich im Log, dass er erfolgreich die Zeit mit dem DC synchronisiert usw. Ich wäre glücklich, wenn jemand eine Idee hat. Liebe Grüße

das war auch meine Vermutung - impliziert aber eine andere Interpretation von "günstig", als für die meisten Kunden üblich, die nur einen 2-Node-Cluster haben

Vermutlich wärst du selbst drauf gekommen. ;)

DAS nenne ich mal nen guten Tip, danke!

Vermutlich meinst du Fibre Channel SAN. Auch ein iSCSI SAN kann über Glasfaser gehen und ein FC SAN kann über Kupfer gehen ;)

Hi Nicht doch, das sind "bedauerliche Einzelfälle". VG Damian

Moin, das darunterliegende Protokoll - iSCSI., FC, SAS - hat nichts damit zu tun, wie zuverlässig das ganze funktioniert. Das Besondere an iSCSI *könnte* sein, dass Windows nur die ersten 10(?) Buchstaben des Maschinennamen für die IQN-Generierung verwendet. Wenn die Nodes also "HYPERVSERVER01" und "HYPERVSERVER02" heißen, ist es für das SAN derselbe IQN. Da kann es zu Fehlern kommen. Daher sollte man die IQNs kontrollieren und bei Bedarf anpassen, bevor man das ans SAN anschließt oder die LUNs für dieses Pärchen freizont. Die Cluster-Vorprüfung sagt Dir das übrigens, weil die SCSI-Reservierung nicht übertragen werden kann.

Hallo zusammen, Broadcom/VMware sammelt gerade massig Audit-Gelder bei vielen Kunden ein, „komisch“ dass Microsoft kurze Zeit später bei den „sündigen Kunden“ auch anklopft und ein Audit macht…komisch, oder „petzt“ da jemand über „Goldgruben“ ??? und wohl auch umgekehrt…“eine Hand wäscht die andere“. Ich sage schon immer „Die Welt ist schlecht und wir sitzen mitten drin“ Wird für einige wohl ein „teurer heißer Herbst“. viele Grüße, Franz

Hallo, zwei -Rechner, die auf die Selbe iSCSI-Quelle zugreifen, kann zu großen Datenverlusten führen. Ich habe gerade einen HyperV-Cluster gebaut. Zwei Knoten und ein, über Glasfaser angeschlossenes SAN. Das funktioniert einfach super. Alle redundant ausgelegt. Aktuell läuft die Migration der VMs auf den Cluster. Kann ich nur empfehlen. Denn so eine Lösung ist kostengünstig und zuverlässig. Warum also noh VM-Ware?

Mich "verwirrt" bei der Connect Sync / Cloud Sync Thematik, dass man bei Connect Sync das Seemless SSOn abschalten soll (Configure Microsoft Entra for increased security - Microsoft Entra | Microsoft Learn). Damit man das PRT bei Anmeldung bekommt, muss das Gerät Entra joined / Hybrid joined sein. Im Hybrid Szenario benötige ich dafür synchronisierte Device Objekte. Beim Cloud Sync kann ich jetzt keine Device Objekte synchronisieren und muss wiederum vom Connect Sync das SSOn "Feature" nach installieren (How to use single sign-on with cloud sync - Microsoft Entra ID | Microsoft Learn). Oder verstehe ich hier etwas falsch?

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen ruhigen Donnerstag, bleibt gesund! Hier derzeit klar bei 13°C, es wird ein meist sonniger Tag bis etwa 20°C

das ist falsch! Bei einem SAN reichen auch bei VMware zwei Hosts! Für vSAN und vVol sind mindestens drei angesagt. Was Hyper-V angeht ... klar geht das als Cluster mit zwei Nodes und SAN

So langsam gehts mir trotzdem auf die Nerven: Ja, man muss dann nur noch den Sync auf Cloud-Sync umstellen, damit man all die neuen Features nutzen kann. Ich bezweifle, dass es wirklich technische Gründe gibt, das nicht auch in Entra Connect zu implementieren, abgesehen davon, dass man Entra Connect insgesamt eigentlich gar nicht mehr haben möchte.

Moin, siehe: Introducing Cloud-Managed Remote Mailboxes: a Step to Last Exchange Server Retirement | Microsoft Community Hub Gruß Jan

Mag sein, nur ist der Exchange nicht der Grund für das Zertifikat auf dem dc.

Da hast du ohne Frage Recht, ich kann nur sagen dass es vom RZ so eingerichtet wurde Die werden ihre Gründe haben.

Exchange funktioniert problemlos ohne Zertifikate auf den dcs.

Du musst dich doch nur selber um Zertifikate kümmern, sofern du anstelle per NTLM halt zertifikatsbasiert authentifizieren möchtest. Theoretisch sollte "bald" aber auch IAKerb / LocalKDC kommen, um auch lokal Kerberos zu können. Da die Nodes (im WG) Cluster so oder so in einem eigenen Management VLAN hängen (sollten), sollte NTLM "kein Drama" sein. Das scheint mir aber genau der richtige Weg zu sein.

Moin, dafür müssten wir jetzt sehr weit ausholen, um die Zertifikats-Basics zu diskutieren, fürchte ich. Wäre vielleicht etwas viel für ein Forum. In aller Kürze: statt eine CA einzurichten, erzeugst du auf "irgendeinem" System mit einem lokalen Tool dein Root-Zertifikat. Mit diesem Root-Zertifikat stellst du mit demselben Tool das gewünschte Server-Zertifikat aus. Das Root-Zertifikat importierst du in die "Vertrauenswürdigen Zertifizierungsstellen" auf den beteiligten Systemen. Das Server-Zertifikat bindest du in den Dienst ein, der es nutzen soll. Da du ja nur Zertifikate brauchst und keine PKI, ist das für "kleine" Zwecke erheblich einfacher und sicherer. Gruß, Nils

Hmm. Ok. Genau für das habe ich ja bereits von meinem RZ (LDAPS wegen Exchange-Anbindung), Root-CA des RZ in den vertrauenswürdigen Stammzertifizierungsstellen sowie Zertifikate für die DC's jeweils in "Eigene Zertifikate". Ich bin aber ehrlich gesagt gerade zu b***d zu verstehen, wie mir das bei Mitgliedsservern oder dem Workgroup-Cluster weiterhelfen kann...?

Moin, na, und noch so ein Missverständnis, das wir ausräumen können. Für einzelne Server-Zertifikate brauchst du ja keine CA bzw. PKI. Im Gegenteil, für so einen Zweck würde ich sogar entschieden davon abraten. Es geht normalerweise darum, dass Zertifikate vorliegen, denen die Systeme vertrauen. Das kann man mit minimaler Infrastruktur einrichten, für die man keine komplexen und anfälligen Systeme braucht. Exemplarisch habe ich das hier mal skizziert: [LDAPS in einer Windows-Domäne ohne PKI | faq-o-matic.net] https://www.faq-o-matic.net/2024/06/18/ldaps-in-einer-windows-domne-ohne-pki/ Gruß, Nils PS. PKI ist böse.

Ok, alles gute Argumente. Habe aber gerade gelesen dass ich für Server 2025 Workgroup Cluster Zertifikate brauche... Keine CA, wird schwierig. Wenn mir da unser Rechenzentrum nicht gnädigerweise Zertifikate ausstellt wird das nix. Mal schauen. Gibt ja jetzt genug für und wieder, muss nur noch sehen welche "Probleme" ich lösen kann und mit welchen Einschränkungen ich leben kann/will. Auf jeden Fall schon mal danke für die Beteiligung!

Es gibt auch regelmäßig den Trend, dass man alle Management Maschinen (Hypervisor, egal welcher Hersteller; Server Remote Access (iLo, iDrac,...); Backup Server; etc.) mal ins AD aufnehmen sollte und dann wieder aus dem AD entfernen sollte usw. Hat halt beides vor und Nachteile.

Und hyper-v Hosts mit laps sind auch ein Stolperstein, wenn mal die komplette Umgebung down sein sollte. Und ja alles schon erlebt. Utilman.exe hilft zwar, dauert aber alles in solche Situationen. ;) seitdem sind die hyper-v Hosts bei den Kunden meist ohne laps konfiguriert und haben einfach komplexe lange Kennwörter, die man ja nie eingeben muss, solange die Dinger im ad hängen.

Moin, das hat jetzt aber schon was davon, das Haar in der Suppe zu suchen. Auf zwei Nicht-AD-Hosts kannst du auf beide genannten "Nachteile" ja gut verzichten. Auch ein lokales Adminkennwort muss man nicht per se regelmäßig wechseln, wenn es ausreichend stark ist. Der Witz an LAPS ist doch primär, dass man von massenweise verwendeten identischen Adminkennwörtern weg will - das kann man für den Use Case doch problemlos organisatorisch sicherstellen. Ähnlich bei Protected Users - die meisten Maßnahmen, die das umsetzt, kommen bei lokalen Systemen ja gar nicht in Betracht, und vom Rest lässt sich ein Großteil organisatorisch abfangen. Wenn ich mir ansehe, wie freimütig die meisten VMware-Systeme in der freien Wildbahn so eingerichtet sind, sehe ich da wirklich keinen grundsätzlichen Nachteil ... Gruß, Nils