NorbertFe

Ich würde sagen auf den DCs anschalten und die auch ggf. mal Rebooten. Danach dann für alle Clients. Denn die Clients sprechen ja signiert, wenn der Server zustimmt. Und der bietet ja jetzt nur noch mandatory SMB Signing an.

vor 9 Minuten schrieb roccomarcy:

Ehrlicherweise muss ich sagen, dass die GPO auch heute Vormittag zum Tagesbeginn aktiviert bzw. geändert habe.

Wäre vielleicht sinnvoller, sowas eben nicht zum Tagesstart zu setzen, sondern eher zum Feierabend. ;)

korrekt. Das Deaktivieren hatte man zu 2003 Zeiten empfohlen, weil es da wohl Performanceprobleme gab (merkbar wegen der damaligen Hardware) und weil zu dieser Zeit natürlich noch jede Menge alte Systeme unterwegs waren, die damit nicht klarkamen. Beides sollte heutzutage der Vergangenheit angehören. :)

Richtig, deine DCs sind immer unsigniert (sowohl als Server als auch als Client). Insofern ist eben ein Test noch viel unnötiger ;) Oder willst du deine DCs noch mal einzeln bestücken.

Ja, wer oder was hindert dich? Natürlich kannst du das auch auf eine oder eine Gruppe von Maschinen anwenden. Macht halt nur meist nur Aufwand für die Erkenntnis, dass man es auch gleich komplett ausrollen konnte. In deinem Fall dürften sich ja sowieso schon alle Windows Maschinen per signed smb unterhalten. ;)

vor 1 Stunde schrieb BOfH_666:

hast Du da ein Beispiel?

Afair Office seit Version 2016.

Sowohl als auch. Also jeweils in ddp und ddcp.

vor 41 Minuten schrieb roccomarcy:

Könnte ich

Könntest du?

vor 1 Minute schrieb Christian-K:

Ich dachte die DAG Funktionalität ist nur für den Ausgleich und das Synchronisieren von Mailbox Databases zuständig.

Naja da das alles multirole Server sind… erübrigt sich diese Denke. ;)

vor 2 Minuten schrieb Christian-K:

Jetzt kann ich den Server noch jederzeit herunterfahren und testen,

Sieht man ja, wie toll das geht. ;)

vor 2 Minuten schrieb Christian-K:

wenn er dann in der DAG ist müsste man sauber mit Wartungsmodus usw. arbeiten

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*

vor 10 Minuten schrieb roccomarcy:

was das für Auswirkungen auf den Betrieb haben könnte.

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?

vor 28 Minuten schrieb Herakles25:

der Server soll eh sterben - aber nicht grad jetzt :)

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. 😑