NorbertFe

Welcher User?

Weil die Gruppe PräWindows 2000 so ziemlich alle Attribute im AD lesen kann (abgesehen von confidental attributes). Das kann sich bei Citrix' Kundenverhalten ja bald ändern. ;)

Hat aber den Nachteil, dass man dann mit der Kiste eben Mitglied des AD ist und somit ggf. auch dort neue Angriffspunkte schafft, die LDAPs oder Radius in der Form nicht haben. Bei ADFS reicht es den Group-Managed Service Account in die Gruppe zu packen unter dem die ADFS laufen. Aber im Zweifel muss man eben mal das Logging im AD hochdrehen. Lösbar sollte es auf jeden Fall auch ohne die Prä-Windows 2000 Gruppe sein.

Indem ein LDAP Bind durchgeführt wird. Hier sieht man das ganz gut: https://connect2id.com/products/ldapauth/auth-explained Für Radius findest du es sicher auch irgendwo. Das ist gut, aber warum kommst du zu dieser Erkenntnis erst jetzt? ;) Ich mein, der Name der Gruppe sollte doch Indikator genug sein. Dazu müssen aber nicht die Authentifizierten User in der Gruppe stecken, da tuts zur Not auch das RD Gateway oder der NPS. Und selbst das könnte man sich vermutlich sparen wenn man die Windows-Autorisierungszugriffsgruppe nutzt.

Nö, macht man eigentlich schon länger nicht mehr so. LDAP Abfragen oder RADIUS sind auch ohne Domainjoin jederzeit möglich (letzteres setzt natürlich einen RADIUS Server voraus). Der User braucht schon ein paar "besondere" Rechte. Vor allem falls Mitgliedschaften abgefragt werden sollen/müssen. Leider steckt bei vielen aber die Gruppe der Authentifizierten User in der Gruppe Prä-Windows 2000. ;) Und die darf viel zu viel lesen. Den Rest versteh ich nicht so ganz, was du da "ableiten" willst usw.

Ah sorry falschrum gedacht. Ich ging davon aus, dass die Shared Mailbox in der Cloud liegt. Aber unabhängig davon: es ist nicht supported :) es kann meist funktionieren, aber wenn nicht, hast du Pech. ;)

Kommt darauf an, was du hören magst. ;) Produkte sind meiner Erfahrung nach für ihren Zweck gut geeignet. Ob sie in deiner Situation helfen kann ich aber nicht sagen :)

Nein. Und deswegen macht es ja jetzt auch keinen Sinn sie JETZT zu kaufen (es sei denn sie ist für den Betrieb notwendig Stichwort Lizenzmobilität) Du kannst also jetzt auf 2019 upgraden und musst eben alles neu kaufen Exchange SE plus SA plus SE CALs plus SA. Deswegen ist eine SA auch _nahtlos_ zu führen. Du kannst sie nicht verlängern. Sonst würde ja jeder immer nur dann die SA kaufen, wenn er meint sie mal günstig zu benötigen. Also SA ist am Ende auch nur ein Abo Modell. Alternativ kannst du natürlich auch auf M365 E3 Lizenzen umstellen, da wäre dann Exchange SE und CALs schon enthalten.

Ist es nicht. Wenn die SA zum Erscheinen von Exchange SE aktiv ist, brauchst du sie erst verlängern, wenn der Ablauftermin näher rückt. Wenn ihr keine SA für die CALs habt, dann müsst ihr die ebenfalls erwerben. Falls ihr CALs mit SA habt, dann natürlich nur die SA rechtzeitig verlängern. Dann müßt ihr die SA verlängern. Kann dir niemand sagen, ob das so ist und außerdem wird dir niemand zu einem Lizenzverstoß raten. Bye Norbert

Hast du den Link gelesen? Warum zitiere ich denn daraus, wenn du hinterher fragst wieso und weshalb? Du sollst per exo powershell die Gruppe auf dem exo Postfach neu berechtigen.

