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.
Sistemi kullanacak bireylerin bir hesaba (Account) ihtiyaçları vardır. Bunların AD de oluşturulması gerekmektedir. Çeşitli toollar mevcuttur. Powershell, CMD dsad.exe, AD administrative center gibi.
AD users and computers. Server Manager->Tools->Active Directory Users and Computers.
Başlattığımız zaman istediğimiz Domain i açıp (örnekte tek domain var) resimde kırmızı ile işaretli OU’larımızı (organizational Unit) görebiliriz.
Kullanıcıları OU’Lara onları nerede yönetmek istiyorsak ona göre oluşturuyoruz. Yani satışta çalışan birini “sales”e pazarlamada çalışan birini “marketing”de.
Yeni kullanıcıyı örneğimizde IT departmanında oluşturacağız. Bu durumda IT’ye sağ tıklıyoruz ve New de user seçiyoruz.
Kişinin adını soyadını giriyoruz. Burada önemli olan “User Logon Name” eşssiz yani unique olmalıdır. Sisteme girişi bu kullanıcı adı ile yapacaktır. Şirketimizde iki kişi aynı ad soyad ile olabilir. Bu durumda “Max Muster” için logon name ilki MMuster@c1.local diğeri ise MMuster2@c1.local olarak tahsis edilmelidir. Bu durum sistem tarafında otomatik olmaz bizim Sistem yöneticileri olarak standart geliştirmemiz gerekir. Büyük küçük harfe duyarlı değildir. “@c1.local” yanı domain adının olduğu yer aşağıya doğru açılabilir burada UPN (Universal Principal Name) i seçebiliriz.
UPN active Directory Domains and Trusts ile oluşturulur. Örneğimizde kurumumuz birden çok lokasyonda ise ve Max Muster örneğin Ankara’da ise o zaman UPN’i @Ank_it_c1.local gibi olacaktır. Ancak her login oluşta bunu yazması zordur. Bu nedenle bu ismi “truncate” kısaltırız ve emaili ile aynı yaparız.
UPN oluşturmak için “AD Domains and Trusts” a gideriz. Orada C1.local’a değil hemen üstünde bulunan AD Domains and Trusts yazısına sağ tıklarız ve Propertiesden yeni UPN’leri oluşturabiliriz.
User oluşturmaya devam ederken Windows2000 öncesi sistemler için kullanıcı adı biraz farklı eski sistemlere geriye yönelik verilen destek nedeniyle mevcut umarım kullanmak zorunda kalmazsınız 🙂
Next
gelen ekranda parola (password) verme ve parola ile iligili ayarlar var. Zaten yeterince açık.
Next diyince kısa bir özet ve sonra finish ile kullanıcıyı oluştururuz. Artık kullanıcımız IT OU sunun altında bizi beklemektedir. Ona sağ tıklayıp pek çok özelliğini değiştirebiliriz.
Logon olma saatleri veya kilitlenmiş hesabın yeniden açılmasını buradan yapabiliyoruz.
Ayrıca bir kullanıcıyı kopyalayabiliriz. Örneğin Satış departmanında çalışacak kişilerden ilkini oluşturduk daha sonra bu kişinin hesabını bir şablon olarak kullanarak aynı ayarlarla diğerlerini oluşturabiliriz. Kopyalama işlemi aslında bir şablon oluşturmadır. Bundan sonra satış departmanında ki her birey için o hesabın bir kopyası oluşturulur ve yaratılır.
Kullanıcı silme işlemide buradan yapılır ancak önerilen önce kullanıcının “disable” edilmesi ve bir süre böyle bırakılması. Daha sonra kullanıcı geri gelirse enable edip devam etmesi sağlanabilir.
Kullanıcıyı oluşturduğumuza göre artık ona bazı haklar verebiliriz. Bunuda “group policy” (GP) ile yaparız. GP ile yapılan kullanıcıların sınırlandırılmasıdır.
İngilizce FSMO okunurken (fezmo) diye okunuyor ilginç geldi 🙂
Neyse DC arka planda çok işler yapar. Bunlar domainin düzgün çalışmasını sağlar.
Forest ın ilk DC si otomatik olarak Forest Root tur. İlk olduğu için bazı görevleride otomatik olarak almak zorundadır.
1- Domain Naming Master 2- Schema Master
Powershellde bu bilgileri edinmek istersek.
Böylece hangi DC hangi rollerde görebiliriz.
Forest Root DC 3 temel FSMO görevini icra eder.
1- RID master : BU rol ile yeni objectler oluşturabiliriz. Objectler AD de oluşturulurken RID master gerekli identifier ve numaraları sağlar ve diğer DC’leri update eder. Böylece bir DC yeni bir object oluşturmak istediğinde ve ona yeni bir SID tahsis etmek istediğinde, RID master tan aldığı bloğu kullanarak SID i oluşturur. Böylece her bir Object için unique ID oluşmasını sağlar.
2- Infrastructure Master : Çok domainli ortamlarda eğer bir useri alıp başka bir domaine taşımak istersek; Insfrastructure Master bu değişikliklerin takibini yapıyor.
3- PDC Emulator : Domain içinde zaman senkronizasyonunundan sorumlu. Böylece tüm DC’ler aynı zamanda olur. Ayrıca eğer bir Group Policyde (GP) değişiklik yapmak istersek bu değişimde PDCde olur. Ayrıca şifre değikliği olduğu zaman bu değişiklik PDC’ye gider ve acil mesaj olarak tüm diğer DC’lere ulaştırılır.
Yukarıda bahsettiğimiz bu görevler Forest Roottan başka DC’lerede paylaştırılabilir. Kimin hangi rolde olduğunu powershellden de görebiliriz.
Peki forest root DC ye bakım update patching vs yapılacağı zaman sistemi down etmek gerektiğinde ne yapmamız gerekir?
İşte bu rolleri taşıyabiliriz. Bu taşıma işlemi bir kaç yolla yapılabilir. Powershell, Snap-in veya ntdsutil.exe
Transfer esnasında en son güncel veri kullanılır. Böylece kayıp oluşmaz.
Ancak peki ya bu FSMO görevlerini taşıyan DC çökerse, crash olursa veya …
Bu durumda yapılan işleme “Seizing Roles” denir. Bu durumda eksik veya zamanı geçmiş veri kullanılır.
BU işlem için Powershell veya ntdsutil.exe kullanılır ancak snap-in kullanılamaz
Transfer etmek için gerekli toollar server manager üzerinde tools menüsü altında. Örneğin Schema Master’ı transfer etmek istersek Server Manager–> Tools –> Active Directory Schema, veya Domain Naming Master’ı transfer etmek istersek Server Manager –> Tools–> Active Directory Domanins and Trusts, eğer RootMaster, Infrastructure Master veya PDC Emulator’ü transfer etmek istersek Server Manager–>Tools–>Active Directory Users And Computers’ı kullanırız.
Ancak Seizing için ntdsutil.exe yi veya Powershell i kullanmamız gerekiyor.
Powershell komutu :
Move-ADDirectoryServerOperationMasterRole
Sistem üzerinde hangi FSMO rollerinin hangi DC’lerde oldğunu bilmek önemli. Powershell in bu komutu detaylandırılmadı.
DC kurulumunda otomatik olarak oluşturulurlar. DC kurulup yeniden başlatıldığında “Net Logon servisi” başlar ve SRV kayıtları oluşturulur. SRV kayıtları bir çeşit DNS kaydı gibidir. Ağa bağlanan clientlar hangi servera logon olacaklarını bu kayıtlardan öğrenir.
SRV kayıtlarını en iyi DNS manager üzerinden görebiliriz. Bunun için Server Manager –>tools –>DNS i seçiyoruz.
Şimdi burada “_” altçizgi ile başlayanlar örneklerdir. Bunlardan “_tcp” yi seçtiğimizde tcp protokolü için olan kayıtları görüyoruz. Burada “_gc” Global Catalog Serverini tanımlıyor. Bu hem Dc ye hemde bağlanan clientlara gerekli.
“_kerberos” Kerberos serverinın nerede olduğunu gösteriyor. Kerberos login olmak için kullandığımız protokol.
“_kpassword” ayrıca bir DC dir.
“_ldap” yine DC üzerinde koşuyor.
“_udp” de de benzeri kayıtları görebiliriz.
SRV kayıtları hem diğer DC ler için hemde clientlar için gereklidir.
Şifre değiştirirken bile kullanılır. Eğer kayıtlarda bir sıkıntı varsa DC üzerinden “net logon service” restart edilir.
Burada Forest içinde Server ımızı bulduk ve şimdi onu bir DC yapacağız. Sağ panelden “NTDS Settings”e sağ tıklayıp özelliklere giriyoruz.
Görüldüğü üzere C1-DC1 zaten Catalog Server olarak seçilmiş. Pek çok özellik otomatik olarak zaten kurulmuş olarak gelecektir.
Bunlardan önemli bir tanesi SRV kayıtlarıdır. DC kurulumunda otomatik olarak oluşturulurlar. DC kurulup yeniden başlatıldığında “Net Logon servisi” başlar ve SRV kayıtları oluşturulur. SRV kayıtları bir çeşit DNS kaydı gibidir. Ağa bağlanan clientlar hangi servera logon olacaklarını bu kayıtlardan öğrenir.
RODC yani Read Only DC. Uzak bir lokasyonda yani bizim için kontrolü nispeten zor bir ortamda, sadece bzim kontrol edebileceğimiz bir DC içindir. Daha güvenlidir. Özellikle IT personeli olmayan uzak ofislerde kimin login olup olamayacağını belirlediğimiz bir sistemdir. Normal bir DC de olan tüm objectler mevcuttur.
RODC oluşturmak için kurulumda gerekli seçeneği aktif etmek gerekir.
Ana DC RODC de kimin şifrelerinin Cache leneceğini belirleyebiliriz. Tek yönlü replikasyon yapılır.
RODC için (henüz nerede bilmiyorum) bir properties de “Password Replication Policy” bölümü mevcut orada hangi kullanıcı ve groupların passwordlerinin cache yapılacağına karar veriyoruz. (deny allow şeklinde.
Password Replication Policy Domain çapında olduğunda iki group otomatik olarak gelir.
Allowed RODC Password Replication Group
Default olarak grupta kimse yoktur.
Buraya eklenenler RODC’ler tarafından cachelenir.
Denied RODC password Replication Group
Buraya şifrelerinin hiç cachelenmasini istemediğimiz kullanıcıları ekleriz.
Default olarak : Domain adminleri, Enterprise Adminleri ve Group Policy sahipleri mevcuttur.
Böylece tüm RODC’leri bir defada ayarlamış oluruz.
Diğer bir yöntemde “Password Replication Policy (Individual RODCS)
Önerilen Best Practice ise öncelikle Global bir Deny list oluşturmak daha sonrada her bir RODC için izin verilen User ve groupları authentication için local olarak belirlemektir.
RODClerde bazı kısıtlamalar mevcuttur.
Master DC olamazlar
Bridgehead Server olamazlar ????????
Her domainde bir site için bir RODC olabilir.
WAN connection mevcut değilse RODC’ler trustlar arası authentication yapamazlar. Eğer Deny listtle olan biri authenticate yapmak isterse WAN üzerinden kontrol etmesi gerekecektir ancak WAN olmayınca bu mümkün olamayacaktır.
Özellikle yavaş ve güvensiz ağ ortamlarında başka bir yere AD kurmak istiyorsak. IFM denilen uygulama yöntemini kullanabiliriz. Böylede SYSVOL veya DB yi aktarma daha güvenli olur.
IFM = Install For Media
NTDS ile CLI kullanarak AD yi backup alıp bu backup mail veya CD/USB ile uzak yere gönderip. Server manageri kullanrak AD yi kuracaklar.
Böylece büyük AD backup ı veya SYSVOL klasörü ile uğraşmaytacaklar.
Server manager ile kurulum esnasında “Additional Options” bölümünde “install from Media” seçilerek alınan backup seçilip sonra hangi AD replike edilecek seçilerek devam edilecek.
Öncelikle Hyper-Vde normal bir şekilde generation-2 tipte Vm kuruyoruz. (ben alan ve RAM yetersiz olduğu için 30GB disk ve 1024MB Ram verdim).
Takiben sysprep.exe (Windows\System32\sysprep\sysprep.exe yi çalıştırıyoruz.
Generalize ve shut-down seçili olacak. Böylece hostname, ip, bazı donanım driverları gibi özellikler silinip geriye bir şablon sistem çıkarılıyor. Sistemide işlem bitince kapatıyor. Böylece elimizde bir şablon.vhdx diski oluşuyor. Bu diski kolay kullanmak için kopyalıyorum
cp “C:\VMs\C1-base\Virtual Hard Disks\C1-base.vhdx” C:\VMs\C1-base.vhdx
Takiben Powershell i açıp önce bir klasör oluşturuyoruz
Name State CPUUsage(%) MemoryAssigned(M) Uptime Status Version —- —– ———– —————– —— —— ——- C1-DC1 Off 0 0 00:00:00 Normaler Betrieb 8.3
Password ve geri kalan herşey aynı ancak bu DC olacağı için static IP vermek gerekiyor. Hyper-V den başlatabilirsiniz.
Veya hazır powershellde iken
Start-VM C1-DC1
Sisteme consolo veya RDP ile bağlanıyoruz. Öncelikle Dil, sonrada Administrator şifresini tanımlamamız lazım. Daha sonra EULA’yı kabul edip başlangıç ekranına ulaşabiliyoruz.
Simple Network Management Protocol – yani kısaca SNMP. Her sorgulanabilecek item ın bir ID si var ve bunlara OID deniyor.
internet domain e benzer hiyerarşik bir yapıda.
Bununla ilgili bir kaynak web sitesi :
http://www.alvestrand.no/objectid/1.3.6.1.2.html
Okuldu güzel bir çalışma yaptık dün bir sistem server diğeri agent ın kurulu olduğu client oldu.
Agent üzerinde aşağıda ki işlemleri yaptık. Sistem Debian minimal 9
apt install snmpd
/etc/snmp/snmpd.conf folgendes içinde: # Listen for connections from the local system only #agentAddress udp:127.0.0.1:161 # Listen for connections on all interfaces (both IPv4 *and* IPv6) agentAddress udp:161,udp6:[::1]:161 # rocommunity public default -V systemonly rocommunity public default view systemonly included .1.3.6.1.2.1
Sonrada : service snmpd restart
Server üzerinde aşağıdaki işlemleri yaptık. Sistem Debian minimal 9
apt install snmp
Daha sonra Agent sistemin ip sini not edip sorgulamaları yapıp görebildik.
snmpwalk -v 1 -c public 172.16.1.100 .1.3.6.1.2.1.2.2.1.2
Şimdi işler burada karışmaya başlıyor. bu (.1.3.6.1.2.1.2.2.1.2) nedir?
İşte OID budur. Çok fazla detay sorgulayabildiğimiz için kod kullanmışlar. Sistemde ne kurulu ne kadar ram var vs vs vs …. Daha sonra bir örnek ekleyerek açıklayacağım.
Ancak temel olarak her basamak biraz daha derinleştiriyor. örneğin
.1.3.6.1.2.1.2.2.1. bu üst yapı altta ki
.1.3.6.1.2.1.2.2.1. .1.3.6.1.2.1.2.2.1.1 .1.3.6.1.2.1.2.2.1.2 .1.3.6.1.2.1.2.2.1.3 gibi alt yapıları barındırıyor. İşte bu noktada alt yapıyı tümden görmek istiyorsak snmpwalk komutunu eğer tek bir item ın cevabını almak istiyorsak snmpget komutunu kullanıyoruz.
çok basit anlamda SNMP ye değindik umarım daha çok öğrenmek mümkün olur.
SNMP yi özellikle network takibinde MRTG ve PRTG gibi uygulamalar çok kullanıyorlar. Her üterici MIB dosyası ile SNMP bilgilerini paylaşıyor. Daha çok şey var öğrenilecek.
Forest kurulumu iki basamaklı bir processtir. İlk adımda files (dosyalar) kurulur. Sonrada konfigürasyon yapılır.
Kuruluma server manager ile başlıyoruz ve buradan “Add Role” ile AD DS yi seçiyoruz. Kurulum bitince kurulum sonrası yapılandırma gerekiyor burada “Forest” kuracağımız için “Role-Based” i seçiyoruz. Diğer seçenek “Remote desktop based” Kurulum ancak biz Role-based ile devam ediyoruz.
Daha sonra Forest ımıza hangi serveri ekleyeceğimizi soracak. Mümkün mertebe en az Server2016 ile iş tutmaya bakın. Yoksa 2012R2 de olabilir ama öncesine gitmeyin 64 bit desteği olmayabilir. Hatta çoğu zaman olmayacaktır.
Server dan sonra tekrar role seçimi olacaktır bu sefer role server rolü ve “AD DS” seçilecek.
Ek feature isteyip istemediğimizi soracak, istediğimiz ekstra birşey yoksa next ve confirmation ile kurulumu tamamlicaz.
En sonrada serverımızı “Promote to domain controller” seçeneği ile restart edip artık DC mizi başlatmış olacağız.
Şimdi buraya kadar ilk basamak hallolmuş ve file kurulumları tamamlanmıştır. Artık konfigürasyona geçebiliriz.
Yeni bir Forest kurmadan önce değerlendirmemiz ve belirlememiz gereken bazı konular vardır.
Yeni bir forest mı yoksa tree mi?
Ek DC kurulumu gerekliliği
FQDN ne olacak?
Forest funtional level ne olmalı? (DC serverlarının hepsi 2016 değilse 2016 fonksiyonelliğini kullanamazsınız.)
Domain Fonksiyonel seviyesi ne olacak?
Hangi DC de DNS server ve Global Catalog bulunacak.
Eğer birden çok domain varsa eeher domain e bir Global Catalog gerekecektir.
RODC kurulacak mı? Ilk DC RODC olamaz.
Directory Server Restore Mode (DSRM) şifresi ne olacak? Bu şifre AD yi restore etmemiz gerektiğinde lazım olacak o nedenle önemli ve mutlaka güvenli bir yerde saklanması gerekiyor.
Ayrıca domain NetBIOS isminede karar vermek gerekiyor. NetBIOS ismi geriye uyumluluk için gerekli.
Database, log dosyaları ve SYSVOL klasörlerinin yerlerine de karar vermek gerekiyor.
Default olarak veri tabanı ve loglar “C:\Windows\NTDS”
Default olarak SYSVOL klasörü “C:\Windows\SYSVOL”
Bütün bunlar organizasyonun boyutu vs ile ilgilidir. Bu noktadan sonra artık uygulamaya geçiyoruz.
