phatair

Hallo zusammen, wir setzen einen Exchange 2016 Server ein und ich möchte unsere E-Mail Adressrichtlinie überarbeiten. Standardmäßig verwenden bei uns alle User als Mail Adresse den Nachnamen. Die Richtlinie dafür ist schnell geschrieben. Nun habe ich aber folgende Frage/Problem. Einige AD User verwenden aber noch ein altes Anmeldenamenschema und verwenden nicht den Nachnamen als Anmeldenamen. Dieser veraltete Anmeldename steht deshalb auch noch im Exchange Alias drin. Kann ich den Exchange Alias einfach in den Nachname ändern, ob macht das Probleme? Der UserPrincipalName oder der SamAccountname ändern sich dadurch ja nicht, richtig? Das dürfte ja der mailNickname in den Attributen sein. Dann könnte ich die Adressrichtlinie auf Alias stellen und die Standard Mail Adresse würde sich dann am Alias orientieren und dieser orientiert sich ja beim erstellen einer neuen Mailbox auch immer am UserPrincipalName. Vielen Dank. Grüße

Vielen Dank euch. Mir ist auch schon aufgefallen, dass die AD Maschinen SID sich zu der lokalen Maschinen SID unterscheidet. Ich war mir nur unsicher, ob es trotzdem irgendwelche Zusammenhänge gibt, die man berücksichtigen sollte. Lokale Accounts haben wir auf den AD Clients nicht (ausgenommen natürlich ein geänderter lokaler Admin Account).

Vielen Dank. Also lag ich mit meinem Gedanken richtig, dass die Computer SID einmalig sein muss, diese aber problemlos mit einem restore auf ein anderes Gerät "übertragen" werden kann. Wichtig ist nur, dass sie nicht doppelt vorhanden ist.

Hallo zusammen, irgendwie stehe ich gerade auf dem Schlauch und hoffe ihr könnt mir helfen. Wir machen von einigen Windows Clients per Veeam Agent wöchentliche Backups. Wenn dieses Backup auf eine andere Hardware zurückgespielt wird und die ursprüngliche Hardware nicht mehr online geht, muss dann die Computer SID per Syspres auf der neuen Hardware geändert werden? Oder ist das egal, da die Computer SID weiterhin einmalig ist und sich nur die Hardware geändert hat? Das Sysprep bei einem Master Image genutzt werden muss, aus dem dann mehrere Clients geimaged werden ist klar. Aber diesen Fall haben wir ja nicht. Da es sich um einen Domänen Client handelt, hätte ich vielleicht nach dem Restore das Gerät noch mal aus der Domäne genommen und dann noch mal sauber aufgenommen, um mögliche AD Probleme auszuschließen. Für eine Rückmeldung wäre ich sehr dankbar. Gruß

Die Probleme gehen weiter... https://www.bleepingcomputer.com/news/microsoft/new-windows-print-spooler-zero-day-exploitable-via-remote-print-servers/ Wir haben dazu folgende GPO gesetzt, wie im Artikel empfohlen https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.Printing::PackagePointAndPrintServerList_Win7&Language=de-de Falls man schon in der GPO "Point-and-Print-Einschränkungen" die Verbindung zu den entsprechenden Servern eingeschränkt hat, muss die oben genannte GPO trotzdem gesetzt werden!

Die hatten wir vorher komplett vom Client gelöscht (Client Druckserver, Tab Treiber). Ebenso haben wir es auf einem neuen geimaged Gerät getestet.

Also bei uns ist das Update jetzt auf gut 80 Clients (Win 10 20H2) installiert und es gab bis jetzt keine Probleme. Ebenso ist es auf den Printservern (2019 und 2012R2) installiert. Spooler ist auf allen Servern deaktiviert (Ausnahme Print Server und Terminalserver) Da auf den Print und Terminalservern das Update installiert wurde und keine Print-and-Point Einschränkung greift, sind diese "sicher". Wir haben die Point-and-Print Einschränkung in der GPO für die Clients auf aktiviert gesetzt und haben die UAC Meldung aktiviert. Tests haben ergeben, dass die Treiber auch so ohne User Interaktion installiert werden können. Vorher waren die Meldungen unterbunden und das führte dann ja dazu, dass die Sicherheitslücke nicht sauber geschlossen wurde. bzw. weiter ausgenutzt werden konnte und die Einstellung sowieso unsicher ist. Da wurde wohl eine Altlast mitgeschleppt, die gar nicht mehr benötigt wurde. Hat sich das Ganze Theater ja doch gelohnt :) Für alle Clients wurde ebenso per GPO der Remote Zugriff auf den Spooler deaktiviert Ich hoffe ich habe nun nichts übersehen und wir müssten somit gut geschützt sein. Hilfreich war wie gesagt dieses Diagramm Viel Erfolg beim patchen/konfigurieren :)

