Office 365 Integration

[NicoDiehl]

Hallo, 

ich versuche mich gerade an der O365 Integration. Habe die Anleitung durchgearbeitet und es sieht alles soweit gut aus. Folgendes Problem habe ich noch:
In der Transportregel im Exchange Online muss ja eine Ausnahme "Verwende den Connector außer die Sender-IP ist xxxx" eingestellt werden. 
Nun haben wir nur eine Externe IP Adresse und die ist demnach natürlich auch diese IP unter der der NSP bei Microsoft ankommt. 
Allerdings haben ja auch Mails, die von innerhalb unseres Netzes an O365 gehen diese IP als Absender, was dazu führt, dass nur Mails, die von Extern (Homeffice, Handy) zu MS eingeliefert werden, über den NSP laufen. (Ich hoffe ich drücke mich verständlich aus). 
Wie bekomme ich das nun hin, dass auch die Mails aus unserem internen Netz über den NSP gehen?

Gruß
ND

 

[StefanCink]

Hallo Nico,
ich bin mir nicht sicher, ob ich das Setup richtig verstanden habe, aber E-Mails, die im Homeoffice oder vom Handy verschickt werden, werden ja nicht per SMTP bei O365 abgeliefert. Diese Geräte synchronisieren sich per HTTPS direkt mit O365, oder habt ihr OnPrem noch einen Exchange-Server und damit einen Hybrid-Modus?
Gruß Stefan

 

[NicoDiehl]

Hallo Stefan,

der NSP ist OnPrem (da ist auch ein Exchange, aber andere Domain, nicht Hybrid). So wie ich das Konzept verstehe, müsste der Fluss ja so laufen:

Mail raus: Client (Outlook/OWA) --> Office 365 --> NSP für SMIME/Disclaimer --> Office 365 --> Ziel (oder evtl. ohne das 2. mal O365 ?)
Mail rein: irgendwer --> Office 365 --> NSP --> Office 365 --> Outlook

oder habe ich da was total falsch verstanden?

Gruß

Nico

 

[ffischer]

Hallo,,
auf die schnelle würde ich sagen der Mail Flow ist nicht korrekt.

Client via OWA (Mapi over HTTPS) oder EAS (https) => MS365 => NPS mit SMIME /Disclaimer etc. => Ziel
Anders rum

Versender Extern => NSP => MS365 => Client

Der NSP ist der letzte der beim Versand die Mail zu sehen bekommt und beim Empfang der erste der sie sieht.

 

[NicoDiehl]

Hallo,

dann müsste ich ja den MX Record von O365 auf den NSP umbiegen, davon ist in der Anleitung aber nirgends die Rede?
Ich hatte es so verstanden, dass sich der NSP quasi "einklinkt".

Grüße
Nico

 

[ffischer]

Guten Morgen,
bei den onPremise Exchange und anderen mail Server, ist der NSP auch der erste beim Empfang und letzte beim Versand der die Mail berührt.

Ich schau mir mal die Doku an.

 

[NicoDiehl]

Hallo Frank,

ich meine diese Anleitung: https://www.nospamproxy.de/wp-content/uploads/Integration-von-NoSpamProxy-Deutsch.pdf
bzw. die Beschreibung hier: https://www.nospamproxy.de/de/anbindung-von-nospamproxy-in-office-365/

 

[lukas]

Der Weg, den Frank beschreibt ist für die "normale" Konfiguration der richtige.

Die Clients reden mit M365
M365 redet mit dem NSP
Der NSP schickt weg

Bei  eingehenden Szenario:
Der NSP muss die Mails annehmen und nach getaner Arbeit an M365 weiterreichen.
Ob der MX nun auf den NSP zeigt oder auf ein anderes System, das davor liegt (Weitere Gateways, Filter, Proxys, Whatever) das selbst an den NSP schiebt ist dabei egal.

Analog kann es bei ausgehenden Mails auch vorkommen, dass der NSP nicht die letzte Instanz ist. Wenn man beispielsweise keine feste IP hat oder ihre Reputation schlecht ist kann man auch einen Smarthost zwischen schalten, der dann mit dem Internet spricht... oder wenn man Mails halt durch Drittsysteme jagen will/muss die noch andere Dinge machen.

Wichtig ist halt nur, dass man seine "Kette" kennt und diese sinnvoll aufbaut. Beispielsweise sollte man vermeiden vorgelagert ein Scan-Gateway einzusetzen das ein "Ich habe die Mail geprüft" an die Mail anfügt, man munkelt das wäre nicht gut für eine SMIME Signatur-Prüfung

Grüße

 

[NicoDiehl]

Ok, also müsste das Szenario in meinem Fall so aussehen:

Eingehend:
1. MX Record für die Domain muss von "xxx.outlook.com" umgestellt werden auf den OnPrem NSP
2. Mails gehen von außen auf den NSP
3. Der NSP gibt es dann an den Inbound Connector im O365 weiter

Ausgehend:
1. Der User übergibt (mit Outlook/OWA) an O365
2. O365 übergibt es mit dem Outbound Connector an den OnPrem NSP
3. Der NSP liefert es aus.
Dazu muss dann auch der SPF und DKIM für die Domain geändert werden.

Bleibt aber trotzdem das Problem aus dem ersten Post. Mails, die aus dem internen Netz per Outlook oder OWA an O365 gesendet werden kommen ja von der gleichen externen IP, die auch der NSP hat. Dadurch funktioniert dann der Schritt 2 nicht, weil der Connector Mails von dieser IP ja nicht an den NSP "zurück" gibt.

 

[ffischer]

Hallo,
ja genau so sollte es passen.

