PowerShell Integrated Scripting Environment -ISE-

 

 

PowerShell 2.0 ISE ; komutları çalıştırmak için , düzenlemek ve debugging için grafik arayüzüne sahip bir ortam sunuyor ( daha fazla kullanıcı dostu da diyebilirsiniz ) Varsayılanda Windows Server 2008 R2 ile kurulu gelmiyor ama isterseniz ki muhmetelen istersiniz , Server Manager konsolundan aşağıdaki ismi geçen feature’ı ekleyip kullanabilirsiniz.

 

Kurulum sonrasında görünümü aşağıdaki gibidir.

Herkese iyi çalışmalar sorunsuz ve neşeli günler ,

barisca

mstsc.exe ile RDP bağlantısı problemine dair….

Yakın bir zamanda domain’e üye iki adet member server kurmuştum. (Windows server 2008 R2 SP1 Ent.)

Her nedense sunucular, netstat -an ile baktığımda remote destop portunu yani tcp 3389 ‘u dinlemiyordu. Tabi bu aşamada acaba remote dektop açıkmıydı yada firewall uygunmuydu diye düşünen varsa yazının devamını okumasın …

Bu neden kaynaklandı bilmiyorum doğrusu ,

Ama şu şekilde bir çözüm ile düzeldi.

İlgili sunucunun kayıt defterinde , terminal server altındaki RCM subkey’inin permission’larına Network Service hesabını ekleyip tam erişim verince ve ardından sunucuyu yeniden başlatınca düzeldi. Artık sunucularım rdp portlarını dinlemeye başladı. İlginç. …

Power Shell V2 ve Active Directory Modülüne dair…

Son bir kaç yılda izlenebileceği üzere Windows 7 ve Windows Server 2008 R2 devri bağladığından beri PowerShell V2 ile beraber shell yapısının kullanım oranı da artmaya başladı . Özelikle Remoting ve scripting tarafındaki yenilikler yeni shell’I daha da cazip hale getirmeye başladı. Daha önce de PowerShell V2 ile ilgili bir yazı yazmıştım.Şimdi ki yazımızda bunun devamı niteliğindendedir ve Power Shell V2 ile Active Directory objelerinin yönetiminden bahsedeceğiz.

Test için Windows Server 2008 R2 Hyper-V platformunu kullandım.

Lab ortamımızda bulunan makinemiz;

Domain : nwtraders.msft

DC makine adı: testdc.nwtraders.msft

DC ip adresi : 10.11.27.245 /24

Active Directory Module for Windows Power Shell i açıyoruz. Burası AD modülü için ayrıca tasarlanmıştır. Tabi ki power shell’i de açarak AD modülünü import edip aynı alana ulaşabilirsiniz.

Öncelikle Get-Command komutu ile AD de yani AD modülünde neler yapabiliriz bir bakalım:

Output’dan gördüğümüz gibi çalıştırabileceğimiz komutlar “Name” kolonunda ve tanımıda da “Definition” kolonunda açıklanmıştır.

Bir kaç örnek kullanımı inceleyelim.

Nwtraders.msft domainimize yeni bir computer objesi ekleyelim.

Komut tamamlandıktan sonar GUI’den bakacak olursak hesabın açıkdığını görebiliriz.

Şimdi de bir pre-staging uygulaması yapalım.

Daha önceden bir notepad’e yazılmış computer isimlerini alıp AD içerisine objeleri oluşturalım. Amaç isimleri notepad’den almak olacaktır.

Test.txt dosyamız c:\ altında kök dizindedir ve içeriği aşağıdaki gibidir.

 

Şimdi de power shell de dosya içeriğini bir görüntüleyelim

Import işleminden önce content’i gözlemek olası bir sorunu öncesinden çözmek açısından iyi olabilir.

Ve dosya içerisinde isimleri yazan computer accountlarını AD içerisine oluşturalım.

Komut tamamlandı. GUI’den gözlersek sonuç aşağıdaki gibidir.

 

Şimdi de txt dosyasından bilgilerini alarak oluşturduğumuz computer accountları için “location” attribute’u bilgisinin “Main Office” şeklinde doldurulmasını sağlayalım.

İkinci komut sorunsuz çalışmıştır. GUI’den de sonuçlarına bakabiliriz.

Önce ilk oluşturduğumuz computer için bakalım. Bu computer hesabını txt dosyasındaki content’i kullanarak açmamıştık! .

 

Nw-cli-5 için location bilgisi boş iken nw-cli-6 ‘nın yani dosya içerisinden ismi çekilerek oluşturulan computer’un location bilgisinin dolu olduğunu görüyoruz.

 

Computers container’ında bulunan computer accountlarını listelemek için ise;

Genel olarak computer’lar için daha ayrıntılı bilgi almak istersek,

 

Listelediğimiz computer’ları computers container’i içerisinden “client computers” ou’su içerisine taşıyalım.

Ve yine GUI’den gözlemek istersek ,

sonuç resimdeki gibidir.

Computers container’ına da bakacak olursak taşındığını görebiliyoruz.

Herhangi bir komut yada AD modülündeki komutlar hakkında bilgi icin;

Yazı dizimizi okumaya devam edin bir sonraki powershell yazısında görüşmek dileğiyle….

Kaynak : Microsoft TechNet

 

 

 

 

 

 

 

 

 

Power Shell 2.0 ‘ın yenilikleri

Remoting

Uzak sistemleride script çalıştırabilmesi özelliği PS 2.0 ‘ın en gözde yeniliklerinden bir tanesidir. Böylelikle ağınıza bağlı uzak sunucularda scriptlerinizi çalıştırabilirsiniz. Remoting ‘den faydalanabilmek için hem kullandığınız bilgisayarda yada sunucuda hemde uzak bilgisayarda yada sunucuda PS 2.0 yüklü olmalıdır.

İlerleyen yazılarımızda bu özelliğin yapılandırılmasını ve kullanımı inceleyeceğiz.

ScriptCmdlets

PS 2.0 , sistem yöneticilerine yani administrator’lara PS’in kendisini kullanarak ScriptCmdlet ‘ler oluşturma imkanını sağlamıştır. (PS 1.0 ‘da bu işlem genelde developer’ların yapabildiği bir işti)

Yine get-help komutu ile about_scriptcmdletmethods yada paramaters komutları kullanılabilir.

Yenilikleri elbette üstte yazdıklarımla sınırlı değil. Saymak istersek ; background job , script debugging , hosted APIs , yeni değişkenler , cmdlet’ler , operatorler ve dahası ….

Kaynak : Technet

Active Directory Sertifika Servisleri – 2

Bir önceki yazmızda sertifika servisleri , sertifikalar ve genel kullanımlarını örneklerle açıklamıştık. Bu yazımızda , sertifikaların kullanımları ile devam edeceğiz ve farklı kullanım alanlarını inceleyeceğiz.

Yazıda örneklekdireceğimiz uygulamalar ,

–          Cisco router’a , windows server 2008 R2 enterprise üzerine kurulu bir sertifika otoritesinden sertifika alınması

