Tutorial 19 mnt baca

Panduan Lengkap Microsoft Entra ID dan Conditional Access untuk Tim Helpdesk 2026

Panduan praktis Microsoft Entra ID dan Conditional Access untuk tim helpdesk. Pelajari konfigurasi kebijakan MFA, troubleshooting masalah akses, penggunaan What If tool, serta perubahan penting enforcement 2026.

Editorial Team

Pendahuluan: Mengapa Microsoft Entra ID dan Conditional Access Penting untuk Helpdesk

Kalau kamu bekerja di tim helpdesk, coba ingat-ingat — berapa banyak tiket yang masuk soal "tidak bisa login"? Pasti banyak, kan? Nah, di balik sebagian besar masalah akses itu, ada satu fitur kunci yang perlu kamu pahami: Conditional Access di Microsoft Entra ID.

Microsoft Entra ID — dulu dikenal sebagai Azure Active Directory (Azure AD) — adalah layanan manajemen identitas berbasis cloud dari Microsoft. Ini jadi pusat autentikasi dan otorisasi untuk seluruh ekosistem Microsoft 365 dan aplikasi cloud lainnya. Memahami cara kerjanya bukan lagi sekadar nilai tambah buat tim helpdesk. Ini sudah jadi kompetensi inti.

Kenapa? Karena hampir setiap hari kamu akan berhadapan dengan skenario seperti: pengguna gagal login, MFA tiba-tiba nggak jalan, perangkat ditolak kebijakan keamanan, atau akun terkunci tanpa alasan yang jelas. Dengan pemahaman yang solid tentang Conditional Access, kamu bisa mendiagnosis masalah ini jauh lebih cepat — dan tentu saja, menjaga keamanan organisasi tetap terjaga.

Artikel ini akan membahas Microsoft Entra ID dan Conditional Access secara menyeluruh — mulai dari konsep dasar, konfigurasi kebijakan, troubleshooting masalah umum, sampai perubahan penting di tahun 2026. Jadi, mari kita mulai.

Memahami Arsitektur Microsoft Entra ID

Apa Itu Microsoft Entra ID?

Sederhananya, Microsoft Entra ID adalah layanan manajemen identitas dan akses berbasis cloud. Ia menyediakan autentikasi, otorisasi, dan single sign-on (SSO) untuk aplikasi Microsoft 365, Azure, dan ribuan aplikasi SaaS pihak ketiga. Berbeda dengan Active Directory Domain Services (AD DS) tradisional yang berjalan di server on-premises, Entra ID sepenuhnya beroperasi di cloud dan menggunakan protokol modern seperti OAuth 2.0, OpenID Connect, dan SAML 2.0.

Komponen Utama Microsoft Entra ID

  • Tenant: Instance Entra ID milik organisasimu. Setiap organisasi punya satu tenant yang jadi wadah semua objek identitas — pengguna, grup, aplikasi.
  • Users dan Groups: Objek identitas yang merepresentasikan pengguna dan kelompok dalam organisasi. Grup bisa berupa Security Group atau Microsoft 365 Group.
  • Enterprise Applications: Representasi aplikasi yang terdaftar di tenant, baik aplikasi Microsoft, pihak ketiga dari galeri, maupun aplikasi kustom.
  • App Registrations: Konfigurasi teknis aplikasi yang mendefinisikan bagaimana aplikasi berinteraksi dengan Entra ID (permissions, redirect URIs, credentials).
  • Roles dan Permissions: Sistem kontrol akses berbasis peran (RBAC) yang menentukan siapa boleh mengelola apa di dalam tenant.

Hubungan dengan Active Directory On-Premises

Kenyataannya, sebagian besar organisasi masih menggunakan Active Directory on-premises bersamaan dengan Entra ID. Microsoft Entra Connect (dulu Azure AD Connect) jadi jembatan yang menyinkronisasi identitas dari AD on-premises ke Entra ID. Dalam setup hybrid ini, pengguna punya satu identitas yang bisa dipakai di jaringan lokal maupun cloud.

# Memeriksa status sinkronisasi Microsoft Entra Connect
# Jalankan di server Entra Connect
Get-ADSyncScheduler

# Memaksa sinkronisasi manual
Start-ADSyncSyncCycle -PolicyType Delta

# Memeriksa error sinkronisasi
Get-ADSyncConnectorRunStatus

Satu hal yang sering bikin bingung di helpdesk: perubahan di AD on-premises (misalnya reset password atau perubahan group membership) butuh waktu sinkronisasi sebelum tercermin di Entra ID. Siklus default-nya setiap 30 menit, tapi kamu bisa memicu sinkronisasi delta secara manual kalau situasinya mendesak.

