PowerShell is not Recognized as an internal or external command” hatasının çözümü

Merhaba,  herhangi bir sebepten ötürü PowerShell yazılımını veya kodlama dilini J server işletim sisteminizden kaldırmış olabilirsiniz. Örneğin .Net  Framework featureı kaldırırken doğru seçimleri yapmazsak Hem  Server  GUI özelliğini kaldırmış oluruz hem de PowerShell özelliğini.

Aşağıdaki hatanın çözümü  powershell bileşenini yeniden yüklemektir.

Minimum Local Admin yetkisine sahip bir kullanıcıyla sisteme logon oluyoruz ve CMD komut satırı aracında aşağıdaki komutları çalıştırıyoruz.

Not: sunucumuzun Server CORE işletim sistemine sahip olduğunu düşünerek  aşağıdaki komutları çalıştıracağız. GUI sunucu sürümü kullanıyor olsaydık  Server  Manager üzerinden Powershell özelliğini aktif edeblirdik.

dism.exe /online /enable-feature /featurename:MicrosoftWindowsPowerShellRoot

İlk komutumuz başarılı olarak tamamlandı. Şimdi 2. Komutumuzu çalıştırıyoruz.

dism.exe /online /enable-feature /featurename:MicrosoftWindowsPowerShell /all

Yüklemenin tamamlanabilmesi için  shutdown  -r –t 0  komutu ile sunucumuzu restart ediyoruz.

Sunucumuz açıldıktan sonra CMD  komut satırı ekranında  powershell yazarak  kullanıma başlayabiliriz.

Powershella aracımızı geri yüklediğimize göre artık sunucumuzu eski haline GUI arabirimine döndürelim J

Powershell üzerinden çalıştıracağımız komut: Install-WindowsFeature Server-Gui-Shell

Başka yazılarda görüşmek dileğiyle.

Windows Sunucuları kim Restart ettiğini nasıl anlarız ?

Merhaba, yönetmekte olduğunuz windows tabanlı sunucu sayısı fazlaysa ve aynı zamanda yönetmekte olduğunuz windows sunucuların üzerindeki uygulamaların her birinin süreç sahibi kişi ve grupları yine sayı olarak fazlaysa yönetim olarak biraz işiniz zor demektir.  Böyle bir ortamda bir de sunucularınız üzerinde uygulama sahibi kullanıcılarınıza Local Adminlik gibi haklar vermişseniz mecburi nedenlerle bazen istemediğiniz durumlarla karşılaşabilirsiniz. Örneğin bir sunucunuz var üzerinde çok kritik bir uygulama çalışıyor. Ve Bu sunucunun üzerindeki uygulamanın sahipleri aynı zamanda sunucunun localin de admin hakkına sahipler. Bir gün size sunucunun birisi tarafından restart edildiğini söylediler ve sizden kim olduğunu öğrenmenizi istediler.

Böyle bir durumda bir süreç kesintisi ve buna bağlı olarak bazı mali kayıplar ortaya çıkacağı için pek hoş bir durum gibi gözükmüyor. Şimdi gelelim bu kontrolü nasıl yapacağımıza.

Kullanıcılarınız ister domain userlarıyla sunuculara bağlanıp işlemler gerçekleştirsin ister local user accountlarıyla işlem gerçekleştirsinler yapılan çoğu işlem  Event Viewer aracına yani olay görüntüleyiciye yansır.  Aşağıdaki örneğimizde   Ozgur Senerdogan isimli  domain userımız  Server01 isimli sunucunun localinde admin yetkisine sahip.

Server1 isimli sunucumu restart ediyorum.

Saat 12:14 de restart ettim. Ve kullanıcım  CMD ekranında gördüğünüz üzere  ozgur.senerdogan  kullanıcısı.

Sunucum açıldıktan sonra  Start > Run >  eventvwr.msc   komutuyla event viewer aracını çalıştırıyorum.

Windows Logs > System logları alanına geliyorum ve  Filter current log seçeneğini seçiyorum.