–          Kullanıcının , pdf dökümanını sertifikası ile şifrelemesi

konularını inceleyeceğiz.Öncelikle lab ortamımız hakkında bilgi verelim.

Domain : nwtraders.msft

CA : NW-CA

CA’in kurulu olduğu sunucu : bs-dc.nwtraders.msft

Router :  IOS versiyonu , 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(4)T1

DC’in ip adresi : 172.26.1.1 / 16

Router’ın ip adresi :  gigabitethernet 1/0 ‘a 172.26.100.100 /16

Kullanacağım kısaltmalar :

NDE : Network Device Enrollment

Öncelikle , NW-CA otoritesine  Network Device Enrollment rol servisini ekleyelim. Server manager’da add role service link’inden bunu yapabiliriz.

Sonrakı ekranda, bu rol servisinin kullanacağı hesabı belirlememizi istiyor. Nwtraders\nde isimli hesabı kullanıyorum.NDE isimli hesabın herhangi bir özelliği yoktur. IUSRS grubuna üyedir.

Üstteki kullanıcı , IIS_IUSRS grubunada üyedir.Sonraki menümüzde ,

NDE servisinin sertifika yönetiminde kullanacağı  otoriteyi yapılandırıyoruz. Optional bilgileri yazmıyorum. Otorite ismi olarak’ta BS-RA seçtim.

Ardından , kullanılacak olan tedarikçileri ve key uzunluklarını belirliyoruz. Resmetmeye gerek duymadım. Varsayılan tedarikçiyi kullanıyorum. Sihirbazın son kısmında , özet mevcut.

Özet kısmında altını taradığım URL’yi ileride kullanacağız. Bu sırada router’ı yapılandıralım. Router’ın yapılandırılması;

–          Domain Suffix’i

–          DNS adresi

–          NW-CA tanımı

–          Router’a sertifika alımı

şeklinde olacaktır. Router’ın ilgili interface’ine IP ataması yapılmıştır.

DNS suffix’i ve DNS ip’sinin belirlenmesi üstteki gibidir.Router’ın ismininde çözülmesini istersek DC üzerinde kurulu olan DNS server’da router adına bir kayıt açabiliriz.

Üstte görüleceği üzere , router’ın isminide çözümledik. Router’ı komut arayüzünden yapılandırıyoruz (console). Security Device Manager ile rotuer’a bağlanmak istersek , bazı aşamalarda bizden yetkili bir kulalnıcı ve SSH ile güvenli bir bağlantı isteyecektir. Bu duruma karşılık , router’ı ssh ile bağlantı kabul edecek şekilde yapılandıralım. SSH için router’a bir adet sertifika üretelim.

Üstte gürüldüğü gibi , genel amaçlı bir sertifika ürettik. Şimdi SSH için bir kullanıcı oluşturalım ve SSH’i yapılandıralım.

SSH hazırlandı.Aşağıdaki resimden görüleceği üzere ,

yetkili kullanıcıyıda hazırladık. Bu işlemler birer zorunluluk değildir , SDM kullanmak isterseniz ihtiyacınız olacağından yazıya ekliyorum.

Router’a sertifika alımı ile devam edebiliriz. Öncelikle , router’ın NW-CA’ya güvenmesini sağlayalım. Bunun için router’da trustpoint belirliyoruz ve enrollment için kullanacağı URL’yi tanıtıyoruz.

Komutları tab tuşu ile tamamladığımdan , komutun tam halini farklı renkte tarıyorum. Burada yaşadığım bir problemi yazıya eklemek istiyorum. NW-CA otoritesi kurulurken , private key uzunluğunu , 4096 bit seçilmişti. Henüz resmetmediğim router’a otoriteyi tanıtma sırasında , router 4096 bit’lik NW-CA’nın sertifikasını okuyamadı(IOS versiyonundan olduğunu düşünüyorum). Ondan dolayı NW-CA otoritesini kaldırdım (remove role). Yeniden bir otorite kurdum. Private Key uzunluğu 2048 bit’liktir. Yeni otoritenin ismide CA-BS ’dir. Üstteki resimde görüldüğü gibi , trustpoint belirlerken , NW-CA’yı seçmiştim şimdi trustpoint’i CA-BS şeklinde değiştiriyorum.

Enrollment URL’sinde bir değişim yoktur. Şimdi , eklediğimiz trustpoint’i router tarafında yetkilendirelim (authenticate, sonrasında router’a sertifika alacağız). Bu arada , router’da hata denetimi için , debugging’i de açtığımdan ondan dolayı aralarda farklı mesajlar görülüyor. BS-CA ‘yi yetklilendirme yöntemimiz  alttaki resminde görüldüğü gibidir.

Şimdi router ‘a sertifikasını alabiliriz. Yine gerekli komut aşağıdaki resimde görüldüğü gibidir. Router’a sertifika talebinde bulunduğumuzda , talebin tamamlanması için bizden bir password isteyecek. Gerekli olan password’e http://ca.nwtraders.msft/certsrv/mscep_admin link’inden ulaşabiliriz. Her talep için yeni bir parola üretilecektir!!

Üstte görüldüğü gibi , talebimizi gerçekleştirdik.Bizden istediği bilgileri doğru şekilde doldurmaya dikkat etmeliyiz ki , ileride sertifika ismi yada kullanım amacı konularında sorun yaşamayalım.

CA-BS yönetim konsolundaki , onaylanmış ve alınmış sertifikalara bakarsak , r1-nw isimli router’a alınmış belgeyi görebiliriz.

Üstte görüldüğü gibi router , istediğimiz isimde ve kriterlerde sertifikasını almıştır. Router’in running-config ‘iği açıp yine aldığı belgeyi oradan da görebiliriz. Bunun için ; show running-config komutunu çalıştırmak yeterlidir. Yada router üzerindeki sertifikaları görmek isterseniz,

üstteki gibi show crypto ca certificates verbose komutu da kullanılabilir.

 

Şimdi de , Adobe Acrobat 9 Pro ile pdf dökümanı hazırlayalım ve  dökümanı , bir user sertifikası ile şifreleyelim. Burada , administrator kullanıcısına alınmış bir user sertifikasını kullanacağım. Domain Controller üzerine Adobe Acrobat yazılımını kurdum. Administrator kullanıcısının DC üzerinde yüklü olan sertifikalarına bakacak olursak ,

sahip olduğu user belgesini görebiliriz (personel isimli klasöre bakmayı da unutmayınız!). Bu belge ile oluşturacağımız pdf’i şifreleyelim. Acrobat 9 Pro yazılımı açıyorum.

PDF dökümanını kaydetmeden önce , sertifika ile şifreleme opsiyonunu seçiyorum. İlk ekranı next ile geçtiğimde , Acrobat 9 , şifreleme için kullanılabilecek olan sertifikaları gösteriyor.

Seçili olan , sertifika ile pdf’i şifreliyorum. PDF dökümanını , masaüstüne kaydedebiliriz. Deneme amacıyla , pdf dökümanını başka bir pc’ye alıp açmaya çalışırsak ,

