NorbertFe

Afair Office seit Version 2016.

Sowohl als auch. Also jeweils in ddp und ddcp. Könntest du?

Naja da das alles multirole Server sind… erübrigt sich diese Denke. ;) Sieht man ja, wie toll das geht. ;) Warum? Ich kann da auch einfach einen Server runterfahren. Nicht schön, aber auch kein wirkliches Problem. ;) und nur weil ein Server in der dag ist, muss er noch lange keine Datenbankkopien haben.

Microsoft network client: Digitally sign communications (always) = enabled Microsoft network client: Digitally sign communications (if server agrees) = enabled Microsoft network server: Digitally sign communications (always) = enabled Microsoft network server: Digitally sign communications (if client agrees) = enabeld Und Network security: LAN Manager authentication level = Send NTLMv2 response only refuse LM & NTLM

Wenn der eh Mitglied der DAG werden soll, warum konfigurierst du dann erst rum außerhalb der DAG? Hätte man doch von Anfang an gleich in die DAG reinnehmen können, dann gäbs doch gar kein Problem, oder überseh ich was?

Get-clientaccessservices | fl *uri*

Sehr wahrscheinlich gar keine. Denn wenn das Auswirkungen in deiner Umgebung produziert, heißt es, dass da noch ziemlich alte Systeme beteiligt sind. Und die würdest du ja sicherlich kennen, oder? ;)

Ok es gibt eine Umgebung 😉

Tjo, ich weiß schon was du meinst, aber leider sind die Securitygötter immer die, auf die man am wenigsten hören möchte. Ich persönlich hab auch kein Problem damit, die 120 Tage weiterhin beizubehalten und nur die Länge zu erhöhen :)

Natürlich nicht. ;) Und ich bezweifle auch, dass es schon praxisrelevante Anzahlen von Umgebungen ohne NTLM gibt. ;)

Wir sind aktuell bei 14 Zeichen Länge und 10 History sowie 120 Tage maximales Kennwortalter und aktivierte Komplexität. Wir überlegen gerade, ob wir von den 120 Tagen hochgehen auf 365 und dafür 16 Zeichen erzwingen.

Den Default auf die schwächste Richtlinie (also bspw. 12 Zeichen x History usw.) wie bisher konfigurieren. Für alle die davon abweichende (schärfere) Richtlinien benötigen gibt es PSOs.

Dann ist der User offenbar mal aus dem Sync gefallen (oder genommen worden). Sonst wär er ja lokal auch gelöscht. Heißt irgendwo hat jemand das lokale ad Objekt so modifiziert, dass es nicht mehr synchronisiert wird und damit ist es im azure als gelöscht markiert. Jetzt musst du nur noch rausfinden, wie eure Sync rules sind und warum der User da nicht mehr matcht. Danach dann synchen und ggf. wieder die passende Lizenz zuweisen.

Es geht konkret um modern auch für active Sync. ;)

Das sollte man aber mal ändern ;) und sauber konfigurieren. Aber wie siehts jetzt mit tls 1.2 aus?

Und was steht im ehlo String? Und das was da steht, steht das auch im Zertifikat?

Nichts hält länger als das Provisorium. Ein Jahr nach Ankündigung des Produkts soll’s immer noch dauern? ;)

Ach ich lass mich da überraschen. Und wenn man sieht, was für Ausnahmen wieder für die ecc Zertifikate gelten, so is das dann vermutlich auch wieder mit dem anderen Thema. Auf dem Papier erfüllt in der Praxis eher so: najaaaa

Eigentlich nur, wenn dort explizit ein bestimmtes tls Zertifikat gebunden ist. Schau mal nach.

Naja bis cu2 würd ich da mal nix erwarten. 😑

Für die SA Inhaber der Exchange Admins sollte es keine zu großen Veränderungen geben. https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-roadmap-update/bc-p/4136089/highlight/true#M39043

Na dann get-exchangecertificate :p achne das ging ja nicht in diesem Fall 😂

Fürs nächste mal einfach certlm.msc ;) viel schneller.

Weil die bösen Angriffe ja alle nur von außen kommen. ;) Aber am Ende eh egal, so wie viele schon jetzt ihre Exchange Server nicht gepatcht haben, wird das auch niemanden stören.

Danke für die Rückmeldung.