Conditional Access: Mesin Kebijakan Zero Trust

Konsep Dasar Conditional Access

Conditional Access itu, secara sederhana, adalah mesin kebijakan Zero Trust dari Microsoft. Ia mengevaluasi berbagai sinyal sebelum memberikan atau menolak akses ke sumber daya. Logikanya simpel — if-then: jika seorang pengguna ingin mengakses sumber daya tertentu, maka mereka harus memenuhi persyaratan yang sudah ditentukan.

Beberapa contoh skenario:

  • Jika pengguna ingin mengakses Microsoft 365, maka mereka harus menyelesaikan MFA.
  • Jika pengguna login dari luar jaringan kantor, maka perangkat mereka harus compliant dengan kebijakan Intune.
  • Jika pengguna mengakses aplikasi sensitif dari negara yang tidak diizinkan, akses langsung diblokir.

Simpel di permukaan, tapi bisa cukup kompleks kalau sudah banyak kebijakan yang saling bertumpuk.

Sinyal yang Dievaluasi oleh Conditional Access

Conditional Access mengumpulkan dan mengevaluasi berbagai sinyal untuk membuat keputusan akses:

  1. Identitas Pengguna: Siapa yang mencoba mengakses — pengguna tertentu, anggota grup, atau peran direktori.
  2. Lokasi: Dari mana pengguna mengakses — alamat IP, lokasi geografis, atau jaringan terpercaya (named locations).
  3. Perangkat: Status perangkat — apakah terdaftar di Entra ID, compliant dengan kebijakan Intune, atau hybrid joined.
  4. Aplikasi: Aplikasi mana yang diakses — Microsoft 365, aplikasi pihak ketiga, atau aplikasi kustom.
  5. Risiko: Tingkat risiko sign-in dan risiko pengguna yang dihitung oleh Entra ID Protection.
  6. Aplikasi Klien: Jenis aplikasi klien — browser modern, aplikasi mobile, atau legacy authentication.

Tindakan yang Dapat Dilakukan (Grant Controls)

Berdasarkan evaluasi sinyal-sinyal di atas, Conditional Access bisa mengambil beberapa tindakan:

  • Block Access: Memblokir akses sepenuhnya.
  • Grant Access dengan persyaratan:
    • Require multifactor authentication (MFA)
    • Require device to be marked as compliant
    • Require Microsoft Entra hybrid joined device
    • Require approved client app
    • Require app protection policy
    • Require password change
    • Require authentication strength
  • Session Controls: Membatasi akses dalam sesi — misalnya sign-in frequency, persistent browser session, atau Conditional Access App Control.

Konfigurasi Kebijakan Conditional Access: Panduan Langkah demi Langkah

Prasyarat dan Lisensi

Sebelum mulai mengkonfigurasi, pastikan dulu organisasimu punya lisensi yang memadai:

  • Microsoft Entra ID P1: Diperlukan untuk fitur Conditional Access dasar.
  • Microsoft Entra ID P2: Diperlukan untuk fitur berbasis risiko (risk-based policies) dan Entra ID Protection.
  • Peran minimum: Conditional Access Administrator atau Security Administrator.

Jangan sampai sudah konfigurasi panjang lebar, ternyata lisensinya belum mencukupi. Percayalah, itu pernah terjadi (dan cukup memalukan).

Membuat Kebijakan MFA untuk Semua Pengguna

Berikut langkah-langkah membuat kebijakan Conditional Access yang mewajibkan MFA untuk semua pengguna saat mengakses Microsoft 365:

  1. Buka Microsoft Entra admin center (entra.microsoft.com).
  2. Navigasi ke Protection → Conditional Access → Policies.
  3. Klik + New policy.
  4. Beri nama kebijakan, misalnya: "Require MFA for all users - Microsoft 365".
  5. Di bagian Users:
    • Include: All users
    • Exclude: Akun break-glass/emergency access
  6. Di bagian Target resources:
    • Cloud apps: Office 365
  7. Di bagian Grant:
    • Pilih Grant access
    • Centang Require multifactor authentication
  8. Atur Enable policy ke Report-only terlebih dahulu untuk pengujian.
  9. Klik Create.

Penting banget: Selalu gunakan mode Report-only sebelum mengaktifkan kebijakan. Ini memungkinkan kamu memonitor dampak kebijakan tanpa benar-benar memblokir siapa pun. Saya pernah lihat ada admin yang langsung mengaktifkan kebijakan tanpa testing — hasilnya? Seluruh kantor nggak bisa login selama satu jam.