Event  id olarak 1074 değerini giriyor ve Ok diyorum.

Sarı ile işaretli alanlarda gördüğünüz üzere   1074 id li eventta açıklayıcı bilgi yer almakta.

Hangi userın hangi zaman diliminde sunucuyu restart ettiği bilgileri mevcut.

Peki işlemimiz restart değil Shutdown olsaydı. Yani shutdown –s  komutunu verseydik o zamanda yine aynı event id yi aratarak kontrol sağlayabilecektik. Aşağıda örnek ekran görüntüsü paylaşıyorum. Sunucuyu ozgur.senerdogan kullanıcısıyla  shutdown ettim ve yansıyan bilgiler aşağıdaki gibidir.

Peki  suddenly shutdown dediğimiz windows üzerinden değilde  makinenin elektriğini keserek kapanmış olsaydı bunu nasıl anlardık yine Event viewer aracı üzerinden   System loglarını kontrol etmemiz gerekir. Fakat aratacağımız event id kodu 1076 olmalı.

Aşağıda daha önceden sunucuyu power off yapmıştım onun uyarısı mevcut.

faydalı olması dileğiyle.

Dünya'daki Tüm Siber Saldırıları Canlı İzleyebileceğiniz Siteler

Dünya genelinde her dakika da neredeyse her saniye de siber saldırılar yaşanıyor. bunların bazıları saldırıya uğrayanlar için telafisi güç sonuçlar ortaya koyabiliyor :) aşağıda linkini paylaştığım site üzerinden canlı olarak dünya genelindeki siber saldırıları izlemeniz mümkün.

Norse Attack Map

Digital Attack Map Top daily DDoS attacks worldwide

iyi çalışmalar.

Exchange 2013 RBAC Delegasyonu ve OU bazlı Database Filtreleme.

Merhaba, Bu makalemizde   Exchange 2010 ürünü ile birlikte özellik olarak gelen  ve 2013 Platformunda da devam eden  Adını sıkça duyduğumuz  Role Based Access Control  özelliğini inceliyor ve detaylandırıyor olacağız. Öncelikle RBAC nedir neden kullanılır kısaca değinmekte yarar var.  Örneğin çok  Lokasyona sahip bir işletmede Sistem Yöneticisi  olarak çalışıyorsunuz ve Coğrafi bölgeleriniz mevcut. Ankara, İzmir, Gaziantep  vs gibi ve burada çalışan personel sayısı hem fazla hem de o  Bölgeler de görev yapan IT Support  Personeliniz mevcut. Bu durumda mevcut iş yükünüzün azalması için  Yönetimini yaptığınız Sistemlerin  Bazılarında Delegasyon yoluna giderek Teknik bilgisi yeterli olan Donanım destek uzmanı arkadaşlara bazı  görevleri atayarak günlük gelen bazı talepleri onların çözmesini ve sizin üzerinizde yoğunluk oluşturmamasını sağlayabilirsiniz. Hepimizin bildiği üzere Bazı yapılarda ( İlaç, sağlık, Medya, Perakende ) personel sirkülasyonu yoğun olur.  Sürekli işe girişler işten ayrılışlar vs. Bu gibi durumlarda Exchange yönetimi sizdeyse ve başka bu görevi yapan kişi yoksa bu işlemlerin bazıları sizin üzerinize kalacaktır. RBAC özelliği sayesinde bölgelerinizdeki IT ekibinize  Exchange Server üzerinde belirlediğiniz rolleri atayabilir ve sadece belirlediğiniz kişi ve gruplar üzerinde işlem yapmalarını sağlayabilirsiniz. Kısaca RBAC nedir üzerinden tekrar geçtikten sonra uygulamaya başlayabiliriz. Öncelikli olarak Coğrafi yerleşkelerinizdeki IT Support personellerinizin olduğu Group ları öncelikle belirlemeniz ve ardından bu gruplara önce Active Directory tarafında sadece User create, ve password resetleme bazlı delegasyon vermelisiniz. Bizim örneğimizde Mevcut Active directory yapımız ve OU şemamız aşağıdaki gibidir.

