Koşullu Erişim (CA) Politikalarını Yönetmek için PowerShell'i Kullanma

Microsoft, kiracının verilerini ve kullanıcılarını yönetmek için birçok yöntem sağlar. PowerShell, AzureAD modülündeki bir dizi cmdlet'i kullanan Koşullu Erişim İlkeleri de dahil olmak üzere kaynakları yönetmek için güçlü bir araçtır. Bu yazıda sekiz PowerShell cmdlet'ini ve bunların nasıl kullanılacağını inceliyoruz.

**Hem AzureAD hem de AzureADPreview PowerShell modüllerinin bu cmdlet'leri içerdiğini unutmayın.

PowerShell ve CA Politikaları

Öncelikle AzureAD veya AzureADPreview modülünü kullanarak Azure Active Directory'ye bağlanın:
Connect-AzureAD

Bağlandıktan sonra, şu iki tek satırı kullanarak mevcut PowerShell cmdlet'lerinin bir listesini alabiliriz:
Get-Command *conditional*
Get-Command *named*

Birleşik olarak toplam elde ederiz: Koşullu Erişim Politikaları ve Ad Konum Politikaları ile ilgili sekiz cmdlet:
Get-AzureADMSConditionalAccessPolicy
Yeni-AzureADMSConditionalAccessPolicy
AzureADMSConditionalAccessPolicy'yi Kaldır
Set-AzureADMSConditionalAccessPolicy

Get-AzureADMSNamedLocationPolicy
Yeni-AzureADMSNamedLocationPolicy< br>AzureADMSNamedLocationPolicy'yi Kaldır
Set-AzureADMSNamedLocationPolicy

Koşullu Erişim Politikaları, kullanıcıların uygulamalara hangi koşullar altında erişebileceğini belirlemek için koşullar belirler. Bu koşullar konumlardan, bir veya daha fazla kullanıcıdan, uygulamalardan, platformlardan ve daha fazlasından oluşabilir.

Aşağıdaki örneklerde PowerShell ile neler yapılandırabileceğimizi görmek için bu koşulları inceliyoruz.

Yeni Koşullu Erişim Politikası oluşturma

Yeni bir alanın veya yeni kiracının Koşullu Erişim Politikası yoktur. Koşullu Erişimi kullanabilmek için koşullarını oluşturmamız gerekir. Adlandırılmış Konumlar gerekiyorsa öncelikle Adlandırılmış Konum oluşturmamız gerekir. Örnek bir senaryo kullanarak bu süreci inceleyelim.

Adlandırılmış Yerler

Koşullu Erişim Politikaları, bir kuruluşun ortamındaki fiziksel konumlara karşılık gelen Adlandırılmış Konumlar içerebilir. Adlandırılmış Konumlar, karşılık gelen IP alt ağı/aralığıyla birlikte Fiziksel konumlar veya tek bir ülke/bir dizi ülke olabilir. MFA veya diğer isteğe bağlı eylemler için kullanıcılara nerede sorulacağını (veya sorulmayacağını) kontrol eden bir koşul sağlamak için Adlandırılmış Konumları kullanabiliriz. Azure AD Modülünde, Adlandırılmış Konumları yönetmek ve tipik Al, Yeni, Kaldır ve Ayarla PowerShell fiilleri gamını çalıştırmak için dört PowerShell cmdlet'inin bulunduğunu gördük.

Yeni veya Greenfield Azure AD'de, Koşullu Erişim tarafından kullanılabilecek Adlandırılmış Konumlar yoktur ve bunları Azure AD'de veya PowerShell ile oluşturmamız gerekir. Yeni bir Adlandırılmış Konum ilkesi oluşturmak için New-AzureADMSNamedLocationPolicy cmdlet'ini kullanmamız gerekir.

Yeni bir Adlandırılmış konum oluştururken birkaç şeyi aklımızda tutmamız gerekir:

  • Görünen Ad gerekli
  • Oluşturduğumuz Adlandırılmış Konumun türünü belirleyeceği için bir IP aralığı veya ülke listesi seçmeniz gerekir.

