.

Can's Windows Server Blog

Active Directory Configuring MSA Service Accounts

Bazen bazı uygulamalar çalışmak için kullanıcı hesabına ihtiyaç duyarlar. Bunlara “Service Accounts” denir.

Bu hesaplarla ilgili sorun şifrelerinin çok sık değişmemesi ve bu nedenle güvelik açığı teşkil etmeye başlamalalarıdır. Çoğu zaman şifre değişikliği sistemin reboot edilmesini gerektirebilir ve bu istenen bir durum değildir.

Local Sistem hesabı kullanabiliriz ama genellikle bu hesaplarda çok fazla yetki vardır bu nedenle çok da iyi olmaz. Lokal Servis hesaplarında ise çok yetersiz yetki olur bu durumda istenmeyebilir. Network Servis hesaplarınıda kullanabiliriz. Bu hesaplarda ağda pek çok servise erişebilirler ancak bu durumda istediğimiz bir durum olmayabilir.

Önemli olan şey ihtiyaç duyulan minimum yetkiyi vermektir. İşte bu nedenle Managed Service Accounts (MSA) kullanırız.

MSA hem bilgisayar hesabı hemde kullanıcı hesabı gibi davranabilir. Bu bize her ikisinin iyi tarafarını kullanma şansı verir özellikle password ve SPN (Service Principle Name) kullanımında esneklik sağlar. Pek çok hizmet service bilgilerini SPN record olarak DNS’e kaydeder. Bu durum servisten servise farklılık gösterir. Bazıları kayıt işlemini otomatik yaparken bazen bu işlemi manuel olarak yapmak zorunda kalabiliriz.

MSA için min Server 2008 R2 veya yenisi, .NET Framework 3.5.x ve active Directory Module for Powershell.

MSA’ler Managed Service Accounts adı verilen bir Containerda tutulurlar.
* CN= Managed Service Accounts, DC=<domain>,DC=<com> container

MSA bir kullanıcı hesabı ve bilgisayar hesabının karışımıdır. MSA kullanıcı hesabı gibi authentication yapabilir. Ve Bilgisayar hesabı gibi davranır ve AD onun passwordünü değiştirebilir. MSA sistem(bilgisayar) objectlerinin kullandığı password-update mekanizmasını kullanır.

Oluşturmak için

Container a girip sağ taraftan new dediğimizde karşımıza bazı opsiyonlar çıkacak bunlardan “User” seçip devam ediyoruz. Gelen pencere neredeyse aynı user hesabı oluşturmak için kullandığımız gibi.

Bunu yapmanın bir diğer yoluda AD Users and Computers.

Eski sistemlerde Managed Accounts diye de geçebilir. Ve SPN’i manuel oluşturmak gerekirdi.

Artık password otomasyonu daha kolay ve güvenli hale gelmiştir.

Active Directory Authentication Policies and Silos

Bununla kullanıcı, servis ve sistemlerin AD’ye nasıl bağlanacaklarını kontrol ediyoruz.

Öncelikle Active Directory Administrative Centerda sol menude “Authentication”ı seçiyoruz ve orta panelde “Authentication Policies” ve “Authentication Policy Silos”‘u görüyoruz.

Öncelikle bir “Authentication Policy” oluşturmamız gerekiyor daha sonra bu oluşturduğumuz policy’i Silo kullanarak uygulayacağız.

Authentication Policy e tıkladıktan sonra sağ panelde new seçiyoruz. Gelen pencere son derece çok detay içeriyor.

Ancak Screenshot eksik daha aşağıya kaydırmamız gerekli…..

Burada Only Audit policy restriction seçersek sisteme uygulanmaz ancak sanki uygulanmış gibi log tutar. Böylece uygulamadan önce bir süre takip edip kimi nasıl etkiliyor görebiliriz.

Accounts kısmında istersek bir kullanıcı, sistem veya servis de seçebiliriz.

Ekranı aşağıya kaydırınce …..

