Microsoft’tan EWSAllowedAppIDs İçin Güvenli Test Rehberi

Microsoft Exchange ekibi, Exchange Online’da Exchange Web Services (EWS) kullanımının sona erdirilmesine yönelik geçiş sürecinde, yöneticilerin EWSAllowedAppIDs yapılandırmasının doğru çalıştığını güvenli şekilde doğrulayabilmesi için yeni bir test rehberi yayımladı.

20 Ağustos 2026 tarihli rehberde, özellikle EWSAllowedAppIDs ile benzer isimlere sahip eski EWS erişim kontrollerinin birbirine karıştırılmaması gerektiği vurgulanıyor.

EWSAllowedAppIDs ne işe yarıyor?

EWSAllowedAppIDs, Exchange Online içerisinde EWS erişimini uygulama kimliği (Application ID / Client ID) üzerinden kontrol eden tenant seviyesinde bir izin mekanizması olarak kullanılıyor.

EWS etkin durumdayken bu listeye bir veya daha fazla Application ID eklenirse, yalnızca listede bulunan uygulamaların EWS üzerinden erişimine izin veriliyor.

Microsoft, bu kontrolün özellikle EWS kullanımının sonlandırılması sürecinde EWS erişimine geçici olarak ihtiyaç duyan uygulamaların doğrulanması için kullanılabileceğini belirtiyor.

EWSAllowList ile EWSAllowedAppIDs aynı şey değil

Microsoft’un özellikle dikkat çektiği konulardan biri, benzer isimlere sahip iki farklı erişim mekanizmasının birbirine karıştırılması.

EWSAllowedAppIDs, uygulama kimliğine dayalı yeni EWS kontrolü olarak çalışıyor.

Buna karşılık EWSAllowList ve EWSBlockList, eski EwsApplicationAccessPolicy yapısının parçası olan User-Agent tabanlı kontroller olarak görev yapıyor. Bu eski yapı yalnızca EWS trafiğini değil, REST isteklerini de etkileyebiliyor.

Dolayısıyla bir uygulamanın EWSAllowedAppIDs testi başarıyla sonuçlansa bile bu durum, ayrıca kullanılan User-Agent tabanlı politikanın doğru yapılandırıldığı anlamına gelmiyor. Microsoft’un önerisi, iki erişim katmanının birbirinden bağımsız olarak test edilmesi.

Test öncesinde hangi şartlar gerekiyor?

Microsoft’a göre güvenilir bir pozitif ve negatif test için şu şartların sağlanması gerekiyor:

• Uygulamanın OAuth token alabilmesi
• Uygulamaya EWS application permission verilmesi
• Tenant genelinde admin consent işleminin tamamlanmış olması
• Test sırasında EWSEnabled değerinin True olması
• Test mailbox’ının Inbox klasöründe en az bir öğe bulunması
• Pozitif testte Application ID’nin listede bulunması
• Negatif testte Application ID’nin listeden çıkarılması
• Her liste değişikliğinden sonra yapılandırmanın yayılması için en az 24 saat beklenmesi

Microsoft, mümkünse testlerin doğrudan üretim tenant’ında değil, test tenant’ında gerçekleştirilmesini öneriyor.

Çünkü üretim ortamında bir Application ID’nin listeden çıkarılması, ilgili uygulamanın EWS erişimini kaybetmesine neden olabilir.

Erişim İzin Testi Nasıl Yapılıyor?

İlk aşamada Exchange Online PowerShell bağlantısı kuruluyor:

Connect-ExchangeOnline

Ardından mevcut EWS durumunun ve Application ID listesinin yedeği alınmalı:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Kontrollü test için Microsoft, EWSEnabled değerinin geçici olarak $null yapılmasını öneriyor:

Set-OrganizationConfig -EWSEnabled $null

Daha sonra mevcut Application ID listesi korunarak test edilecek uygulamanın ID’si listeye ekleniyor:

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs
$updated = @($current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ }; $appId) | Select-Object -Unique
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Liste kontrol edildikten sonra:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Microsoft, EWSAllowedAppIDs değişikliklerinin Exchange Online tarafında yayılmasının 24 saate kadar sürebileceğini belirtiyor.

Sonrasında EWS tekrar etkinleştiriliyor:

Set-OrganizationConfig -EWSEnabled $true

Bu değişikliğin etkili olması için yaklaşık bir saat beklenmesi gerekiyor.

Ardından Microsoft tarafından sağlanan Test-EWSAppAccess.ps1 script’i ile uygulamanın mailbox’a erişimi test ediliyor:

.\Test-EWSAppAccess.ps1 -AppId $appId -TenantId $tenantId -Mailbox $mailbox -SecretKey $secretKey

Başarılı testte uygulamanın mailbox’a erişebildiğini belirten bir sonuç alınması ve $LASTEXITCODE değerinin 0 olması bekleniyor.

Erişim Engelleme Testi Nasıl Yapılıyor?

İkinci aşamada yalnızca test edilen Application ID listeden çıkarılıyor. Diğer uygulamaların mevcut izinlerinin korunması gerekiyor:

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs
$updated = $current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ -and $_ -ne $appId }
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Application ID’nin gerçekten kaldırıldığı doğrulandıktan sonra en az 24 saat beklenmesi gerekiyor.

Ardından aynı test script’i tekrar çalıştırılıyor. Başarılı bir negatif test sonucunda uygulamanın mailbox’a erişememesi ve işlemin exit code 1 ile sonuçlanması bekleniyor.

Microsoft, Application ID kaldırıldıktan hemen sonra yapılan bir testte erişimin hâlâ başarılı olmasının, yapılandırmanın yanlış olduğu anlamına gelmeyebileceğini belirtiyor. Bunun nedeni Exchange Online tarafındaki yapılandırma önbelleklemesi olabilir.

EWS’yi hızlı şekilde yeniden etkinleştirme

Test sırasında beklenmeyen bir sonuç alınması ve EWS erişiminin hızlı şekilde geri açılması gerekirse Microsoft önemli bir ayrıntıya dikkat çekiyor.

EWSAllowedAppIDs değişiklikleri yaklaşık 24 saat, EWSEnabled değişiklikleri ise yaklaşık 1 saat içerisinde etkili oluyor.

Ancak EWSEnabled değeri $null olduğunda EWSAllowedAppIDs kontrolü göz ardı ediliyor.

Bu nedenle EWS’yi kısıtlamasız şekilde yeniden etkinleştirmenin en hızlı yolu:

Set-OrganizationConfig -EWSEnabled $null

Bu değişiklikten yaklaşık bir saat sonra EWS tenant genelinde yeniden sınırsız şekilde kullanılabilir hale geliyor.

EWSEditor ile alternatif test

Microsoft, yöneticiler ve geliştiriciler için EWSEditor aracının da kullanılabileceğini belirtiyor.

Bu araç, test mailbox’ına gerçek bir EWS API çağrısı gerçekleştirilmesine olanak sağlıyor. Böylece doğrulanan uygulamanın kimliği kullanılarak daha gerçekçi bir EWS erişim testi yapılabiliyor.

Ancak OAuth uygulaması, EWS izinleri, admin consent, test mailbox’ı ve yapılandırma değişikliklerinin yayılması için gereken bekleme süresi yine gerekiyor.

Microsoft’tan önemli uyarılar

Microsoft, test sırasında bazı yaygın hatalardan kaçınılmasını öneriyor:

• Application ID çıkarıldıktan hemen sonra negatif test yapmak
• Mevcut Application ID listesini korumadan listenin tamamını değiştirmek
• Inbox’ı boş olan bir mailbox ile test yapmak
• OAuth, permission, consent veya credential problemlerini EWSAllowedAppIDs engellemesi olarak yorumlamak
• EWSAllowList veya EWSBlockList ile EWSAllowedAppIDs yapılarını birbirine karıştırmak
• Sadece REST kullanan bir uygulamayı EWS Application ID listesine eklemek

EWS emekliliği sürecinde kritik ayrım

Microsoft’un verdiği mesajın özeti oldukça net: EWS erişimini uygulama bazında kontrol etmek için EWSAllowedAppIDs kullanılmalı. EWSAllowList ve EWSBlockList ise eski User-Agent tabanlı politika mekanizmasının parçaları olarak ayrıca değerlendirilmelidir.

Özellikle Exchange Online’da EWS’nin kullanımının sonlandırılması yaklaşırken, yalnızca isminde “EWS” geçen bir ayarın EWS retirement istisnası olduğunu düşünmek yanlış yapılandırmalara yol açabilir.

Microsoft, müşterilerin öncelikle uygulamalarının gerçekten EWS kullanıp kullanmadığını belirlemesini, ardından gerekli uygulama kimliklerini kontrollü şekilde EWSAllowedAppIDs üzerinden test etmesini öneriyor.

Kısacası: EWSAllowedAppIDs yeni uygulama-ID tabanlı EWS erişim kapısıdır. EWSAllowList ve EWSBlockList ise eski User-Agent tabanlı erişim politikalarıdır. İki mekanizma birbirinin alternatifi değildir ve ayrı ayrı test edilmelidir.