İlk Adlandırılmış Konum için bazı temel kriterleri kullanabiliriz - Chicago Ofisi, 16 bitlik alt ağ maskesiyle 10.25.0.0 IP Aralığı ve bu konumu güvenilir konum olarak işaretleyeceğiz. New York Ofisi için IP aralığı 10.26.0.0 ve aynı alt ağ maskesi 16 bit olan ikinci bir konum da oluşturulabilir. Adlandırılmış Konumu oluşturmak için PowerShell gereklidir. Aşağıdaki örnekte ofisin IP alt ağı için bir MS Graph nesnesinin bulunduğuna dikkat edin.

Örnek:
BT, kullanıcılar uygulamalara iki konumdan erişmediği sürece tüm bulut uygulamaları için çok faktörlü kimlik doğrulamayı (MFA) zorunlu kılacak bir Koşullu Erişim Politikası istiyor. Konumlar sırasıyla 10.25.0.0/16 ve 10.26.0.0/16 alt ağlarına sahip Chicago ve New York'taki fiziksel ofislerdir. Öncelikle New-AzureADMSNamedLocationPolicy kullanarak iki Adlandırılmış Konum oluşturacağız ve ardından konumlara referans vermek için New-AzureADMSConditionalAccessPolicy kullanarak yeni bir CA İlkesi oluşturacağız:
$CHISubnet=New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$CHISubnet.cidrAddress='10.25.0.0/16'
Yeni-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName 'Chicago Office' -IsTrusted $True -IpRanges $CHISubnet
$NYSubnet=New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$NYSubnet.cidrAddress='10.26.0.0/16'
Yeni-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName 'New York Office' -IsTrusted $True -IpRanges $NYSubnet

Konumların özelliklerini Get-AzureADMSNamedLocationPolicy cmdlet'iyle doğrulayabiliriz, devam etmeden önce yapmamız gerekenler:

** Adil olmak gerekirse, Adlandırılmış Konum oluşturulurken de aynı çıktı oluşturulur, ancak yukarıda Adlandırılmış Konum cmdlet'lerinin Get-* bölümünde görülebilecekler gösterilmektedir.

Adlandırılmış Konumlar oluşturulduktan sonra artık bunları bir CA Politikasında kullanabiliriz (CA Politikasında birçok ayar bulunduğunu unutmayın). Öncelikle CA Politikasının Koşulunu (Uygulamalar, Kullanıcılar ve Konumlar) tutacak bir nesneye ihtiyacımız var. ConditionalAccessConditionSet'te kullanılabilen koşulların dökümü burada tanımlanır.
$CAConditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$CAConditions.Applications=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition
$CAConditions.Applications.IncludeApplications='Tümü'

Bu bölümde, Koşullu Erişim Politikasını uygulayacak kullanıcıları (Users.ExcludeUsers) ve hariç tutmak istediğimiz kullanıcıları (Users.ExcludeUsers) tanımlıyoruz. Bu durumda, hariç tutulan kullanıcı, tanımladığımız tüm politikaların dışında bırakılan ve Azure AD'deki kullanıcıya ait Nesne GUID'si olarak aşağıda gösterilen bir Break Glass hesabıdır. Konumlara ilişkin GUID'ler, Şekil 2'de görüldüğü gibi kimlik alanındadır.
$CAConditions.Users=New-Object -TypeName Microsoft.Open.MSGraph .Model.ConditionalAccessUserCondition
$CAConditions.Users.IncludeUsers='Tümü'
$CAConditions.Users.ExcludeUsers='22561a78-a72e-4d39-898d-cd7c57c84ca6'
$CAConditions.Locations=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$CAConditions.Locations.IncludeLocations='0743ff81-cea0-40d2-b0f0-4028cdc1c61a','0f0c7a7f-4863-480e-9b71-d8f9eddb37e4′