resimde görüldüğü gibi hata alıyoruz , çünkü , pdf’i şifrelemek için kullandığımız belge test için kullandığım pc’de  kurulu değil. Şifrelemek için kullandığımız sertifikayı test için kullandığımız pc’ye de kurarsak , pdf açılmaktadır.

Bu yazımızda da yine sertifikaların kullanımına dair örnekler verdik. Sonraki yazılarımızda yine otoritelerin yönetimi ve sertifikaların kullanımına dair uygulamalara devam edeceğiz.

Kaynak : Technet Library , Cisco Offical Web Site

PowerShell de nedir ?

Microsoft’un geliştirdiği ; .Net Framework yapısı  ile entegre olmuş , scripting dilini kullanan , komut satırı arayüzünü ( yani shell’i ) kullanan ve görevleri otomatize  etmek için kullanılan bir framework’tür.

COM ve WMI yapısına sağladığı tam erişim ile gerek yerel bilgisayarda gerekse uzak sistemlerde ( gereksinimleri sağlayan ) , sistem yöneticisinin  yönetimsel görevleri yerine getirmesini sağlar. Bu yazımda ve ilerleyen yazılarımda power shell için PS kısaltmasını kullanacağım.

PS içinde yönetimsel görevler cmdlet ‘ler ile yürütülür. Genelde script’ler ile yada bir nevi uygulama dosyaları olan executable dosyalarıyla yada  .net class’ları ile  birleştirilir ve PowerShell  komut satırı aracı ile gerçekleştirilir.

PowerShell ‘in son sürümü şimdilik 2.0 ‘dır ve Windows 7 ve Windows Server 2008 R2 ile varsayılanda gelmektedir.

 

image

Active Directory Sertifika Servisleri – 1

Sertifika Servisleri , Public Key teknolojilerini esas alan güvenlik sistemleri tarafından kullanılan, dijital sertifika üretmek ve sertifikaları yönetmek gibi servislerı sunan , kimlik denetimi ve erişim kontrolü sağlayan güvenlik teknolojileridir.

Organizasyonlarda ; kişinin , cihazın yada servisin kimliğini  bir private key’e bağlayarak güvenliği arttırır ve sertifika yönetiminde organizasyona düşük maliyetli , etkin ve güvenli bir çözüm sağlar.

Sertifika servisleri tarafından desteklenen uygulamalara bakacak olursak ;

– S/Mime (Secure / Multipurpose Internet Mail Extensions)

– Kablosuz bağlantılarda güvenlik

– VPN

– IPSec

– EFS

– Smart Card ile oturum açma

– SSL ve TLS

– Dijital imza

şeklinde geniş bir yelpazeye sahip olduğunu görebiliriz. Windows Server 2008 tarafındaki CA yeniliklerine bakarsak :

– Router gibi network cihazlarına sertifika verebilecek olan Network Device Enrollment (mscep.dll dosyasını hatırlarsınız)

– Sertifika durumunun daha hızlı kontrolünü sağlayan Online Responder Service  şeklindedir.

Yazımızda  , ilgileneceğimiz konuları sıralamak gerekirse ,

CA seçimi ve kurulumu ,

Key Archival için konfigürasyonlar

Sertifika şablonları ve yeni şablon oluşturma

Sertifikaların dağıtımı

IIS (7.5) üzerinde SSL sertifikası ile web sayfası yayınlanması

Güvenli E-mail transferi

şeklinde sıralayabiliriz. Test ortamında Windows Server 2008 R2 Enterpise, Windows 7 Ultimate , Windows Server 2003 R2 Enterprise işletim sistemleri kullanılacaktır.

Yazı içinde geçecek olan bazı kısaltmaları açıklayayım.

IIS : Internet Information Servis

CA : Certificate Authority

NW-CA Kuracağımız sertifika orotitesinin ismi.

Certsrv : IIS altında bulunan ve web üzerinde sertifika alabilmemizi sağlayan alt dizin.

Windows Server 2008 R2 , DC ve CA olarak hizmet verecektir.

Windows 7 , istemci olarak hizmet verecektir.

Windows Server 2003 R2 , POP/SMTP server olarak hizmet verecektir.

Active Directory Domain Servislerinin kurulumu , e-mail servislerinin kurulumu ve adımları bu yazıda yer almamaktadır.

Domain ismi: nwtraders.msft

DC:  bs-dc.nwtraders.msft

E-mail Server: bs-smtp.nwtraders.msft şeklindedir.

CA kurulumu

Server Manager’dan rol ekleme sihirbazı yardımı ile CA yapısını kuralım.

image001

Kurulum öncesinde domain servisleri ve dns yapılandırıldığından roller arasında seçili görünmektedir. Anlaşılacağı üzere CA servisini domain controller üzerine kuruyorum.

İlerlediğimizde rol servislerini göreceğiz

image002

İşaretli olan rol servisi bizim için çekirdek servistir.Sertifika dağıtımı, yönetimi için kullanılmaktadır.

Web enrollmentrol servisi ; kullanıcıların sertifika talebi ve yenilemeleri için , revocation list’e erişim için ve smart card sertifikalarının dağıtımı için basitleştirilmiş bir web arayüzü sunmaktadır.

Online Responder ; kompleks  yapılar içinde  , “revocation” kontrolünü daha rahat erişilebilir kılmaktadır.

Network Device Enrollment ; Network cihazlarına sertifika alımını sağlamaktadır.

Enrollment Web Service ; kullanıcıların ya da bilgisayarların , bilgisayarlar domain üyesi olmasa bile ya da domain network’ünde olmasa bile , sertifika almasını sağlamaktadır.

Enrollment Policy Web Service ; bir üstteki rol servisi ile kooperatif çalışan bir servistir.

Rolleri seçerek kurulumu devam ettirelim. Web enrollment  rol servisini seçtiğimizde IIS bileşeni de kurulacaktır.Network device enrollment rol servisini ve altındaki 2 role servisini seçtiğimizde , CA kurulumu ile aynı anda yapılamayacağını gösterir bir uyarı alırsınız. Bu rol servisini kurulumu tamamladıktan sonra kurabilirsiniz. Bu arada , son rol servisi için Enterprise Adminsgrubu üyesi bir kullanıcı kullanmanız gerekir. Altta görüleceği üzere ilgili rol servislerini seçtik ve kuruluma devam ediyoruz.

image003

Eğer yetkili bir hesap ile giriş yapmadıysanız , aşağıdaki resimde aktif durumda olan Enterprise CA türü pasif olacaktır.

image004

Enterprise CA türü , active directory yapısına ihtiyaç duyar ve sertifika dağıtımı için AD servisini kullanır.

Standalone CA türünün  , sertifika dağıtımı ve yönetimi için AD servisine ihtiyacı yoktur. Domain üyesi bir sunucuya da kurulabilir. Bu CA türünde , Auto-Enrollment’ın rahatlığından faydalanamayız.

Biz Enterprise CA kuracağız. Dolayısıyla auto-enrollment’dan yararlanabileceğiz.

image005