Was genau meinst du damit? Reicht es aus, wenn sie digital signiert sind? Es ist ja definitiv keine Lösung, dass eine UAC erscheint und administrative Rechte benötigt werden, wenn der User einen Drucker verbinden möchte. Entweder müssen wir den Treiber dann zentral verteilen oder aber eben die "richtigen" Treiber verwenden. Wir haben ja auf allen Servern den Print Spooler Dienst beendet/deaktiviert auf denen er nicht benötigt wird. Einzig auf den Terminalservern und Print Servern + Clients läuft dieser noch. Auf den Terminalservern konnten wir die ACL nicht anpassen, da danach keiner mehr drucken konnte (hie rmüssen wir noch prüfen ob es ein grundsätliches Problem ist oder ein Fehler bei der Konfig gemacht wurde). Aber die ACL Methode ist ja auch etwas umstritten. Ebenso haben wir auf der Firewall zwischen den Server und Client VLANs IPS aktiviert. Das schützt zumindest die Kommunikation zwischen den Bereichen. Wir werden jetzt mal testen, ob wir die Print-and-Point Einschränkung rausnehmen können, ohne das die User erhöhte Berechtigungen für die Drucker Installation benötigen.

Hallo zusammen, also ich bin langsam auch etwas verwirrt was die ganzen Infos angeht. Wir haben im Moment auf allen Member Servern den Print Spooler deaktiviert. Auf den Print Servern haben wir die ACL angepasst. Auf den Clients/RDP Servern haben wir die GPO konfiguriert, dass die Clients keine Remote Anfragen für den Spooler Dienst annehmen Aktuell haben wir aber die Point-and-Print Einschränkung aktiviert, damit die Clients die Drucker ohne Meldung installieren können. Wir haben diese GPO an alle Clients und RDP Server verteilt (sonst keine Server) und die Option "Benutzer können Print-und-Point Einschränkung nur mit folgenden Servern verwenden" aktiviert und unsere Print Server angegeben. Nun könnten wir die GPO deaktivieren und die Universal Druckertreiber zentral verteilen. Damit könnten die User die Drucker ohne Meldung installieren (da Treiber schon vorhanden) und unsere Umgebung soweit gesichert - verstehe ich das richtig? Oder aber wir belassen es so wie es ist und aktivieren auf den Druckservern die neuen Reg Keys für "RestrictDriverInstallationToAdministrators". Nur verstehe ich noch nicht wirklich, dass dieser Reg Key macht? Mit dem Wert 1 für den Key kann ja nur noch der Admin Treiber auf dem jeweiligen Server installieren und es werden die Point-and-Print Einstellungen aus der GPO überschreiben. Wenn, wie bei uns, die Point-and-Print Einstellungen aber gar nicht für die Server gelten, dann hat sich das Thema ja sowieso erledigt und der Server ist sowieso schon geschützt, wenn der aktuelle Patch installiert ist, da der Patch ja nur nicht schützt wenn die Point-and-Print Einschränkung gesetzt ist. Verstehe ich das richtig? Schönen Abend noch Beste Grüße Edit: Laut diesem Diagramm (https://www.kb.cert.org/vuls/id/383432) wären die clients wohl lokal angreifbar, wenn wir es so belassen wie es jetzt ist und den Patch installiert haben. Müssen und wohl mal Gedanken über das Verteilen der Drucker Treiber machen, um die point-and-print Einschränkungen (Meldungen) wieder auf default zu setzen. Wenn ich es richtig verstehe, ist eine User Installation eines Drucker Treibers nicht mehr möglich, wenn man die Schwachstelle sauber schließen möchte (Stand jetzt).

Hat wunderbar funktioniert. Nu kommt beim gpupdate keine Meldung. Wenn ich auf anderen PCs die gleiche Fehlermeldung habe, werde ich einfach mal versuchen die GPT.INI auszutauschen. Dann könnte ich das nämlich automatisiert verteilen. Vielen Dank.

Hi Martin super, danke. Eine Frage noch. Warum erhöhe ich die Versionsnummer genau um 65537? Hat das irgendeinen Hintergrund? Gruß, Steffen

Ok, ich drücke mich immer etwas unglücklich aus - Sorry! Ich meinte, bei den Domain GPOs liegen die GPOs ja im Sysvol\fqdn\Policies Verzeichnis. Dort liegen dann die Ordner mit den entsprechenden GUIDs und darunter dann immer die Verzeichnisse Machine, User, Group Policy und die GPT.ini Wenn wir jetzt nur Domain GPOs verwenden, dürfte ja unter C:\Windows\System32\GroupPolicy\ nichts liegen. Die Verzeichnisse "C:\Windows\System32\GroupPolicy\Machine" und "C:\Windows\System32\GroupPolicy\User" sind ja auch leer. Aber der Ordner "C:\Windows\System32\GroupPolicy\DataStore\0\sysvol\<unser FQDN>\Policies" eben nicht. Dort liegen Ordner mit GUIDs die ich nicht kenne. Daher die Frage ob Windows hier per Default irgendwas erstellt. Das hat jetzt natürlich nichts direkt mit der Disk Quota Problematik zu tun, ist mir aber aufgefallen und wollte nur wissen ob dieser Ordner dort überhaupt sein sollte, wenn wir nur Domain GPOs verwenden. Die andere Frage ist eben, ob ich die GPT.ini unter "C:\Windows\System32\GroupPolicy\" einfach anpassen und für alle Clients verteilen kann. Auf allen Clients sind keine lokalen GPOs definiert. Ich würde dann aus dieser GPT.ini den Eintrag {3610eda5-77ef-11d2-8dc5-00c04fa31a66} löschen und dann verteilen. Oder kann diese GPT.ini einfach komplett gelöscht werden, wenn keine lokalen GPOs verwendet werden? In der GPT.ini steht folgendes [General] displayName=Neues Gruppenrichtlinienobjekt gPCFunctionalityVersion=2 gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{3D271CFC-2BC6-4AC2-B633-3BDFF5BDAB2A}][{3610EDA5-77EF-11D2-8DC5-00C04FA31A66}{0F6B957D-509E-11D1-A7CC-0000F87571E3}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-0000F87571E3}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}] Version=1048595 gPCUserExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]

Hi Martin, vielen Dank für den Hinweis. Das stimmt natürlich, die lokale GPO setzt nur die RegKeys. Unter C:\Windows\System32\GroupPolicy finde ich eine GPT.ini und dort ist tatsächlich den Wert {3610eda5-77ef-11d2-8dc5-00c04fa31a66} enthalten. In den Ordnern "C:\Windows\System32\GroupPolicy\Machine" und "C:\Windows\System32\GroupPolicy\User" liegen nur leere Ordner und sonst nichts. Es gibt aber noch den Ordner "C:\Windows\System32\GroupPolicy\DataStore\0\sysvol\<unser FQDN>\Policies Dort liegen mehrere Ordner mit unbekannten IDs z.B. {9D9D2DCB-CA6C-4193-89D9-5A341FA15FF0} und in diesen Ordner liegen dann noch mal jeweils GPT.ini Dateien und ein Ordner Machine. In diesem Machine Ordner liegen dann unterschiedliche Dateien/Ordner. Alle haben das gleiche Datum vom November 2019. Weißt du, ob das einfach default Dateien sind? Wir nutzen für unsere GPOs einen central Store und verwenden nirgends lokale GPOs Da wir diese Fehlermeldung beim gpupdate auf allen Clients haben, kann ich die lokale gpt.ini einmal anpassen und diese dann für alle Clients verteilen?

Hallo zusammen, wir erhalten auf unseren AD Geräten bei einem gpupdate immer die Fehlermeldung Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen möglicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen". Google hat mir hier schon einige Lösungen gezeigt. Vor allem diesen MS Beitrag https://docs.microsoft.com/de-de/archive/blogs/core/event-id-1085-source-grouppolicy-windows-failed-to-apply-the-microsoft-disk-quota-settings-resolved Dort wird gesagt, dass in einer GPO Disk Quota mal konfiguriert war oder noch konfiguriert ist. Das dann ein Attribut gelöscht werden muss. Ich habe alle GPOs geprüft, dieses Attribut ist in keiner unserer GPOs gesetzt, auch nicht in der DefaultDomainSettings GPO. Wenn ich ein gpresult ausführe, sehe ich, dass der Eintrag von der lokalen Richtlinie kommt (LocalGPO) - Siehe angehängten Screenshot. In dem Regedit Pfad \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\ finde ich dann auch das im oberen Link genannten Attribut mit dem Wert {3610eda5-77ef-11d2-8dc5-00c04fa31a66} Es wird also durch die lokale GPO die Disk Quota genutzt und deshalb die Warnung. Wir verwenden diese aber auf den PCs nicht. Kann ich den RegKey einfach löschen oder muss ich per Domain GPO die lokale GPO irgendwie mit den korrekten Werten überschreiben? Ich möchte ja einfach nur, dass diese Disk Quota nicht mehr genutzt wird und die Fehlermeldung beim gpupdate verschwindet Für einen Tipp wäre ich sehr dankbar. Gruß

Danke Martin, auf dem Win 10 PC hatte tatsächlich noch ein Update gefehlt. Nach der Installation sind nun alle neuen Sicherheitsrichtlinien auch dort konfigurierbar. Wieder was gelernt - Danke!

Hallo zusammen, ich habe mal eine Verständnisfrage zu dem Zentralen Speicher von GPOs. Die Situation bei uns ist wie folgt. Die Administrativen Templates liegen bei uns im Sysvol, also zentral. Wenn wir über die Gruppenrichtlinienverwaltung die GPOs bearbeiten bzw. erstellen, werden diese auch vom zentralen Speicher abgerufen. Funktioniert alles wunderbar. nun habe ich die ADMX Vorlagen für Windows aktualisiert (20H2), damit wir in den GPOs auch die Netlogon Secure Channel Einstellung setzen können. Die Einstellung ist nicht in den Administrativen Vorlagen enthalten, sondern in den Windows Einstellungen Siehe hier: Policy path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options Setting name: Domain controller: Allow vulnerable Netlogon secure channel connections Wenn ich von meinem Windows 10 PC eine neue GPO erstelle, ist diese Einstellung aber nicht sichtbar. Mache ich das von einem Server 2012R2 sehe ich die Einstellung. Daher meine Frage, woher kommen die Windows Einstellungen bzw. die Sicherheitseinstellungen in den GPOs? Die zieht er sich ja nicht vom zentralen Speicher. Zieht er sich die dann immer vom lokalen PC? Wenn diese vom lokalen PC kommen, werden diese dann über die Windows Updates gepflegt oder muss ich dann auf dem Client noch ein manuelles Update einspielen damit ich die Einstellungen auch sehe? Vielen Dank euch schon mal. Beste Grüße

Leider nein, dass hatten wir auch schon überlegt. Es handelt sich um ein /22 Netz und in diesem sind auch jetzt schon Geräte aus der Haustechnik (Strommesser, Klimaschränke, Rollos, usw). Diese sind zwar in einem eigenen IP Bereich (141.x) und die Server im (143.x), aber ich bkeomme die Haustechnik so schnell nicht angepasst. Ich müsste dort dann ja überall die Subnetzmaske anpassen, und das ist bei diesen Geräten oft nicht machbar bzw. nur durch den Techniker. Das Problem ist, dass wir hier gar keine Trennung haben. Die Geräte können alle miteinander kommunizieren und für mich ist das aus Sicht der Sicherheit keine gute Lösung. Wir wollen die Segmente sauber durch die FW trennen und keine direkte Kommunikation erlauben. Schon gar keine Haustechnik. Aber es sollen auch Abteilungen wie die Entwicklung eigene VLANs bekommen, dass man Zugriffe über die FW steuern kann. Durch die Trennung von Server und Clients können wir dann auch noch mal genauer die Zugriffe steuern. Bis jetzt ist das ja nur über die Windows FW möglich, und das ist unschön zu managen. PRTG haben wir im Einsatz, ich wüsste im Moment nur nicht wie ich hier die einzelnen Zugriffe auf die Server protokollieren kann. Ich habe jetzt mal zum Test Wireshark auf dem DNS Server laufen und sehe hier ganz gut welche Zugriffe passieren. Wahrscheinlich komme ich um diesen Aufwand nicht herum :/

Hallo zusammen, wir sind gerade dabei unser LAN umzustrukturieren. Wir haben zwar jetzt schon mehrere VLANs für DMZ, Management, Fertigung usw. aber das Hauptproblem ist, dass Drucker, Server, Clients in einem VLAN sind. Da wir auch eine neue Firewall implementieren, wollen wir jetzt eigene VLANs für Server, Drucker, Clients usw. einführen. Einen Teil haben wir schon umgestellt und es läuft soweit gut. Nun stellt sich die Frage wie wir die Server am Bestem umziehen. Hier würde ich gerne die momentanen Zugriffe Monitoren um zu sehen welche IPs/Geräte auf die entsprechenden Server zugreifen. Über die letzten 20 Jahre wurde hier nicht alles sauber dokumentiert. Zum Beispiel DNS. Diese sind oft per IP in irgendwelchen Konfigs eingetragen worden und hier würde ich nun gerne sehen welche IPs innerhalb 1 Woche auf den DNS Server zugreifen. Da im Moment alles in einem Subnetz abläuft, sehe ich das in unser alten Firewall aber nicht. Mir fällt im Moment nur ein, Wireshark auf dem DNS Server laufen zu lassen und dort zu prüfen was für Anfragen kommen. Das müsste ich dann auf jedem Server machen, den wir umziehen. Gibt es noch eine andere Methode oder hättet ihr noch einen Tipp, wie man die IP Umstellung der Server gut vorbereiten kann (also vorher abklärt, welche Systeme zugreifen um diese dann nach der Umstellung anzupassen bzw. zu prüfen)? Vielen Dank und Gruß

Danke Nils.

Hi Nils, ich möchte eigentlich nur eine Namensauflösung aus der Domäne ermöglichen. Es handelt sich um Windows Server, HP Switche, ESX Server usw. Wir könnten dann z.B. für uns Überwachungstool die DNS Namen anstatt der IPs verwenden. Da wir demnächst auch größere IP Änderungen vornehmen, würde das auch die Arbeit erleichtern, da wir dann nur die IPs im DNS ändern und nicht alle Konfigs anpassen müssen.

Hallo zusammen, die Frage ist vielleicht etwas doof und ich stehe gerade etwas auf dem Schlauch, hoffe aber trotzdem auf Hilfe :) Wir haben bei uns im DNS im Moment nur eine Zone eingetragen. Das ist die DNS Zone unserer Domäne. Nun haben wir weitere VLANs wie z.B. DMZ oder Management. Die Geräte in der DMZ oder dem Management sind nicht in der Domäne, haben aber meistens einen passenden DNS Suffix eingetragen wie z.B. dmz.local oder mgmt.local Nun möchte ich diese Geräte auch per DNS aus unserem Server und Client VLAN erreichbar machen. Die Frage ist nun. Erstelle ich dafür eigene DNS Zonen und erstelle darin statische DNS Einträge für die Server usw? z.b. server1.dmz.local oder erstelle ich die statischen DNS Einträge für die Server einfach in der bestehenden Zone? Würde ich die Einträge im bestehender Zone erstellen, wäre ja aber der FQDN falsch, da die Geräte dann den Domänen Suffix erhalten würden. Wenn ich eigene Zonen erstelle, könnte ich die Zonen dem bestehenden DNS Suffix ja entsprechend anpassen. Habe ich hier einen Denkfehler? Danke und Gruß!

Tendiere Richtung VMDK mitnehmen. Der 2008R2 Server ist sehr alt und wurde von einem Vorgänger installiert, der gerne an den unmöglichsten Stellen Anpassungen vorgenommen hat. Wie Sunny61 schon sagt - Du nimmst alles und alle Einstellungen mit und das möchte ich in dem Fall lieber nicht. Aber für die nächsten Updates ist das gut zu wissen.

Ok. Danke für den Hinweis.

Hm...ok. Früher war das ja eher ein "no go". Hat sich das mit Server 2019 geändert? Ich war bisher immer ein Freund einer sauberen Neuinstallation.

Genau - das möchte ich mir eigentlich sparen und weiß dann zum Zeitpunkt X sind alle Daten auf dem neuen Server und ich muss nicht hoffen das alles sauber per RoboCopy kopiert wurde.