Assigned Silos : Henüz boş ancak policyi oluşturduktan sonra Silo’da oluşturacağız. O zaman uyguladığımızda burası otomatik dolacak.

Daha aşağıya kaydırdırdığımızda şu 5 başlığı göreceğiz. Böylece kine nasıl uygulanacak belirleyebileceğiz.

Bu başlıklarda genelde seçenekler hemen hemen aynı. Eğer ağda eski tip sistemler varsa Kerberos desteklemeyebilirler, bu durumda NTLM kullanabiliriz.

“Specify a Ticket Granting Ticket lifetime for user accounts” seçtiğimiz zaman sistemi Kerberos kullanmaya zorluyoruz.

İstersek Allow NTLM network authentication when user is restricted to selected devices seçeneği ile herşey kerberos iken bazılarını NTLM’de yapabiliriz.

Bu şekilde okuyup inceleyip Authentication policy oluşturuyoruz.

Daha sonra

New dedikten sonra gelen pencerede ayarları yapıyoruz. İsim veriyoruz, kime uygulanacağını belirliyoruz sonrada nasıl uygulanacağını belirliyoruz.

Active Directory Password Policy Object (PSOs)

PSO ayarlanması için powershell veya Active Directory Administrative Center.

Burada lütfen zamanların yazılışına ve yazım formatının farklılığına dikkat edin. Microsoft powershell i zor ve saçma yapan şey işte bu standartsızlık. Çoğu komutta böyle bir yazım tarzı yokken bunda var. Bu farkı bilmeyen biri uzun süre çırpınabilir.

PS C:\>Import-Module ActiveDirectory

PS C:\>New-ADFineGrainedPasswordPolicy Test -ComplexityEnabled:$true -LockoutDuration:"00:30:00" -LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0" -MaxPasswordAge:"60.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"12" -PasswordHistoryCount:"30" -Precedence:"1" -ReversibleEncryptionEnabled:$false -ProtectedFromAccidentalDeletion:$true

PS C:\>Add-ADFineGrainedPasswordPolicySubject test -Subjects Ankara

Burda -Subjects ile bir OU hedefleniyor ancak yazım hatası var sistem OU yu bu şekilde bulamıyor. Detayını bilemedim.

Tabii ki diğer yol administrative center yani GUI.

Server Manager –>Tools –> Active Directory Administrative Center

Gelen pencerede sol taraftan Domainimizi “C1.local” tıklıyoruz. Gelen listede aşağıda “System” ı çift tıklıyoruz. orta panelde liste gelecek orada “Password Settings Container”ı seçin.

Bu containera çift tıkladığımızda boş olarak gelir. Sağ taraftan “new” diyerek devam ediyoruz. Account lock-out policy ve Password Policy de olan pek çok ayar burada da var. Çoğu zaten adından anlaşılıyor.

Ancak Precedence bir den çok PSO bir gruba veya hesaba uygulandığında hangi sıra ile uygulanacağını belirliyor. Ne kadar düşükse o kadar etkilidir. örneğin 1 her zaman 2 den daha üstündür. Ancak eğer bir kullanıcı hesabına direk eklenmiş ise (applies directly to) bu durum OU ya yapılan uyguladan üstündür. Yani OUda başka ayar olsada burada yaptıklarımız o hesap için geçerli olacaktır.

Directly applies To : dan da hangi hesap ve/veya grubu etkilemesini istiyorsak ekliyoruz.

Yapılan ayarı kontrol etmek için yine “Active Directory Administrative Center”‘da domainde hesabı bulup üzerine sağ tıklıyoruz ve “View resultant password settings” i seçiyoruz.

Hangileri uygulanmış görüyoruz.

Active Directory administrative centerdan bu yaptıklarımız aynen “active directory users and computers” dan da yapılabilir.

Active Directory Hesap Güvenliğinin ayarlanması

Server 2016 de pekçok şey ayarlanabilmektedir. Bunlardan bir kaçı

  • Password Policy
  • Account Lockout policy
  • Fine grained password Policy
  • Kerberos Policy