Sırada tip seçimi gelmektedir.CA yapısının hiyerarşisi gereği , subordinate kurabilmek için root CA’e ihtiyacımız var. Bunu, root domain ve child domain gibi düşünebilirsiniz.

Ardından CA için private key konfigürasyonu gelmektedir. Varsayılan hali ile devam edebilirsiniz. Ben test ortamımda biraz değiştireceğim.

image006

Eğer , w2k8 ve Vista ile gelen Suite-B şifreleme algoritmasını kullanmak isterseniz , Service Provider seçiminde ,

image007

ECDSA_P256 ile devam etmelisiniz (Eliptic Curve Digital Signature Algorithym) . Ben , varsayılan tedarikçiyi kullanıyorum. Anahtar uzunluğunu 4096 yapıyorum ve Hash algoritmasını SHA 512 olarak seçiyorum.

Bir sonraki menüde  , CA ismi belirtilmekte. CA’in ismini NW-CA olarak belirliyorum. Sade bir menu olduğundan resmetme gereği duymadım.

İsim belirleme sonrasında , CA’in geçerlilik süresi gelmekte. Varsayılan değerinde yani 5 yıl şeklinde bırakıyorum.

Geçerlilik süresinden sonra CA veritabanının ve log’larının kaydedileceği yerler görünmekte. Test ortamımda değiştirmiyorum. Siz , şirket politikanız doğrultusunda , veritabanını ve log’ları farklı bir yere alabilirsiniz. (raid yapınıza uygun şekilde olabilir.).

Wizard’ın son aşamasında sihirbaz size , özeti sunmaktadır. Özete dikkat ederseniz , CA sunucusunun isminin, CA rolü kurulumu sonrasında değişmemesi gerektiği uyarısı önemlidir.

CA rolünün kurulumundan sonra , administrative tool altından CA konsolunu açabiliriz.

image008

Sertifika konsolunda CA’in ismi altında , yapının yönetimi sırasında kullanacağımız alt node’lar mevcuttur.

Revoked Certificates

Herhangi bir sebepten dolayı iptal edilen sertifikaların listesini bulabilirsiniz.

Issued Certificates

Onaylanmış ve dağıtılmış sertifikaların listesini bulabilirsiniz.

Pending Requests

Onaylanmak için bekleyen sertifikaların listesini bulabilirsiniz. Her sertifika otomatik olarak dağıtılamayabilir(Key Recovery Agent sertifikası için onay gerekmektedir.İlerleyen kısımlarda göreceğiz.)

Failed Requests

Başarısız taleplerin listesini bulabilirsiniz. Örneğin , kullanıcı bir sertifika talep ettiyse ve sertifikada istenen her niteliğe sahip değilse , bu talep başarısız olarak değerlendirilir.

Certificate Templates

Dağıtabileceğimiz sertifikaların listesidir.Listede olmayan bir belgeyi dağıtmak isterseniz , o sertifikayı bu kısma taşımanız gerekir ve bunuda yazının ilerleyen kısımlarında açıklayacağız.

NW-CA ‘nın özelliklerine bakacak olursak ;

image009

çeşitli tab’ları ve alt menüleri görebiliriz. Resimde görülen View Certificate altında , NW-CA’nın otorite olma belgesini ve özelliklerini görebiliriz. Butona tıklarsak ;

image010

genel özellikler görülmektedir. Bu sertifika , NW-CA’nin bir otorite olduğunu gösterir. Details panelinde , sertifikaya ve otoriteye ait detaylı bilgiler edinilebilir.

image011

Üstteki resimde , detaylar mevcuttur. Seçili olan öğe bize NW-CA hakkında fikir vermektedir. Sertifikanın seri numarası görünmektedir.En alt kısımda (resimde görülmüyor) sertifikanın thumbprint numarası görülmektedir.

NW-CA’nın özellikleri ile devam edelim. Policy Module kısmı , CA’in sertifika talepleri ile nasıl ilgileneceğini belirler.

image012

Policy Module özelliklerinden görüleceği üzere NW-CA otoritesi, sertifika şablonunda bir yapılandırma varsa onu kullanacaktır , aksi taktirde otomatik olarak onaylayacaktır.

NW-CA özelliklerinde bir başka tab ise Recovery Agents tab’ıdır.

image013

Dağıtılan sertifikaların Private Key’lerini arşivlenmek istersek , Recovery Agents panelinden ilgili gereksinimler yerine getirilmelidir. Buradaki gereksinim , NW-CA’ya bir adet key recovery belgesi göstermektir ama henüz hiç bir kullanıcıya key recovery belgesi verilmediğinden bunu yapamayız.Yazının sonuna geldiğinizde bunun da yapılmış olduğunu ve kullanıldığını göreceksiniz.

Key recovery belgesini , administrator için talep edelim ve recovery agents panelini yapılandıralım. Bu yapılandırmayı , sertifika dağıtımlarından önce yapmalısınız ki , olası bir disaster anında bütün sertifikaların privete key’lerini kurtarabilin.

Öncelikle, Administrator’a Key Recovery belgesini alalım. Bunun için web’den NW-CA’ya erişebiliriz. Daha önce web-enrollment rol servisini kurduğumuzdan , IIS bileşeni ve gerekli alt dizinler kurulmuştur. IIS  yönetim konsolundan doğrulayalım.

image014

IIS manager’dan görüldiğü gibi , Default Web Site altına , web’den bağlantı sırasında kullanacağımız certsrv alt dizini gelmiştir.

NW-CA’ya web’ten bağlanmak için , http://bs-dc/certsrvurl’sini kullanabiliriz. Web arayüzü bize username ve password soracaktır. Biz administrator kullanıcısına ait olacak bir sertifika almak istediğimizden onun bilgileri ile giriş yapıyoruz. Hangi kullanıcıya sertifika alacaksanız onun bilgilerini kullanmalısınız.

image015

Web arayüzü üstteki gibidir. Amacımız Key Recovery sertifikası talep etmektir. Request ….ile devam ediyoruz.

image016

Request seçeneği ile devam ettiğimizde , karşımıza üstteki gibi iki seçenek  gelmektedir. Bizim istediğimiz belge User belgesi değildir. Dolayısıyla gelişmiş talep seçenekleri ile devam edeceğim.

image017

Gelişmiş menüde üstteki gibi 2 seçenek görülmektedir. Biz NW-CA’ya talepte bulunacağız ve talebimizi anlık olarak gerçekleştirip sonucunu alacağız. İlk seçenek ile devam ediyorum.

image018

Gelişmiş menüsünde alınabilecek sertifikalar arasında , Key Recovery belgesini göremiyoruz. Bunun sebebi , key recovery belgesinin henüz dağıtılabilecek belgeler arasında olmayışıdır. Bunun için NW-CA yönetim konsolundaki Certificate Templates klasörüne bakabiliriz.

image019

Görüldüğü gibi , Key Recovery belgesi henüz kullanılabilir değildir. Certificate Template klasörüne sağ tıklayıp , belgeyi kullanılabilir hale getirelim. Bunun için sağ tıkladığımızda karşımıza gelen newàcertificate template to issueseçeneğini kullanacağız.Kaşımıza açılan pencereden Key recovery belgesini seçersek , kullanılabilir hale gelecektir.