Mevcut Active Directory ve OU Yapımız.

Dikkat ederseniz 1 Tane Merkez Bölgemiz Yani İstanbul Lokasyonumuz mevcut. Diğer Coğrafi bölgelerimiz aslında bir nevi şube yapısında ve o bölgelerde IT Support personelimiz mevcut. Biz bölgelerimize bölge bazlı delegasyon ve ardından kendi Mailbox Databaselerine Mailbox create edebilme yetkisi vereceğiz. Özellikle üzerinde durmak istediğim bir husus Hem DC Tarafında hem Exchange tarafında Delagasyon yaparken  User bazlı değil Universal Security Group bazlı yaparsanız hem yönetimi hem de  Destek personellerinizin sayısının artması ya da azalması durumunda tekrar delegasyonla uğraşmak yerine mevcut grupa  ilgili işe başlayan yeni personeli üye yaparak çözüm üretmiş olursunuz.

Exchange tarafında öncelikle Delegasyon yaparak ilerleyelim.

Delegasyon yapılacak bölge OU > Ankara-Bolge  ilgili Universal  Security Group ismi aşağıdaki gibidir.ve şu an için tek üyeye sahiptir.

Exchange Delegasyonunu  Exchange Sunucu üzerinde Exchange Management Shell de ilgili parametreleri  çalıştırarak yapıyoruz. Burada dikkat edilmesi gereken husus Delegasyon yapacağımız Security Group’un Universal Sec. Group olması. Ve parametrelerin aşağıdaki gibi kendi yapınıza özgü Doğru OU ismi ve Doğru Universal Security Group ismi yazılarak parametrelerin sağlanmasıdır.

Yukarıdaki örnekte aslında şunu yaptık. 1. Atayacağımız role için bir isim oluşturduk bu isim “AnkaraMailRecipients” 2.  “ANK-ITM” universal sec. Groupa bu role için yetki verdik. 3. Contoso.com Domainindeki  Ankara-Bolge  OU birimini kapsam içine alması için  OU Scope alanına bu bilgiyi girdik.

İlk Satırdaki parametrede Mail Recipients için delegasyon yaptık. 2. Satırdaki parametreyle de Mail Recipient Creation işlemi için delegasyon yaptık ve bu işlemin sonunda  bu gruba üye olan Emre.A kullanıcısı ile Exchange Administrative Center a giriş yaptığımız da karşımıza gelen ekran aşağıdaki gibidir.

Fark ettiğiniz üzere Delegasyonla yalnızca User Mailbox Create etme ve yetki sahibi olduğu OU üzerindeki Recipients rolüne sahip olduğu için ilgili kullanıcının EAC alanı oldukça kısıtlı.

Aynı Delegasyon işlemlerinizi mevcut yapınızda kaç tane coğrafi lokasyona sahipseniz her birine eğer Exchange üzerinde delegasyon vermek istiyorsanız teker  teker yapmanız gerekir. Ben örnek olması açısından Ankara-Bolge OU birimini seçtim. Fakat komutların doğru parametreler girildiği takdirde sorunsuz çalıştığını görmeniz açısından Adana-Bolge OU birimi içinde ilgili  Universal Security Groupa delegasyon yapacağım.

Active Directory tarafında Adana-Bolge OU düzenim ve grup bilgim aşağıdaki gibidir.

Resimde Gördüğünüz üzere  Adana-Bolge OU birimi içinde ilgili universal security grupa delegasyonla mailbox create etme ve sadece kendi OU biriminde bu işlemleri yapabilmesi için delegasyon tanımladık.

Delegasyon sonrası EAC üzerinde ilgili kullanıcının yetki durumu aşağıdaki gibidir.