Mengkonfigurasi Named Locations

Named locations memungkinkan kamu mendefinisikan jaringan terpercaya yang bisa digunakan sebagai sinyal dalam kebijakan Conditional Access:

  1. Di Conditional Access, klik Named locations.
  2. Klik + IP ranges location.
  3. Masukkan nama lokasi (misalnya: "Kantor Pusat Jakarta").
  4. Masukkan rentang IP publik kantor dalam notasi CIDR (misalnya: 203.0.113.0/24).
  5. Centang Mark as trusted location jika diperlukan.
  6. Klik Create.
# Membuat Named Location menggunakan Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    displayName = "Kantor Pusat Jakarta"
    isTrusted = $true
    ipRanges = @(
        @{
            "@odata.type" = "#microsoft.graph.iPv4CidrRange"
            cidrAddress = "203.0.113.0/24"
        }
    )
}

New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params

Kebijakan Berbasis Lokasi: Memblokir Akses dari Negara Tertentu

Untuk membatasi akses berdasarkan lokasi geografis, ikuti langkah berikut:

  1. Buat Named Location tipe Countries/Regions yang berisi negara-negara yang diizinkan.
  2. Buat kebijakan Conditional Access baru.
  3. Di bagian Conditions → Locations:
    • Include: Any location
    • Exclude: Named location yang berisi negara yang diizinkan
  4. Di bagian Grant: Pilih Block access.

Kebijakan Kepatuhan Perangkat (Device Compliance)

Untuk memastikan hanya perangkat yang sesuai kebijakan (compliant) yang bisa mengakses sumber daya organisasi:

  1. Pastikan perangkat sudah terdaftar di Microsoft Intune.
  2. Buat compliance policy di Intune yang mendefinisikan standar perangkat (versi OS minimum, enkripsi, antivirus, dan sebagainya).
  3. Buat kebijakan Conditional Access dengan grant control: Require device to be marked as compliant.

Kamu juga bisa mengombinasikan persyaratan — pilih "Require one of the selected controls" (lebih fleksibel) atau "Require all the selected controls" (lebih ketat). Misalnya, mewajibkan MFA atau perangkat compliant, atau MFA dan perangkat compliant. Tergantung seberapa ketat kebijakan keamanan organisasimu.

Troubleshooting Conditional Access: Panduan untuk Helpdesk

Nah, ini bagian yang paling sering kamu butuhkan di lapangan. Mari kita bahas masalah-masalah yang paling umum.

Masalah #1: Pengguna Tidak Bisa Login — "Your sign-in was blocked"

Ini keluhan nomor satu yang diterima helpdesk soal Conditional Access. Pesan error ini muncul ketika satu atau lebih kebijakan memblokir akses pengguna.

Langkah-langkah Diagnosis:

  1. Periksa Sign-in Logs:
    • Buka Entra admin center → Identity → Monitoring & health → Sign-in logs.
    • Cari entri sign-in yang gagal untuk pengguna tersebut.
    • Klik entri tersebut dan pilih tab Conditional Access.
    • Di sini kamu bisa melihat kebijakan mana yang diterapkan (Applied) dan mana yang gagal (Failure).
  2. Gunakan Sign-in Diagnostic:
    • Di halaman detail sign-in, klik Troubleshoot Event di bagian Basic info.
    • Diagnostic akan memberikan penjelasan detail tentang mengapa sign-in gagal.
  3. Periksa detail kegagalan: Perhatikan informasi berikut di tab Conditional Access:
    • Policy Name: Nama kebijakan yang menyebabkan blokir.
    • Result: "Failure" menunjukkan kebijakan menolak akses.
    • Grant Controls: Persyaratan yang tidak dipenuhi pengguna.
# Memeriksa sign-in logs menggunakan Microsoft Graph PowerShell
Connect-MgGraph -Scopes "AuditLog.Read.All"

# Mendapatkan sign-in logs untuk pengguna tertentu (24 jam terakhir)
$userId = "[email protected]"
$startDate = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$userId' and createdDateTime ge $startDate" |
    Select-Object CreatedDateTime, AppDisplayName, Status, ConditionalAccessStatus |
    Format-Table -AutoSize

