testperson

Evtl. jetzt (schon) beachten und direkt angehen: Host Europe wechselt auch zur Microsoft 365/CloudBorns IT- und Windows-Blog

Intune. Im etwas weiter oben verlinkten Beitrag, war der "UseNewOutlook" übrigens schon drin. :-)

Da bin ich bei dir. Allerdings wäre das der Grund, warum die User gesynced werden (sollten). Ohne Sync habe ich dann online ja keinen Mailuser (Kontakt). Das könntest du dadurch abfangen, dass du "Register security information" per Conditional Access bspw. nur aus trusted Locations erlaubst.

Wenn wir beim Thema "Lizenzen" sind, müssten die User aber doch mindestens eine Entra Id P1 Lizenz haben, da sie an der Anmeldung mittels Conditional Access gehindert werden. Ein Grund wäre hier doch, falls sie eine Mailbox auf dem lokalen Exchange haben sollten. Ansonsten müsste man die akzeptierte(n) Domäne(n) ja auf non-authoritative konfigurieren.

Okay, wir reden nicht über "SecPol", wir reden über Conditonal Access Policies. Ist der Sync User in der "AllUser_NoLicence"? Falls ja, würde ich ihn aus dem dynamischen Filter ausschließen und testen. Ansonsten mit "What If" oder den Sign In Logs einmal prüfen, ob es tatsächlich an dieser Policy scheitert.

Hi, wo hast du denn hier eine "SecPol" erstellt bzw. was verstehst du hier gerade unter "SecPol"? Und wie steht es um den "On-Premises Directory Synchronization Service Account"? Gruß Jan

Hi, ich würde auch bei der Message Delivery Restriction mein Glück mal mit der PowerShell versuchen. Evtl. ist es generell nicht die ungeschickteste Idee, es direkt mit dem Public Folder in einer Verteilerliste und "Set-Mailbox ... -AcceptMessagesOnlyFromDLMembers <Verteilerliste>" zu erledigen. Configure message delivery restrictions for a mailbox in Exchange Online | Microsoft Learn Set-Mailbox (ExchangePowerShell) | Microsoft Learn HTH Jan

Für Exchange online gibt es jetzt weitere Optionen: Enable or disable access to Outlook for Windows | Microsoft Learn Wenn ich den Artikel (so früh am Morgen) richtig lese, sollte Get-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -OneWinNativeOutlookEnabled $false genügen. Alternativ geht es auch pro Mailbox: Set-CASMailbox -Identity colin@contoso.onmicrosoft.com -OneWinNativeOutlookEnabled $false Oooahhhh... Der Download vom neuen Outlook ist dann noch möglich, es endet dann in:

So. Zwei Spaß und Spiel Domains (eine mit MTA-STS, die andere ohne) sind für Inbound SMTP DANE konfiguriert. Bei der dritten Domain im Bunde warte ich mal noch die restlichen 6,5 Tage. Für .de Domains benötigt der selfHOST Support dann übrigens: DNSSEC Schlüssel Flags DNSSEC Schlüssel Protokoll DNSSEC Algorithmus Öffentlicher Schlüssel Für .it und .cloud Domains (wie oben geschrieben): DNSSEC KeyTag DNSSEC Algorithmus DNSSEC Digest Typ DNSSEC Digest

Hi, da es bei Server 2025 Domain Controllern Probleme mit der Netzwerkerkennung gibt und es scheinbar (auch) mit Anpassung der IPv6 Konfiguration zusammenhängt, ist es hier vielleicht auch das "Problem": When is Network Profile Issue for Domain Controllers going to be at least acknowledged? | Microsoft Community Hub Gruß Jan

DNSSEC funktioniert (scheinbar) schonmal. Die Domain ist bei selfHOST registriert und die DNS Zone liegt bei Azure. Hab den Support angeschrieben und die brauchen dann nur die Infos aus dem oben verlinkten Artikel und richten das dann ein. # Punkt 6 aus # https://learn.microsoft.com/en-us/azure/dns/dnssec-how-to?tabs=sign-portal#sign-a-zone-with-dnssec Key Tag: 4535 Algorithm: 13 Digest Type: 2 Digest: 7A1C9811A965C46319D94D1D4BC6321762B632133F196F876C65802EC5089001 Morgen dann mal in Ruhe mit How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications | Microsoft Learn weitermachen. Wobei ich da wohl nach dem ersten Überfliegen recht zügig 7 Tage Pause machen muss..

Da ist man heute nochmal im Azure DNS Portal und stolpert über "DNSSEC". Scheinbar ist das Anfang des Jahres live gegangen: How to sign your Azure Public DNS zone with DNSSEC | Microsoft Learn Jetzt muss ich nur noch den Prozess für .it in Erfahrung bringen.