Buraya kadar doğru parametrelerle ilgili OU birimleri üzerinde belirlediğimiz USG lere üye IT Personelimize Exchange 2013 üzerinde mailbox create edebilme yetkisi tanımladık. Asıl bundan sonraki süreç  işimize daha çok yarayacağı gibi istemediğimiz karışıklıkların önüne geçmiş olacağız J hepinizin bildiği üzere Exchange yönetiminde en önemli hususlardan biri doğru birimlere doğru Mailbox Database yapılarını konumlandırmak örneğin;  Merkez Muhasebe birimindeki kullanıcılarınızın kullanmış olduğu Mailbox Database kısıtlamalarının VIP kullanıcılar için geçerli olmasını istemezsiniz veya tam tersi. İşte bu noktada Mailbox Create ederken doğru seçim yapılmadığı takdirde kısa süre sonra mailbox ım doldu kota sorunum var vs gibi şikayetler alırsınız. Burada tanımlayacağımız Restrictionlar sayesinde bölge IT personeliniz kendi bölgeleri dışındaki hiçbir Mailbox Database üzerinde mailbox create edemeyecekler. İşlemlere geçmeden önce Exchange Sunucumuz üzerindeki Mailbox Databaselerin durumunu ve isim bilgilerini aşağıda paylaşıyorum.

İlk olarak yazımın başında yapmış olduğum üzere Ankara-Bolge OU birimi için Database bazlı Restriction uygulayacağım. Komutları yine biraz sıkıcı gelse de J Exchange Management Shell üzerinde çalıştırıyoruz.

Öncelikle bir Ankara-Bolge DB leri için Management Scope oluşturalım. İlgili resim ve parametreleri aşağıdaki gibidir.

Şimdi de önceden oluşturduğumuz role grupla bu  yeni oluşturduğumuz ve Database filtreleme görevi görecek olan Management Scope ilişkisini kuralım.

Yukarıda yapmış olduğumuz işlem ile oluşturmuş olduğumuz Database Resctriction görevi görecek olan Management Scope ile önceden var olan rolümüz arasında ilişki kurduk. Dikkat ederseniz Role Assignee  alanında Security Group ismini veriyoruz. Ve o security grup üzerinde hali hazırda yetki olduğu için sadece yetkilerde bir güncelleme oluyor. Ve Mail recipients ve mail recipient creation işlemlerinde yukarıdaki Scope’a uygun kriterleri hedef almasını sağlamış oluyoruz. Şimdi deneme sırasına geçebiliriz J

Resimdeki   hata da belirttiği üzere Emre A kullanıcısı Ankara-Bolge OU su üzerinde yetkili ve mailbox Database Restriction işlemini uygularken biz  Ankara Mailbox DB01 üzerinde uyguladık. Dolayısıyla Emre A kullanıcısının Adana Mailbox DB01 üzerine mailbox create etme yetkisi yok. Verdiği hata da bu yönde. Fakat doğru mailbox seçimini manuel yapabilir veya direk seçim yapmadan next ile ilerlerse varsayılan olarak Ankara Mailbox DB01 üzerinde mailbox create ettiğiniz göreceksiniz.

Gelin aynı işlemi hızlıca Adana-Bolge OU birimi içinde gerçekleştirelim bazı komut ve detaylara girerek siz okuyucuları sıkmak istemiyorum parametreler yazımın başında da bahsettiğim gibi aynı tek değişken madde ortamınızdaki Domain ismi ve OU isimleriniz ve yetki ataması gerçekleştireceğiniz Universal Security Group isimleri olacaktır.

Adana-Bolge OU su için delegasyon ve Mailbox Database restriction işlemi gerçekleştiriyorum.

Parametrelerimiz yukarıda da gördüğünüz gibi aynı. Fakat OU ve Sec. Grup isimleri sadece değişik.

Şimdi gelelim deneme işlemine J normal şartlar altında bu yaptığımız işlemle Adana daki IT Personelimiz Şafak Tan. Adana Mailbox DB01 dışında bir DB’ye mailbox oluşturamaması lazım