Outlook reden per MAPI over HTTPS btw, OWA per HTTPS und Mobilgeräte per ActiveSync, sprich direkt mit dem MS365 Exchange.
Wenn die die Mails schicken geht das direkt auf den MS365 und nicht zum NSP.

Änderungen SPF ist korrekt.
DKIM nein die Domain (deinedomain.tld) Signatur bleibt ja die liegt ja auf der Domäne und nicht auf einer MS365 Domäne.

Somit gehen Interne Mails nicht über den NSP.

 

[NicoDiehl]

> Somit gehen Interne Mails nicht über den NSP.

Die intern zu intern ja, korrekt, aber die intern zu extern müssen ja über den NSP für S/MIME und Disclaimer. Und da ist eben das Problem.

 

[ffischer]

korrekt die gehen über den NSP
also muss im MS365 Sendeconnector der NSP angegeben werden.

Wie gesagt und der Kollege ..

Client => Exchange/MS365 => NSP =====> Empfänger

Versender Extern ==> NSP => Exchange/MS365 =====> Client/OWA/EAS/Outlook

 

[NicoDiehl]

Ja, hab ich verstanden ;-)

Aber, wie ich geschrieben habe:
In der Transportregel im Exchange Online muss ja eine Ausnahme "Verwende den Connector außer die Sender-IP ist <IP des NSP>" eingestellt werden.
Nun haben wir nur eine Externe IP Adresse und die ist demnach natürlich auch diese IP unter der der NSP bei Microsoft ankommt.
Allerdings haben ja auch Mails, die von innerhalb unseres Netzes (per Outlook, OWA) an O365 gehen diese IP als Absender, was dazu führt, dass nur Mails, die von Extern (Homeffice, Handy) zu MS eingeliefert werden, über den NSP laufen.

Grüße
Nico

 

[lukas]

Änderungen SPF ist korrekt.
DKIM nein die Domain (deinedomain.tld) Signatur bleibt ja die liegt ja auf der Domäne und nicht auf einer MS365 Domäne.

Doch, DKIM sollte auch geändert bzw. zusätzlich hinzugefügt werden, da der NSP seine eigene DKIM-Signatur aufträgt (sofern man die Aktion in seinen Regeln nutzt, was definitiv Sinn macht).
Ausserdem bekommt man aus M365 den privaten key nicht exportiert.

In der Transportregel im Exchange Online muss ja eine Ausnahme "Verwende den Connector außer die Sender-IP ist <IP des NSP>" eingestellt werden.

Kannst du mal die konkrete Seite in der PDF dazu nennen? Spontan wüßte ich jetzt keine Stelle wo eine "außer die IP ist" in die Transportregel rein müsste.

 

[ffischer]

Ihr Hostet den NSP onPremise, sprich Installation als vm irgend wo in der Firma.
vom dortigen ISP gibt es eine feste IP Adresse.

Was hat die IP mit Microsoft zu tun ?

aktuell ist der MX so wie: deintennantbeims365-3987ds.mail.protection.outlook.com mit der IP Adresse 104.47.11.88

dein NSP vor Ort im Netz der Firma am ISP der (Telekom,Vodafone usw) 64.48.99.36

aktuell zeigt der MX auf die der MS365
neu müsste dann sein auf die 64.48.99.36
dann nimmt der NSP diese an.

er schickt die dann auf deintennantbeims365-3987ds.mail.protection.outlook.com weiter.

habe gerade kein Exch.MS365 zur Hand, erst später, aber wenn das genau so ist beim Sendeconnector wie beim normalen Exch. onPremise, entferne ich alle Sendekonnectoren und füge nur einen neuen hinzu der zum NSP verweist,
am NSP gebe ich dann an das NSp das direkt per MX versendet.

aber vll. versteh ich gerade dein Konstrukt nicht.

 

[NicoDiehl]

@lukas: Das steht auf Seite 18:

8. Klicken Sie Ausnahme hinzufügen und dann Absender sowie IP liegt in einem dieser Bereiche oder stimmt genau überein mit.
9. Fügen Sie die von NoSpamProxy genutzte IP-Adresse hinzu, klicken Sie OK und dann Speichern.

@ffischer:
Laut Anleitung erstelle ich im 365 einen Sendeconnector, der alle ausgehenden Mails an den NSP weiterleitet.
Dieser greift laut Anleitung "Nur, wenn ich eine Transportregel eingerichtet habe, die Nachrichten an diesen Konnektor umleitet."
In der vorgegebenen Transportregel gibt es die Ausnahme die ich oben an lukas geschrieben habe.
Das führt dazu, dass Mails von innerhalb unseres Netzes von dieser Regel ignoriert werden...

Ich könnte mir vorstellen, dass diese Ausnahme nur für den NSP in der Cloud Sinn macht, aber das steht halt nicht dabei..

 

[lukas]

Mhh interessant, kann ich ehrlich gesagt spontan auch nicht einordnen. In der Webbasierten Anleitung die du verlinkt hast gibt es diese Ausnahme jedoch nicht. Genau so wie es da im Screenshot dargestellt ist habe ich meine Transportregel auch eingestellt und sie tut, was sie soll.

Wobei die Clients wie Outlook und OWA ja nichtsdestotrotz direkt mit M365 sprechen und daher als Absender nicht die lokale IP-Adresse sondern die von Microsoft auftauchen sollte wodurch es nicht in diese Ausnahme läuft. Diese Ausnahme würde also dann greifen, wenn du im internen Netzwerk irgendwelche Server, Dienste oder Geräte hättest die Mails über den M365 als SMTP versendet.
Warum diese Mails dann nicht über den NSP sondern direkt isn Netz gehen sollten? Man weiss es nicht.

 

[NicoDiehl]

Ich habe mal die exception raus genommen, scheint bis jetzt kein Problem zu sein...

Danke erstmal