# Memeriksa detail kebijakan Conditional Access yang diterapkan
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$userId' and conditionalAccessStatus eq 'failure'" -Top 5 |
    ForEach-Object {
        Write-Host "Sign-in pada: $($_.CreatedDateTime)" -ForegroundColor Yellow
        Write-Host "Aplikasi: $($_.AppDisplayName)"
        $_.AppliedConditionalAccessPolicies | ForEach-Object {
            Write-Host "  Kebijakan: $($_.DisplayName) - Hasil: $($_.Result)"
        }
        Write-Host ""
    }

Masalah #2: MFA Tidak Muncul atau Tidak Berfungsi

Pengguna melaporkan bahwa mereka nggak diminta MFA meskipun kebijakan sudah aktif, atau sebaliknya — MFA terus muncul berulang-ulang. Dua-duanya sama menyebalkannya.

MFA Tidak Muncul:

  • Periksa scope kebijakan: Pastikan pengguna atau grup mereka termasuk dalam assignment kebijakan dan tidak dikecualikan (excluded).
  • Periksa trusted locations: Kalau pengguna login dari lokasi terpercaya, kebijakan mungkin dikonfigurasi untuk mengecualikan lokasi tersebut.
  • Periksa sesi yang ada: Kalau pengguna sudah punya sesi aktif, MFA mungkin nggak diminta lagi sampai sesi berakhir. Cek pengaturan Sign-in frequency di session controls.
  • Periksa status kebijakan: Pastikan kebijakan dalam status On, bukan Report-only. Ini kesalahan yang lebih sering terjadi dari yang kamu kira.

MFA Terus Berulang:

  • Token lifetime terlalu pendek: Token yang umurnya terlalu singkat bisa menyebabkan pengguna diminta MFA terlalu sering.
  • Sign-in frequency terlalu ketat: Kalau diatur ke 1 jam misalnya, pengguna akan diminta MFA terus-menerus.
  • Persistent browser session dinonaktifkan: Pengguna harus MFA setiap kali menutup dan membuka browser.
  • Kebijakan saling bertentangan: Dua atau lebih kebijakan yang tumpang tindih bisa menyebabkan perilaku yang nggak terduga.

Masalah #3: Perangkat Tidak Dikenali sebagai Compliant

Pengguna bilang nggak bisa akses sumber daya karena perangkatnya dianggap tidak compliant — padahal mereka yakin perangkatnya sudah sesuai. Ini cukup sering terjadi, jadi jangan langsung percaya klaim pengguna (maaf, tapi memang begitu kenyataannya).

Langkah-langkah Troubleshooting:

  1. Verifikasi status compliance di Intune:
    • Buka Microsoft Intune admin center → Devices → cari perangkat pengguna.
    • Periksa kolom Compliance — Compliant, Not Compliant, atau In Grace Period?
    • Klik perangkat untuk melihat detail ketidakpatuhan — persyaratan mana yang nggak dipenuhi.
  2. Periksa sinkronisasi perangkat:
    • Pastikan perangkat terakhir check-in ke Intune baru-baru ini.
    • Minta pengguna sinkronisasi manual via Company Portal atau Settings → Accounts → Access work or school → Sync.
  3. Periksa registrasi perangkat di Entra ID:
    • Di Entra admin center, buka Identity → Devices → All devices.
    • Cari perangkat pengguna dan verifikasi statusnya (Entra registered, Entra joined, atau Hybrid Entra joined).
# Memeriksa status perangkat di Entra ID menggunakan PowerShell
Connect-MgGraph -Scopes "Device.Read.All"

# Mencari perangkat berdasarkan nama pengguna
$userDevices = Get-MgUserRegisteredDevice -UserId "[email protected]"
$userDevices | ForEach-Object {
    $device = Get-MgDevice -DeviceId $_.Id
    [PSCustomObject]@{
        DisplayName    = $device.DisplayName
        OS             = $device.OperatingSystem
        OSVersion      = $device.OperatingSystemVersion
        TrustType      = $device.TrustType
        IsCompliant    = $device.IsCompliant
        IsManaged      = $device.IsManaged
        LastSignIn     = $device.ApproximateLastSignInDateTime
    }
} | Format-Table -AutoSize

Masalah #4: Akses Diblokir Tanpa Pesan Error yang Jelas

Kadang pengguna mengalami penolakan akses tanpa pesan error yang informatif. Ini sering banget terjadi pada aplikasi mobile atau klien email tradisional.

Solusi:

  • Gunakan What If tool untuk mensimulasikan skenario sign-in pengguna (lebih detail di bagian berikutnya).
  • Periksa apakah aplikasi klien mendukung modern authentication. Aplikasi yang masih pakai legacy authentication (Basic Auth) mungkin nggak bisa menampilkan prompt MFA dengan benar.
  • Pastikan pengguna menggunakan versi terbaru dari aplikasi klien — Outlook, Teams, dan sebagainya.