** 'Tüm' Uygulamalara Dikkat Edin VE 'Tüm' kullanıcı ayarları, Azure AD Portalını da etkiler; bu, portala erişemeyebileceğiniz ve CA İlkelerinizi değiştiremeyeceğiniz anlamına gelir. Burada [Users.ExcludeUsers] gösterildiği gibi bir Break Glass Hesabı oluşturduğunuzdan ve hariç tuttuğunuzdan emin olun. Break Glass Hesapları hakkında daha fazla bilgi için bu blog gönderisine bakın.

Daha sonra MFA gereksinimi için Hibe Kontrollerini yapılandırmamız gerekiyor. Yukarıdaki Koşullar gibi aynı zamanda bir Graph nesnesine ihtiyacımız var ve bizim durumumuzda MFA'da kontrolün yanı sıra bir operatör ('Or'/'And') da sağlıyoruz:
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“OR ”
$CAControls.BuiltInControls=“Mfa”

** Kullanılabilir IntegratedInControl'lerin listesini burada bulabilirsiniz.

Politika Ayarlarının Özeti:

  • Tüm Bulut Uygulamaları için geçerlidir
  • Azure AD'deki tüm kullanıcılara uygulanır
  • Tek hesaba başvuru hariç tutuldu
  • Bu kullanıcılar ve bu uygulamalar için MFA'yı zorunlu kılar
  • MFA'nın uygulanmayacağı İki Adlı Konum dahil

Artık $CAConditions nesnemiz ve $CAControls nesnemiz gerekli ayarlarla doldurulmuş durumda ve bunu başlangıç gereksinimlerimize göre bir CA Politikası oluşturmak için kullanabiliriz:
Yeni -AzureADMSConditionalAccessPolicy -DisplayName “CloudApps-MFA-CorpWide” -Durum “Etkin” -Conditions $CAConditions -GrantControls $CAControls