Steht die Gruppe denn noch drin mit den Rechten? Ansonsten kann man generell dazu raten keine Berechtigungen oder übergreifend zu pflegen. ich kann dir aber bestätigen, dass zumindest bei Neueintragung der Gruppe auf der cloudseite die Berechtigungen dann auch irgendwann funktionieren müssen. https://learn.microsoft.com/en-us/exchange/permissions

https://www.faq-o-matic.net/2011/02/07/bilder-im-active-directory/ da sieht man mal, wie viel software inzwischen eingestellt wurde. ;) kaum noch ein Link aus meinem Artikel funktioniert. der hier geht aber definitiv noch: https://www.codetwo.de/freeware/active-directory-photos/

Ja mit Powershell und einer entsprechenden Schleife. Oder mit einem entsprechenden Tool.

Ohne den gpresult Report wird das vermutlich schwierig, hier weiterzuhelfen.

Ja, aber die gelten dann für die jeweiligen gpp und nicht für Scripts im gpo.

Im Zweifel mal nachschauen, wo die "Public Folder Database 1154646891" noch im AD steht. Sie muss ja noch an irgendwelchen Objekten hängen. Wird man mit adsiedit sicherlich finden können. Alternativ mal ein LDIF vom gesamten AD ziehen und mit dem Editor durchsuchen. Irgendwo muss der Kram ja auftauchen.

Warum dann migrieren? :) Aber muss wohl jeder selbst merken.

Ich würde kurzfristig „jetzt“ weggehen. ;) wenn du die jetzt migrieren hast du sie auch in 5 Jahren noch.

Du brauchst doch nur bei deiner external rule die signed Mails ausnehmen. Aber probier’s halt.

Stellt man sich diese Frage nicht bevor man sie entfernt? ;) An deiner Stelle würde ich es jetzt einfach abwarten. Sehr wahrscheinlich ist es aber nicht kritisch.

Du definierst eine Regel (Prio 2) , welche auf Multipart/Signed abzielt und exludierst dann in der selben Regel, signed Nachrichten . Und dann wunderst du dich, dass auf diese (ausgeschlossenen Nachrichten) die Prio 3 Regeln angewandt werden. Und zusätzlich müsstest du dann in Prio 3 natürlich die in Prio 2 bearbeiteten Mails ausschließen, damit sie eben nicht dort verarbeitet werden. Evtl. bin ich ja zu blond, um das zu verstehen.

Deswegen fragen wir dich ja nicht.

Möglich. Antworte doch mal auf die Frage: Was genau soll diese Regel tun?

Ich versteh dein Konstrukt immer noch nicht. Vielleicht weil ich schwer von Kapee bin, aber wenn deine Regel aus 1. als Match "multipart/signed" nimmt und du gleichzeitig in 2. du dieser Rule sagst, dass ExceptIfMessage Signed ist, dann matcht die nie diese Regel. Mal davon abgesehen, dass "signed, encrypted" zumindest lt. dem Exchange 2010 Artikel so nicht funktioniert, aber das mag in ExO natürlich inzwischen funktionieren. Was kommt denn dann als Prio3 und prio 4 bei dir?

Nochmal zum Verständnis. Du willst alle eingehenden Nachrichten "außer digital signierte" mit einem Betreff versehen, richtig? New-TransportRule -Name "Signierte E-Mails in Klars***rift" -HeaderMatchesMessageHeader "Content-Type" -HeaderMatchesPatterns "multipart/signed" -SetHeaderName "X-Processed" -SetHeaderValue "True" Wenn ich das richtig lese, dann zielt das doch darauf ab, Mails mit dem Header multipart/signed zu identifizieren, richtig? Und im nächsten Schritt schließt du sie von der Verarbeitung wieder aus. Set-TransportRule -Identity "Signierte E-Mails in Klars***rift" -ExceptIfMessageTypeMatches "Signed" Wäre für mich jetzt nicht verwunderlich, dass eben signierte Nachrichten dann von der Regel (vermutlich mit Priority 3 oder später) verarbeitet werden. Evtl. hilft das: https://thoughtsofanidlemind.com/2011/05/12/excluding-disclaimers-for-encrypted-or-signed-messages/