Jump to content

Lukikum

Members
  • Gesamte Inhalte

    149
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Lukikum

  1. Hallo zusammen,

     

    kennt jemand eine Möglichkeit im Exchange 2019 on premise eine 2 faktor Authentifzierung für owa einzuführen? Ich habe schon viel recherchiert aber immer nur was zu Exchange Online gefunden. Auch wenn ich gerne so früh wie möglich migrieren würde, wird es vermutlich noch eine Weile dauern, weshalb ich ich nach einer Zwischenlösung suche.

    Vielen Dank und liebe Grüße
    Lukas

  2. Am 20.7.2022 um 11:13 schrieb NorbertFe:

    Da du oben die Antwort mit dem Pipeline Tracing als Lösung markiert hast, sei die Frage gestattet, ob du die Lösung deines Problems auch gefunden hast. Würde mich interessieren, was rauskam.

    Hi Norbert,

    kurzes Update für dich. Kurz vor meinem Urlaub hat sich herausgestellt, dass die Mails nun richtig markiert werden. Zum Pipeline Tracing bin ich nicht mehr gekommen, allerdings habbe ich nichts geändert, also scheint es wohl doch am Smarthost Anbieter gelegen zu haben.

    LG

  3. Moin zusammen,

    ich bin es mal wieder :P

    Und zwar habe ich momentan die Anfrage bekommen, ob es möglich eine Outlook Kalenderberechtigung so zu setzen, dass für Standard User nur die farblich hinterlegte Kategorie zu sehen ist + wie die Kategorie benannt ist. Allerdings sollen die Standardnutzer aus Datenschutzgründen nicht den Body des Kalendereintrages sehen dürfen. Ich finde aber nicht welche Berechtigungsstufe für die Kategorien verantwortlich ist und ich befürchte, dass das die gleiche Berechtigung ist wie für den Body vom Kalendereintrag.

    Hat jemand eine Idee?

    LG
    Lukas

  4. vor 2 Minuten schrieb NorbertFe:

    Das läßt sich anhand des SPF Records NICHT eindeutig als Phishingmails klassifizieren.

    Doch würde ich schon sagen, wenn unsere Mail Domäne von einer IP-Adresse verschickt wird, die nicht im SPF Record hinterlegt ist, muss es sich um eine Fälschung handeln. Oder jemand hat versäumt uns mitzuteilen, dass das System mit im Record aufgenommen werden muss.

  5. vor 26 Minuten schrieb NorbertFe:

    Das können die großen Provider im Webinterface zwar relativ easy umsetzen, bei eigenen Mailsystemen mit Fat-Clients ist das aber im Falle von Outlook mit Nachteilen behaftet:

    1. Das Ding steht im Zweifel über jeder Externen Mail (so machen das leider inzwischen viele) "Achtung dies ist eine externe Mail klicken Sie bla bla nicht".

    2. Beim Einfügen von Infos in die Mail zerstört man digital signierte Mails und damit das sicherste Kriterium anhand dessen man prüfen kann, ob die Mail wirklich von der angegebenen Quelle stammt.

    3. Tritt im Allgemeinen ein Gewöhnungseffekt ein, wenn 1. umgesetzt wird. Mal vom optisch schlechten Ergebnis, wenn die Mailkonversation ein paarmal hin und her geht.

     

     

    Da du oben die Antwort mit dem Pipeline Tracing als Lösung markiert hast, sei die Frage gestattet, ob du die Lösung deines Problems auch gefunden hast. Würde mich interessieren, was rauskam.

     

    Bye

    Norbert

    Da stimm ich dir zu, bis jetzt war nur die Planung nur Mails zu markieren, die unsere E-Mail Domänen benutzen, aber von außerhalb kommen und einen SPF_Fail oder Softfail vorweisen. Also sichere Phishingmails. Bevor ich dort aber zu viel Zeit investiere schau ich aber erstmal ob das blocken bei SPF_Fail nicht einfach viel sinnvoller ist, bzw. ich bespreche es mal mit unserem Informationssicherheitsbeauftragten.

    Das Pipeline tracing ist in der org noch nicht konfiguriert gewesen, das muss ich erstmal einrichten und dann noch ein paar Tests machen. Ich gebe dir Bescheid was dabei rum kam.

    LG

  6. vor 11 Minuten schrieb NorbertFe:

    äußerst unwahrscheinlich. Keinen SPF Record zu haben ist zwar ein Kriterium anhand dessen man Rückschlüsse ziehen darf, aber es ist kein Grund eine Mail deswegen abzulehnen. Keinen SPF Record zu haben führt aber bei vielen inzwischen dazu eben als "verdächtig" klassifiziert zu werden. Ist aber meist nur ein (kleiner) Punkt von mehreren, denn wenn man keinen SPF hat, hat man meist auch kein DKIM und erst recht kein DMARC im Einsatz. Man sollte die genannten Dinge aber aus reinem Eigeninteresse durchaus nutzen, damit sicher(er)gestellt ist, dass die eigenen Mails eben auch im Posteingang landen und nicht im Junkfolder und vor allem, dass die eigene Domain weniger einfach für Phishing genutzt werden kann. Und selbst dann hat man noch genug zu tun. ;)

     

    Bye

    Norbert

    Danke für die ausführliche Antwort :thumb1:

    vor 7 Minuten schrieb testperson:

    Ich finde es an der Stelle gar nicht verkehrt, dass Gmail jetzt mit dezenten Hinweisen an das Thema rangeht:

    image.png.538757762be15ec7117a7c11766e89be.png

    Ja das finde ich auch nicht schlecht, so in die Richtung wollte ich es auch machen. Nur etwas einfacher markiert ;)

  7. vor 1 Minute schrieb NorbertFe:

    Ich wollte darauf hinaus:

    Achso ja, ich bin mir nur nicht sicher wie die Kriterien bei Spamassasin für SPF_Fails/Softfails sind. Evtl reicht es ja auch schon dass sie kein SPF Record gepublished haben um einen SPF_Fail/Softfail im Spamassasin auszulösen.  Die dann zu blocken wäre schlecht.

  8. vor 10 Minuten schrieb testperson:

    Sofern ihr keine (externe) Anwendung habt die das benötigt, verbietet doch am Smarthost "einfach" die eigene Domain als Absender.

    Leider haben wir Anwendungen die das benötigen. Ich kann leider auch nicht selber einsehen wie das Regelwerk beim Smarthost funktioniert. Man kann bei deren Regeln leider auch keine IP basierte Ausnahme machen.

     

    vor 32 Minuten schrieb NorbertFe:

    Habt ihr denn SPF, DKIM und DMARC für eure Umgebung? ;) Oder gehört ihr auch zu denen

    Wir haben einen SPF Record, aber von DKIM und DMARC weiß ich nichts. Ich bin leider auch erst seit einem Monat dabei die ganzen Thematiken der Mail Administration aufzuarbeiten. Ich hab Mxtoolbox benutzt um das zu überprüfen.

     

    vor 32 Minuten schrieb NorbertFe:

    ? ;)

    Worauf willst du hinaus ?

  9. vor 14 Minuten schrieb NorbertFe:

    Mails anzunehmen um dann die Verarbeitung hinten zu erledigen ist bei Spam äußerst kontraproduktiv in meinen Augen. Dann nimmst du dem Spammer den Mist ja trotzdem ab um ihn dann zu löschen/quarantänieren/zuzustellen. Keine der drei Möglichkeiten ist wirklich sinnvoll IMHO. Aber da ich eure Anforderungen und Umgebung nicht kenne, mag das ja irgendeinen verborgenen Sinn haben. ;)

    Also momentan wird die Spamerkennung bei unserem Smarthost Anbieter über Spamassasin gemacht. Dort werden natürlich schon viele Mails automatisch geblockt oder als Spam markiert. Die Mails die durchkommen oder falsch markiert werden leiten wir dann an einen Spamtrainer weiter um den Algorithmus zu traineren.

     

    Wir hatten letztens aber den Fall dass jemand die Adresse von unserer GF gefälscht hat und nicht als Spam markiert wurde. Meine Idee war es jetzt dass der Smarthost Mails die einen SPF_Fail oder SPF_Softfail vorweisen,  mit einem Header versehen, damit ich beim Exchange eine Regel machen kann um die Mails als "Extern" zu markieren. Wenn ihr jetzt sagt, dass best practice bei einem SPF_Fail einfach blocken ist, wäre das natürlich dann überflüssig.

     

  10. vor 15 Stunden schrieb NorbertFe:

    Je nach Einstellung ist das also beabsichtigt? Hmm. Also so pauschal würd ich das ohne Beleg erstmal in Frage stellen. DIe Mails werden euch per SMTP zugestellt nehme ich an?

    Ja die Mails werden per SMTP zugestellt. Zuerst werden sie an einen HAproxy geleitet und dann von dort zu unserem Servercluster.

     

    vor 15 Stunden schrieb NorbertFe:

    Wenn nicht jeder Geschäftspartner SPF Records veröffentlicht hat, haben die ohne SPF Records ja auch keine Probleme mit SPF Records. ;) (Dafür dann halt andere).

    Mh das stimmt, ich müsste mal in Erfahrung bringen wie beim SpamAssasin SPF_Fail und SPF_Softfail definiert werden.

  11. vor 1 Stunde schrieb mikro:

    Moin hast du im OWA oder Postfach Emailweiterleitungsregeln? Die erzeugen eine neue Mail und zeigen somit nicht mehr den ursprünglichen Header an.

     

    mikro

    Ne eine Weiterleitung wird es nicht sein :-)

    vor 1 Stunde schrieb cj_berlin:

    Moin,

     

    ein häufiger Kritikpunkt am Exchange ist, dass er zu viele Informationen dem Header bei Versand hinzufügt. Dass er beim Empfang etwas entfernen würde (ohne dass dies in einer Transportregel gefordert wird), ist mir neu. Wenn die hinzugefügte Zeile allerdings nicht RFC-konform ist, könnte es schon sein, dass sie verworfen wird.

    Mhh unser Smarthost fügt so einige Header hinzu, würde mich wundern wenn der neue aufeinmal nicht konform sein sollte. Wenn es anscheinend doch nicht so üblich ist, dass Exchange gerne mal Header Zeilen verwirft, könnte es doch am Smarthost Anbieter liegen.

    vor einer Stunde schrieb NorbertFe:

    Und die Behauptung steht jetzt mal einfach so im Raum. ;) gibts da auch Beispiele oder Belege?

    Nicht wirklich, das ist die Aussage die ich bekommen habe "MS-Exchange-Server löschen (je nach Einstellung) Header-Zeilen. Das ist kein Bug, sondern so beabsichtigt, insbesondere, wenn Exchange-Cluster betrieben werden und die Zwischenstationen dort nicht alle abgebildet werden sollen. Dort kann natürlich auch die Header-Zeile "X-HZI-spffail: Yes" zum Opfer fallen. "

    Als Beispiel meinte er, dass ein Header der von deren Server erstellt wird, immer von unseren Exchange entfernt wird. Hab jetzt keinen Grund gesehen ihm nicht zu vertrauen da er schon einiges an Erfahrung hat und mit vielen verschieden SMTP Serversystemen arbeitet.

    vor einer Stunde schrieb NorbertFe:

    Nennt sich pipeline tracing.

    Danke, ich werde mich darüber mal einlesen und schauen was sich dabei ergibt :)

     

    vor einer Stunde schrieb NorbertFe:

    Warum nimmst du die überhaupt an? Bei spf fail hat doch der Absender klar definiert was er erwartet, was mit gefälschten Mails passieren soll. (Zumindest wenn er weiß was er tut)

    Ich habe die Konfiguration so von meinem Vorgänger übernommen. Die Mails werden bei einem SPF_Fail mit einem Spamscore versehen, zusätzlich sollen sie jetzt aber auch noch markiert werden. Der Grund warum wir die nicht ablehnen, ist vermutlich durch zu viele false positive, da nicht jeder Geschäftspartner SPF Records veröffentlicht hat. Bei unserem Fachbereich arbeiten wir viel mit kleineren Nischenunternehmen zusammen. Kann aber auch sein dass sich in dem Bereich noch nicht genug gedanken gemacht wurden, muss ich noch überprüfen. Es gibt halt einiges was ich aufarbeiten muss :P

    Gruß
    Lukas

  12. Hallo zusammen,

     

    ich habe mitgeteilt bekommen, dass Exchange Server gerne mal Header Zeilen löschen. Ich habe von unserem Smarthost aber eine Regelung einführen lassen, die eine Header Zeile hinzufügt, sobald ein SPF_Fail stattfindet (Grund dafür ist eine Markierung von gefälschten Adressen). Diese Headerzeile konnte ich aber nicht in einer Testmail finden.

    Gibt es eine Möglichkeit zu überprüfen welche Header Zeilen der Exchange entfernt? Smarthost Anbieter meint zumindest dass die Regel richtig konifguriert ist. Also denke ich dass das Problem dort liegen könnte.

    LG
    Lukas

  13. vor 1 Stunde schrieb NilsK:

    Moin,

     

    vielleicht beschreibst du besser das konkrete Problem, das du lösen willst. Sonst stochern wir hier wild herum.

     

    Gruß, Nils

     

    Hallo Nils,

    das Problem ist folgendes:
    Wir haben externe Konten die nur beschränkt auf unsere Umgebung Zugang haben sollen.  Deshalb werden sie in eine GG Gepackt die den Zugang zum Gobalen Adressbuch verhindert. Nun können die externen leute auch nicht mehr über die Standard Kalender Berechtigung auf die Kalender interne Mitarbeiter zugreifen. Meine Vermutung ist, dass das mit der Gruppenmitgliedschaft zusammenhängt. Problem ist nur, dass unser AD Admin im Urlaub ist und ich nun versuche nachzuvollziehen wieso ebenfalls der Zugriff auf Kalender verhindert wird.

    LG
    Lukas

  14. vor 2 Minuten schrieb cj_berlin:

    Moin,

    es gibt AD-Berechtigungen (wie z. B. Send-As), Postfachberechtigungen (wie z.B. Elemente löschen) und Ordnerberechtigungen (wie z.B. eigene Elemente bearbeiten). Erstere werden im AD hinterlegt, der Rest im Postfach selbst gespeichert.

    Und wo finde ich z.B. die Outlook Berchtigung für Kalender die Standardmäßig auf allen Kalendern hinterlegt ist? Also "Standard". Ist das dann über die set-organizationconfig geregelt? Gibt es zufällig eine gute Liste wo die ganze Berechtigunselemente aufgelistet sind?

    LG

  15. vor 6 Minuten schrieb tesso:
    $Quotas = Get-Mailbox -ResultSize Unlimited | Where-Object {$_.WhenMailboxCreated -gt (Get-Date).AddDays(-256) -and $_.RecipientTypeDetails -eq '1'}
    $Quotas | Set-Mailbox -UseDatabaseQuotaDefaults $true

    So zum Beispiel

    Super, vielen Dank. Da war ich schon echt nah dran, ich hab nur die pipe Position falsch gesetzt :streber: Hat jetzt wie gewünscht geklappt !!

  16. Hallo zusammen,

    als Neuling fällt es mir ein wenig schwer sich einen Powershell Befehl zusammenzustellen, wo ich ein Set-Mailbox an eine Bedinung knöpfen kann. Als Beispiel:

    Ich habe mir eine Variable mit folgenden Werten erstellt:
    $Quotas = Get-Mailbox -ResultSize Unlimited | Where-Object {$.WhenMailboxCreated -gt (Get-Date).AddDays(-256) -and $.RecipientTypeDetails -eq '1'}

    Wie kann ich diese Variable jetzt benutzen um auf die ausgegebenen Postfächer den Befehl anzuwenden: Set-Mailbox -UseDatabaseQuotaDefaults $true

    LG
    Lukas

  17. Hallo zusammen,

    ich habe gestern meine Aubsilung zum FISI abgeschlossen und widme mich jetzt der Exchange Server 2019 Verwaltung. Ich habe eine Frage zu Verteilern:

    Kann man einen Verteiler erstellen und dort eine Globale Gruppe hinterlegen um die Mitglieder aus der GG mit dem Verteiler zu erreichen? Ausführliche Antworten sind auch sehr gerne willkommen.

     

    EDIT: Ich stelle es mir dann so vor wie ein "Fake dynamischen Verteiler" der automatisch durch die Mitgliedschaft der GG gepflegt wird.

×
×
  • Neu erstellen...