phatair

Hallo zusammen, wir haben aktuell folgendes sporadisches Problem. Auf einigen Windows 10 22H2 (10.0.19045.3448) Clients fehlen plötzlich die WSUS GPO Einträge bzw. der komplette Schlüssel in der Registry -> "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" Damit greifen die Clients auf Windows Update zu und es wird z.B. auch das Windows 11 Update beworben. Im WSUS stehen die Clients dann auch "Client hat sich seit x Tagen nicht mehr gemeldet" drin. Prüft man per gpresult /r die GPOs auf dem Client, ist die GPO aber noch zugewiesen. Ebenso zeigt gpresult /h <pfad> auf dem Client an, dass die WSUS GPO übernommen wurde Prüft man aber eben den Regpfad, fehlt der komplette WindowsUpdate Ordner/Schlüssel. Führt man ein gpupdate /force durch, wird der Regestry Eintrag wieder gesetzt und alles funktioniert wie es soll. Wie man ja aber bei Gruppenrichtlininen.de gelernt hat, soll man force nur im Ausnahmefall nutzen :) Ich verstehe nicht, warum plötzlich bei einigen Clients dieser Eintrag nicht mehr per GPO gesetzt wird bzw. verschwindet. Hat hier jemand eine Idee? Vielen Dank. Grüße, Steffen

Das wars tatsächlich. Hatte ich null auf dem Schirm, dass hinter dem Public Folder ja noch eine Mailbox steht die auch eine Quota hat. Nach der Anpassung habe ich noch den Information Store Dienst neu gestartet und dann ging es sofort. Vielen Dank für eure Hilfe.

Leider hat beides nicht geholfen, weder Information-Store aufheben/anbinden noch der Reboot danach. Hm.... blöde Frage, aber wo prüfe ich das? In der ECP sehe ich unter -> Öffentliche Ordner -> "Postfächer für öffentliche Ordner" die entsprechende Mailbox. Schaue ich mir die Postfachnutzung an, ist es schon merkwürdig. Hier steht, dass das Kontingent nicht eingeschränkt ist. Klicke ich aber auf "Weitere Optionen..." steht doch eine Einschränkung drinnen, oder verstehe ich das falsch Heißt also, wenn alle Public Folder in dieser Mailbox 11GB erreichen, ist Schluss oder? Grüße

Nein, noch nicht. Das wäre mal die letzte Idee, richtig. Werde ich machen und berichten. Was genau hat das mit meinem Problem zu tun?

Hallo zusammen, ich habe folgendes Problem Wir haben auf unserem Exchange 2016 noch ein paar Public Folders. Bei einem habe ich nun das Problem, dass die User keine Mails mehr in diesen Public Folder verschieben können. Sie erhalten die Fehlermeldung Ich habe dann die Quota für den Public Folder angepasst (inkl. Unterordner) Get-PublicFolder -Identity "<identity>" -Recurse | Set-PublicFolder -IssueWarningQuota 12GB -ProhibitPostQuota 12.5GB Danach habe ich den Public Folder geprüft, es werden mir die neuen Werte auch angezeigt ProhibitPostQuota : 12 GB IssueWarningQuota : 12.5 GB MaxItemSize : 100 MB Mit folgenden Befehl habe ich dann die aktuelle Größe von dem Public Folder geprüft Get-PublicFolder "<Identity>" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speiche r in Byte'; E={$_.Sum}} | fl Als Größe wird mir dann angezeigt Für mich heißt das, dass der Public Folder einen Grenzwert von 12,5GB hat und seine aktuelle Größe rund 9GB ist. Warum erhalte ich dann aber in Outlook die Meldung, dass der Nachrichtenspeicher voll ist? Hat hier jemand eine Idee? Cache Mode habe ich in Outlook schon deaktiviert um mögliches Caching auszuschließen. Vielen Dank.

Ok, da sucht man längere Zeit nach einer Lösung und wenn man dann die Frage im Forum stellt, findet man die Lösung :) Ich habe dann dem Computer Objekt in der AD einfach eine weitere Gruppe temporär als Mitgliedschaft hinzugefügt. Den Server neu gestartet und nun zeigt gpresult -r wieder alle Computermitgliedschaft an. Auch wenn man die temporäre Gruppe danach wieder entfernt. Ich hoffe damit sind alle Probleme, die durch den Befehl winmgmt /resetrepository hervorgerufen wurden, nun beseitigt. Besonders ärgerlich war, dass die GPOs plötzlich nicht mehr gewirkt haben. Vielleicht hilft ja der Beitrag in Zukunft jemanden.

