SMTP basic auth ile hâlâ posta gönderen tüm cihazları bulun

Microsoft, Exchange Online'daki SMTP AUTH için Basic authentication desteğinin kaldırılacağını duyurdu. İlk bozulacak olanlar da kimsenin yapılandırdığını hatırlamadığı cihazlar: tarayıcılar, çok işlevli yazıcılar ve bir web formuna posta kutusu parolası yazılmış eski uygulama sunucuları. Kaldırma takvimi güncellendi. Bu yüzden güncel kilometre taşları için bu yazı da dahil olmak üzere bir blog yazısındaki tarihe güvenmek yerine Microsoft'un son duyurusuna bakın. Hangi tarih olursa olsun envanter çalışması aynıdır.

Bu konu neden hâlâ açık

Exchange Online'da Basic authentication; Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover ve Outlook istemcileri için zaten kapatılmıştı. SMTP AUTH ise kullanıldığı yerlerde dokunulmadan bırakıldı, kullanılmadığı tenant'larda devre dışı bırakıldı.

Microsoft'un legacy authentication'ın engellenmesine ilişkin rehberindeki analizine göre credential stuffing saldırılarının yüzde 97'sinden fazlası ve password spray saldırılarının yüzde 99'undan fazlası legacy authentication kullanıyor.

SMTP AUTH'u, posta göndermesi gereken POP3 ve IMAP4 istemcileri ile posta üreten uygulamalar, raporlama sunucuları ve çok işlevli cihazlar kullanır.

Hâlâ kullananları bulun

Hiçbir şey bulamayabilirsiniz. security defaults etkinse Exchange Online'da SMTP AUTH zaten devre dışıdır. Ocak 2020'den sonra oluşturulan kuruluşlarda da, biri posta kutusu bazında etkinleştirmediyse devre dışıdır.

Aksi halde sign-in loglarıyla başlayın. Microsoft Entra admin center'da Entra ID > Monitoring & health > Sign-in logs yolunu izleyin, Client App sütununu ekleyin ve legacy authentication protokollerine göre filtreleyin. Cihazlar nadiren etkileşimli oturum açtığı için aynı işlemi User sign-ins (non-interactive) sekmesinde de tekrarlayın. Sign-ins using legacy authentication workbook'u ön değerlendirmede yardımcı olur.

Ardından posta kutularına bakın. Posta kutusu bazındaki ayarlar kuruluş genelindeki ayarı geçersiz kıldığı için SMTP AUTH'un açıkça etkinleştirildiği kutuları listeleyin:

$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

Boş değer, posta kutusunun kuruluş ayarını izlediği anlamına gelir. Bunu Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled ile kontrol edin. Sonra yazıcının "scan to email" sayfasına, ERP'nin bildirim ayarlarına, izleme ve yedekleme araçlarına ve rapor gönderen zamanlanmış tüm betiklere bakın.

Her bulguyu bir sahibiyle eşleştirin; gönderen adresi, portu, göndericiyi üçüncü bir tarafın barındırıp barındırmadığını ve alıcıların dahili mi harici mi olduğunu not edin. Doğru değişimi seçmek için bu bilgilere ihtiyacınız olacak.

Her biri neye geçmeli

Doğru hedef; göndericinin neler yapabildiğine, nerede çalıştığına ve kime posta gönderdiğine bağlıdır.

Microsoft, Client SMTP submission için OAuth'u önerir. Yalnızca dahili posta için HVE'yi, dahili ve harici posta için Azure Communication Services Email'i işaret eder. On-premises bir posta sunucunuz varsa, ona Basic authentication ile veya anonim relay ile (open relay değil) relay yapabilirsiniz.

Önce hacmi kontrol edin. OAuth ile gönderim günde 10.000 alıcı ve dakikada 30 mesajla sınırlıdır. SMTP relay bu sınırlara tabi değildir, ancak kendi makul sınırları vardır. HVE'de ise dahili posta için alıcı veya mesaj hızı sınırı yoktur.

Yazıcılar ve tarayıcılar

