Jump to content

Hinterlegtes S/MIME Zertifikat in Outlook 365 für bestimmte Empfänger deaktivieren


Recommended Posts

Hallöchen zusammen,

 

wir arbeiten seit einiger Zeit mit E-Mail-Signierung und haben dazu für jeden Benutzer ein persönliches Benutzerzertifikat geordert. 

Die Zertifikate wurden auf einem Server hinterlegt, der für die E-Mail-Signierung und bei Bedarf auch für die Verschlüsselung von E-Mails zuständig ist.

Die Anforderung jedoch ist, auch intern E-Mails zu signieren. Da wir keinen Exchange in der Enterprise Version besitzen, können wir die Zertifikate auch nicht im Exchange hinterlegen um interne E-Mails zu signieren.

Also haben wir jedem Benutzer das Zertifikat im Outlook-Client hinterlegt. Das Problem ist leider, dass einige Firmen keine Signierten E-Mails entgegen nehmen.

Natürlich kann der User in Outlook händisch die Signierung aktivieren und deaktivieren, aber das führt dazu, das die Kollegen genervt sind immer darauf zu achten.  

 

 

Meine Frage:

kennt jemand eine Möglichkeit wie ich dem Outlook-Client sagen kann, wenn eine E-Mail zu Empfänger XYZ  gesendet wird, dann bitte keine Signierung anhängen also die Signierung deaktivieren?

 

Ich bedanke mich für Eure Unterstützung.

 

Gruß Eure Sandra

Edited by Sandra1982
Schreibfehler
Link to post
vor 12 Minuten schrieb Sandra1982:

Die Zertifikate wurden auf einem Server hinterlegt, der für die E-Mail-Signierung und bei Bedarf auch für die Verschlüsselung von E-Mails zuständig ist.

 

vor 12 Minuten schrieb Sandra1982:

wie ich dem Outlook-Client sagen kann, wenn eine E-Mail zu Empfänger XYZ  gesendet wird, dann bitte keine Signierung anhängen also die Signierung deaktivieren?

Also wenn das so geht, wie bei den Systemen die ich kenne, wirst du wohl die Kollegen aus der it fragen müssen. Üblicherweise gehts per subject command. Und die werden auf dem oben erwähnten Server definiert und am Client dann verwendet.

Link to post
Posted (edited)
vor 38 Minuten schrieb NorbertFe:

 

Also wenn das so geht, wie bei den Systemen die ich kenne, wirst du wohl die Kollegen aus der it fragen müssen. Üblicherweise gehts per subject command. Und die werden auf dem oben erwähnten Server definiert und am Client dann verwendet.

Danke für Deine Antwort!

Das Problem ist, dass die E-Mails vom Exchange Server zu dem Server geleitet werden, der die Signierung vornimmt. Da interne E-Mails jedoch den Exchange nicht verlassen, gelangen diese erst garnicht zu dem Server der die Signierung vornimmt. Quasi signiert der Server nur die die E-Mails, die nach extern gesendet werden. DIe Anforderung ist jedoch, dass interne E-Mails auch signiert werden müssen. Soweit funktioniert ja auch alles, nur das es jetzt ärger mit manchen externen Empfängern gibt. Auf dem Server können wir natürlich die externen E-Mail-Adressen die Ärger machen in eine Liste packen, dass die Signierung nicht angehängt wird. Aber da wir intern signieren müssen macht das ja der Outlook Client und da müsste man dann immer darauf achten, dass die Signierung im Outlook-Client deaktiviert wird. Ich hoffe es ist verständlich erklärt *lol* sorry

 

Gruß Sandra

Edited by Sandra1982
Link to post
vor 34 Minuten schrieb Sandra1982:

DIe Anforderung ist jedoch, dass interne E-Mails auch signiert werden müssen.