Hallo zusammen, wir haben auf unseren Servern die Endpoint Protection von Kaspersky deinstalliert. Da nach der Deinstallation die neue Endpoint Protection die Meldung gebracht hat, dass noch eine andere Endpoint Protection installiert ist, haben wir uns an den Kaspersky Support gewendet. Dieser hatte uns den Tipp gegeben, nach der Deinstallation den Befehl winmgmt /resetrepository auszuführen. Dies haben wir gemacht und danach ließ sich auch die neue Endpoint Protection sauber installiert. Nun ist uns aber foglendes aufgefallen. Auf allen Server wo wir diesen Befehl ausgeführt haben, waren keine GPOs mehr aktiv. Wir haben dies mit gpresult -r geprüft. Es waren keine zugewiesenen GPOs mehr aufgelistet und ebenso auch keine Sicherheitsgruppen mehr, die dem Computer zugeordnet sind. Auch fehlt im der gpresult -r Ausagbe der Domänennamen und der Standort. Die GPOs haben wir wieder aktiviert bekommen, nach dem wir ein gpupdate force ausgeführt haben (ein einfaches gpupdate hat nicht ausgereicht). Die Gruppenmitgliedschaften werden aber weiterhin nicht angezeigt. Auch ein Reboot des Servers hat nicht geholfen. Hat jemand eine Idee wie man das wieder korrigieren kann? Wir sind wohl etwas blauäugig an den Befehl winmgmt /resetrepository rangegangen. Es handelt sich bei den Servern um Server 2019. Domänenfunktionsebene und Gesamtstrukturfunktionsebene ist Windows Server 2016. Hat jemand eine Idee wie ich das wieder korrigiert bekomme? Vielen Dank für eure Hilfe. Gruß EDIT: Ich habe die Frage auch bei Administrator.de gestellt. Falls ich eine Lösung finde, werde ich diese in beiden Foren bekannt geben. EDIT2: Es scheint aber so zu sein, dass die Gruppenzugehörigkeiten bei gpresult -r wohl nur nicht angezeigt werden. Hier wird ja z.b. auch normalerweise die Gruppe "Authentifzierte Benutzer" mit aufgeführt. Wir haben eine GPO die die lokalen Admins auf den Server regelt. Ich habe nun eben mal einen Test durchgeführt und in die lokale "Administratoren" Gruppe auf dem betroffenen Server einen User aufgenommen. Dann habe ich gpupdate ausgeführt und der User wurde wieder aus der Gruppe entfernt. die GPO greift also und es wird auch erkannt, dass der Server noch in der Gruppe "Authentifizierte Benutzer" ist. Somit ist das wohl nur ein Anzeigefehler, aber auch das ist unschön. Wäre super wenn jemand eine Idee hätte wie man das wieder korrigiert bekommt.

Ich hätte dazu noch mal eine Frage und hole den Beitrag noch mal hoch. Ich habe jetzt mit netdom den Alias erstellt netdom computername <computer> /add:<alias> Danach habe ich mit setspn -l <computername> die SPNs geprüft und der neue Alias war schon als SPN eingetragen. Damit muss ich doch gar nicht separat den SPN erstellten, es reicht doch der netdom Befehl, oder sehe ich das falsch? Früher musste man ja noch die RegKeys eintragen, damit der Alias funktioniert. Da war dann wohl der manuelle setspn notwendig.

Hallo zusammen, da wir gerade das NTLM Auditing aktiviert haben und prüfen wo bei uns überall NTLM noch verwendet wird, ist uns aufgefallen, dass 90% der NTLM Anfragen an unseren Print Server gehen. Hier bin ich dann auf folgenden MS Artikel gestoßen https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-print-nightmare-artifact-krbtgt-nt-authority/ba-p/3757962 Es scheint massive Probleme geben zu können, wenn der damalige PrintNightmare Patch installiert wurde. Das führt unter anderem dazu, dass die Clients NTLM Anfragen an den Print Server schicken und das führt möglicherweise zu langsamen Druckaufträgen, DC Anmeldeproblemen usw. (sehr einfach zusammengefasst) In dem Artikel ist ein sehr aufwendiger Prozess beschrieben um zu prüfen ob man betroffen ist. In den Kommentaren ist eine einfachere Lösung zu finden. Das Logging auf dem Client aktivieren Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters" -Name LogLevel -Type DWORD -Value 1 -Force Dann ist im System EventLog die Security-Kerberos EventID 3 zu finden mit folgendem Inhalt wenn ich nun vom Client drucke, sehe ich diese Einträge im EventLog. Die Lösung ist, ein Reg Key zu setzen (bei uns ging es auch ohne den Print Spooler restart). New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" -Name RpcNamedPipeAuthentication -Type DWORD -Value 2 -Force Restart-Service Spooler Damit ist der Fehler im EventLog weg. Wir werden das nun auf allen Clients ausbringen und damit müsste ein großer Teil des NTLM Traffics entfallen und auch die möglichen Probleme beim drucken und der DC Anmeldung. Viele haben wahrscheinlich schon NTLM deaktiviert und kennen möglicherweise die Lösung/Problem schon, aber vielleicht hilft es ja noch jemanden. Quellen: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-print-nightmare-artifact-krbtgt-nt-authority/ba-p/3757962 https://www.borncity.com/blog/2023/05/15/print-nightmare-nachwehen-bei-windows-domain-controllern-langsame-print-server-und-ausgebremste-dcs/