Server Manager –> tools –> Group Policy Management

Sonra domain içinde ki “Default Domain Policy” e sağ tıklayıp “edit” diyoruz böylece GPO editor başlıyor.

GPO içinde password ile ilgili yere
Default Domain Policy –> Policies–>Windows Settings –>Security Settings –>Account Policies –>Password Policy
ile ulaşıyoruz.

Bir Policy editlerken “Explain” kısmında yazan açıklamayıda okumakta fayda var.

Policylerde “default”lar genelde iyi ayarlanmıştır.

Bazen kullanıcılar Laptop kullanırlar ve mobildirler. Bu durumda hem domain hemde local password policy kullanmaları gerekir.

Bunu ayarlamak biraz daha ilginç. Başlattan “Windows Administrative Tools” a gidip ordan “Local Security Policy” seçilir.

Burda Domain GPO sunda ki gibi aynı seçenekleri görürüz ancak bunlar local acount üzerinde geçerlidir.

Account Lockout Policy özellikle brute force karşı geliştirilmiştir. Bununla ilgili counterlar ve zamanlarla ilgili seçenekler var okuyarak incelemek gerekli.

Kerberos : Bir kullanıcı kullanıcı adı ve şifresini girdiği zaman bu bilgi DC’ye gelir ve DC sorgulama yapılan sisteme bir ticket gönderir. (Ticket Granting Ticket– veya — PSO – Password Settings Object). işte bu gelen ticket ile kaynaklara erişime izin verir.

NTLM (New Technology LAN Manager) bu Kerberostan önce kullanılan (ve halen zaman zaman kullanılan ) bir yöntemdir. Kerberos güvenlik anlamında NTLM’den daha güçlüdür. Bu nedenle mümkün olduğunca Kerberos kullanmalıyız.

GP Editorde Account Policies altında Kerberos Policy mevcuttur. Burada “Enforce User Logon Restrictions” default olarak enabled dır. Temel mantık olarak security önlemleri artıkça performans düşer. Bununla her kullanıcı session ı kullanıcı haklarına uyumlumu değilmi kontrol edilir. (User accounts- User rights Policies). böylece Kerberos ile login olurken bunun kontrol edilmesini zorunlu kılıyoruz. Ayrıca lifetime ayarları da burada mevcuttur.

Active Directory Powershell

GUI ile yapılan hemen herşeyi Powershell ilede yapabiliriz. Soru Windows temelli sistemlerde hangisi daha kolay. Bazen GUI ile iki tıkta işi bitirebilirken bazende powershellde bin tıklık işi iki satırda bitirmek mümkün. Ayrıca bazı işlemler sadece powershellden yapılabiliyor.

AD için powershell Server Manager ekranında “Active Directory Module for windows powershell” ile erişebiliriz. Yada normal powershell de import edebiliriz. Böylece tüm ad komutlarına ulaşabiliriz.

Ad hesapları için Powershell Komutları :

  • New-ADUser
  • Set-ADUser
  • Remove-ADUser
  • Set-ADAccountPassword
  • Set-ADAccountExpiration
  • Unlock-ADAccount
  • Enable-ADAccount
  • Disable-ADAccount

Tabii kelimeler İngilizce ama çevirme ile uğraşmayacağım zaten son derece net.

Aşağıda ki basit örnekte kullanıcıdan şifre girmesini istiyoruz.

New-ADUser "Can" -AccountPassword (Read-Host -AsSecureString "Sifre Girin:") -Department IT

Ad grupları için Powershell Komutları :

  • New-ADGroup
  • Set-ADGroup
  • Get-ADGroup
  • Remove-ADGroup
  • Add-ADGroupMember
  • Remove-ADGroupMember
  • Add-ADPrincipalGroupMembership

Buda aslında son derece basit İngilizce sadece sonuncu “Add-ADPrincipalGroupMembership” objectlere grup üyeliği ekliyor.

