Revan 14 Geschrieben 25. November 2019 Melden Teilen Geschrieben 25. November 2019 Hallo, ich möchte an unserem Exchange 2013 auf Server 2012 die Header Firewall einschalten. Wir haben nur einen Send-Connector mit Namen "Exchange Default", also verwende ich diesen Befehl: Get-SendConnector | Remove-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing Oder auch diesen: Get-SendConnector -identity "Exchange Default" | Remove-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing Bei der Ausführung gibt es diese Warnung: WARNUNG: Der Zugriffssteuerungseintrag für das Objekt "CN=Exchange Default,CN=Connections,CN=Exchange Routing Group (...),CN=Routing Groups,CN=Exchange Administrative Group (...),CN=Administrative Groups,CN=...,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=...=local" für Attribut "ExtendedRight (ObjectType: ...)" kann nicht entfernt werden, da er nicht vorhanden ist. Dennoch werden mir im Header die Routing Informationen angezeigt. Könnte mir jemand einen Tip geben warum es nicht funktioniert? Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 Leg doch einfach mal nen neuen sende connector an. ;) Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 26. November 2019 Autor Melden Teilen Geschrieben 26. November 2019 Mit einem neuen Connector hat das aktivieren geklappt. Vielen Dank für den Tip. Warum das mit dem alten Connector nicht geklappt hat würde ich aber trotzdem gerne erfahren. Leider sehe ich im Submitting Host aber immer noch die interne IP des Servers. Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 Welches ist denn der Submitting Host? Deiner? Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 26. November 2019 Autor Melden Teilen Geschrieben 26. November 2019 Ja, es geht ja um den Send Connector Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 Von wo nach wo schickst du und wie und was kontrollierst du? Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 26. November 2019 Autor Melden Teilen Geschrieben 26. November 2019 Ich schicke eine Mail von meinem internen Exchange Konto zu einem privaten O365 Konto und prüfe den Header der empfangenen Mail hier: https://mha.azurewebsites.net/ Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 Hast du den alten Sendeconnector denn gelöscht? Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 26. November 2019 Autor Melden Teilen Geschrieben 26. November 2019 Deaktiviert Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 und seit dem gibts keine Änderung? Das kann schon einen Moment dauern, nachdem man die Rechte gesetzt hat. Im Zweifel hilft ein Neustart des Transportdienstes. Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 26. November 2019 Autor Melden Teilen Geschrieben 26. November 2019 Nein, leider nicht. Habe jetzt auch mal den Transport Service neu gestartet. Hat aber auch nicht geholfen. Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. November 2019 Melden Teilen Geschrieben 26. November 2019 Wieviele Header siehst du denn in der Webseite? Ich kann das grad nur bedingt nachvollziehen. ;) Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 27. November 2019 Autor Melden Teilen Geschrieben 27. November 2019 Entschuldige, was meinst du damit? Ein Header, 5 Hops, im ersten Hop steht die interne IP des sendenden Exchange Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 27. November 2019 Melden Teilen Geschrieben 27. November 2019 und der zweite ist dann deine externe IP? Du bist dir sicher, dass du den Befehl korrekt ausgeführt hast? Ich kann den Fehler nicht nachvollziehen. Da ich das gerade bei einem anderen Kunden (Exchange 2019 Migration) umgesetzt habe, kann ich sagen, dass es prinzipiell funktioniert. Wenn es bei dir nicht geht, dann kontrollier doch einfach mal, ob die Rechte tatsächlich entzogen wurden. :) Zitieren Link zu diesem Kommentar
Revan 14 Geschrieben 27. November 2019 Autor Melden Teilen Geschrieben 27. November 2019 (bearbeitet) Ja genau, der zweite ist die externe IP. Get-SendConnector "Internet" | Get-ADPermission | Where-Object { $_.extendedrights -like "*routing*" } | fl user User : domain\Exchange Servers User : MS Exchange\Partner Servers User : MS Exchange\Hub Transport Servers User : MS Exchange\Edge Transport Servers User : MS Exchange\Externally Secured Servers User : MS Exchange\Legacy Exchange Servers Sollte so passen oder? Noch mal entfernen schlägt jetzt wieder fehl mit der gleichen Fehlermeldung wie aus Post 1 Ich hab testweise die Berechtigung wieder erteilt. Get-SendConnector "Internet" | Add-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing Jetzt bekomme ich in Hop1 den fqdn des Exchange, in Hop2 den fqdn + interne IP, in Hop3 den externen hostnamen + interne ip und in Hop4 den externen hostnamen + externe ip >Get-SendConnector "Internet" | Get-ADPermission | Where-Object { $_.extendedrights -like "*routing*" } | fl user zeigt jetzt: User : NT-AUTORITÄT\ANONYMOUS-ANMELDUNG User : domain\Exchange Servers User : MS Exchange\Partner Servers User : MS Exchange\Hub Transport Servers User : MS Exchange\Edge Transport Servers User : MS Exchange\Externally Secured Servers User : MS Exchange\Legacy Exchange Servers Es ändert sich also schon etwas. Ich dachte allerdings das die interne IP gar nicht mehr mitgesendet wird wenn das Recht entzogen wurde bearbeitet 27. November 2019 von Revan Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.