Menggunakan What If Tool untuk Simulasi Kebijakan

Apa Itu What If Tool?

What If tool adalah salah satu senjata terbaik yang dimiliki tim helpdesk. Ini alat diagnostik bawaan di Conditional Access yang memungkinkan kamu mensimulasikan skenario sign-in tanpa benar-benar melakukan sign-in. Sangat berguna untuk:

  • Menguji kebijakan baru sebelum diaktifkan.
  • Mendiagnosis mengapa pengguna tertentu diblokir atau diminta MFA.
  • Memverifikasi bahwa kebijakan bekerja sesuai harapan.
  • Mengidentifikasi kebijakan yang saling bertentangan.

Jujur, kalau kamu belum pernah pakai What If tool, kamu melewatkan banyak hal. Ini bisa menghemat waktu troubleshooting secara signifikan.

Cara Menggunakan What If Tool

  1. Buka Entra admin center → Protection → Conditional Access → Policies.
  2. Klik What If di toolbar atas.
  3. Isi parameter simulasi:
    • User: Pilih pengguna yang ingin disimulasikan.
    • Cloud apps: Pilih aplikasi target (misalnya Office 365).
    • IP address: Masukkan alamat IP sumber (opsional).
    • Device platform: Pilih platform — Windows, iOS, Android, dan lainnya.
    • Client app: Pilih jenis klien — Browser, Mobile apps and desktop clients, dll.
    • Sign-in risk: Pilih tingkat risiko (opsional).
    • Device state: Atur status perangkat — compliant, hybrid joined, dll. (opsional).
  4. Klik What If untuk menjalankan simulasi.
  5. Tinjau hasilnya:
    • Policies that will apply: Kebijakan yang akan diterapkan.
    • Policies that will not apply: Kebijakan yang nggak berlaku, beserta alasannya.

Menggunakan What If API melalui PowerShell

Untuk skenario yang lebih kompleks atau kalau kamu butuh otomasi, bisa juga menggunakan What If Evaluation API via Microsoft Graph:

# Menggunakan Maester PowerShell module untuk What If testing
# Install module terlebih dahulu: Install-Module Maester -Scope CurrentUser
Import-Module Maester

# Koneksi ke Microsoft Graph
Connect-MgGraph -Scopes "Policy.Read.All", "Directory.Read.All"

# Menjalankan What If test
$result = Test-MtConditionalAccessWhatIf `
    -UserId "[email protected]" `
    -IncludeApplications "Office365" `
    -ClientAppType "browser" `
    -DevicePlatform "windows"

# Menampilkan hasil
$result | Format-List

Perubahan Penting Conditional Access di Tahun 2026

Tahun 2026 membawa beberapa perubahan besar yang perlu kamu persiapkan dari sekarang. Ini bukan perubahan kecil — beberapa di antaranya bisa berdampak langsung pada volume tiket helpdesk.

Peningkatan Enforcement untuk Kebijakan dengan Resource Exclusions

Mulai 27 Maret 2026, Microsoft akan menerapkan perubahan signifikan pada cara Conditional Access mengevaluasi kebijakan yang menargetkan "All resources" dengan pengecualian resource tertentu. Perubahan ini diluncurkan bertahap sampai Juni 2026.

Apa yang berubah?

Sebelumnya, ada semacam celah: ketika sebuah klien aplikasi meminta akses hanya dengan scope terbatas, sign-in tersebut bisa lolos tanpa memicu tantangan Conditional Access seperti MFA atau device compliance — meskipun kebijakan sebenarnya menargetkan semua sumber daya. Dengan pembaruan ini, enforcement akan jauh lebih konsisten.

Dampak pada Helpdesk:

  • Kemungkinan lonjakan tiket dari pengguna yang tiba-tiba diminta MFA saat menggunakan aplikasi yang sebelumnya nggak meminta MFA.
  • Aplikasi kustom dengan scope terbatas mungkin mengalami kegagalan autentikasi.
  • Tim helpdesk perlu memahami perubahan ini supaya bisa memberikan penjelasan yang tepat dan mengarahkan ke tim development jika masalahnya terkait aplikasi kustom.