C:\>New-ADGroup -Name "Satis" -Path "ou=yonetim,dc=C1,dc=local" -GroupScope Global -GroupCategory Security
C:\> Add-ADGroupMember -Name "Satis" -Members "Can"

Bir başka örnek

Set-ADAccountPassword -identity "CN=Can Can,OU=Satis,DC=C1,DC=local" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd")

Powershell ile yapılacak çok şey var ancak bu ayrı bir eğitim konusu.

Active Directory OU’ların organizasyonu

En önemli konu domainimizi yada domainlerimizi nasıl yöneteceğimize karar vermektir. Tek lokasyon mu çok lokasyon mu belkide departmanlara göre veya kurumun kullandığı donanımlara görede ayrım yapılmak zorunda olabilir.

Diğer bir konu ise group policyleridir (GP). GP’lerin nasıl çalışmasını istediğimizede karar vermemiz gerekiyor. Genellikle GP’ler çalışanların departmanlarına göre olabilirken lokasyon gibi çeşitli farklı temelleride olabilir.

Lokasyon temelli :

  • Static
  • Delegasyon (karmaşık olabilir)

Organizasyon temelli :

  • Static değildir.
  • Kategorize etmek kolaydır.

Kaynak temelli : Örneğin Serverlara ayrı clientlara ayrı. Hatta server tiplerine de ayrı olabilir.

  • Statik değildir.
  • yönetimi delege etmek kolaydır.

Çok kullanıcılı strateji

  • Static
  • Yönetim delegasyonu kolay
  • Yeni kullanıcıları eklemek veya çıkartmak kolay

Hybrid

  • Lokasyon, organizasyon ve kaynak temellidir.

OU oluşturmada çeşitli katmalnar oluşturulabilir ancak derinleştikçe karmaşıklaşır. Önerilen 5 seviyeden daha aşağı inmemektir.

Genelde önce lokasyona daha sonrada o site içindeki kaynaklara göre organize edilirler. Yinede karar verme sürecinde çeşitli faktörleri göz önünde bulundurmalısınız. En çok kullanılan bu nedenle hybrid yaklaşımdır.

Şimdi yapacığım örnekte birden çok lokasyon için ama domain üzerinde OU’ları oluşturacağım. Bunun için C1.local a sağ tıklayıp new–>Organizational Unit seçip bir isim vereceğim. (lokasyonlar)

Burada öenmli bir detay bazı sembollerin üzerinde şekiller varken bazılarında yok. Çünkü sembol olmayanlar Container ve onlara GP uygulanamaz.

Ayrıca Ankara lokasyonunu kaynaklara göre bölmekte istiyorum bu nedenle yeni OU oluşturdum bunlardan biride Servers.

OUyu yanlış yere yerleştirsek bilr sağ klikle ve move diyerek başka yere taşıyıp onunla çalışmaya devam edebiliriz.

Active Directory Sistem Hesaplarını Yönetmek

Managing Computer Accounts

Sistem hesaplarını yönetmek için öncelikle OU ları oluşturmamız gerekir. Ancak OU’ları neye göre oluşturacağız. Normalde Computer accounts (Sistem hesapları) default olarak Computers adı verilen default OU’ya giderler. DC’ler default olarak Domain Controller adı verilen OU’ya giderler.

Genel olarak client sistemler lokasyona göre alt gruplara böünürken server sistemler genellikle görevlerine göre alt gruplara bölünür.

AD içinde sistem hesabı oluşturma yollarından biride o sistemi domain e eklemektir.

AD DS de hesap oluşturmak için

  • Account Operators grubundan
  • Domain admin grubundan
  • Enterprise admin grubundan
  • veya yetkilendirilmiş bir hesabın kullanıcı adı ve şifresi gereklidir. Yetkilendirilmiş kullanıcılar 10 sisteme kadar sistem ekleyebilirler.

AD’de Sistem hesapları yaratılabilir, silinebilir veya taşınabilir.

