Marco31

Hallo Forum,

seit gestern funktioniert meine interne WSUS-DB nicht mehr. Der Dienst ist beendet und lässt sich nicht mehr starten, Fehler 1069... Merkwürdig ist, dass das gleiche Problem bei einem anderen Dienst auch auftrat, da habe ich es beheben können indem ich die Anmeldedaten für das Dienstkonto neu eingegeben habe; er hat dann den Benutzer auch bei "Anmelden als Dienst" eingetragen, dann ließ sich der Dienst wieder starten.

Nur leider funktioniert das ja nicht beim Konto der internen DB, da habe ich ja keine Anmeldedaten... Hat jemand eine Idee wie man das Problem löst?

Die einzige Veränderung am Server war die gestrige Installation der aktuellen Updates.

Kleiner Nachtrag: Im Sicherheitsprotokoll wird gemeldet: "Dem Benutzer wurde nicht der angeforderte Anmeldetyp für diesen Computer gewährt." Anmeldetyp = 5 (Service)
Tja, tatsächlich ist in der lokalen Sicherheitsrichtlinie "anmelden als Dienst" der Benutzer NT SERVICE\MSSQL$MICROSOFT##WID nicht vorhanden, ich kann diese aber auch nicht hinzufügen... Hat da Microsoft was geändert was mir entgangen ist bezüglich Dienstkonten...?

LÖSUNG:

Hat sich erledigt; war eigene Dummheit  Hatte ne gpo für "Anmelden als Dienst" konfiguriert, die hatte das ganze überschrieben... GPO entfernt, schon läuft es wieder!

Das ist vielleicht falsch rübergekommen; primär sichern wir auf Disk mit Veeam, da habe ich auch vergleichbare Möglichkeiten. Instant Recovery, Surebackup etc. Und nachts geht's dann auf Band. 

Ich sichere seit 20 Jahren auf Bänder,  vor ein paar Jahren musste man sich noch anhören wie rückständig das wäre... Zeiten ändern sich 😉

Der Memory Bedarf scheint mir schon höher als normal... Wir haben eine sehr kleine Umgebung und LSASS genehmigt sich nach ner Woche Laufzeit 300MB. Nix was dem Server was ausmacht, aber mehr als normalerweise. 

Veeam zum Beispiel funktioniert mit gMSA, gibt's auch Anleitungen zu.

Hallo Forum,

eine Frage an alle die schon WDAC einsetzen.

Ich bin am testen von WDAC um damit mittelfristig Applocker abzulösen. Als GUI für die Policy-Erstellung gibt's ja den Windows Defender-Anwendungssteuerungs-Assistent; das ist in dem Falle um einiges komfortabler als Powershell.

Dabei sind mir aber trotz Studium der entsprechenden Microsoft-Artikel einige Sachen noch nicht ganz klar:

- Wenn ich eine Richtlinie erstelle, generiert mir der WDAC-Assi eine .xml und eine .cip Datei. Auf welche von beiden muss die gpo verweisen? 

- Oder muss ich eine der beiden Dateien noch in besagte Binärdatei konvertieren? Laut Settings im Assi erstellt er ja bei Auswahl der Option die Binärdatei mit...

- Wie kann ich feststellen ob die Policy auch wirklich verarbeitet wird? Bisher lässt sich nämlich auf dem Testclient jede Anwendung ohne Meldung im Ereignislog ausführen, da dürfte also noch was im argen liegen.

Hmmm, DNS Namensauflösung scheint zumindest nicht das einzige Problem zu sein... Die Kollegen des RZ haben jetzt bei der VPN-Verbindung den DNS mitgegeben, leider wird die Anmeldung von Mitgliedern in protected Users immer noch wegen Kontobeschränkungen abgelehnt. Jemand noch eine Idee? 

Im Zweifel müsste ich eine Art Jump Host bauen, auf den ich mich mit einem User anmelde und dann innerhalb des Netzes mit protected Users arbeite.

Firewall und VPN werden vom RZ bereitgestellt, bei dem Konstrukt bekomme ich über VPN keine Namensauflösung auf meine Domäne. Daher RDP per IP 

vor 47 Minuten schrieb cj_berlin:

Moin,

 

nur damit es nicht ungesagt bleibt:

• seit Server 2016 ist es möglich, SPNs auch auf IP-basis zu vergeben und den Client per Registry anzuweisen, solche Service-Tickets anzufordern - das muss man aber halt tun

 Danke für den Hinweis, das werde ich dann so umsetzen👍

Über IP normalerweise; meinst du daran liegt es?

Keine Ahnung warum; wenn der User in "protected Users" ist, bekomme ich bei der RDP-Anmeldung über VPN die Meldung, dass eine Anmeldung aufgrund von Kontobeschränkungen nicht möglich ist. Entferne ich die Gruppe "protected Users" funktioniert es wieder.

Wundert mich ja auch etwas...