Persiapan yang Harus Dilakukan:

  1. Audit semua kebijakan Conditional Access yang menargetkan "All resources" dengan pengecualian.
  2. Gunakan Report-only mode dan Sign-in logs untuk mengidentifikasi sign-in yang bakal terdampak.
  3. Koordinasi dengan tim development untuk memastikan aplikasi kustom siap menangani tantangan MFA dan device compliance.
  4. Siapkan komunikasi ke pengguna tentang potensi perubahan pengalaman login.

Mandatory MFA untuk Azure Portal dan Admin Centers

Microsoft sudah mewajibkan MFA untuk semua pengguna yang mengakses Azure portal, Microsoft Entra admin center, dan Intune admin center. Kebijakan ini diterapkan otomatis melalui Microsoft-managed Conditional Access policies. Dan angkanya nggak bohong — penelitian menunjukkan MFA mengurangi risiko kompromi akun hingga lebih dari 99%.

Poin penting untuk helpdesk:

  • Semua administrator harus sudah mendaftarkan metode MFA.
  • Kalau administrator nggak bisa akses portal admin, langkah pertama: verifikasi apakah mereka sudah mendaftarkan metode MFA yang valid.
  • Akun break-glass (emergency access) harus dikecualikan dari kebijakan ini dan didokumentasikan dengan baik.

Deprecation Enkripsi RC4 di Kerberos

Meskipun nggak secara langsung terkait Conditional Access, perubahan ini sangat relevan untuk lingkungan hybrid. Mulai Januari 2026, Microsoft mulai menonaktifkan enkripsi RC4 pada autentikasi Kerberos sebagai respons terhadap CVE-2026-20833.

Timeline-nya:

  • Januari 2026: Audit events baru untuk mendeteksi penggunaan RC4. Registry key RC4DefaultDisablementPhase tersedia untuk kontrol.
  • April 2026: Domain controller menggunakan AES-SHA1 secara default untuk akun tanpa pengaturan enkripsi eksplisit.
  • Juli 2026: Registry key RC4DefaultDisablementPhase dihapus; AES jadi standar wajib.
# Mendeteksi service accounts yang masih menggunakan RC4
# Jalankan di Domain Controller
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
    Where-Object {
        $_.'msDS-SupportedEncryptionTypes' -band 0x4  # RC4_HMAC_MD5
    } |
    Select-Object Name, SamAccountName,
        @{N='EncTypes';E={$_.'msDS-SupportedEncryptionTypes'}},
        @{N='SPNs';E={$_.ServicePrincipalName -join '; '}} |
    Format-Table -AutoSize

# Mengonfigurasi service account untuk menggunakan AES
Set-ADUser -Identity "svc_account" -KerberosEncryptionType AES128,AES256

# Memeriksa event log untuk penggunaan RC4
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
    Id = 43  # Event ID untuk RC4 usage warning
} -MaxEvents 50 |
    Select-Object TimeCreated, Message |
    Format-List

Dampak pada Helpdesk:

  • Aplikasi lama yang bergantung pada RC4 mungkin mengalami kegagalan autentikasi.
  • Service accounts yang belum dikonfigurasi untuk AES perlu segera diperbarui.
  • Tim helpdesk harus berkoordinasi dengan tim infrastruktur untuk mengidentifikasi dan memigrasi semua service accounts yang masih pakai RC4.

Best Practices Pengelolaan Conditional Access untuk Tim Helpdesk

1. Dokumentasi yang Komprehensif

Buat dan pelihara dokumentasi detail tentang semua kebijakan Conditional Access di organisasimu. Dokumentasi harus mencakup:

  • Nama dan tujuan setiap kebijakan.
  • Scope pengguna dan aplikasi yang terpengaruh.
  • Grant controls yang diterapkan.
  • Pengecualian (exclusions) dan alasannya.
  • Tanggal pembuatan dan terakhir dimodifikasi.
  • Pemilik kebijakan — siapa yang bertanggung jawab.

Serius, dokumentasi yang baik bisa menyelamatkanmu dari berjam-jam troubleshooting yang nggak perlu.

2. Gunakan Naming Convention yang Konsisten

Terapkan konvensi penamaan yang memudahkan identifikasi kebijakan. Contoh format yang sudah terbukti efektif:

[Tipe]-[Target]-[Kondisi]-[Tindakan]

Contoh:
CA001-AllUsers-AnyLocation-RequireMFA
CA002-Admins-UntrustedLocations-BlockAccess
CA003-GuestUsers-NonCompliantDevices-BlockAccess
CA004-AllUsers-LegacyAuth-BlockAccess

3. Selalu Miliki Akun Break-Glass