Danke Martin. Dann werde ich mich mal an die Arbeit machen und die DNS Share Aliase überarbeiten.

Wäre das der richtige Weg oder gibt es andere Stellen wo man das Auditing aktivieren sollte? Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options Network Security: Restrict NTLM: Audit NTLM authentication in this domain Vielen Dank für deine Hilfe.

Danke euch. Das der ping auch andere Technik nutzt, war mir im Detail nicht klar. Ich dachte der geht tatsächlich nur über den dns. Wins und netbios ist bei uns deaktiviert. Das interessante ist ja, wird der dns Eintrag von service Account über den dhcp vorgenommen (dns Einträge immer dynamisch aktualisieren), wird der bestehende dns Eintrag aktualisiert und der Client steht nur einmal im dns mit der jeweiligen IP (LAN oder WLAN). Stellt man am dhcp es so ein (dns Eintrag nur noch Aufforderung von dhcp clients dynamisch aktualisieren) und der Client trägt sich selber ein, dann steht der Client zweimal im dns (einmal mit LAN und einmal mit der WLAN IP). In diesem Fall gibt ein nslookup auch beide Einträge zurück und da frage ich mich eben, ob die korrekte Namensauflösung nur zu 50% funktioniert oder wie entschieden wird welcher dns Eintrag der aktuelle/ korrekte ist. Wir haben genau deswegen ein Termin mit unserem Consultant. Dachte mir nur, vielleicht hat hier ja schon vorab eine Idee, weil das vielleicht ein bekannte Thema ist. LG

Hallo zusammen, Ich hoffe es ist ok, wenn ich mich hier mal einklinke. Wir haben tatsächlich auch ein paar file shares auf die über einen dns alias zugegriffen wird. Auch wir haben weder einen spn angepasst noch netdom bzw die regkeys eingetragen. Es handelt sich hier um server 2019. Fragen: - Kann man prüfen warum bei uns die Zugriff trotzdem sauber funktionieren? Sehe ich ob es ein ntlm fallback gibt? - registriert man den spn mit dem setspn? - führt man den Befehl auf dem betroffenen Server oder dem dc aus? Danke euch und mal wieder das Grundwissen aufgefrischt😇

Ja, da hat ms sich mal wieder was geleistet. In deren Screenshot war tatsächlich powerpoint.exe gestanden und das bsi hat das 1:1 so in deren Warnung übernommen. Bis jetzt haben wir auch keine Probleme festgestellt und verteilen die regkeys jetzt an alle. Soweit ich das richtig verstehe, verhindern die keys doch, das aus der engine vom ie11 subprozesse gestartet werden (z.b. dann word, excel, usw). Es hieß ja, dass es Probleme mit office geben könnte. Das verstehe ich dann nicht, da die regkeys ja für den ie gelten. Oder verdrehe ich da was?

Du meinst, dass der dhcp der Firewall die dns Einträge im Windows dns vornimmt und man dort den Service Account hinterlegt? Wir setzen fortigate ein und da ist mir aktuell nichts bekannt. Aber guter Hinweis, wir werden bei fortinet mal ein Ticket dazu eröffnen. Kann jemand bestätigen, dass es normal ist das mehrere dns Einträge von demselben Client erstellt werden, wenn der Client selber die dns Einträge vornimmt? Ich frage mich nur, wie dann die Namensauflösung funktioniert. Das Verhalten ist aktuell wie folgt. Client ist mit LAN und später mit WLAN verbunden. Im dns steht der Client dann zweimal drin, einmal mit der LAN IP und dann nochmal mit der wlan IP. Nun ist der Client wieder mit LAN verbunden. Ich habe von 3 clients einen ping auf den Namen ausgeführt, wurden alle korrekt aufgelöst. Gibt es eine Logik die prüft welcher von den beiden dns Einträgen aktuell/ erreichbar ist? Kann ich mir eigentlich nicht vorstellen. Aber war es dann nur Zufall, dass alle 3 Tests richtig aufgelöst haben? Ich hätte erwartet, dass per Zufall zwischen den beiden dns Einträgen gewählt wird und man löst der dns auf die aktuelle IP auf und mal nicht.