Tja, leider haben sich die protected users selbst disqualifiziert; damit war nämlich kein Zugriff mehr per RDP über VPN möglich... 😞

Da ich (leider) auch noch Server 2016 im Einsatz habe ist LAPS für die Server (noch) kein Thema - ich habe auch keine Lust das native LAPS UND das "alte" LAPS zu verwalten... Bei der überschaubaren Anzahl der Server kann man das auch "per Hand" umsetzen.

vor 29 Minuten schrieb testperson:

Hi,

hier wäre es wohl "am einfachsten", die DCs so aufzustellen, dass einer immer verfügbar ist. Je nach vorhandener Infrastruktur zwei DCs in der virtualisierten Umgebung, einer direkt auf Blech und ein vierter an einem anderen Standort (Cloud, "Colocation", "Brandabschnitt", ...).

Normalerweise ja, ich hatte aber vor einiger Zeit den Fall wo wirklich nichts mehr ging in Sachen DC - da hätte ich dann ein Problem gehabt. 

vor 29 Minuten schrieb testperson:

An die LAPS Kennwörter würdest du ohne verfügbaren Domain Controller nicht dran kommen. ;)

 

Gruß

Jan

 Verdammt, stimmt ja  Also doch "Notfall-Admin-Konto"

Ok, danke erstmal. Punkt a kann ich ausschließen, mit Ausnahme von langen Remotesessions bei Dienstleister-Einsatz... Zu Punkt b sind mir (derzeit) keine Anwendungen bekannt, das wird sich dann wohl zeigen... Und Punkt c wird dann zum Problem falls die DC's mal nicht verfügbar sind - hier sollte man sich dann also einen "Not-Admin" anlegen, der nur in diesem Fall benutzt wird... Oder lokaler Server-Admin, ggf mit LAPS.

Liege ich da soweit richtig?

Hallo Forum,

man will es ja den potentiellen Angreifern so schwer wie möglich machen, dabei bin ich auf die Gruppe "protected Users" gestoßen. Hört sich für mich erst einmal so an, als wären da die Domänen- und Server-Admin-Konten gut aufgehoben. Interessant wäre jetzt natürlich, wer das einsetzt und welche Probleme dabei unter Umständen auftreten. 

Wäre für jeden Erfahrungsbericht dankbar

Am 23.9.2023 um 07:48 schrieb q617:

Warum keine moderne Cloud-Lösung?

Wer sponsert dich eigentlich? All deine Kommentare sind "Warum keine moderne Cloud Lösung?"...

Ja, sieht bisher sehr gut aus. AD Ereignislogs sauber, dcdiag unauffällig, Server & Clients laufen alle. Ich denke mit nem blauen Auge davon gekommen

Möchte hier auch noch mal den Veeam-Support lobend erwähnen; wegen nem Problem beim Restore hatte ich ein Ticket aufgemacht und der Rückruf kam keine 15 Minuten später inkl. Problemlösung, so wünscht man sich das!

Ich hatte vom kurzem den Fall, das bei einer VM keine Anmeldung mehr möglich war. Durch einen Download war C:\ so voll das jegliche Anmeldung in einer nicht mehr reagierenden VM endete. Da ich das Windows Admin Center laufen habe, konnte die da über "Dateien" die Downloads löschen. Danach konnte man sich wieder an der VM anmelden. Vielleicht hilft ja eine ähnliche Vorgehensweise beim TO? 

Festplatte vergrößern ist doch easy going bei Virtualisierung solange noch genug Platz am Storage ist. Ist ja einer der großen Vorteile bei VM's...

Was ich auch nicht bedacht hatte: wenn DNS weg ist wirds auch schwierig mit Zugriff auf vcenter und alles was per DNS aufgelöst werden muss. Da haben Einträge in die hosts Datei dann geholfen. Lernen auf die harte Tour 

Ja, hatte die VM mit der nicht-authorisierenden Wiederherstellung gelöscht und wieder neu recovered, dann die Reg-Keys für den Authorisierenden Modus gesetzt.

Das sieht bisher ganz gut aus! Ich konnte erst keinen neuen Server in die Domäne aufnehmen, nach entfernen des ursprünglichen Replikationspartners (Sozusagen DC alt 2) mit metadata cleanup ging auch das dann. Der neue zweite DC ist hochgestuft, Sysvol und Netlogon auch vorhanden.

Ich denke (und hoffe) dass damit das schlimmste überstanden ist, werde die Server jetzt wieder hochfahren. 

Vielen Dank für die Hilfe!!!! Rettung in höchster Not

Auf was sollte ich in den nächsten Tagen in Sachen AD besonders achten?

Die Clients waren alle aus, hatte getestet ob die Server alle noch laufen. Die Zeit nehme ich mir, wichtig ist dass es danach wieder funktioniert

Du meinst also den "alten" DC noch mal wiederherstellen, diesmal Authorisierend?

Ist es schädlich dass andere Server jetzt schon hochgefahren sind?