Id              : cb14d13f-6ecb-4113-b684-cb6ace507edd
DisplayName     : CloudApps-MFA-CorpWide
State           : enabled
Conditions      : class ConditionalAccessConditionSet {
                    Applications: class ConditionalAccessApplicationCondition {
                    IncludeApplications: System.Collections.Generic.List`1[System.String]
                    ExcludeApplications: System.Collections.Generic.List`1[System.String]
                    IncludeUserActions: System.Collections.Generic.List`1[System.String]
                    IncludeProtectionLevels:
                  }

                    Users: class ConditionalAccessUserCondition {
                    IncludeUsers: System.Collections.Generic.List`1[System.String]
                    ExcludeUsers: System.Collections.Generic.List`1[System.String]
                    IncludeGroups: System.Collections.Generic.List`1[System.String]
                    ExcludeGroups: System.Collections.Generic.List`1[System.String]
                    IncludeRoles: System.Collections.Generic.List`1[System.String]
                    ExcludeRoles: System.Collections.Generic.List`1[System.String]
                  }

                    Platforms:
                    Locations: class ConditionalAccessLocationCondition {
                    IncludeLocations: System.Collections.Generic.List`1[System.String]
                    ExcludeLocations: System.Collections.Generic.List`1[System.String]
                  }

                    UserRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    SignInRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    ClientAppTypes: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessClientApp]
                    Devices:
                  }

GrantControls   : class ConditionalAccessGrantControls {
                    _Operator: OR
                    BuiltInControls: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControl]
                    CustomAuthenticationFactors: System.Collections.Generic.List`1[System.String]
                    TermsOfUse: System.Collections.Generic.List`1[System.String]
                  }

SessionControls :
Figure: Output from New-AzureADMSConditionalAccessPolicy cmdlet.

Ne yazık ki, bu CA Politikası için uygulanan tüm ayarlar, özellikler karmaşık veri kümeleri içerdiğinden 'System.Collections' tarafından gizlenmiştir. CA İlkesi ayarlarını doğrulamak için, neyin mevcut olduğunu görmek üzere her koşulu ayrı ayrı seçmeliyiz. Uygulamalar, Kullanıcılar ve Konumların tümü bir CA İlkesindeki Koşullar özelliğinin alt özellikleridir; böylece bu bölümlerin her birini şu şekilde ayırabiliriz:
((Get-AzureADMSConditionalAccessPolicy).Conditions).Applications

IncludeApplications ExcludeApplications IncludeUserActions IncludeProtectionLevels
------------------- ------------------- ------------------ -----------------------
{All}               {}                  {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Kullanıcılar

IncludeUsers  : {All}
 ExcludeUsers  : {22561a78-a72e-4d39-898d-cd7c57c84ca6}
 IncludeGroups : {}
 ExcludeGroups : {}
 IncludeRoles  : {}
 ExcludeRoles  : {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations                                                             ExcludeLocations
----------------                                                             ----------------
{0743ff81-cea0-40d2-b0f0-4028cdc1c61a, 0f0c7a7f-4863-480e-9b71-d8f9eddb37e4} {}

Her durumda Uygulamalar, Kullanıcılar ve Konumlar, Koşullu Erişim Politikalarında ObjectId'ler olarak listelenir. Yönetim için bir rapor oluşturulmuşsa bu değerleri adlara dönüştürmek için ek PowerShell sorguları gerekecektir. ObjectId'leri adlara dönüştürmek, CA Politikalarının doğrulanmasına veya belgelenmesine/denetlenmesine de yardımcı olacaktır.

Mevcut Koşullu Erişim Politikasını Değiştirme

Artık bir CA Politikamız olduğuna göre Uygulamaları, Kullanıcıları, Konumları ve Kontrollerin yanı sıra Platformlar ve Oturum Açma Riski gibi diğer yapılandırılmamış öğeleri güncellemek için PowerShell'i kullanabiliriz.

CA Politikasının Uygulanmasını Değiştirme
Uygulanabilecek değişikliklerden biri CA Politikasının durumunun değiştirilmesidir. CA Politikalarının üç durumu vardır: EnabledForReportingButNotEnforced, Enabled ve Disabled. Örneğin, yeni bir CA İlkesi mevcutsa ve kurumsal bir konumdayken kullanıcılardan MFA istenirse, bu durumda politika potansiyel olarak devre dışı bırakılabilir veya yalnızca sorun giderme işlemi gerçekleştirilene kadar rapor verecek şekilde ayarlanabilir:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -Durum Devre Dışı
Ayarla -AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -Durum Raporlama İçin Etkin Ancak Zorlanmadı

Politika etkin bir şekilde devre dışı bırakıldığında, BT artık politikada değişiklikler yapabilir, bunları doğrulayabilir ve ardından politikayı yeniden etkinleştirebilir:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -Durum Etkin

CA İlkesi Denetimlerini Değiştirme
Önceki örnekte, aşağıdaki durumlarda bir MFA istemine gereksinim vardır: bir bulut uygulaması kullanarak ve iki Adlandırılmış Konumun dışından bağlanarak. Bu denetimler, ek güvenlik gereksinimlerine veya olası alternatiflere (Azure AD'ye Katıldı/Uyumluluk) ihtiyaç duyulması durumunda da ayarlanabilir. CA İlkelerindeki kontroller, önceki örnekteki tek kontrole (OR) karşı birleştirilebilir (AND).

Örneğin, bir kullanıcı hariciyken bir bulut uygulamasına eriştiğinde bunu Uyumlu bir Cihazdan yapması gerektiğini VE MFA için sorulması gerektiğini eklemek istersek, bunu yeni bir Kontrol nesnesi oluşturup ardından uygulayarak yapabiliriz. bunu mevcut CA Politikasına ekleyin. Uyumlu Cihaz, jailbreakli değil, işletim sistemi sürüm düzeyi gibi önceden tanımlanmış belirli bir kriter listesini karşılayan bir cihazdır. İlk olarak Kontroller:
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“AND”
$CAControls.BuiltInControls=“Mfa”,”CompliantDevice”

Her iki Kontrolün de doğru olması gerektiğini bildiren bir AND operatörümüz olduğuna dikkat edin. Ayrıca yapılandırılmış Kontrollerin MFA ve Uyumlu Cihaz olduğu da dikkate alınmalıdır. Bu kontroller daha sonra mevcut ayarların üzerine yazılarak mevcut bir CA İlkesine uygulanır:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163s - GrantControls $CAControls

Önce :

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse
 
 OR        {Mfa}           {}                          {}

Sonrasında :

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse 

AND        {Mfa, CompliantDevice} {}                   {}

Artık bunu şu şekilde tek satırlık bir satıra yerleştirebiliriz:
Remove-AzureADMSConditionalAccessPolicy -PolicyId 7ac2fcee-d5bd-4003-ad10-5dfa838417da

Herhangi bir bilgi istemi verilmediğinden CA Politikalarını kaldırırken dikkatli olun.

Adlandırılmış Yerler

Daha önce de belirtildiği gibi, Koşullu Erişim Politikaları, bir kuruluşun ortamındaki fiziksel konumlara karşılık gelmek için Adlandırılmış Konumlar kavramını kullanır. PowerShell'de gösterilenleri ve Adlandırılmış konumlar için Azure AD portalında görüntülenenleri karşılaştırmak için Get-AzureADMSNamedLocationPolicy'yi kullanabiliriz. Bu, bir konfigürasyonun doğrulanması ve iki ekran arasındaki farkların anlaşılması açısından faydalıdır:

Mevcut Adlandırılmış Konumu Değiştir

Organizasyonlar zamanla değişir; bu da adlandırılmış konumlar için değişikliklerin gerekli olduğu anlamına gelebilir. Örneğin, konumları yeniden adlandırmanız, alt ağlar eklemeniz, alt ağları kaldırmanız, bunları güvenilir olarak işaretlemeniz veya güveni kaldırmanız gerekebilir. Tüm bu değişiklikler Set-AzureADMSNamedLocationPolicy cmdlet'i ile gerçekleştirilebilir. Bu değişikliklerin her birini yapmak için ne gerektiğini görelim:

Adlandırılmış Konum 'Adını' Değiştir
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -DisplayName 'Chicago Loop Office'
IP Aralığını Değiştir
$ipRanges=New-Object -TypeName Microsoft.Open .MSGraph.Model.IpRange
$ipRanges.cidrAddress='10.25.0.0/16'
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IpRanges $ipRanges -OdataType “#microsoft.graph.ipNamedLocation”
<Güvenilir
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $False
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $True

Adlandırılmış Bir Konumu Kaldırma

Ofisler kapatıldığında veya Koşullu Erişim Politikası için artık ihtiyaç kalmadığında, istenildiği takdirde Adlandırılmış Konumlar kaldırılabilir. Adlandırılmış Lokasyonların geride bırakılması bir güvenlik riski oluşturmaz. Öncelikle konumu içeren mevcut Koşullu Erişim Politikalarının olup olmadığını belirlememiz gerekir. Bunları CA Politikasının Koşullar özelliğinden seçebilir ve konumu System.Collections.Generic.List olarak saklayan Locations alt özelliğine bakabiliriz:

Locations: class ConditionalAccessLocationCondition {
IncludeLocations: System.Collections.Generic.List`1[System.String] 
ExcludeLocations: System.Collections.Generic.List`1[System.String]

GUID'i açığa çıkarabiliriz:
((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations ExcludeLocations
---------------- ----------------
{088f361c-4103-43e1-a11d-0394018ab62b} {}

Adlandırılmış Konum olan Chicago Ofisimizi kaldırmamız gerektiğini varsayalım:

OdataType : #microsoft.graph.ipNamedLocation
Id : 088f361c-4103-43e1-a11d-0394018ab62b
DisplayName : Chicago Office
IpRanges : {class IpRange {
CidrAddress: 10.25.0.0/16
}
}
IsTrusted : True
CountriesAndRegions :
IncludeUnknownCountriesAndRegions :

'Id' değeri, CA'daki Locations.IncludeLocations değeriyle eşleştirmek için kullanabileceğimiz değerdir. Bu Adlandırılmış Konumla herhangi bir CA Politikasını bulmak için değeri şu şekilde eşleştirmemiz gerekir:
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where {$_ .DisplayName -eq 'Chicago office'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach ($CAPolicies'te $CAPolicy) {
If ($OldNamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
Write-Host “CA Politikası $ ($CAPolicy.Id) Adlandırılmış Konumu içerir.”

Yalnızca tek bir konumumuz olabilir veya birden fazla konumumuz olabilir, ancak eşleşen tüm girişler görüntülenecektir:
CA Politikası 4e7dac6d-d471-483f-9677-46407acaa3f5, Adlandırılmış Konumu içerir.
Politikayı kaldırmaya ya da sadece Adlandırılmış Konumu kaldırmaya karar verebiliriz. Adlandırılmış Konum tek konumsa, CA Politikasını korumak için onu değiştirmemiz gerekir. Bu örnekte konumu başka bir Adlandırılmış Konumla değiştireceğiz. Öncelikle Chicago dışındaki Adlandırılmış Konumları bulun:
Get-AzureADMSNamedLocationPolicy | Nerede {$_.DisplayName -ne 'Chicago ofisi'} | ft GörünenAdı,Kimlik

DisplayName Id
----------- --
New York Office 0fae649d-a695-4761-9a83-cd20a96d0739

Daha sonra kaldırmamız gereken kimliği değiştirmek için bu konumdaki kimliği kullanırız:
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where {$_.DisplayName -eq 'Chicago office'}).Id
$NewNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where {$_.DisplayName -eq ' LA Office Office'}).Id
$conditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet span>
$conditions.Locations=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$conditions.Locations.IncludeLocations=“$NewNamedLocationId”
Foreach ($$CAPolicies'te CAPolicy) {
If ($OldNamedLocationId-eq ((($CAPolicy).Conditions).Locations).IncludeLocations) {
Set-AzureADMSConditionalAccessPolicy -PolicyId $ ($CAPolicy.ID) -Conditions $Conditions
< span class="crayon-inline lang:default decode:true">

Şimdi Adlandırılmış Konuma Sahip CA Politikalarını bulmak için çalıştırdığımız kod bloğunun aynısını yeniden çalıştırıyoruz:
$NamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where { $_.DisplayName -eq 'Chicago office'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach ($CAPolicies'te $CAPolicy) {
If ( $NamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
Write-Host “CA Politikası ve #36 ($CAPolicy.ID), Adlandırılmış Konumu içerir.”

Remove-AzureADMSNamedLocationPolicy -PolicyId $OldNamedLocationId

**İpucu: Bir Adlandırılmış Konumu Koşullu Erişim Politikasından kaldırdığınızdan emin olun
Koşullu Erişim Politikasında tanımlanan bir Adlandırılmış Konumu kaldırmaya çalışırsak bir hata oluşturulur. Bunun nedeni, Adlandırılmış Konumun Koşullu Erişim ilkesine eklenmiş olması ve önce kaldırılması gerekmesidir.

Son Düşünceler

Makaleden, Microsoft'un Koşullu Erişim İlkelerine uygun bir erişim noktası sağlayan bir dizi PowerShell cmdlet'i sağladığını görebiliriz. Bu CA Politikaları, bu cmdlet'lerde olduğu gibi oluşturulabilir, değiştirilebilir ve hatta kaldırılabilir. Ayrıca, Koşullu Erişim Politikaları tarafından kullanılabilecek Adlandırılmış Konumlar oluşturmaya yönelik cmdlet'lerimiz de mevcuttur. Bu cmdlet'lerin potansiyel kullanımları, bir kuruluşun güvenlik duruşunu doğrulaması gereken güvenlik personeli/danışmanları için CA Politikalarının oluşturulması ve yönetilmesinden Politikaların belgelenmesine ve denetlenmesine kadar uzanır. Bir politikanın çeşitli hareketli parçaları (Konumlar, Platformlar, Hibe Kontrolleri, Oturum kontrolleri ve daha fazlası) için kullanılacak değerlere ilişkin rehberlik için cmdlet'lere yönelik Get-Help'in yanı sıra bu makalede sağlanan belge bağlantılarını da okuduğunuzdan emin olun.

İlgili makaleler