Dann habt ihr die falsche Technik. Denn die läßt sich, wie du richtig erkennst gar nicht in diesem Fall dafür nutzen. Im Übrigen würde das Ablegen von Zertifikaten nicht für die Signatur von Mails, sondern für die Verschlüsselung und Validierung sein. Signieren würde man immer mit seinem eigenen public key und der muss dann halt am Client/Outlook vorhanden sein.

vor 36 Minuten schrieb Sandra1982:

Soweit funktioniert ja auch alles, nur das es jetzt ärger mit manchen externen Empfängern gibt.

Na das nenn ich mal aussagekräftige Fehlerbeschreibung. Ist ähnlich wie "geht nicht". ;)

 

vor 37 Minuten schrieb Sandra1982:

Aber da wir intern signieren müssen macht das ja der Outlook Client und da müsste man dann immer darauf achten, dass die Signierung im Outlook-Client deaktiviert wird. Ich hoffe es ist verständlich erklärt *lol* sorry

Mir ist das Problem schon klar. Was mir bei dem ganzen Fließtext jetzt nicht klar ist, signiert ihr bereits intern oder nicht? Falls nein, habt ihr also ein Compliance Problem, weil ihr intern nicht signiert aber sonst nur "Ärger mit manchen externen Empfängern (die man lösen könnte (zentral))". Falls ihr schon intern signiert, muss man schauen, was euer Gateway leisten kann und wie es mit bereits signierten Mails umgeht. Am Ende sind das meiner Meinung nach aber zwei konträre Anforderungen, die sich technisch einfach nicht sinnvoll unter einen Hut bringen lassen. Das müßte man jetzt nur den Entscheidern beibringen. Entweder clientseitig end-to-end (dann geht alles aber der User ist eben verantwortlich) oder serverseitig gateway-to-end (dann geht intern nicht "sinnvoll"), aber der User ist aus der Verantwortung.

 

Bye

Norbert

  • Like 1
Link to post
Posted (edited)
vor 3 Stunden schrieb NorbertFe:

Was mir bei dem ganzen Fließtext jetzt nicht klar ist, signiert ihr bereits intern oder nicht?

Die User senden eine E-Mail über den Exchange. Nach dem Exchange wird die E-Mail über den NSP-Server signiert,

Da meine Kollegen aber auch Ihre Postfächer im Exchange haben findet keine E-Mail-Signierung innerhalb unserer Domäne/kommunikation statt.

Also war der Lösungsansatz, im Outlookclient bei allen Mitarbeitern auch das S/MIME Zertifikat zu hinterlegen. So ist auch die interne Signierung gewährleistet.

 

Jetzt gab es bei einem Kunden Probleme, der keine signierten E-Mails empfangen kann/möchte. Also haben wir auf dem NSP-Server die besagte E-Mail Adresse hinterlegt um an dieser Stelle keine Signierung zu diesem Empfänger zu machen. Da wir aber das Zertifikat auch im Outlook-Client hinterlegt haben, wird trotzdem die E-Mail schon am Client signiert.

Outlook bietet zwar die Option, die Signierung händisch zu deaktivieren aber das ist zu aufwendig bzw. zu nervig für die Kollegen. Ausserdem wird dann wieder vergessen die Signierung einzuschalten, das würde der Chef nicht gerne sehen.

Um das ganze zu umgehen, würde ich gerne schon dem Outlook-Client sagen, wenn eine E-Mail zu diesem Empfänger geht, dann signiere diese E-Mail nicht. Quasi so, wie ich es an dem NSP-Server machen kann, der diese Option bereits hat. Ich habe gedacht, das es vielleicht eine GPO für Outlook gibt, wo ich Empfängeradressen eintragen kann wo der Outlook-Client die signierung dann nicht vornimmt. Danke für Deine Geduld mit mir :)  

 

Edited by Sandra1982
Link to post
vor 30 Minuten schrieb Sandra1982:

Die User senden eine E-Mail über den Exchange. Nach dem Exchange wird die E-Mail über den NSP-Server signiert,

 

ok

vor 30 Minuten schrieb Sandra1982:

