cj_berlin

Moin, nein, Erzwingen heißt erzwingen. Das hat auch Auswirkungen - das Kennwort und das NTLM-Secret für "erzwungene" User wird halt durch AD automatisch gemanagt. Für Systeme, die explizite Authentifizierung erwarten, braucht man einen separaten User, und der hat dann halt keine SmartCard oder zumindest nicht verpflichtend. Aber für Tier 0-Admins darf es keine Anwendungen geben, die was anderes als Kerberos haben wollen.

Moin, entweder 2x Get-ADGroupMember und ein Compare-Object, oder 1x Get-ADPrincipalGroupMembership für alle in Frage kommenden User und das Ergebnis nach beiden Gruppen filtern. Vermutlich ist #1 schneller und einfacher.

Verhindert aber nicht RENDOM. Auch Exchange im Forest verhindert nicht RENDOM, funktioniert danach halt einfach nicht mehr Ich würde migrieren.

Er meint die Devices umbenennen, nicht die DNS records Easy:

Dann setz mal den oberen Radiobutton auf 'Always'. Und, wenn DHCP nicht auf dem Domain Controller läuft (was es auch sollte!), musst Du ein Service Account eintragen und den DHCP-Server in die DNSUpdateProxy-Gruppe stecken.

Da sind zwei Faktoren im Spiel: welche Updates lässt die Zone zu? Wenn sie auf "sichere Updates" steht, werden Linux-Clients ihre A-records nicht dynamisch registrieren können, egal wie lang sie sind. wer trägt die Records ein? Wenn das derDHCÜ-Server tut, sollte es funktionieren (und der erste Punkt keine Rolle spielen)

User löschen, 15 Minuten warten, aus dem Papierkorb wiederherstellen. Falls es ein synchronisierter User ist, AAD Connect für diese Zeit anhalten.

Hier liegt seit gestern Schnee. Nicht viel, bleibt aber liegen. Bin vorhin durch den Wald gefahren - traumhaft!

Moin, hat SERVERX1 denn diese GUID auf dem Host, wo die VM jetzt läuft?

Dienst aus der Registry austragen und sich die Rechte notfalls mit Gewalt nehmen. Oder sc im SYSTEM-Kontext, sollte auch gehen.

In welchem Szenario? Linux-Rechner, der einen langen Hostnamen hat, für den Windows DHCP im Windows-DNS einen A-Record erzeugen soll?

Moin, aber spätestens im Header einer empfangenen Mail (aus einem "falschen" Netzwerk verschickt) steht doch, von welchem Server sie ursprünglich ausgeht. Das sollte ein guter Anhaltspunkt fürs Troubleshooting sein

Hmmm. Dann sind das ja interne Mails - warum sollten sie überhaupt auf SPF geprüft werden? Welches System macht es? Welchen Bericht meinst Du genau? Im SMTP-Protokoll oder im Mail-Header steht nicht drin, in welchem Netz der Nutzer seinen Browser aufgerufen hat, um die Mail abzusetzen, denn an dieser Stelle ist SMTP noch gar nicht involviert. Und wenn Exchange angefangen hat, bei OWA diese Info im Header zu verewigen, dann wohl kaum in einem Header, der für die SPF-Prüfung relevant ist...

Moin, sprechen wir hier von Exchange OWA, oder was ist "euer offizielles Webmail"?