Akun break-glass (emergency access) adalah akun administrator yang dikecualikan dari semua kebijakan Conditional Access. Akun ini hanya dipakai dalam situasi darurat ketika semua admin lain terkunci. Beberapa aturan penting:

  • Buat minimal 2 akun break-glass.
  • Jangan gunakan MFA berbasis telepon — gunakan FIDO2 security key yang disimpan di brankas.
  • Kecualikan akun ini dari semua kebijakan Conditional Access.
  • Pantau penggunaan akun melalui alert di Sign-in logs.
  • Uji secara berkala untuk memastikan masih berfungsi.

4. Implementasi Bertahap

Jangan pernah — dan saya ulangi, jangan pernah — langsung mengaktifkan kebijakan baru ke mode On. Gunakan pendekatan bertahap:

  1. Report-only: Aktifkan kebijakan dalam mode report-only selama 1-2 minggu.
  2. Analisis dampak: Tinjau Conditional Access insights and reporting workbook di Azure Monitor.
  3. Pilot group: Aktifkan kebijakan untuk grup kecil terlebih dahulu.
  4. Gradual rollout: Perluas scope bertahap ke grup yang lebih besar.
  5. Full deployment: Aktifkan untuk seluruh organisasi setelah validasi menyeluruh.

5. Blokir Legacy Authentication

Legacy authentication (Basic Auth) nggak mendukung MFA dan merupakan vektor serangan utama. Ini harus jadi salah satu kebijakan pertama yang kamu terapkan:

  1. Buat kebijakan baru yang menargetkan All users.
  2. Di Conditions → Client apps, pilih:
    • Exchange ActiveSync clients
    • Other clients
  3. Di Grant: Pilih Block access.

6. Monitoring dan Alerting

Konfigurasi monitoring untuk mendeteksi masalah Conditional Access secara proaktif — jangan tunggu sampai tiket menggunung:

# Query KQL untuk Azure Monitor / Log Analytics
# Mendeteksi sign-in yang diblokir oleh Conditional Access dalam 24 jam terakhir

SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "failure"
| summarize BlockedCount = count() by
    UserPrincipalName,
    AppDisplayName,
    tostring(ConditionalAccessPolicies)
| where BlockedCount > 5
| order by BlockedCount desc

# Mendeteksi peningkatan mendadak sign-in yang diblokir
SigninLogs
| where TimeGenerated > ago(1h)
| where ConditionalAccessStatus == "failure"
| summarize CurrentHourBlocks = count()
| extend PreviousHourBlocks = toscalar(
    SigninLogs
    | where TimeGenerated between(ago(2h) .. ago(1h))
    | where ConditionalAccessStatus == "failure"
    | count
)
| where CurrentHourBlocks > PreviousHourBlocks * 2

Skenario Helpdesk Sehari-hari dan Penyelesaiannya

Skenario 1: Karyawan Baru Tidak Bisa Login ke Teams

Keluhan: "Saya baru bergabung dan tidak bisa login ke Microsoft Teams. Muncul pesan bahwa akses diblokir."

Ini skenario klasik. Biasanya masalahnya sederhana, tapi perlu diperiksa secara sistematis.

Langkah Penyelesaian:

  1. Periksa apakah akun sudah disinkronisasi dari AD on-premises ke Entra ID (kalau menggunakan hybrid setup).
  2. Pastikan lisensi Microsoft 365 sudah ditetapkan ke akun.
  3. Verifikasi apakah pengguna sudah mendaftarkan metode MFA — karyawan baru sering banget belum melakukan ini.
  4. Periksa apakah perangkat sudah terdaftar dan compliant di Intune (kalau kebijakan device compliance diterapkan).
  5. Gunakan What If tool untuk mensimulasikan sign-in dan identifikasi kebijakan yang memblokir.

Skenario 2: Pengguna Remote Diminta MFA Terus-menerus

Keluhan: "Setiap kali saya membuka Outlook, saya diminta MFA lagi. Ini sangat mengganggu."

Saya paham frustrasinya — dan ini memang salah satu keluhan yang paling sering muncul dari pengguna remote.

Langkah Penyelesaian:

  1. Periksa pengaturan Sign-in frequency pada kebijakan yang berlaku — mungkin diatur terlalu pendek.
  2. Periksa apakah persistent browser session diaktifkan.
  3. Verifikasi bahwa Outlook menggunakan modern authentication (bukan Basic Auth).
  4. Pastikan perangkat terdaftar di Entra ID — perangkat yang nggak terdaftar sering kali nggak mendapatkan Primary Refresh Token (PRT) yang memungkinkan SSO tanpa MFA berulang.
  5. Periksa apakah ada beberapa kebijakan yang saling tumpang tindih.