Hata mesajımızı görmüş olduğunuz üzere Ankara Mailbox DB01 üzerine mailbox create etmek istediğimizde bizi bu Mailbox DB üzerine yazma yetkimiz olmadığı için uyarıyor J

Yani işlemimiz başarılı.

Buraya kadar yapmış olduğumuz işlemlerle hem yapınızda dağınık bir coğrafi lokasyon durumu ve bölge IT support birimleriniz söz konusuysa Exchange delegasyonu gerçekleştirebilirsiniz hem de Delegasyon yaparken bölge bazlı Mailbox Database kısıtlamasına giderek kimin hangi DB üzerinde mailbox create ettiğini veya doğru yanlış yapılacak mailbox oluşturma işlemlerini önlemiş olursunuz. Gerçek hayatta bu senaryonu kendim 13 lokasyon da faaliyet gösteren bir Sağlık Grubunda uyguladım. En çok fayda sağlayan nokta hem gereksiz iş yükünün azalması hem de oluşabilecek hataları önlemek yönündeydi.

Faydalı olması dileklerimle.

Group Policy ile Gizli Paylaşımların(Administrative Share) Kapatılması

Merhaba,  bu yazımızda Group Policy aracılığıyla Windows Gizli paylaşımlarının kapatılmasını uygulayacağız. Hem Client bazında hem De Serverlar bazında bu işlemi Group Policy aracılığıyla uygulamanız mümkün. Bu işlemi yapma nedeninizi tamamen yönetmekte olduğunuz yapının iç güvenlik standartlarına ve politikalarına bağlı olarak belirleyebilirsiniz.

Ben örneğimde bu işlemi tüm Active Directory ortamımdaki makinelerim için değilse Sadece Yönetim makinelerim için yapacağım. Dilerseniz siz kendi yapınıza göre çeşitli varyasyonlar belirleyebilirsiniz.

Uygulamamıza geçelim, hızlıca ortamımıza göz atalım. Serverlarım için Active Directory de ayrı OU birimlerim mevcut.  PC’lerim için ayrı. Ben uygulamam da production serverlarıma ve Müdürler PC’lerime bu policyi uygulayacağım. Zaten gerçek hayatta da işleyiş hemen hemen bu şekildedir.

Not:  Administrative Share’lerin kapatılması sonucu Ortamınız da SCCM ürünü varsa uygulama deployment işlemlerinizde ve SCCM ile windows update dağıtımları gerçekleştiriyorsanız bu işlemlerinizde sorun yaşayabilirsiniz. SCCM  uzmanları bu administrative sharelerin kapatılmasını genelde önermez.

Uygulamamızda  Merkez_Servers altındaki sunucular üzerinde policyi uygulayacağım. Ayrıca  Müdürler PCS altındaki client makineler için policy uygulayacağım.

Öncelikle Client makinelerimiz için policy uygulayalım. Fakat policy uygulamaya geçmeden önce  client bir PC’me  Network üzerinden C$  yöntemiyle erişmeyi deneyeceğim.

Gördüğünüz üzere network üzerinden  Client makinamın C$ birimine ulaşabiliyorum. Aynı şekilde 2. Partition varsa ona da erişebilirim.

Gördüğünüz üzere yedekler önemli adında da client makinem de bir klasör var J dolayısıyla bu bir güvenlik açığı.

Şimdi hızlıca işlemlerimize başlayalım. Ortamım hakkında bilgi verdikten ve erişim testi yaptıktan sonra

İlk olarak Group Policy Management Console aracımı başlatıyorum.

Policy uygulamak istediğim OU birimimi buluyorum ve  Sağ click > Create a GPO in this domain, and Link it here seçeneğini seçiyorum. Böylelikle hem yeni bir GPO objesi oluşturmuş hem de linklemiş oluyorum. Bildiğiniz üzere oluşturduğunuz GPO objeleri bir birime veya domaine veya Site a linklenmediği sürece  etkili olmaz, kıscası çalışmaz J