Ayrıca “Offline Domain Join” kavramı vardır. Bu sistem yöneticisinin domaine alınacak sisteme fiziksel erişiminin olmadığı zamanlarda kullanılabilir.

Bu processte öncelikle ADde djoin.exe çalıştırılır.

PS C:\Users\Administrator> djoin.exe /Provision /Domain c1.local /Machine fs1 /savefile c:\fs1.local-join.txt

Provisioning the computer...
Successfully provisioned [fs1] in the domain [c1.local].
Provisioning data was saved successfully to [c:\fs1.local-join.txt].

Computer provisioning completed successfully.
The operation completed successfully.

Daha sonra oluşturduğumuz c:\fs1.local-join.txt dosyasını clienta gönderip import işlemini yapacağız.

djoin /requestODJ /LoadFile c:\fs1.local-join.txt /WindowsPath %systemroot%

bundan sonra client i reboot ederiz ve client domaine katılır.

Active Directory Grup Yönetimi

Öncelikle grup oluşturmadan bahsedeceğiz. Grup oluşturmadan en önemli nokta grubun nerede oluşturulacağıdır.

Resimde IT’ye sağ tıkladık “new–> group” seçtik ve bu pencere geldi. Şimdi Gruba bir isim vereceğiz ancak aynı zamanda grubun scope unu seçeceğiz. Burada eğer :

Global Group : Bunun içine başka kullanıcıları koyacağımız anlamına gelir.
Domain Local : bu grubu bazı kaynaklara erişim için izin vermek üzere kullanacağız anlamına gelir.
Universal grup : İçine Forest’tan kullanıcı ve grupları ekleyeceğimiz anlamına gelir.

Grup tipinde de

Security Group : içine ACL (Access List)
koyabileceğimiz veya yetkiler atayabileceğimiz anlamına gelir.
Distribution group: genellikle email için kullanılır ve yetki yoktur.

Grubun yerini ve tipini belirledik ve örnekte “IT Users” isminide verdikten sonra ok e basıp oluşturuyoruz. Daha sonra gruba sağ tıklayıp, yerini değiştirebiliriz (Move) veya içine başka grup ekleyebiliriz (nesting) veya diğer işlemleride yapabiliriz.

Grup işlemlerini Powershell ile de yapabiliriz.

Get-ADGroupMember : bir Grubun üyelerini görmek için.
Get-ADGroupMember -Identitiy administrators : Administrator grubunda kimler var görmek için.
Get-ADGroupMember -Identitiy “Enterprise Admins” -recursive : böylece hiyerarşik olarak Enterprise adminlerini görürüz.


Bir grubu restricted yapmakta mümkündür böylece içine kimse isteğimiz dışında atanamaz veya çıkarılamaz. Bunu Group Policy Management Editor ile yaparız. Genellikle en önemli hesaplar bu grupta bulunur.

Restricted Group ayarı :
Computer Configuration –> Policies–> Windows Settings –>Security Settings–>Restricted Groups

Az önce oluşturduğumuz “max muster” kullanıcısı eğer bu grupta değilse onu administrator olarak atayamayız. Atarsak geri çıkarılır. Veya içindeyse çıkarsakta geri alınır.Ama önce DC yi yeni kurduğumuzda korumak istediğimiz grupları buraya eklemeliyiz. Restricted grouplar sadece domain levelde mümkündür.

Ayrıca istersek gruplarda delegate yetkisi verebiliriz. Böylece her hangi bir kullanıcı o grubun üzerinde belirli işlemleri yapmaya yetkili olur. Bunu yapmak için grup ismine sağ tıklayıp “delegate control” seçip sonra wizard ı takip ediyoruz.

Bazı gruplar default olarak kurulmuştur.

Ayrıca protected grouplar mevcuttur. Protected gruplar OU da ki değişimlerden etkilenmezler. Bu grupların amacı policylerin kendilerine enforce edilmesini önlemektir.


Active Directory Groups