Skenario 3: Aplikasi Pihak Ketiga Tidak Bisa Mengakses Data Microsoft 365

Keluhan: "Aplikasi CRM kami yang terintegrasi dengan SharePoint tiba-tiba tidak bisa mengambil data."

Langkah Penyelesaian:

  1. Periksa apakah ada perubahan kebijakan Conditional Access baru-baru ini yang mungkin mempengaruhi aplikasi.
  2. Verifikasi bahwa service principal aplikasi masih punya consent yang valid.
  3. Periksa Sign-in logs untuk service principal tersebut — gunakan filter "Service principal sign-ins".
  4. Kalau menggunakan client credentials flow, pastikan secret atau certificate belum kedaluwarsa.
  5. Periksa apakah aplikasi terdampak perubahan enforcement Conditional Access 2026 (terutama kalau pakai scope terbatas).

Audit dan Pelaporan Conditional Access

Menggunakan Audit Logs

Setiap perubahan pada kebijakan Conditional Access dicatat di audit logs. Ini penting untuk melacak siapa yang bikin perubahan dan kapan — terutama kalau tiba-tiba ada kebijakan yang berubah dan nggak ada yang ngaku.

# Memeriksa perubahan kebijakan Conditional Access melalui Audit Logs
Connect-MgGraph -Scopes "AuditLog.Read.All"

Get-MgAuditLogDirectoryAudit -Filter "category eq 'Policy' and activityDisplayName eq 'Update conditional access policy'" -Top 20 |
    Select-Object ActivityDateTime,
        @{N='InitiatedBy';E={$_.InitiatedBy.User.UserPrincipalName}},
        @{N='PolicyName';E={$_.TargetResources[0].DisplayName}},
        ActivityDisplayName |
    Format-Table -AutoSize

Conditional Access Insights and Reporting Workbook

Microsoft menyediakan workbook bawaan di Azure Monitor yang memberikan visualisasi lengkap tentang dampak kebijakan Conditional Access. Cara mengaksesnya:

  1. Pastikan Sign-in logs sudah dikirim ke Log Analytics workspace.
  2. Buka Entra admin center → Identity → Monitoring & health → Workbooks.
  3. Pilih workbook Conditional Access insights and reporting.
  4. Tinjau dashboard yang menampilkan:
    • Jumlah sign-in yang terdampak per kebijakan.
    • Kebijakan dalam mode report-only dan dampak estimasinya.
    • Tren sign-in yang diblokir dari waktu ke waktu.
    • Sign-in yang gagal memenuhi grant controls.

Kesimpulan

Microsoft Entra ID dan Conditional Access adalah komponen fundamental dalam arsitektur keamanan modern. Bagi tim helpdesk, pemahaman tentang cara kerja, konfigurasi, dan troubleshooting Conditional Access sudah bukan opsional lagi — ini yang membedakan tim helpdesk yang cuma reaktif dari yang benar-benar proaktif.

Dengan perubahan besar di tahun 2026 — peningkatan enforcement Conditional Access, mandatory MFA untuk admin portals, dan deprecation RC4 di Kerberos — sekarang waktu yang tepat untuk mempersiapkan diri. Beberapa langkah konkret yang bisa kamu ambil:

  • Perbarui pengetahuan: Ikuti perkembangan terbaru dari Microsoft Learn dan Microsoft Tech Community.
  • Kuasai tools: Sign-in logs, What If tool, dan PowerShell — tiga senjata utama untuk diagnosis yang cepat dan akurat.
  • Bangun dokumentasi: Catat setiap kebijakan, pengecualian, dan prosedur troubleshooting dalam knowledge base internal.
  • Kolaborasi dengan tim keamanan: Helpdesk adalah garis depan yang sering pertama kali mendeteksi masalah — jaga komunikasi tetap erat dengan tim keamanan dan infrastruktur.
  • Edukasi pengguna: Proaktif mengedukasi pengguna tentang MFA, registrasi perangkat, dan praktik keamanan yang baik. Ini cara paling efektif mengurangi volume tiket.

Dengan fondasi pengetahuan yang kuat, tim helpdesk bisa menyelesaikan masalah akses lebih cepat, mengurangi downtime pengguna, dan berkontribusi langsung pada keamanan organisasi secara keseluruhan. Semoga panduan ini bermanfaat — selamat mencoba dan semoga tiket-tiket Conditional Access nggak lagi bikin pusing!

Tentang Penulis Editorial Team

Our team of expert writers and editors.