Gpo objemizi oluşturduk ve linkledikten sonra Edit seçeneğiyle işlemlere başlayabiliriz.

Makinelerle ilgili süreçleri yöneteceğimiz için  > Computer Configuration > Preferences > Windows Settings  adımlarını takip ediyorum.

Registry sekmesine kadar geliyorum ve ardından  Registry üzerinden sağ click > New >  Registry Item seçeneğini takip ediyorum.

Yapacağımız işlem Registry içerisinde tam olarak aşağıdaki alanda gerçekleşecek ve bu alana göre Registry item ekleyeceğiz. Aksi takdirde policymiz çalışmayacaktır.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Registry item ekleme penceresinde seçimlerimiz önemli öncelikle Action kısmında Create seçeneğini seçmeliyiz ki belirttiğimiz registry item oluşsun. Ardından  Key Path alanını doğru göstermeliyiz.

Key Path alanıdan tam registry yolunu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters biçimiyle gösterdikten sonra Value Name alanına  “AutoShareWks”  yazmalıyız.  Value Type alanından ise REG_DWORD seçimini yapmalıyız sonrasında  Value data  kısmını 0 olarak set etmeliyiz. Ardından Apply  ve Ok diyerek ilgili  registry keyimizi oluşturmuş oluyoruz.

Policymizi n çalışması için gerekli olan Registry keyini oluşturduktan sonra Hemen  cmd üzerinde  Gpupdate /force komutunu çalıştırarak policy güncellenmesini sağlıyorum.

Policymi uyguladığım OU birimim altındaki client makinelerim ilk restart sonrası policyden etkilenecektir.

Hemen test ediyorum.

Testimiz başarıı policyden etkilenen client makinemin C$ birimine gidemiyorum.

Aynı makinemin E$ gizli paylaşımına da gidemiyorum J

Client tarafında  cmd üzerinde >  Gpesult /r  komutunu çalıştırarak aldığı policyleri kontrol ediyorum.

Not: Gpresult /r komutunu çalıştırınca tam çıktı alabilmeniz için Local admin yetkisine sahip olmanız gerekli. Benim kullanıcımın bu yönde yetkisi mevcut. Aksi takdirde Makineye uygulanan policyleri görmez Sadece user policyleri görebilirdi.

Makinem üzerinde regediti kontrol ettiğimde de ilgili registry keyinin oluştuğunu görüyorum.

Evet arkadaşlar buraya kadar Client makinelerimizin Gizli paylaşımlarını policy aracılığıyla kapatmış bulunuyoruz. Şimdi ise aynı işlemi bazı kritik serverlarımız için yapalım. Fakat bazı farklılıklarla.

Policy uygulayacağım Serverlarımın OU birimlerini göstermek istiyorum.

Hızlıca GPMC aracımı başlatarak  sadece Production_Servers  OU birimim için bir policy oluşturuyor ve linkliyorum.

Edit diyerek yine Computer Configuration > Preferences > Windows Settings > Registry  yolunu takip ediyorum.

New Registry Item > seçeneğini seçiyorum ve aşağıdaki parametrelere sahip bir REG_DWORD oluşturuyorum.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareServer

Serverlar için bu işlemi yapacak olduğumdan  key ismimiz değişik.

Apply ve OK diyerek key oluşturma işlemimizi tamamlıyorum.

DC üzerinden tekrar  > Gpupdate /force komutunu çalıştırarak

Hemen işlemimizi test edelim fakat sunucuları istediğimiz zaman Restart vb işlemler yapamayacağımız için  sunucularımızda da istersek GPMC konsol üzerinden istersek sunucu da  gpupdate /force komutunu çalıştırarak bir süre beklemeliyiz ardından test işlemini yapabiliriz. Ben test ortamımda olduğum için sunucularımı restart ettim.

Hatta önerim, Server servisini de restart etmeniz yönünde Default olarak bu servis Running durumdadır. Policynin çalışmadığını düşündüğümüz durumlar da bu Servisi restart ederek çözüme kavuştuğumuz oldu J