image020

Son durumda , kullanılabilecek şablonlar arasına key recovery belgesi de geldi. Şimdi web arayüzünü tazeleyelim.

image021

Web arayüzünü tazelediğimizde , siteden sertifika talebi için , sitenin SSL üzerinden hizmet vermesi gerektiği uyarısını alıyoruz ki bunu bir önceki denememde de almıştım. Ama artık Certificate Template drop down menüsünde Key Recovery belgesi de mevcuttur.Uyarıyı OK ile kapatıyorum. Sertifikayı MMC konsolundan da alabiliriz ya da site’ye ssl sertifikası alıp yine buradan devam edebiliriz. MMC konsolundan sertifika talebi oldukça zahmetsiz olduğundan , site’ye SSL sertifikası alıp yine buradan devam edeceğim. Yani IIS üzerindeki web sayfasının (Default web site) SSL ile yayınlanmasını sağlayacağım.

Site’ye SSL sertifikası almak için IIS yönetim konsoluna geçiyorum. NW-CA’ya http://bs-dc/certsrv  ismi ile bağlanıyorduk. Yeni bir isim belirleyelim. Sertifika Otoritesine web üzerinden bağlanmak için kullanacağımız isim  ca.nwtraders.msft olsun. DNS’te ca isimli bir kayıt açmayı unutmayın.

image022

IIS yönetim konsolundaki Server Certificates alt menüsünü kullanacağız.Bu menüye girdiğimizde , bs-dc sunucusunun sahip olduğu bir kaç sertifikayı görebilirsiniz.

image023

Create Domain Certificate ile devam ediyorum.

image024

Bilgileri doldururken , organizasyonunuza özel olarak yapıladırmanız uygundur. Önemli olan, common name kısmıdır. Web sitesine erişim için hangi ismi kullanacaksanız onu yazmalısınız. Sonraki panelde hangi otoriteden talep edecekseniz onu seçeceksiniz ve finish ile sihirbazı bitireceksiniz.Formu doldurmak için hayali bilgiler kullandım.

IIS manager’da Server Certificates menüsüne tekrar baktığımızda , yeni aldığımız sertifikayı da görebiliriz.

image025

Şimdi bu sertifikanın site tarafından kullanılmasını sağlayalım. Sitemiz Default Web Site olduğundan , o seviyeye inelim.

image026

Sertifikanın site tarafından kullanılması için , Actions panelindeki Bindings menüsünü kullanacağız. Menüye yeni sertifikamızı eklersek işimiz tamamlanacak.

image027

Menüde , Add butonundan , sertifikayı seçmeliyiz. Sertifika talebinde bulunurken , sertifika ismine (common name değil , friendly name) WEB_SRV yazmıştım onu seçiyorum ve close ile menüleri kapatıyorum. Son durumda Bindings menüsü aşağıdaki gibidir.

image028

SSL ile erişimi şart koşmak isterseniz , IIS yönetim konsolundaki , Default Web Site seviyesinden SSL Settings ayarına ulaşabilirsiniz.

image029

Burada kutucuğu işaretlerseniz , siteye erişimi mutlaka SSL ile yapacaktır. Eğer siteye bağlanan istemcide de sertifika olmasını isterseniz, alt kısımdaki dairelerden requiredairesini işaretleyebilirsiniz. Siteye http üzerinden bağlanmak isterseniz , ssl ile bağlanmayı şart koştuğumuzdan

image030

uyarısını alacaksınız. Https ile bağlanıp sertifika talep menüsüne geçiyorum. Siteye bağlantı için kullanacağım url : Https://ca.nwtraders.msft/certsrvlink’idir.

image031

Artık administrator’a key recovery belgesini alabiliriz. Key recovery belgesini seçip alt kısımdan talep ederseniz , site size aşağıdaki mesajı verecektir.

image032

Talebimiz beklemededir.Bu sertifikayı değilde farklı bir sertifikayı alıyor olsaydık (mesela user yada basic efs sertifikasi) talebimiz onaylanırdı ve sertifikamızı hemen kurabilirdik. Key recovery belgesinin özellikleri gereği , CA yöneticisinin onaylaması gerekmektedir.NW-CA konsolundaki Pending klasöründen bekleyen belgeyi onaylayalım.

image033

Onaylama sürecinden sonra  Key Recovery Agent yapılandırmasının son adımını yapıp tamamlayabiliriz.

image034

Görüldüğü gibi onaylanan sertifikalar arasına Key Recovery belgesi de geldi. NW-CA özelliklerinden , Recovery Agent menüsüne giderek , otoritemize key arşivlemede kullanacağı Key Recovery belgesini gösterebiliriz.

image035

Recovery Agents menüsünde Add butonuna tıkladığımızda yöneticinin sahip olduğu belge görülmektedir ve belge özelliklerinde de belgenin amacının Key Recovery olduğu yazmaktadır.Belgeyi seçip Apply ile devam ederek , key arşivleme işlemini tamamlayalım. Artık , dağıtacağımız belgelerin Private Key’lerin arşivlenmesini isteyebiliriz. Key Recovery belgesini hangi bilgisayara kurarsanız ancak o bilgisayar üzerinde recovery işlemi yapabilirsiniz , dikkat !!!!!!!!!

Sertifikaların kullanımı

Organizasyonumuza dağıtmak üzere , dosya şifrelemede , güvenli e-mail transferinde ve kimlik denetiminde kullanılacak bir sertifika şablonu hazırlayalım. Şablon hazırlamak için , NW-CA yönetim konsolundaki Certificate Templates klasörünü kullanabiliriz. Klasöre sağ tıklayıp Manageile devam edersek , genel şablon listesini görebiliriz.

image036

Genel şablon listesi üstteki gibidir. İstediğimiz nitelikte sertifika hazırlamak için , User belgesini kopyalayalım ve istediğimiz özellikleri ekleyelim. User belgesine sağ tıklayıp duplicateile devam edeceğim.

image037

Şablona isim olarak resimde görülen ismi verdim. Belgenin geçerlilik süresi 1 yıl , yenileme periyodu 6 hafta olarak görülüyor.

Request Handling menüsünden , sertifikanın private key’inin arşivlenmesi için

image038

üstteki kutucuğu işaretliyorum. Buna dikkat etmek gerekir çünkü varsayılan ayarlar ile devam edersem , private key arşivlenmeyecektir. Suite-B kullanacaksak , cryptographymenüsüne de uğramanız gerekecektir.

image039

Subject Name menüsünde , belgeyi alacak olan kullanıcıların sahip olması gereken nitelikler görülmektedir. Kullanıcının  , email adresi ve upn’i olmalıdır. Henüz email adresi dağıtmadığımızı hatırlatmakta fayda var. Belge bir bilgisayara verilecek olsaydı , DNS ismi olması gerekirdi!!!