Kullanıcıları gruplar halinde yönetmek daha kolaydır. Kullanıcı grupları oluşturmak için ya “Domain admin”, “Account Operator”, “Enterprise Admin” veya “Hesap oluşturmak için izin verilmiş birisi” olması gerekmektedir.

Grup oluşturmadan önce grup tipine karar vermemiz gerekmektedir.

  • Distribution Grup : genellikle email uygulamalarınca kullanılmaktadır. SID yoktur ve security enabled değildir ve bu nedenle izinler buna tahsis edilemez.
  • Security Grup : SID tahsis edilmiştir ve bu nedenle izinler verilebilir. Ayrıca istenirse emailler içinde kullanılabilir.

Gruplar istenirse diğer tipe çevrilebilir yani istersek security grubunu distribution grubuna veya distribution grubunu security grubuna çevirebiliriz.

Grubu oluştururken karar vermemiz gereken bir diğer kavram grubun scope’u dur.

  • Domain Local : Domain Controller a local bir gruptur.
  • Global : Domain içinde kullanıcıları organize etmemizi sağlar
  • Universal : Tüm forest içinde kullanıcılarımızı organize etmemizi sağlar.

Global grup Universal gruba çevrilebilir. Universal grup ise hem domain local a hemde Global gruba çevrilebilir. Lokal sistemde oluşturulan local grup çevirelemez.

Grup yönetimi ve nesting uygulanması (burada İngilizce IGDLA Implementing Group Management and Nesting)

I= Identities, users or computers.
G= Global group ve üye rollerini baz alan üyler ve bu üye rolleride Domain Local grup üyeleridir.
DL = Domain Local Gruplar; bunlar yönetimi sağlar.
A = Assignment yani tahsis etme yetkilendirme.

İlk yapılması gereken hesapları belirlemek ve oluşturmak. Sonra bu hesapları gruplara ekleyeceğiz. Global grup genellikle bir domain için kullanıcı ve bilgisayarların toplanma grubudur. Bunlar daha sonra Domain-Local gruplara bölünür. Domain-Local grupları kaynaklara erişim için izin verilmesini sağlar.

Örneğin ACL_Sales_Read grubu isminden belli olduğu gibi Sales grubu kaynaklarını okuma iznidir.

IGDLA bir işlem sıralaması önerisidir. Sıralama istediğimiz şekilde olabilir. Örneğin her bir yetkiyi kullanıcılara tek tek atayabiliriz ancak kullanıcı sistemden ayrılıp yerine yenisi geldiğinde yeni gelenide tek tek ayarlamak gerekir ki bu o kadar da iyi değildir. Gruplar oluşturulduğunda yetki için yeni kullanıcıyı istediğimiz gruplara ekleriz ve yetkiler otomatik olarak tahsis edilir.

Group Policy – 1

Kullanıcıların sınırlandırılması ve daha pek çok şeyi yapabildiğimiz group policy (GP) ye Server Manager –> Tools –> Group Policy Management dan ulaşabiliyoruz.

Burada (https://win.buyukburc.de/2019/04/26/user-accounts/ ) oluşturduğumuz ilk kullanıcımıza domain içinde bazı haklar vereceğiz. Bunun için GP Management üzerinde Forest –> Domains –> C1.local –> IT ye sağ tıklayıp “Create new Group Policy object and link it here” seçeneğini seçiyoruz.

Herhangi bir isim vermeden ok tıklayıp geçiyoruz. Böylece Sol taraftaki ağaç yapısında IT nin altında beliriyor. Sonra o beliren yen, objeye sağ tıklayıp edit seçiyoruz ve karşımıza “Group Policy Management Editor” geliyor.

Bu ekranda Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment tıkladığımızda yan tarafta IT OU içinde bir kullanıcıya verilebilecek neredeyse tüm hakları görürüz.

Örneğin kullanıcımız “Max Muster” in domain a bir workstation eklemesini istemiyorsak “Add workstations to domain” policysini aktif ederiz.

GP konusuna daha sonra daha detaylı gireceğiz.