Testimiz server1 için başarılı.

Şimdi server2  isimli sunucumuzu deneyelim.

Ondada işlemimiz başarılı hatta diğer sürücülere de erişemiyoruz.

Evet arkadaşlar işlemimiz aslında son derece basit sadece doğru planlama ve karar mekanizması işletmemiz gerekiyor. Yazımın başlarında da belirttiğim gibi ortamında SCCM ürünü vars ve client veya server ürünlerinize windows update i bu üründen geçiyorsanız veya uygulama dağıtımınız çok yoğun durumdaysa bu ayarı pek tavsiye etmiyoruz. Onun dışında gönü rahatlığıyla kullanabilirsiniz.

Başka yazılarımda görüşmek dileğiyle

Yönetici Hakları Olmadan Windows Servislerinin Yönetimi

Bu yazımız da Windows tabanlı işletim sistemi üzerindeki ( Server, Client ) servislerin Local Administrator veya Server Admin tarzı yetkilere sahip olmadan nasıl yönetileceğinden bahsedeceğim. Bildiğiniz üzere ister Sunucu ister istemci Windows makineler üzerinde Servisleri Stop, Start, Pause, veya Restart edebilmek için normal şartlar altında Local Administrator veya daha üst bir yetki gerektirir. Peki şimdi makalemizi yazma amacımıza gelebiliriz. Diyelim ki Kritik sunucuları yönetiyorsunuz. Ve bu sunuculara erişme yetkisi ( RDP ) olan kullanıcılarınız var ama bu kullanıcılara her ihtimale karşı Sunucular üzerinde Local admin veya Server Admin tarzı yetkiler vermek istemiyorsunuz. Çünkü sunucuları bilginiz dışında veya istem dışı Shutdown edebilir Restart edebilirler veya sunucular üzerinde sizin politikalarınıza aykırı işlemler gerçekleştirebilirler. ( Program kurulumu, donanım eklemesi vs ) Fakat bu kullanıcılarınızın aynı zamanda sunucular üzerinde çalışan bazı servislere müdahale edebilmelerini istiyorsunuz. Örneğin Sistem Yöneticisi olarak çalıştığınız yapı Türkiye genelinde coğrafi yerleşkeleri olan ve her coğrafi yerleşkede sunucuları ve üzerinde çalışan uygulamaları olan bir kurum. Siz istiyorsunuz ki her coğrafi bölgedeki sunucuların üzerinde o bölgedeki IT personellerinin Adminlik yetkisi olmasın ama belirlediğim çalışması gereken Sistemsel servislere müdahale edebilsinler. Bu durumda IT Destek personelinize veya IT birimindeki diğer iş birimlerindeki kişilere gereksiz sistemsel yetkiler vermek yerine alternatif çözümler üretmeniz gerekecektir.

Ben makalemin konusuna örnek olarak şöyle bir yapı kurguluyorum. Türkiye Genelinde 14 Farklı Lokasyon da Hizmet veren Hastaneler grubunun bulunduğu her Lokasyondaki Print Serverların üzerindeki “Print Spooler” servisini Bölge hastanelerindeki IT Personellerine yönetebilme yetkisi vermek istiyorum.
Bu örnek sadece benim verdiğim ve gerçek hayatta faaliyete aldığım bir örnek. Siz kendi yapınızda oluşabilecek ihtiyaçlara göre aksiyon alabilir çözüm üretebilirsiniz. Örneğin çok lokasyonlu Mağazacılık Sektöründe çalışıyorsunuzdur. Mağazalarınızdaki Sunucuların üzerinde çalışan Kasa veya Retail uygulamasına ait servisler vardır ve Start Stop, Restart olması gerekiyordur. Böyle durumlar da bu şekilde çözüm üretebilirsiniz.
Ben makalemize örnek olacak işlemleri “SubInAcl Tool” aracılığıyla gerçekleştireceğim.
İlgili Download linki : https://www.microsoft.com/en-us/download/details.aspx?id=23510
Kurulumu oldukça basit Next, next finish şeklinde olduğu için kurulum aşamasına girmiyorum.
Mevcut Yapım Aşağıdaki gibi. 

 

 