Da meine Kollegen aber auch Ihre Postfächer im Exchange haben findet keine E-Mail-Signierung innerhalb unserer Domäne/kommunikation statt.

 

ok

 

vor 30 Minuten schrieb Sandra1982:

Also war der Lösungsansatz, im Outlookclient bei allen Mitarbeitern auch das S/MIME Zertifikat zu hinterlegen. So ist auch die interne Signierung gewährleistet.

 

das selbe Zertifikat wie im NSP oder ein anderes?

 

vor 31 Minuten schrieb Sandra1982:

Jetzt gab es bei einem Kunden Probleme, der keine signierten E-Mails empfangen kann/möchte. Also haben wir auf dem NSP-Server die besagte E-Mail Adresse hinterlegt um an dieser Stelle keine Signierung zu diesem Empfänger zu machen. Da wir aber das Zertifikat auch im Outlook-Client hinterlegt haben, wird trotzdem die E-Mail schon am Client signiert.

Outlook bietet zwar die Option, die Signierung händisch zu deaktivieren aber das ist zu aufwendig bzw. zu nervig für die Kollegen. Ausserdem wird dann wieder vergessen die Signierung einzuschalten, das würde der Chef nicht gerne sehen.

Um das ganze zu umgehen, würde ich gerne schon dem Outlook-Client sagen, wenn eine E-Mail zu diesem Empfänger geht, dann signiere diese E-Mail nicht. Quasi so, wie ich es an dem NSP-Server machen kann, der diese Option bereits hat. Ich habe gedacht, das es vielleicht eine GPO für Outlook gibt, wo ich Empfängeradressen eintragen kann wo der Outlook-Client die signierung dann nicht vornimmt. Danke für Deine Geduld mit mir :)  

 

vor 2 Stunden schrieb NorbertFe:

Am Ende sind das meiner Meinung nach aber zwei konträre Anforderungen, die sich technisch einfach nicht sinnvoll unter einen Hut bringen lassen. Das müßte man jetzt nur den Entscheidern beibringen. Entweder clientseitig end-to-end (dann geht alles aber der User ist eben verantwortlich) oder serverseitig gateway-to-end (dann geht intern nicht "sinnvoll"), aber der User ist aus der Verantwortung.

War meine Antwort nicht eindeutig genug? :)

Link to post
vor 29 Minuten schrieb NorbertFe:

War meine Antwort nicht eindeutig genug? :)

 

Ja, die Lösung ist in der Tat nicht die Optimalste. Das derartige Problme auftauchen würden hätte niemand gedacht, aber irgendwas ist ja immer.

Trotzdem hätte ich gedacht, dass es innerhalb des Outlook-Clients auch möglich wäre einzelne Empfänger auszuschließen.

 

Danke für Deine Unterstützung :)

Ich wünsche Dir und auch allen anderen ein schönes Wochenende :)

 

LG Sandra

Link to post
Gerade eben schrieb Sandra1982:

Ja, die Lösung ist in der Tat nicht die Optimalste

Na oder das am bestenstenste optimierteste Optimums. ;)

 

vor 1 Minute schrieb Sandra1982:

Das derartige Problme auftauchen würden hätte niemand gedacht, aber irgendwas ist ja immer.

Ähm doch.

 

vor 1 Minute schrieb Sandra1982:

Trotzdem hätte ich gedacht, dass es innerhalb des Outlook-Clients auch möglich wäre einzelne Empfänger auszuschließen.

 

Nicht, dass ich wüßte. Aber auch das wäre ja dann eine clientseitige Lösung, die dir zentral keine Steuerungsmöglichkeit geben würde. ;)

Link to post

Hallo und schönen Freitag Nachmittag,

 

Ihr habt ein Produkt im Einsatz, welches eine Gateway Signierung und Verschlüsselung macht und wollt das nun mit einer Client Lösung machen / kombinieren ?

 

Du siehst und merkst selbst, das wird nichts und wird auch so nicht gehen ! Und eine zentrale Verwaltung ist so nicht möglich !

 

Viele Grüße Arnd

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...