Microsoft on teatanud Basic authentication'i kasutuselt kõrvaldamisest Exchange Online'i SMTP AUTH-is. Esimesena lähevad rikki seadmed, mille seadistamist keegi enam ei mäleta: skannerid, multifunktsionaalsed printerid ja vanad rakendusserverid, kuhu on veebivormi kaudu sisestatud postkasti parool. Kasutuselt kõrvaldamise ajakava on muutunud, seega vaadake kehtivaid tähtaegu Microsofti viimasest teadaandest, mitte ei looda ühegi ajaveebipostituse kuupäevale, sealhulgas sellele. Inventeerimistöö on sama, olenemata kuupäevast.
Miks see auk on veel lahti
Basic authentication on Exchange Online'is juba välja lülitatud Exchange ActiveSyncil, POP-il, IMAP-il, Remote PowerShellil, EWS-il, OAB-l, Autodiscover'il ja Outlooki klientidel. SMTP AUTH jäeti puutumata sinna, kus seda kasutati, ja lülitati välja üürnikes (tenant), kus seda ei kasutatud.
Microsofti analüüsi järgi kasutab üle 97 protsendi credential stuffing'u rünnakutest ja üle 99 protsendi password spray rünnakutest legacy authentication'it. Vt juhendit legacy authentication'i blokeerimiseks.
SMTP AUTH-i kasutavad POP3- ja IMAP4-kliendid, kes peavad ka saatma, ning rakendused, aruandlusserverid ja multifunktsionaalsed seadmed, mis genereerivad kirju.
Leidke, mis seda veel kasutab
Võib juhtuda, et te ei leia midagi. Kui security defaults on sisse lülitatud, on SMTP AUTH Exchange Online'is juba keelatud. Samuti on see keelatud organisatsioonidel, mis loodi pärast 2020. aasta jaanuari, välja arvatud juhul, kui keegi on selle postkastipõhiselt lubanud.
Muul juhul alustage sisselogimislogidest. Minge Microsoft Entra admin center'is asukohta Entra ID > Monitoring & health > Sign-in logs, lisage veerg Client App ja filtreerige legacy authentication'i protokollide järgi. Korrake sama vahelehel User sign-ins (non-interactive), sest seadmed logivad interaktiivselt sisse harva. Triaaži aitab teha töövihik Sign-ins using legacy authentication.
Seejärel vaadake postkaste. Postkastipõhised sätted on ülimuslikud kogu organisatsiooni sätte ees, seega koostage loend postkastidest, kus SMTP AUTH on selgesõnaliselt lubatud:
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}
Tühi väärtus tähendab, et postkast järgib organisatsiooni sätet. Kontrollige seda käsuga Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Seejärel vaadake üle printeri "scan to email" leht, ERP-i teavitusseaded, seire- ja varundustööriistad ning kõik ajastatud skriptid, mis saadavad aruandeid.
Siduge iga leid omanikuga ning kirjutage üles saatja aadress, port, see, kas saatjat majutab kolmas osapool, ja see, kas adressaadid on sisemised või välised. Neid fakte on vaja asenduslahenduse valimiseks.
Kuhu iga saatja tuleks üle viia
Õige siht sõltub sellest, mida saatja suudab, kus ta töötab ja kellele ta kirju saadab.
| Saatja | Üleminek | Kolmanda osapoole majutatud? | Märkused |
|---|---|---|---|
| OAuth'i toetav rakendus | Client SMTP submission koos OAuth'iga | Toetatud | Port 587, TLS 1.2 või 1.3, litsentseeritud postkast |
| Ainult sisemised teavitused | High Volume Email | Toetatud | Port 587, HVE konto |
| Sisemised adressaadid, autentimine pole võimalik | Direct Send | Toetatud | Port 25, uuendage SPF-i |
| Sisemised ja välised adressaadid | Azure Communication Services Email | Microsofti võrdluses katmata | Microsofti soovitus selle juhtumi jaoks |
| Seade ilma OAuth'ita, teie võrgus | SMTP relay konnektori kaudu | Ei toetata | Port 25, sertifikaat või staatiline IP |
| Kohandatud skript või omaarendus | OAuth 2.0 või Graph API | Teie kood | Muutke koodi |
Microsoft soovitab OAuth'i client SMTP submission'i jaoks ning osutab HVE-le ainult sisemise posti ja Azure Communication Services Email'ile sisemise ja välise posti jaoks. Kui teil on on-premises meiliserver, saate relee teha ka selle kaudu, kasutades selle vastu kas Basic authentication'it või anonüümset releed (mitte open relay't).
Kontrollige kõigepealt mahtu. OAuth'iga saatmine on piiratud 10 000 adressaadiga päevas ja 30 sõnumiga minutis. SMTP relay'le need piirangud ei kehti, kuigi sellel on omad mõistlikud piirangud, ja HVE-l puuduvad sisemise posti puhul adressaatide ja sõnumite kiiruse piirangud.
Printerid ja skannerid
Kontrollige kõigepealt püsivara, sest tootja uuendus võib lisada OAuth'i. Kui mitte, on tavaliseks lahenduseks konnektoripõhine SMTP relay. See ei vaja litsentseeritud postkasti, autentib TLS-sertifikaadi (soovitatav) või staatilise avaliku IP-aadressi abil, mida ei jaga ükski teine organisatsioon, ning kasutab porti 25 teie MX-lõpp-punkti vastu.
Relay ei salvesta sõnumeid kausta Sent Items ega mööda anti-spam'i filtritest, seega võidakse kahtlane post filtreerida. Microsoft soovitab lisada SPF-kirje kirje, ja kirjet saate üle vaadata meie DMARC-i ja SPF-i kontrollijaga. Seade, mille vaikeport on 465, ei toeta TLS-i versioone, mida client SMTP submission nõuab, ja seade ilma TLS 1.2-ta ei saa seda üldse kasutada.
ERP-süsteemid ja muud rakendused
Line-of-business rakendused, näiteks ERP, on kõige keerulisemad, sest meilikoodi omab tarnija. Küsige, kas toode toetab SMTP jaoks OAuth 2.0 või Graph API-t. Kui ei, on varulahenduseks konnektoriga relay, eeldusel et rakendus töötab teie enda võrgus.
Kui tarnija majutab rakendust ise, relay'd kasutada ei saa: Microsofti tabelis on SMTP relay ainus meetod, mis ei toeta kolmanda osapoole majutatud saatjaid. Tarnija saab kasutada client SMTP submission'it koos OAuth'iga, HVE-d (kui post läheb ainult sisemistele adressaatidele) või Azure Communication Services Email'i. Direct Send töötab majutatud saatjatega samuti, kuid on autentimata, seega uuendage oma SPF-kirjet, et lubada tarnijal saata teie domeeni nimel.
Kui rakendus saadab muult aadressilt kui sisse logiv postkast, andke talle Send As õigus. Ilma selleta tagastatakse sõnumid veateatega 5.7.60 SMTP; Client doesn't have permissions to send as this sender.
Skriptid
Teie hallatavate skriptide jaoks nimetab Microsoft autenditud posti alternatiivina Graph API-t. Teise võimalusena saate implementeerida OAuth 2.0 IMAP-i, POP-i või SMTP lõpp-punktide vastu.
Kust alustada
- Tõmmake Entra sisselogimislogidest välja legacy sisselogimised, nii interaktiivsed kui ka mitteinteraktiivsed, ja koostage loend postkastidest, kus
SmtpClientAuthenticationDisabledon$false. - Nimetage igale saatjale omanik ning kirjutage üles tema adressaadid (sisemised või välised), port, TLS-i tugi ja see, kas teda majutab kolmas osapool.
- Valige siht ülaltoodud tabelist, testige ühte seadet iga tüübi kohta ja lülitage iga seade ümber alles pärast edukat testsõnumit.
- Pärast migratsiooni käivitage
Set-TransportConfig -SmtpClientAuthenticationDisabled $true. Postkast, mille väärtus on endiselt$false, tühistab selle, seega seadke iga selline käsugaSet-CASMailboxväärtusele$null(järgib organisatsiooni sätet) või$true. Käivitage uuesti filter-eq $false, et tõendada, et ühtegi ei ole järel, ning kinnitage organisatsiooni väärtus käsugaGet-TransportConfig. - Looge Conditional Access poliitika, mis blokeerib legacy authentication'i. Seadke see esmalt režiimi Report-only ning jätke välja vähemalt üks hädaabikonto.
Kui inventuur toob välja rohkem, kui jõuate õigeks ajaks üle viia, aitab meie konsultatsioonimeeskond hindamise ja ülemineku kavandamisega.