Ozgur Senerdogan kullanıcısına Antalya Bölgesindeki Print Serverlar üzerindeki Print Spooler Servislerini yönetme yetkisi vereceğiz. Kullanıcının bunun dışında bir yetkisi olmayacak.
Windows 8.1 istemci bir makineye Domain Admin yetkisine sahip bir kullanıcıyla oturum açıyorum. SubinAcl Toolunu kurarak çalıştırıyorum.
CMD komut satırına geçerek > programın kurulu olduğu C:\Program Files (x86) dizinine kadar geçiyorum. Sonrasındaki komut aşağıdaki gibidir. 

 

Bu komut ile birlikte programın kurulu olduğu bilgisayar veya sunucu üzerinde ilgili kullanıcıya Print Spooler serivisine müdahale edebilme yetkisi verdik. Amacımız sunucular üzerindeki servisler için yetki vermek. Bunun için kullanacağımız komut aşağıdaki gibi olmalıdır.

 

 

Yukarıdaki komutla şunu yapmış olduk. ANT-PRINTSRV01 ve 02 isimli sunucular üzerindeki Print spooler servislerinin Full Control yetkisini Mshowto Domainindeki ozgur.senerdogan kullanıcısına verdik.
Yetkilendirme yaparken baz alacağımız örnek harf parametre karşılığı listeyi aşağıda paylaşıyorum.

 

İlk testimizde “PTO” yetkisi vermiştik. P= Pause, Continue Service. T=Start Service O=Stop Service olarak algılayabilirsiniz.
Şimdi gelelim testimize.
Ozgur.senerdogan kullanıcısı ile her iki sunucu da oturum açarak ilgili servisi Stop – Start etmeyi deniyorum.

 

 

Testimiz başarılı J
Şimdide deneme amaçlı 1 sunucu da Domainimizdeki Hasan.dimdik kullanıcısına Windows Time Servisini Restart etme yetkisi verelim.
Servis ismini yazarken ServiceName alanını baz almalıyız.

 

 

Yetkiyi aşağıdaki şekilde verdik. F parametresi = Servis üzerinde Full kontrolü belirtiyor.

 

 

 

 

Hemen testimizi yapalım.

 

 

 

Testimiz başarılı. Hasan.Dimdik kullanıcısına Windows Time servisi için yetki vermiştik. Yetkimiz görüldüğü üzere çalışıyor. Deneme amaçlı Print Spooler servisini Stop etmeye çalıştığımda “Access denied” hatasını alıyorum. Çünkü kullanıcının o servisi yönetme yetkisi yok.
Yaptığımız örneklerden sonra yazımın başlarında da belirttiğim gibi kendi yönettiğiniz yapı genelinde benzer ihtiyaçlar olması halinde ilgili tool aracılığıyla bu işlemleri gerçekleştirebilirsiniz.
Peki aklınıza şöyle bir soru gelebilir. Biz Group Policy aracılığıyla bu işlemi yapamıyor muyuz? Pek tabii ki yapabiliyoruz. Fakat çok fazla grup Policy objeniz varsa SYSVOL klasörüm çabuk şişmesin diyebilirsiniz. Veya farklı bir açıdan bakacak olursak Group Policy tarafındaki “System Services” kısmından sadece Windows tabanlı servisleri yönetebiliyor yetki verebiliyoruz. Örneğimi açıklarken Mağazacılık uygulamalarından vb. örnek vermiştim bu tarz 3.parti uygulamaların çalıştırdığı Servisler Group Policy deki Services alanında gözükmeyeceği için bu tarz bir Tool aracılığıyla rahatlıkla bu yetki verme işlemini tamamlayabilirsiniz.
Yazımı faydalı olması dileği ile başka yazımda görüşmek üzere sonlandırıyorum J