Önce firmware'i kontrol edin, çünkü üretici güncellemesi OAuth desteği ekleyebilir. Eklemediyse olağan çözüm connector tabanlı SMTP relay'dir. Lisanslı posta kutusu gerektirmez, TLS sertifikasıyla (önerilen) veya başka bir kuruluşla paylaşılmayan statik bir genel IP ile kimlik doğrular ve MX endpoint'inize karşı port 25'i kullanır.

Relay, Sent Items'a kayıt yapmaz ve anti-spam denetimini atlamaz. Bu nedenle şüpheli postalar filtrelenebilir. Microsoft bir SPF kaydı girişi eklenmesini önerir; kaydı DMARC ve SPF denetleyicimizle inceleyebilirsiniz. Varsayılan olarak port 465 kullanan bir cihaz, Client SMTP submission'ın gerektirdiği TLS sürümlerini desteklemez. TLS 1.2 desteği olmayan bir cihaz ise bunu hiç kullanamaz.

ERP sistemleri ve diğer uygulamalar

ERP gibi iş kolu uygulamaları en zor olanlardır, çünkü posta koduna üretici sahiptir. Ürünün SMTP için OAuth 2.0'ı veya Graph API'yi destekleyip desteklemediğini sorun. Desteklemiyorsa, uygulama kendi ağınızda çalışıyorsa yedek çözüm connector relay'dir.

Uygulamayı üretici barındırıyorsa relay seçeneği elenir: Microsoft'un tablosunda SMTP relay, üçüncü taraf barındırılan göndericileri desteklemeyen tek yöntem olarak geçer. Üretici OAuth ile Client SMTP submission'ı, posta yalnızca dahili alıcılara gidiyorsa HVE'yi veya Azure Communication Services Email'i kullanabilir. Direct Send de barındırılan göndericiler için çalışır, ancak kimlik doğrulamasızdır. Bu nedenle üreticinin alan adınız adına posta göndermesine izin vermek için SPF kaydınızı güncelleyin.

Uygulama, oturum açan posta kutusundan farklı bir adres olarak gönderiyorsa Send As izni verin. İzin olmazsa mesajlar şu hatayla geri döner: 5.7.60 SMTP; Client doesn't have permissions to send as this sender.

Betikler

Kontrolünüzdeki betikler için Microsoft, kimliği doğrulanmış posta gönderimi için alternatif olarak Graph API'yi gösterir. Alternatif olarak IMAP, POP veya SMTP endpoint'lerine karşı OAuth 2.0 uygulayabilirsiniz.

Nereden başlamalı

1. Entra sign-in loglarından, etkileşimli ve etkileşimsiz olarak legacy oturum açmaları çekin ve SmtpClientAuthenticationDisabled değeri $false olan posta kutularını listeleyin.
2. Her gönderen için bir sahip belirleyin; alıcılarını (dahili veya harici), portunu, TLS desteğini ve bir üçüncü tarafça barındırılıp barındırılmadığını kaydedin.
3. Yukarıdaki tablodan bir hedef seçin, her cihaz türünden bir cihazı test edin ve her birini yalnızca başarılı bir test mesajından sonra geçirin.
4. Geçişten sonra Set-TransportConfig -SmtpClientAuthenticationDisabled $true komutunu çalıştırın. Hâlâ $false olan bir posta kutusu bunu geçersiz kılar. Bu nedenle her birini Set-CASMailbox ile $null (kuruluşu izlesin) veya $true yapın. Hiçbirinin kalmadığını kanıtlamak için -eq $false filtresini yeniden çalıştırın ve kuruluş değerini Get-TransportConfig ile doğrulayın.
5. Legacy authentication'ı engelleyen bir Conditional Access politikası oluşturun. Önce Report-only olarak ayarlayın ve en az bir acil durum hesabını hariç tutun.

Envanter, zamanında geçirebileceğinizden fazlasını ortaya çıkarırsa danışmanlık ekibimiz değerlendirme ve geçiş planı konusunda yardımcı olabilir.