Noch ein kleines Update Werden die DNS Einträge vom Service Account, der im DHCP hinterlegt ist, eingetragen, werden die DNS Einträge aktualisiert. So zum Beispiel wenn ein Notebook von LAN zu WLAN wechselt. Werden die DNS Einträge direkt vom Computer Objekt geschrieben, wird der bestehende DNS Eintrag nicht aktualisiert, sondern man hat 2 Einträge im DNS. Der DNS Eintrga von einem Notebook hat dann eben einmal die LAN und einmal die WLAN IP im DNS hinterlegt. Ich würde jetzt vermuten, dass es dann ja Zufall ist ob bei der Namensauflösung die WLAN oder LAN IP genommen wird. Oder gibt es da eine Logik? Das ist mir jetzt nur beim testen aufgefallen. Ändert aber nichts daran, dass ich für den VPN das Computer Objekt in der ACL benötige. Hat da niemand eine Idee, wie man das automatisieren kann, dass automatisch noch das Computer Objekt in der ACL vom DNS Eintrag steht? Ich wäre für Hilfe sehr dankbar :)

Hallo zusammen, es gibt aktuell eine Zero Day Sicherheitslücke und für bestimmte Office Anwendungen noch kein Patch. Es muss manuell ein RegKey eingetragen werden. "Nebenwirkungen" sind noch keine bekannt. Wir testen gerade Quelle: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36884 Visio.exe https://aka.ms/Storm-0978 https://www.borncity.com/blog/2023/07/13/office-und-windows-html-rce-schwachstelle-cve-2023-36884-erlaubt-systembernahme/#comment-152256

Hallo zusammen, wir haben folgende Konfig bei uns - 2 DHCP Server im Failover Betrieb - DNS Einstellung im DHCP Scope sieht wie folgt aus - Service Account im DHCP hinterlegt für die DNS Registrierung Bis vor kurzem hatten wir bei den DNS Einstellungen noch "DNS Einträge immer dynamisch aktualisieren" aktiviert und alle Einträge wurden durch den Service Account erstellt und dieser war auch in der ACL eingetragen. Nun hatten wir folgendes Problem. Unsere VPN Clients erhalten die IP nicht vom internen DHCP, sondern von der Firewall. Damit haben diese Clients sich immer versucht selber in den DNS Einzutragen und konnten den bestehenden Eintrag nicht ändern, da dort ja der Service Account hinterlegt war. Hat man den DNS Eintrag gelöscht, konnte der Client sich aus dem VPN im DNS eintragen, aber wenn der Client dann wieder im internen LAN war hatten wir wieder das Problem, da dann das Computer Objekt in der ACL vom DNS Eintrag stand und der Service Account diesen nicht ändern konnte. Deshalb haben wir die Einstellung auf oben geändert, damit die Windows Clients immer ihre DNS Einträge selber vornehmen und damit die Änderung vom VPN und LAN funktioniert. So richtig sauber läuft das aber nicht, da doch immer mal wieder ein Client vom DHCP Service Account eingetragen wird. Ich habe dann diesen MS Beitrag dazu gefunden. https://social.technet.microsoft.com/wiki/contents/articles/51810.windows-server-integration-between-dns-and-dhcp.aspx Hier geht es genau um unsere Problematik Genau diese Idee hatte ich auch, es müsste einfach für jeden DNS Eintrag automatisch das Computer Objekt zusätzlich in die ACL eingetragen werden. Dann hätte ich den Service Account und das Computer Objekt in der ACL und der DNS Eintrag könnte aus dem VPN und aus dem LAN vom Client geändert werden. Es wird dort auch ein Script erwähnt, aber das ist leider nicht mehr verfügbar. Hat von euch jemand eine Idee wie ich das realisieren könnte? Ein Script wäre zwar ganz nett oder setzt man da die Berechtigung direkt im Schema/DNS, damit neu erstelle Einträge gleich das Computer Objekt in die ACL eingetragen bekommen? Vielen Dank und Grüße