Sei mir bitte nicht böse, aber bei den hier aufkommenden und fehlenden (absoluten) Basics, solltet ihr das evtl. nochmal überdenken. Alternativ holt euch doch einen Dienstleister dazu, der euch hier einmal unterstützt und das alles evtl. mit euch gerade zieht. Mit Exchange 2016 (oder auch 2019) müsst ihr ja eh einen Plan für "ab Oktober 2025" haben.

Hi, naja, "null sender" / "empty sender" ist halt ein leerer "Absender" (<>). Ihr doktort da jetzt ein halbes Jahr dran rum. Für die Zeit (Geld) hätte man wohl reichlich viel feste IP beim ISP bekommen. Alternativ wäre es ja auch denkbar sich irgendwo in einer (private) Cloud ein entsprechendes Mail Relay aufzusetzen / bereitstellen zu lassen. Gruß Jan

LAPS unter Windows Server 2025 / Windows 11 24H2 hat da eine bzw. zwei (drei) coole, neue Funktion(en): Kennwörter ohne "leicht zu verwechselnde" Zeichen erstellen (+ besser lesbare Schriftart im ADUC) Kennwortsätze bzw. Passphrases sind möglich (Verwaltung des lokalen Adminkontos, der dann pro Device ebenfalls einmalig ist)

Hi, falls der Domain User mit lokalen Adminrechten in der Gruppe der "Protected Users" ist, dann ist das so. Gruß Jan

Hi, da sollte doch ein Link sein "Ich kann meine Microsoft Authenticat-App im Moment nicht verwenden." (Imgur: The magic of the Internet). Gruß Jan

Hi, warum muss der User denn (nur) vorübergehend per Remote Desktop zugreifen und auf was soll zugegriffen werden? Auf dem DC werden wohl auch (hoffentlich) die Anwendungen fehlen. Wäre es alternativ möglich, einen PC dafür bereitzustellen und auf diesen zuzugreifen? "Notfalls" halt einen PC dafür kaufen. Gruß Jan

Schau dir dafür ggfs. die Antwort von @Squire an. Wenn du per Gruppe berechtigst und die Berechtigungen der User aufräumst, ist Automapping egal. (Es sei denn du pflegst die entsprechenden Attribute im AD händisch.)

Hi, bei FullAccess benötigst du das Kennwort nicht, da der zugreifende User ja halt FullAccess hat. Generell sollte bei Gruppenpostfächer niemand das Kennwort kennen/brauchen und der Account dahinter ist doch deaktiviert. Gruß Jan

Hi, du hast die Lösung doch im Endeffekt schon: Nimm den Hostname / FQDN des Systems? Gruß Jan

Und dafür über 1000 Domänen oder wie viele waren es. :-D

Das vorausgesetzt, hast du eigentlich kein Problem, außer den Fehler im RCA? Puh, nunja, trink nen Kaffe oder Bier, oder, oder, oder. ;) (Bei uns geht das auch durch die WAF der Sophos und ich habe keinen Fehler. Ich habe aber auch keinen Zugriff auf die Sophos und kann daher nicht sagen, was konfiguriert ist. ;))

Wenn du "Support device authentication using certificate" (GPS: Support device authentication using certificate) deaktivierst, wird wohl Ruhe sein. Im Default / "not configured": Ansonsten auf den Clients und DCs: Location: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Type: DWORD Name: LogLevel Value: 0x1 Location: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Type: DWORD Name: KerbDebuglevel Value: 0xffffffff Location: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Type: DWORD Name: KdcDebugLevel Value: 0x1 Location: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Type: DWORD Name: KdcExtraLogLevel Value: 0x1f Dann wirst du vermutlich zum gleichen Zeitpunkt auf den DCs unter System die Event Id 29 / Kerberos-Key-Distribution-Center als Warnung haben sowie Event Id 19 / "Kerberos-Key-Distribution-Center" als Error. Auf dem Client wird dann der "Security-Kerberos" Error / Event Id 3 im System Event kommen und den Error Code 0x19 haben, der laut dem obigen Link - in meinen Augen - nur ein Hinweis ist "Additional pre-authentication required". Warum Win 11 24H2 bei mir (in der Testumgebung) sind es ausschließlich Server 2025. Der Win 11 24H2 Testclient ist ruhig.

Hi, aus 4771(F) Kerberos pre-authentication failed. - Windows 10 | Microsoft Learn: Failure Code 10: Pre-Authentication Type 16: Sind SmartCards / Zertifikate im Spiel? Gruß Jan