AuthMechanism 10 og AuthAs Internal: Slik klassifiserer Exchange innlevering i headeren

Ved analyse av spam-, spoofing- og e-postflytsaker i Exchange-miljøer er tre headerfelt avgjørende, som Exchange setter ved mottak:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource: EX01.example.com
X-MS-Exchange-Organization-AuthMechanism: 10

AuthAs angir hvordan avsenderen fremstod overfor transporten. AuthSource oppgir serveren som foretok vurderingen. AuthMechanism dokumenterer hvilken mekanisme autentiseringen skjedde gjennom. Sammen avgjør de om Exchange behandler en melding som intern eller ekstern, og denne klassifiseringen har betydelige konsekvenser.

Hvorfor klassifiseringen er viktig

AuthAs har i praksis to verdier: Internal og Anonymous. En melding klassifisert som Internal behandles annerledes enn ekstern e-post:

• E-postflytregler med betingelsen «avsender utenfor organisasjonen» gjelder ikke.
• Meldingen kan leveres til distribusjonsgrupper og postbokser som krever autentiserte avsendere (RequireSenderAuthenticationEnabled).
• Anti-spam- og anti-spoofing-kontroller blir mindre strenge eller utelates; i hybridmiljøer legges ikke den eksterne ansvarsfraskrivelsen til, og Outlook viser ingen «Ekstern»-indikasjon.
• Visningsnavnet løses opp fra adresseboken, og e-posten fremstår som intern post for mottakerne.

Derfor bør spørsmålet «AuthAs Internal eller Anonymous?» være først i enhver headeranalyse: Det gjør det mulig å avklare hvorfor en åpenbar spoofing-e-post passerte spamfilteret, eller hvorfor en e-postflytregel aldri ble utløst.

AuthMechanism-verdiene

Microsoft dokumenterer ikke kodingen av AuthMechanism fullstendig offentlig. To verdier er relevante og godt dokumentert for feilsøking:

Andre verdier forekommer i headere, men uten offisiell referanse. I praksis er skillet tilstrekkelig: 04 betyr faktisk Exchange-autentisering, 10 betyr tillit basert på connector-konfigurasjon.

Hva Externally Secured faktisk betyr

Alternativet ExternalAuthoritative på en Receive Connector forteller Exchange: Noen andre sørger for sikringen av denne forbindelsen, for eksempel en brannmur, et dedikert nettverkssegment eller IPsec. Exchange kontrollerer da ikke lenger noe, men behandler enhver innlevering via denne connectoren som autentisert og intern, inkludert retten til å bruke vilkårlige interne avsenderadresser.

Dette er ment for få scenarioer, for eksempel en fullt ut pålitelig applikasjonsserver i eget datasenter. Det blir problematisk dersom connectoren peker mot en foranliggende e-postgateway eller et spamfilter i DMZ-en, som også mottar internettpost. Da får hver ekstern e-post etter innleveringen:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10

Konsekvensene er at eksterne e-poster anses som interne, e-postflytregler for eksterne avsendere ikke gjelder, spoofing-beskyttelsen for eget domene er virkningsløs, og enhver som når gatewayen, kan levere med interne avsenderadresser til mottakere som egentlig krever autentiserte avsendere.

Finn berørte connectorer

Exchange Management Shell viser hvilke Receive Connectorer som er konfigurert med ExternalAuthoritative:

Get-ReceiveConnector | Where-Object {
  $_.AuthMechanism -match "ExternalAuthoritative"
} | Format-Table Identity, RemoteIPRanges, AuthMechanism, PermissionGroups

Kontroller for hvert treff hvilke RemoteIPRanges som er angitt, og om systemene bak faktisk trenger denne tilliten. En gateway som bare skal videresende e-post, trenger den ikke.

Alternativet for relay-scenarioer

Dersom et system bare skal relayere anonymt via Exchange (skrivere, applikasjoner, overvåking), er en anonym relay-connector en ryddigere løsning: anonym innlevering pluss retten til å levere til vilkårlige mottakere, men uten Internal-klassifisering.

New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport `
  -RemoteIPRanges 192.0.2.10 -Bindings 0.0.0.0:25 -Usage Custom -PermissionGroups AnonymousUsers

Get-ReceiveConnector "EX01\Anonymous Relay" | Add-ADPermission `
  -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

E-poster via denne connectoren forblir AuthAs: Anonymous, gjennomgår de vanlige kontrollene og kan ikke utgi seg for å ha interne avsendere. ExternalAuthoritative er forbeholdt systemene du bevisst vil gi rett til å bruke interne avsenderadresser.

Les headeren i sammenheng

Om en konkret melding ble klassifisert som intern eller ekstern, og hvilken vei den kom via, kan raskest leses av i den fullstendige headeren: AuthAs, AuthMechanism og AuthSource sammen med Received-kjeden. Mail Header Analyzer på dette nettstedet analyserer disse feltene direkte i nettleseren og markerer hybridklassifiseringen i leveringsveien; headeren forlater ikke nettleseren.

Artikkelen Intern eller ekstern? Klassifisering av Exchange-hybrid-e-post i headeren beskriver hvordan klassifiseringen bevares mellom Exchange Online og OnPrem i hybridmiljøer, og hvordan feil klassifisering kan gjenkjennes.