Vielen Dank. Die Info habe ich tatsächlich immer gründlich ignoriert Danke für eure Hilfe.

Hi Evgenij, ich hatte mich auf die grün markierte Antwort in dem Thread bezogen Du hast Recht, dass auch das im nächsten Beitrag erwähnt wird. Ich hatte bei uns geprüft ob die audit.csv in der DDP vorhanden ist. Das war sie nicht und ich habe habe sie erstellten lassen, in dem ich eben eine Änderung gemacht habe und diese dann wieder auf default zurückgesetzt habe. Nun gibt es die audit.csv. Sorry - diese Info hatte ich komplett vergessen. Es ist nun aktuell so - In einer dedizierten GPO wird das advanced Audit Policies gesetzt. - Auf dem entsprechenden Server sehe ich die GPO Einstellungen im gpedit.msc und im rsop.msc nicht - Im gpresult -h "html file" und mit auditpol /get /category:* sehe ich die Einstellungen Es wird ja auch das Security EventLog gefüllt, ich hätte einfach erwartet das ich diese Einstellung im gpedit.msc sehe, oder zumindest im rsop.msc. Aber anscheinend macht MS da was es will. Einige GPO Einstellungen werden in der gpedit.msc angezeigt (z.B. in den Sicherheitsoptionen mit dem geänderten Icon) und andere nicht. VG

Hallo zusammen, danke euch. Ich hatte das nicht in einem offiziellen MS Dokument gelesen, diese Behauptung hatte jemand im MS Forum aufgestellt https://learn.microsoft.com/en-us/answers/questions/123130/advance-audit-policy-no-longer-applying-after-runn Mir ist klar, dass ich mit gpedit.msc die lokalen Richtlinien sehe und diese von den Domain Policies überschrieben werden. Ich dachte nur, dass ich die Advanced Audit Policy "Überschreibungen" in der gpedit.msc sehe (wie z.B. in den Sicherheitsoptionen ja zu sehen ist, das Icon ändert sich). Ich hätte aber zumindest erwartet, dass es im rsop.msc zu sehen ist. Aber auch dort sehe ich die Änderungen nicht. Laut dem oben verlinkten Artikel verstehe ich das auch so, oder stehe ich komplett auf dem Schlauch? Gruß

Hallo zusammen, ich habe folgendes Problem. Ich habe eine neue GPO erstellt in der ich die Advance Audit Policy konfiguriert z.b. für File Zugriff aktiviert habe. Ebenso habe ich folgende Einstellung in den Sicherheitsoptionen aktiviert -> Überwachung: Unterkategorieeinstellungen der Überwachungsrichtlinie erzwingen (Windows Vista oder höher), um Kategorieeinstellungen der Überwachungsrichtlinie außer Kraft zu setzen Wenn ich diese GPO nun auf den betroffenen Server aktiviere und mir dort per gpedit.msc die GPO Einstellungen anzeigen lasse, stehen weiterhin alle Advance Audit Policys auf nicht konfiguriert. Prüfe ich die Einstellung per auditpol /get /category:*, sehe ich das sie aber korrekt eingestellt sind. Ich habe nun gelesen, dass man die Advance Audit Policy nur in der Default Domain Policy aktivieren soll, damit es eben in der lokalen gpmc sichtbar ist. Das kann ich mir aber nicht vorstellen und hatte das auch getestet, war trotzdem nicht sichtbar. Kennt jemand das Problem und weiß wie ich es lösen kann?

Na sauber, dann hab ich ja mal schön mit Unwissenheit geglänzt Danke.

Danke - das war einfach :) Dann ist es bei uns tatsächlich über Kerberos abgesichert Dann muss ich hier mal noch etwas Suchen, damit ich das verstehe. Scheint dann ja doch "out of the Box" zu funktionieren, da ich nicht wüsste das hier bei uns etwas in der Richtung konfiguriert wurde. Dann erklärt es aber das Verhalten. Danke!

Hi Evgenij, die Frage ist vielleicht etwas peinlich, aber wie kann ich das prüfen? Bei uns ist RDP nur mit "Network Level Authentication" aktiviert, aber das hat ja erstmal nix mit Kerberos zu tun. Das was ich jetzt gefunden habe, scheint es ja nicht "out of the box" mit Kerberos abgesichert zu sein, daher würde ich jetzt bei uns mal sagen - das ist nicht der Fall.