AuthMechanism 10 och AuthAs Internal: Så klassificerar Exchange leverans i rubriken

Vid analys av skräppost-, spoofing- och e-postflödesfall i Exchange-miljöer är tre rubriker som Exchange stämplar vid mottagning avgörande:

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

AuthAs fastställer hur avsändaren framträdde för transporten. AuthSource anger servern som gjorde bedömningen. AuthMechanism dokumenterar genom vilken mekanism autentiseringen skedde. Tillsammans avgör de om Exchange behandlar ett meddelande som internt eller externt, och denna klassificering får betydande konsekvenser.

Varför klassificeringen är viktig

AuthAs har i praktiken två värden: Internal och Anonymous. Ett meddelande som klassificeras som Internal behandlas annorlunda än extern e-post:

• E-postflödesregler med villkoret ”avsändaren finns utanför organisationen” tillämpas inte.
• Meddelandet får levereras till distributionsgrupper och postlådor som kräver autentiserade avsändare (RequireSenderAuthenticationEnabled).
• Antispam- och antispoofing-kontroller blir mindre strikta eller uteblir; i hybridmiljöer läggs den externa disclaimern inte till och Outlook visar ingen ”Extern”-markering.
• Visningsnamnet löses upp från adressboken och e-postmeddelandet ser ut som intern e-post för mottagarna.

Just därför bör frågan ”AuthAs Internal eller Anonymous?” ställas i början av varje rubrikanalys: Då går det att klarlägga varför ett uppenbart spoofing-meddelande passerade skräppostfiltret eller varför en e-postflödesregel aldrig utlöstes.

AuthMechanism-värdena

Microsoft dokumenterar inte kodningen av AuthMechanism fullständigt offentligt. Två värden är relevanta för felsökning och väl dokumenterade:

Fler värden förekommer i rubriker, men saknar officiell referens. I praktiken räcker distinktionen: 04 innebär verklig Exchange-autentisering, 10 innebär förtroende genom connector-konfiguration.

Vad Externally Secured verkligen innebär

Alternativet ExternalAuthoritative på en Receive Connector säger till Exchange: Någon annan ansvarar för att säkra den här anslutningen, exempelvis en brandvägg, ett dedikerat nätverkssegment eller IPsec. Exchange kontrollerar då inte längre något utan behandlar varje leverans via denna connector som autentiserad och intern, inklusive rätten att använda godtyckliga interna avsändaradresser.

Detta är avsett för ett fåtal scenarier, till exempel en helt betrodd applikationsserver i det egna datacentret. Det blir problematiskt om connectorn pekar på en framförliggande e-postgateway eller ett skräppostfilter i DMZ:en, via vilken även internetpost tas emot. Då får varje externt e-postmeddelande efter leveransen:

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

Konsekvenserna är att externa e-postmeddelanden betraktas som interna, e-postflödesregler för externa avsändare inte tillämpas, spoofing-skyddet för den egna domänen blir verkningslöst och att alla som når gatewayen kan leverera med interna avsändaradresser till mottagare som egentligen kräver autentiserade avsändare.

Hitta berörda connectorer

Exchange Management Shell visar vilka Receive Connectorer som är konfigurerade med ExternalAuthoritative:

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

Kontrollera för varje träff vilka RemoteIPRanges som är angivna och om systemen bakom verkligen behöver detta förtroende. En gateway som endast ska vidarebefordra e-post behöver det inte.

Alternativet för reläscenarier

Om ett system endast ska reläa anonymt via Exchange (skrivare, applikationer, övervakning) är en anonym relay-connector den renare lösningen: anonym leverans plus rätten att leverera till godtyckliga mottagare, men utan Internal-klassificering.

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-post via denna connector förblir AuthAs: Anonymous, genomgår normala kontroller och kan inte utge sig för att ha interna avsändare. ExternalAuthoritative bör reserveras för de system som du medvetet vill ge rätten att använda interna avsändaradresser.

Läs rubriken i sitt sammanhang

Huruvida ett specifikt meddelande har klassificerats som internt eller externt och vilken väg det tog framgår snabbast av den fullständiga rubriken: AuthAs, AuthMechanism och AuthSource tillsammans med Received-kedjan. Mail Header Analyzer på denna webbplats analyserar dessa fält direkt i webbläsaren och markerar hybridklassificeringen i leveransvägen; rubriken lämnar inte webbläsaren.

Hur klassificeringen bevaras mellan Exchange Online och OnPrem i hybridmiljöer och hur en felaktig tilldelning kan identifieras behandlas i artikeln Intern eller extern? Klassificera Exchange-hybridmeddelanden i rubriken.