Eğer istenirse , Issuance Requirements menüsünden, bu sertifikayı almak isteyenlerin taleplerinin yönetici tarafından onaylanmasını şart koşabiliriz ama biz otomatik olarak dağıtacağımızdan , belgeyi talep etme hakkı olanların almasını sağlayacağız . Belgeyi kimlerin talep edebileceği kısmını da Securitymenüsünde belirleyeceğiz.

Biz bu belgeye EFS’te kullanılması özelliğini de eklemek istiyoruz. Onun için Superseded Templates menüsüne Basic EFS şablonunu da eklemeyi unutmayalım.

Belgenin amacına bakmak için, Extensions menüsüne geçebiliriz.

image040

Resimden görüldüğü üzere , belgemiz , kullanıcılara dosya şifreleme , güvenli e-mail transferi ve kimlik doğrulama imkanı sağlayacaktır. Son olarak , domain kullanıcılarının sertifikayı talep edip alabilmeleri için security menüsüne geçelim ve ilgili izinleri verelim.

image041

Üstte görüldüğü gibi , domain users’a, belgeyi okuyup otomatik olarak kurabilmesi için gerekli  izinleri veriyoruz. GPO yardımı ile de auto-enrollment’ı kullanıcı ve bilgisayar bazında ayarlayacağız . NW-CA tarafında sertifika hazırlığımızı tamamladık. OK ile şablonu oluşturalım.

image042

Son olarak şablonu , kullanılabilir şablonlar arasına eklemeliyiz ki , kullanıcılar NW-CA’dan talep edebilsinler.

