Kurumsal İstemci Oturum Yönetimi Neden Gerekli?
Merhabalar, Techaptic kanalına hoş geldiniz. Bugün sizlerle Active Directory ortamlarımızda özellikle istemciler için yerel oturum açma işlemlerini nasıl kurumsal bir seviyede yönetebileceğimizle ilgili bir video hazırladık. Hatırlarsanız serinin ilk bölümünde bu sürecin adım adım nasıl devreye alınacağını görmüştük. Bir admin konsolumuz vardı. Bu konsol oluşturduğumuz iki custom attribute’umuzu yönetiyordu. Bunlardan biri politikanın ilgili bilgisayarda açılmasını veya kapatılmasını sağlayan Techaptic Logon Policy Enabled idi. Diğeri ise kimlerin o bilgisayarda yerel oturum açabileceği bilgisini tutan Techaptic Logon Principals attribute’uydu. Ayrıca bu konsolun yönetim için tek başına yeterli olmadığından da bahsetmiştik. Bu yüzden bir startup script’imiz vardı. Bu startup script ile bilgisayarlarda oluşturulan ve belirli zamanlarda çalışan bir zamanlanmış görevimiz de vardı. Bu görev, ilgili bilgisayar Active Directory ile iletişime geçtiğinde Domain Controller’a bağlanıp ilgili attribute bilgilerini okuyarak cache dosyasını yazıyor ve Allow log on locally ayarını güncelliyordu. İletişime geçemediği durumlarda ise bu işlemi cache dosyasındaki son bilgileri baz alarak yapıyordu. Tek bir konsol ile bu senaryo özellikle küçük ortamlar için oldukça yeterli bir çözüm olacaktır. Fakat orta ve büyük yapılarda bazı sınırlamalar ortaya çıkmaya başlar. Öncelikle politikayı her bilgisayarda tek tek yapılandırmak oldukça fazla zaman alabilir. Bilgisayar sayısı arttıkça bu değişiklikleri tek tek yapmak pratik olmaktan çıkar. Özellikle yüzlerce ya da binlerce bilgisayar olduğunda bu işlemlerin toplu olarak yapılabilmesi gerekir. Aksi halde süreç oldukça zaman alacaktır. İster istemez yüzlerce ya da binlerce bilgisayarın olduğu bir ortamda bu işin toplu olarak yapılabilmesi ihtiyacı ortaya çıkar. Bununla birlikte ayarlar yapılmaya başlandıktan sonra varsa eksikliklerin tespiti ve bunların kapatılması ihtiyacı da oluşur. Sonuçta bilgisayar sayısı ne kadar fazlaysa insan hatalarının artması da bir o kadar olası bir durumdur. Ve yapılandırma sonunda, biz bu işi nasıl yaptık deyip ikinci veya üçüncü bir kontrolün de sağlanması oldukça önemlidir. Ayrıca kimi ortamlar bu düzenlemelerin sadece belirli kişiler tarafından yapılmasını da isteyebilir. Yani herkesin bu işi yapabilmesi yerine belirli teknisyenlerin sadece bu işi yapıp diğer Active Directory yönetim işlemlerini yapamaması ihtiyacı da doğabilir. Bu, özellikle denetleme mekanizmasını ve hesap verebilirliği güçlendiren önemli bir adımdır. Son olarak orta ve büyük ölçekli yapılar bu işin raporlanması ve denetlenmesinin yanında otomasyona da ihtiyaç duyarak hem insan hatalarını en aza indirmek hem de teknisyenlerin zamanlarını daha verimli kullanmak için koşullu ayar setlerine de gereksinim duyar. İşte biz bu videoda sizlere ManageEngine ADManager Plus ürünü ile bu tür ihtiyaçların nasıl karşılanabileceğinden bahsedeceğiz. Bu ürün genel olarak teknisyen ile Active Directory arasında bir tür ara katman görevi üstlenerek raporlama, yönetim, otomasyon ve entegrasyon gibi araçlar sunar.
ADManager Plus Hazırlığı ve Tekil Bilgisayar Yönetimi
Şimdi isterseniz hemen ADManager Plus arayüzüne geçip bu senaryo üzerinde bahsettiğimiz ayarların nasıl yapılandırılabildiğine bakalım. Önce kısaca yaptığımız temel ayarları gözden geçirelim. Sağ üst tarafta Directory and Application Settings diye bir bölüm var. Burada gerek raporlama gerekse de yönetim işlemlerini yapacak bir hesap tanımladık. Sonra Admin Sekmesi. Admin sekmesindeki Custom Attributes bölümünden Active Directory’mizde yapılandırılmış olan custom attribute’larımızı ekledik. Ve ürüne bunların hangi syntax’ları kullandığını tanımladık. Ek olarak bu attribute’ların hem bilgisayar raporlarında görünmesi hem de bilgisayar düzenleme işlemlerinde kullanılması için ekrandaki ayarları uyguladık. Şimdi bu kısa açıklamadan sonra artık yönetim işlemlerine geçebiliriz. Management Sekmesi bize bu tür yapılandırma işlemlerini yapabilmemizi sağlayacak. Sol tarafta Computer Management’dan Modify Single Computer diyerek ilgili bilgisayarı seçip istediğimiz değişikliği yapabiliriz. Ben bu örneğimde VID-CLIENT01’i kullanacağım. Sağdan Modify Computer diyelim. Bu bölüm aslında varsayılan olarak sistem şablonunu kullanır. Ama biz kendi oluşturduğumuz şablonu bu video üzerinde daraltıp sadece ihtiyacımız olan bilgilerin gözükmesini sağladık. Dolayısıyla ekranda bu bilgisayar için yalnızca ihtiyacımız olan alanları görüyoruz. Techaptic Logon Policy Enabled değerini True yapıp kaydedebiliriz. Ayrıca kimlerin bu bilgisayarda oturum açabileceğini belirlemek istiyorsak Techaptic Logon Principals alanından ilgili kullanıcı ya da grup hesabının DN bilgisini girebiliriz. Bu bilgilere ürünün raporlar sekmesindeki hazır raporlarından erişebileceğimiz gibi kendi oluşturduğumuz Custom rapordan da erişebiliriz. Bu örnekte Workstation Logon Access raporunu açıyoruz. Ben örneğimde Lab User 01 hesabını kullanacağım, dolayısıyla bunun DN bilgisini kopyalayacağım. Böylelikle tanımladığımız bu hesap ve yerel yöneticiler grubundaki hesaplar dışında kalan kullanıcılar bu bilgisayarda oturum açamayacak.
Anlık Politika Senkronizasyonu
Peki bunun çalışması için şartlarımız neydi? Ya ilgili bilgisayar Active Directory ile iletişim kurabileceği şekilde yeniden başlatılacaktı. Ya da zamanlanmış görev yarım saatlik aralıklarla Active Directory’ye gidip bilgileri güncelleyecekti. Biz bu üründe betikler yardımıyla üçüncü bir seçenek daha oluşturduk. O da anlık senkronizasyon. Üründeki otomasyon bölümü bu tür işler için oldukça esnek araçlara sahip. Ekranda bu iş için oluşturduğumuz otomasyonu görüyoruz. Edit deyip detaylarına bakalım. Burada aksiyonumuz bir PowerShell betiği. Bu PowerShell betiğinin çalıştırılabilmesi için PS1 dosyasını ürünün kurulum dizinindeki Scripts klasörüne kopyaladık. Ve DNS Hostname attribute’unu, yani ilgili bilgisayarın FQDN bilgisini parametre alacak şekilde yapılandırdık. Böylece bu betik karşı bilgisayarlara gidip önceden startup script ile oluşturulmuş zamanlanmış görevi tetikleyecek şekilde tasarlandı. Tabii bu tür betiklerin ortamda çalışabilmesi için ürünün Windows servisinin gerekli yetkilere sahip bir hesapla çalışıyor olması gerekir. Ayrıca bu otomasyon özelinde Remote Scheduled Tasks Management için gereken RPC erişiminin güvenlik duvarı üzerinden izinli olması gerekir. Şimdi tekrardan Otomasyon sayfasına dönüp bu otomasyonu çalıştıralım. İşlemin tetiklendiğini söylüyor. Şimdi bunun durum bilgilerini incelemek için yanındaki ikona tıklayalım. Burada bu otomasyonla ilgili birçok geçmiş kaydı görüyoruz. En güncel olanlar en üst bölümde yer alır ve belirli bir request ID ile sistemde tutulur. Detaylı bilgi için bu ID’ye tıklayalım. Buradaki mesajda ilgili betiğin arka planda çalıştığını söylüyor. İsterseniz bilgisayara bağlanalım ve yaptığımız ayarların aktif olup olmadığını kontrol edelim. Lab User 01 kullanıcısına bu bilgisayarda yetki vermiştik zaten. Bu yüzden başka bir hesap ile oturum açmaya çalışalım. Gördüğünüz gibi bu hesapla oturum açamıyoruz. Yani betiğimiz çalışıyor.
Teknisyenlere Yetki Devri
Şimdi senaryo şöyle olsun. Biz bu yönetim işinin sadece belirli bir teknisyen veya teknisyenlerin yapmasını isteyelim. Fakat bunu yaparken o teknisyenler Active Directory’nin diğer ayarlarını değiştiremesinler. Bunun için üründe oldukça esnek rol tanımlamaları mevcut. Delegations sekmesinde gerek teknisyenlerin eklenmesi gerekse de rollerin tanımlanmasıyla ilgili ayarları yapabiliriz. Roller tarafında bu örnek üzerinde Manage Logon Assignment diye bir rol tanımladık. Bu rolün içerisinde hem özel raporlara erişim hem de bilgisayar objelerine düzenleme hakları var. Bunun ayarlarına da bakalım. Computer Management sekmesinde belirli attribute’lara yetkiler vermişiz. Ve ilgili bilgisayarlara düzenleme yetkisi vermişiz. Ve raporlara da bir yetki verdik. Bunun nedenini birazdan açıklayacağım. Özellikle Custom Raporlar kısmında. Sonra da bu rolü……teknisyene iliştirdik. Tabii bu rolü teknisyene iliştirdiğimizde ayrıca hangi Organizational Unit’ler üzerinde bunu yapabilsin yapamasın dediğimiz ayarlarımız da var. Dolayısıyla burada belirli bir OU’nun altında bu ayarları yapabilmesini istedik. Ve belirli bir şablonla bunu yapabilmesini istedik. Bu şekilde ilgili rolü daha da kısıtladık. Şimdi ilgili teknisyenle bir oturum açıp arayüzünün nasıl gözüktüğünü görelim. Hesabımız labsport01’di. Ekranda ürünü trial versiyonda kullandığımız için bir uyarı gösteriyor. Continue deyip ilerleyebiliriz. Gördüğünüz gibi rolü oldukça kısıtladığım için temelde iki sekme var. Bir Management bir de Report. Aslında teknisyenin asıl işini yapabileceği alan raporlar kısmı olacak. Burada ürünün güzel bir özelliği var. İlgili rapordaki objeleri verilen yetkiler dahilinde doğrudan yönetebiliyor. Sadece görüntülemek değil. Dolayısıyla biz ilgili bilgisayarı burada listeleyip ilgili bilgileri alırken eğer o bilgisayarın da içerisine gidersek bununla alakalı ayarları da burada yapabiliyor oluyoruz. Böylelikle bu alanları istediği gibi ilgili teknisyen güncelleyebilir. Biz kullanıcılar bölümünü de buraya eklemiştik. Dolayısıyla DN bilgilerini kolaylıkla buradan kopyalayıp bilgisayar objelerinde güncelleyebilir. Tabii bunu yapabilmesi için öncesinde bu raporun ilgili teknisyenle paylaşılması gerekir ki teknisyen ilgili rapora erişsin ve bu işlemleri yapabilsin. Buraya kadar her şey yolunda.
CSV ile Toplu Bilgisayar Güncellemesi
Fakat şöyle bir durum var. Tekil envanter değişikliklerinde ilgili teknisyenin bu işlemleri yapması mümkün. Fakat biz bu sistemi bütün bilgisayarlarda devreye almak istediğimizde ne yapacağız o zaman? Örneğin bir envanter yazılımımız var veya bu bilgileri bir Excel dosyasında tutuyoruzdur. Bu senaryoda hangi bilgisayarı kime verdiğimiz bellidir. Ve bu bilgisayarlarda ek olarak destek amacıyla kimlerin oturum açabileceğini de Active Directory’deki grup hesapları üzerinden yönetebiliriz. İşte bu noktada yüzlerce veya binlerce bilgisayar için bu işlemleri tek tek yapmak istemeyiz. Bunun için üründe Management sekmesinin altında ilgili obje tipleri için Bulk Modification bölümleri vardır. Bizim örneğimizde politikalar bilgisayar objeleri üzerinde tutulduğunda Computer Management alanına gelip Modify Bulk Computers diyebiliriz. Burada doğru formatla hazırlanmış bir CSV dosyası kullanarak ayarların toplu bir şekilde güncellenmesini sağlayabiliriz. Bir örnek yapalım. Sol tarafta Import bölümü var. Buraya tıklayalım. Ve Browse bölümünden ilgili CSV dosyasını seçelim. Ben öncesinde bir CSV dosyası hazırlamıştım bu video için. Bunu seçip Open diyorum. Ve OK diyorum. Şu an işlemi kaydetmeden önce uygulayacağımız ayarların bir listesini görüyoruz. Lab User 1, 2, 3 kullanıcıları ilgili bilgisayarlarda yetkilendirilmek istenmiş. Ve bununla birlikte Group Workstation Support grubu da bu üç bilgisayarda yetkilendirilecek. Ayarları kaydetmek için bu üç checkboxı işaretleyelim. Ve Update in AD diyelim. Ben sadece iki Custom Attribute’a değişiklik yapacağım. Dolayısıyla Name attribute’unun işaretini kaldırıyorum. Ve bu şekilde OK diyorum. İşlemin başarılı olduğunu söylüyor. Hemen bir bilgisayarda test edelim. Önce Automation bölümünden betiğimizi kullanarak güncel ayarların bilgisayar tarafından çekilmesini sağlayalım. Hemen Run Now diyelim. OK diyelim. Bu sefer ikinci bilgisayarı test edebiliriz. Lab User 02 kullanıcısı dışında bir hesap kullanacağız. Bunun için Lab User 01’i kullanabiliriz. Gördüğünüz gibi bilgisayar güncel politikayı aldığından bu hesap ile oturum açamadık.
Çalışan Yaşam Döngüsü Otomasyonuna Geçiş
Buraya kadar her şey yolunda. Şimdi bir kullanıcının envanter değişikliği durumunda bu yapının ADManager Plus ile nasıl yönetilebileceğini gördük. Fakat yeni bir kullanıcının işe girdiği onboarding veya işten çıktığı offboarding durumlarında bu süreci nasıl yöneteceğiz? Tabi sonuçta bu tür olaylar bir firmada genellikle çok sık yaşanmaz. Ve bizim az önce kullandığımız ekranlar bu senaryolar için pekâlâ kullanılabilir. Ama bu bilgisayarlarda veya kullanıcılarda yaptığımız işlemler genellikle bununla sınırlı kalmıyor. Örneğin yeni bir kullanıcı işe başladığında hesabı açılır. Belirli bir grup ya da gruplara dahil edilir. Mailbox hesabı oluşturmak gibi birçok farklı yapılandırma adımı var. Dolayısıyla bu tür süreçlerle beraber oturum açma yönetiminin de otomasyon sürecine dahil edilebilmesi değerlidir. Biz bu noktada küçük bir senaryo hazırladık. Ve bunu da sadece işten ayrılma süreci için tasarladık. Tabii istenirse birazdan göreceğimiz aksiyonlar ve çok daha fazlası arasından uygun olanlar düzenlenerek işe giriş senaryoları için de kullanılabilir. Offboarding sürecini canlandırmadan önce ilgili bilgisayarlar için politikalarımızın son durumuna bir göz atalım. Tekrardan Reports kısmına geliyoruz. Custom Reports alanından Workstation Logon Access raporunu açıyoruz. Güncel bilgileri çekebilmesi için tekrar Generate diyelim. Tekrardan Computer sekmesine geldiğimizde az önce uygulamış olduğumuz CSV ayarlarının bu bilgisayarlarda geçerli olduğunu görüyoruz. Tamam.
Offboarding Orkestrasyonunun Oluşturulması
Şimdi otomasyon bölümüne gidelim. Ve Orchestration Template altında önceden oluşturduğumuz Workstation User Offboarding şablonunu açalım. Bu şablon türü, bir dizi işlemin sıralı bir şekilde uygulanmasına ve bu akışın belirli bir yönetim aksiyonu tarafından tetiklenebilmesine imkân tanır. Sol tarafta görmüş olduğunuz birçok işlem ihtiyaca göre seçilip özelleştirilerek ilgili akışta sıralı bir şekilde çalıştırılabilir. Biz örnek akışımızda ilk olarak bir betik çalıştıracağız. Bu betikle kullanıcı işten ayrıldığında Active Directory’deki bilgisayar objelerinde Techaptic Logon Principals attribute’u içerisinde kullanıcının DN kaydını arayıp bulunduğu yerden bu kaydı silecek. Böylelikle eski kullanıcı bilgilerinin bilgisayar objelerinde yerel oturum açanlar listesinde gereksiz olarak kalmasını engellemiş olacağız. Tabi bunu yaparken bir nedenle eklemiş olduğumuz diğer kullanıcı veya grup hesaplarının bu ayardan etkilenmesini istemiyoruz. Bu yüzden bunlara dokunmayacağız. Bu arada bu işlemi ilk sırada çalıştıracağız. Çünkü kullanıcıyı başka bir OU’ya taşıdığımızda DN bilgisi değişeceğinden cleanup işlemini taşımadan önce yapacağız. İkinci adımda ise ilgili kullanıcı hesabının dahil olduğu grup üyeliklerini temizleyeceğiz. Böylelikle ilgili gruplara vermiş olduğumuz yetkiler varsa bunların da düşürülmesini sağlayacağız. Yalnız bunu yaparken sistem kullanıcının varsayılan primary group’u olan Domain Users üyeliğini tutacak. Bunun dışındaki üyelikleri kaldıracak. Bunu da ek bir bilgi olarak vermiş olalım. Üçüncü aşamada ise ilgili kullanıcının hesabına rastgele bir şifre tanımlayacağız. Özellikle işten ayrılan kullanıcının eski şifresinin sistemde tanımlı kalmaması ve bunun yerine rastgele bir şifre atanması güvenlik açısından daha doğru bir yaklaşım olacaktır. Ama tabi istenirse ihtiyaca göre belirli bir sabit şifrenin de uygulanması sağlanabilir. Ve son adımda da işten çıkan kullanıcı hesabının Former Employees altındaki Users OU’suna taşınmasını sağlayacağız. Böylelikle çalışan kullanıcı hesapları ile işten ayrılan kullanıcıları ayırarak AD yapımızı daha temiz tutmuş olacağız. Şimdi bu akışın tetiklenmesini uygun bir yönetim aksiyonuna bağlamamız gerekiyor.
Event-Driven Automation ve İK Entegrasyonu
Bunun için tekrardan otomasyon bölümüne gidip bu sefer Event Driven Automation bölümüne gidelim. Ve oluşturduğumuz Workstation User Offboarding otomasyonuna gidelim. Buradaki eventleri kullanıcı ya da grup hesapları için oluşturabiliriz. Bizim işimiz kullanıcı hesabıyla ilgili olduğundan biz kullanıcıyı seçtik burada. Sonra da bu otomasyonun kullanıcı hesabı düzenlendiği sırada tetiklenmesini ve bunun da kapsamını bir tık daha daraltarak yalnızca hesabın pasife çekilmesi durumunda çalışacak şekilde yapılandırdık. Yani biz ADManager Plus üzerinden herhangi bir kullanıcı hesabını pasife çekersek en altta yer alan Workstation User Offboarding orkestrasyon şablonunu tetiklemiş ve içerisindeki işlemlerin sıralı ve otomatik bir şekilde çalışmasını sağlamış olacağız. Bu akışın tetiklenme aksiyonu bana gerçekçi geliyor. Çünkü bir kullanıcı işten ayrıldığında bizim ilk yaptığımız işlem genellikle ilgili hesabın pasife çekilmesi oluyor. Dolayısıyla burada bu süreci manuel olarak tetikleyip geri kalan işlemlerin sistemi halletmesini sağlayacağız. Tabii birçok ortamda onboarding, offboarding ve çalışan yaşam döngüsü içerisinde alınacak aksiyonlar ilk olarak İK süreçlerinden başlayıp sonrasında IT ekibine yansır. Bu noktada İK ekibinin kullandığı bir uygulama varsa ADManager Plus uygulamayla entegre olabilir, kayıtları belirli aralıklarla kontrol ederek bir değişiklik durumunda Active Directory tarafında alınması gereken aksiyonları otomatik uygulayabilir. Böylelikle IT ekibi olarak bizim işimiz büyük ölçüde raporlama ve denetim tarafına kalmış olur. Özellikle bu tür entegrasyon ve otomasyon süreçleriyle ilgili ileride ayrı bir video da çekeceğiz.
Offboarding Akışının Çalıştırılması ve Doğrulanması
Şimdi yaptığımız ayarları inceledik, akışın çalışıp çalışmadığını kontrol edelim. Örnek olarak üçüncü bilgisayarda oturum açma yetkisine sahip olan Lab User 3 kullanıcısını test edebiliriz. Yalnız tetikleme yapmadan önce Active Directory’ye geçip ilgili kullanıcıyı kontrol edebilirim. Bu şekilde. Bu kullanıcının durumunu göstereceğim sizlere. Domain Controller’a bir oturum açalım. Burada Lab User 03 kullanıcısı Techaptic Logon Access OU’sunun altındaki Users OU’sunda ve hesap aktif görünüyor. İçerisine girip grup üyeliklerine bakalım. Gördüğünüz gibi Domain Users’la beraber File Server Access ve VPN Access gruplarına da dahil. Daha önceden raporlarda bu hesabın VID-CLIENT03 bilgisayarında yerel oturum açma yetkisi tanımlandığını gördük. Bu testten sonra Lab User 03 kullanıcısı için yetkinin kaldırılmasını ve diğer hesapların bu ayarlardan etkilenmemesini bekliyoruz. Tekrardan ADManager Plus arayüzüne geçelim ve ilgili hesabı pasife çekerek sonuçlarını gözlemleyelim. Bunun için Management kısmına geliyoruz. Bu sefer User Management altından Enable/Disable Users bölümüne gidelim. Burada hesabı pasife çekmek istediğimiz için Disable diyeceğiz. Ve ilgili hesabı bulacağız. Search diyelim. Hesabı listeledi. Seçip Apply diyebiliriz. İşlemin başarılı olduğunu söylüyor. Ayrıca bir Event-Driven Automation’ı da tetiklediğini söylüyor. Şimdi isterseniz Delegation alanına gidelim ve Audit Report bölümünden bu işlemin arayüzündeki sonuçlarını görelim. Sistem en son işlemi en üste attığı için biz analizimizi aşağıdan yukarıya doğru yapacağız. Burada ilgili kullanıcı hesabını kontrol ettiğimizde az önceki bilgilendirmeyi görüyoruz. Yani Event-Driven Automation’ı tetiklemişiz. Sonrasında betiğimiz çalışmış, başarılı olmuş ve kullanıcı Techaptic Logon Principals listesinden çıkarılmış. Ayrıca ilgili grup üyelikleri de kaldırılmış. Şifresi sıfırlanmış, değiştirilmiş. Son olarak da belirli bir Organizational Unit’e taşındığını söylüyor. Hemen Active Directory’ye geçip doğrulamasını yapalım. Hesabımız Techaptic Logon Access bölümündeydi. Bir Refresh atalım sayfaya. Gördüğünüz gibi hesap buradan gitmiş ve Former Employees altında olmasını bekliyoruz. Buraya da bir Refresh atalım. Evet, buraya taşınmış başarılı bir şekilde ve hesap pasife çekilmiş. Üyeliklerini de kontrol edelim hemen. Gördüğünüz gibi yalnızca Domain Users üyeliği kalmış. Diğer özel grup üyelikleri kaldırılmış. Diğer üyelikleri gitmiş. Şifresi de sıfırlanmıştı. Bunu çok test etmemize gerek yok. Ama konumuzda önemli olan kısım, ilgili bilgisayar objesinden de yerel oturum açan listesinden kaldırılması olacak. Bunun için VID-CLIENT03 bilgisayar objesine gidelim. Attribute Editor’dan kontrolünü sağlayalım. Gördüğünüz gibi Politika halen aktif ve Principles kısmında da sadece ilgili destek grubunun kaydı var. Lab User 03’ün DN bilgisi buradan başarılı bir şekilde silinmiş görünüyor.
Özet ve Yapının Genişletilmesi
Özetle, bu yapıyı kendi ortamlarınızda kullanarak sizler de yerel oturum açma süreçlerini etkili bir şekilde yönetebilir, denetleyebilir ve hatta otomasyonlarla zenginleştirebilirsiniz. Ayrıca bu küçük video serimizde sadece yerel oturum açma yönetimi üzerinde durduk. İsterseniz kullandığımız yapıyı uyarlayarak, Log on as a service, Access this computer from the network veya Log on through Remote Desktop Services gibi diğer kullanıcı haklarını ve bunların deny karşılıklarını da benzer bir mantıkla kendi ortamlarınızda devreye alabilirsiniz. Bir videomuzun da sonuna geldik. Bir sonrakinde görüşmek dileğiyle. Hoşçakalın.