Otorite tarafında yapacaklarımız tamamlandı. Şimdi GPO tarafında auto-enrollment’ı yapılandıralım. Bunu yapıyoruz çünkü her kullanıcı , sertifika talebi konusunda bilgi sahibi olmayabilir ama her kullanıcı e-mail gönderir değil mi ? Domain bazında bir GPO ile auto-enrollment`i (sertifikaların otomatik olarak dağıtılmasını) sağlayabiliriz. Yada Default Domain Policy`den faydalanabiliriz.  Ben test ortamımda Default Domain Policy`i kullanacağım.

image043

Default domain policy’de ilgili group policy objesini, resimde görüldüğü gibi yapılandırıyorum. Siz , bilgisayarlara da otomatik sertifika dağıtmak isterseniz , aynı objeyi , computer configuration tarafında da yapılandırmalısınız.

Artık , bu group policy objesinden etkilenen kullanıcılar daha önce hazırladığımız sertifikayı alabilecekler. Ama e-mail adresleri olmadan  talep ederlerse , talepleri NW-CA’da Failed Request olarak görülecektir.Kullanıcılarımızı oluşturalım ve e-mail adreslerini verelim. E-mail server olarak windows server 2003 R2 üzerinde bir POP/SMTP server kullanıyorum. E-mail server’daki hesaplar

image044

resimde görüldüğü gibidir.

Şimdi , windows 7 istemcimizden bir kullanıcı ile giriş yapalım, sertifikasının gelip gelmediğini ve geldiyse sertifikasını inceleyelim.

W7 istemcim’den selda@nwtraders.msfthesabı ile giriş yapıp ve mmc konsolundan lokal sertifika deposuna baktığımızda

image045

sertifikasının geldiğini görebiliriz.Benzer şekilde , istemcimizden domain kullanıcıları ile giriş yaptığımızda onların da sertifikaları otomatik olarak NW-CA’dan talep edilip yüklenecektir. Belgenin genel özelliklerine bakacak olursak ,

image046

amacımıza yönelik olduğunu görebiliriz. Belge ; dosya şifreleme , email güvenliği ve kimlik denetiminde kullanılacaktır. Artık , gönderdiğimiz e-mail’lerimizde , güvenliği sağlama ve kimlik denetimi adına , digital signature ve encryption kullanabiliriz. Kendi dijital imzamızla e-mail gönderelim ve ardından gönderdiğimiz e-mail’leri , sadece hedefin açabileceği şekilde şifreleyelim. E-mail client yazılımı olarak Outlook 2007 kullanacağız.

Outlook 2007 yazılımını açtıktan sonra , e-mail gönderirken , digital imzamızla imzalayacağız. Bunun için aşağıdaki resimden görüldüğü gibi

image047

Add …. ile başlayan kutucuğu işaretliyoruz. Ardından dijital imzamızla e-mail’i gönderebiliriz. Benim e-mail alıcılarım mergun@nwtraders.msft ve baris@nwtraders.msft  hesaplarına sahip kullanıcılardır. Gönderilmiş öğeler kutusundan , gönderdiğim e-mail’e bakacak olursak ,

image048

e-mail’in tarafımdan imzalandığını , ve güvenilen otoriteyi görebiliriz.Şimdi alıcılardan birinin mailbox’ına bakalım.

baris@nwtraders.msfthesabına baktığımızda ,

image049

selda@nwtraders.msft e-mail hesabından , dijital imzalı bir e-mail gelmiştir.Şu an logon olduğumuz baris@nwtraders.msftkullanıcısının lokal sertifika deposuna bakarsak , NW-CA’dan daha önce oluşturduğumuz belgeyi aldığını görebiliriz. Artık , nwtraders\selda kullanıcısının belgesinin public key’i de kendisinde mevcuttur. Nwtraders\selda kullanıcısına şifrelenmiş bir e-mail göndermek isterse , O’nun public key’ini kullanarak gönderebilir. Şifrelenmiş e-mail göndermek istersek ,  az önceki Add digital signiture … kutucuğunun hemen üzerindeki Encrypt Message content kutucuğunu işaretlememiz yeterlidir. (Öncesinde digital imazalı e-mail alış verişi yapmış olmamız gerektiğini unutmayalım)

Eğer baris@nwtraders.msftkullanıcısı , kendi lokal sertifika deposundaki sertifikasını silerse , yada herhangi bir sebepten dolayı sertifika kaybolursa (donanım sorunları , pc’nin formatlanmazı , düzensiz yedekleme stratejileri) , e-mail’lerini açamaz. Silip açmaya çalışırsak aşağıdaki hatayı alırız.

image050

Elimizde baris kullanıcısının sertifikasının private key’i yoksa , yapabileceğimiz birşey yoktur. Ama biz kullanıcıya sertifika dağıtmadan önce , Key Recovery yapabilmek için , dağıtılan sertifikaların private key’lerini arşivlemiştik.

Şimdi nwtraders\baris kullanıcısının private key’ini deşifre edelim ve kullanıcıya tekrar gönderelim.  Bunun için certutil.exe komut satırı aracını kullanacağız.

image051

Certutil.exe aracı ile sertifika detaylarını ve arşivlenmiş key’i bulalım.Üstte görüldüğü gibi istenileni elde ettik. Şimdi bunu bir dosyaya aktaralım ve kullanıcıya gönderilebilir hale getirelim. Kullanıcı bu işlemi kendisi yapamaz mı ? Kullanıcı Key Recovery Agent belgesine sahip olmadığı için yapamaz. Bu işlemi kim yapar ? Key Recovery belgesine sahip domain kullanıcıları ya da bizim ortamımızda administrator kullanıcısı bu haklar ile donatılmıştır. Bulduğumuz private key’i dosyaya yazdırmak için ,

image052

üstteki komutu kullanıyorum. İlk komut ile detayları edindik , ikinci komut ile bunları bir dosyaya (baris-cer.pfx , ismini istediğiniz gibi belirleyebilirsiniz) yazdırdık. Dosyanın varsayılan yeri C:\Users\Administrator klasöründedir. Çünkü administrator ile işlem yaptık. Nwtraders\baris kullanıcısı , az önce kurtardığımız ve ismini baris-cer.pfx şeklinde yazdırdığımız  belgesini , tekrar bilgisayarına kurarsa , e-mail’lerini tekrar görebilecektir.

Sertifikaların kullanım alanlarından bazılarına, sertifikalara ve sertifika otoritelerine genel bir bakış niteliğinde olan yazımızı bu uygulama ile bitirmiş oluyoruz. Sonraki yazılarımızda , sertifikalara ve otoritelere dair açıklamalara ve örneklere devam edilecektir.

Kaynak :  Technet Library

SCCM & PKI ile Native Mode’a Geçiş

System Center Configuration Manager

&

Public Key Infrastructure Konfigürasyonu

 

Bilgilendirme : Aşağıdaki uygulama yazısı TechNet VirtualLabs kullanılarak yapılmıştır.

System Center ürün ailesinin bir parçası olan Configuration Manager ; işletim sistemi kurulumlarını , sunucu kurulumlarını ve güncelleştirmelerini , istemci bilgisayarlarının kurulumlarını ve güncelleştirmelerini yönetebilen kurumsal bir üründür. Bu yazımızda amacımız SCCM ürününü native mode’da çalıştırmak için gereken altyapının hazırlanmasını , kurulumunu ve yönetimini açıklamaktır.

Amaç :

–          Native Mode yapısı için gereken sertifikaların hazırlanması

–          Mixed Mode’dan native mode’a geçiş

–          Client’ların native mode’a yükseltilmesi

Kullanılanlar :

Domain                       : sccmdomain.smsdemo.microsoft.com

SCCM Server ismi      : SCCMSERVER (Management Point)

SCCM Site ismi           : MCM

 

Amaca yönelik gereken işlemleri adım adım açıklayalım. SCCM site’ını mixed mode’dan native mode’a geçirebilmek için dijital sertifikalara ihtiyacımız olacak. Bunları hazırlayalım.

1-SCCM için Site Server Signing Sertifikasının oluşturulması ve kurulumu

Sertifika Otoritesi yönetim konsolundan , ihtiyacımız doğrultusunda bir tane sertifika şablonu hazırlayacağız , bunun için CA yönetim konsolunu açıyoruz.

Sertifikayı hazırlamak için Certificate Templates klasörüne sağ tıklayıp Manage ile tüm şablonları görebileceğimiz yeni bir pencere açıyoruz. Hazırlayacağımız şablonda Document Signing extension’ı olmalıdır.

Sertifika şablonlarının arasından ismi Computer olan şablonu dublicate (çoğaltacağız) işlemi ile çoklayıp isteğimize uygun yeni bir şablon oluşturacağız.

Yeni şablonun ismini görüldüğü gibi yazıyorum. Alt kısımıdaki Publish certificate in ….

kutucuğunu da işaretliyoruz. Ardından Subject Name tab’ındaki Supply in the request kutucuğunu işaretliyoruz. Gerekli bilgiler talep sırasında tedarik edilecektir. Ardından Extensions tab’ına geçiyoruz.

Burada , Application Policies extension’ını edit’leyip Client ve Server authentication extension’ını çıkaracağız , Document Signing extension’ını ekleyeceğiz.

Yapılandırma sonrasındaki durum üstteki gibidir. Bu şablonun talebini ve alınma faslını bir yöneticinin onayından geçirmek istersek , Issuance Requirements tab’ındaki ilk kutucuğunu işaretleyip onaya zorunlu tutabiliriz. Ardından hazırladığımız şablonu kullanılabilir hale getirmeliyiz.

Hazırladığımız şablon, son durumda kullanılabilir şablonların arasında yerini aldı. Şimdi bu sertifikayı SCCM Site sunucusuna alalım.

Bir browser açıp adres satırına , http://sccmserver/certsrv yazarak sertifika otoritesinin web arayüzüne bağlanalım. Yeni ve spesifik bir sertifika talebinde bulunacağız.(şablonunu az önce hazırlamıştık)

Normal şartlarda bizim hazırladığımız sertifika şablonu seçili değildir. Certificate Template penceresinden ConfigMgr Site Server Signing Certificate isimli şablonu seçiyoruz ve aşağıdaki bilgileri uygun şekilde dolduruyoruz. Özel olarak Name kutucuğuna The site code of this site server is MCM ismini yazıyoruz. Aslında isim site adını barındırsa yeterlidir. Bizim SCCM site’nın isminin MCM olduğunu hatırlayınız. Store Certificate … kutucuğunu işaretliyoruz. Friendly name kısmı size kalmıştır. Sonrasında Submit ile talebimizi gerçekleştiriyoruz. Eğer bir yöneticinin onayını mecbur tuttuysanız, talebiniz değerlendirilmek üzere sertifika sunucusuna gidecektir. Ben yönetici onayını istemiştim , aşağıda görüldüğü gibi talebim bir Request ID ile otoriteye gitti.

Sonrasında , CA yönetim konsolunda Pending Requests klasörü altında bekleyen sertifikayı onaylamayı unutmayınız. Onaylama ardından tekrar web arayüzünden onayladığımız sertifikayı yükleyelim. Web arayüzünde View the Status of Pending Certificates link’ine tıklarsak , onayladığımız ve yüklenmek için bekleyen belgemizi görebiliriz.

Bekleyen sertifikanın üzerine tıklayıp yükledik. Site Server sertifikası tamamlandı. Sıradaki adıma geçelim.

2- SCCM için Web Server sertifikasının oluşturulması ve kurulumu

Client’lar, IIS servislerine erişirken IIS tarafından kullanılacak olan Web Server sertifikasını oluşturacağız. IIS bileşenini kullanan SCCM site sistemi için bir grup oluşturup , sertifikayı kullanabilmesi için bu gruba izin vereceğiz.(SCCM site’ında fazlaca sunucu varsa hepsi için tek bir grup, yönetim kolaylığı sağlayacaktır )

IIS tabanlı site sistemi rol’leri için bir security grup oluşturalım.

Yeni oluşturduğumuz grubun bilgileri üstteki gibidir. Management Point , Distribution Point, Software Update Point ve Storage Point olarak kullanılan sunucuları bu gruba ekleyelim. Benim sanal lab’ımda tamamı SCCMSERVER isimli sunucuda olduğundan sadece onu gruba ekledim.

Web Server Signing sertifikasını oluşturmaya başlayalım. Sertifika Otoritesi yönetim konsolunda yine bir duplication işlemi yapacağız. Bu sefer Web Server sertifikasını çoğaltacağız. Şablona dair isim bilgileri aşağıdaki gibidir.

Subject Name penceresinde yapılması gerekenler aşağıdaki gibidir. Sertifika talebi sırasında gereken bilgiler AD veritabanından tedarik edilecektir.

Şimdi , AD’de oluşturduğumuz security grubuna bu sertifika şablonu üzerinde enroll ve autoenroll izinlerini verelim.

AD’de oluşturduğumuz gruba SCCMSERVER’ı üye yapmıştık. Token’ının güncellenmesi için sunucuyu yeniden başlatmalısınız unutmayınız , aksi taktirde grup üyeliği hemen geçerli olmayacağından sertifika talebinde bulunamayacaktır. Sertifikayı aşağıda görüldüğü gibi kullanılabilir hale getirelim.

Sertifika kullanılabilir hale geldiğine göre , mmc konsolundan talep edebilirim.

Talebim sonucunda web server sertifikası da local sertifika deposunda yerini aldı.

IIS bileşenini yeni yüklediğimiz Web Server Signing sertifikasını kullanacak şekilde yapılandıralım. Production ortamında , hangi web site kullanılıyorsa (SCCM tarafından) , sertifikayı ona alacağız dikkat!!! Lab ortamında Default Web Site kullanılmaktadır.

Server Certificate butonu ile az önce lokal sertifika deposuna yüklediğimiz sertifikayı IIS’in Default Web Site’ine yüklemiş olduk. Sertifika bilgilerini gözlemek isterseniz , View Certificate butonunu kullanabilirsiniz.

Web Server Signing sertifikasını da hazırlamış olduk. Şimdi SCCM için Client sertifikasını oluşturalım ve yükleyelim.

3-SCCM için Client sertifikasının oluşturulması ve kurulumu

Native mode’da çalışacak olan Client’ın kullanacağı belgeyi hazırlayacağız. Bir Group Policy objesi ile auto-enrollment yapılandıralım.

Computer belgesi için üstte görüldüğü gibi bir yapılandırma yaptık. Client yeniden başlatıldığında ihtiyacı olan sertifikayı/sertifikaları alacaktır. Yeniden başlatamıyorsanız daha önce hazırladığımız ve üst kısımlardaki resimden de görebileceğiniz  sertifikayı/sertifikaları export edip client’a yükleyebilirsiniz.(şu an lab ortamında 4 adet sertifikamız mevcut)

4-Mixed mode’dan Native mode’da yükseltme

Şimdi SCCM site’ımızı native mode’a yükselteceğiz. Öncelikle uygunluğu doğrulayalım. Yeni bir paket oluşturalım.

Yeni Paketin ismini aşağıda görüldüğü gibi veriyorum. Lab ortamımda bu paket için gereken kaynak dosyaları

client bilgisayarına yüklenmiş durumdadır.Dolayısıyla sonraki ekrandaki This Package contains source files kutucuğunu işaretlemeden geçiyorum.

Distribution Point üzerindeki varsayılan paylaşım noktasını kullanacağımdan üstteki gibi devam ediyorum. Sonraki Distribution Settings penceresinde de varsayılan ayarlarla devam ediyorum.

Sonraki menüde management information format dosyası raporlaması için bir yapılandırma seçeneği gelmekte. Varsayılan ile devam ediyorum.

Sonraki ekranda Security seçimleri gelmekte. İlgili objelerin paket üzerindeki güvenlik hakları bilgilerini aşağıda görmekteyiz.

Varsayılan güvenlik izinleri ile devam ediyorum. Summary sayfasındaki yapılandırmada istediklerinizin doğru biçimde seçildiğini gözledikten sonra paketi hazırlayabiliriz.

Paket hazırlama işlemini bitirmiş olduk.

Hali hazırda paket içinde herhangi bir program yoktur. Yeni program ekleyelim.

Bunun için yeni program ekleme sihirbazını kullanabiliriz.Bendeki program system32 altında olduğundan yapılandırmayı aşağıdaki gibi yapıyorum.

Requirements penceresinde , maximum Allowed run time dakikasını 5 yapıyorum , varsayılanı 120 idi.

Environment kısmında , programın çalışabilme durumunu aşağıdaki gibi

belirliyorum.  Ardından next şeklinde devam edip paketi tamamlayabiliriz.

Özeti üstteki gibidir.

Sonrasında Software Distribution’ın alt kısmından Advertisement belirleyelim. Site sunucusunda ConfManager Client yüklü olmadığından şimdi belirlediğimiz advertised program’ı sccmserver isimli site server’a dağıtmayacağız (system32\Ccm dizininde) manuel olarak çalıştırağız.(kurmak istersek)

Advertisement’ın özeti üstteki gibidir. Burada , kurulacak paketi programı ve hangi sistemlere kurulacağını belirlemiş olduk. Daha önce hazırladığım paketleri/programları kullandık. Şimdi de sccm client’a yani Windows XP tarafına geçip yazılımı alalım.

Windows XP’de denetim masasından Configuration Manager’ı çalıştırıyoruz.

Actions panelinden yeni belirlediğimiz adversitement’ı alması için tetikliyoruz.

Böylece XP client , içinde yeni advertisement bulunan policy’i talep edecektir. Talebin sonucunu görmek birkaç dakika sürebilir. Sonucunda system tray’de New Program Available icon’u görülür. Eğer beklenen zamanda sonuç alamazsak ,

üstteki menüde görülen paneli kontrol edebilirsiniz. Yeni programın kurulumunu (New Program Available icon’u görüldükten sonra) yaptığınızı varsayıyorum. Sonrasında ,

raporlamaya bakarsak native mode ile sorun yaşayan client olmadığını görebiliriz. Ortam native mode’a hazır görünüyor.

Native Mode’a yükseltelim.

SCCM yönetim konsolunda , site özelliklerinde üstte görüldüğü gibi site modunu Native’e değiştiriyoruz. Hemen altında bizden gerekli sertifikayı isteyecek. Daha önce hazırladığımız ve içinde document signing extension’ını barındıran sertifikayı seçiyoruz. Sertifikanın parmak izi numarasıda alt kısmında görünecektir.

Native mode’a geçiş tamamlanmıştır. Client tarafını da Native Mode’a geçirelim. SCCM site server’da SMS Agent Host servisini yeniden başlatarak başlayalım. Denetim masasındaki Configuration Manager’ı çalıştırırsak native mode’a geçtiğini görebiliriz. Aynı servisi client tarafında yeniden başlatırsak aşağıdaki gibi

mode’un native’e döndüğünü ve connection type’ın Always Inranet’e değiştiğini gözleriz. IP Address’te 0.0.0.0 göründüğünü önemsemeyiniz , sanal pc’nin network kablosu unplugged halde kalmıştı screenshot aldığımda.

Ne yaptığımızı özetleyecek olursak :

–          Native Mode için gereken sertifikaları hazırladık , kurulması gereken yerlere kurduk

–          Native Mode’a uygunluğu gözleyip , raporladık ve Native Mode’a hazır olmayan istemci olmadığını rapordan gördük.

Kaynak : TechNet VirtualLabs