Geçtiğimiz günlerde FreeBSD 12. sürümü yayınlandı. FreeBSD ücretsiz ve açık kaynaklı BSD(Berkeley Software Distribution) tabanlı Unix benzeri bir işletim sistemidir. 25 yılı aşkın süredir aktif ve geliştirilen bir işletim sistemi olan FreeBSD, açık kaynak ve BSD dünyasına birçok yenilik getirmiş ve destek olmuştur. FreeBSD birçok sektörde aktif olarak rol almaktadır. Birçok ünlü donanım üreticisi tarafından ürünlerini oluştururlarken FreeBSD kullanılmaktadır.

FreeBSD 12 Sistem Gereksinimleri

https://www.freebsd.org/doc/handbook/bsdinstall-hardware.html

https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ DVD kurulum ortamı için FreeBSD-12.0-RELEASE-amd64-dvd1.iso dosyasını seçerek indirebilirsiniz.

Hızlı kurulum adımına geçmek Enter'a basınız.

Kuruluma başlamak için "Install" seçip Enter'a basınız.

Türkçe klavye kullanmak istiyorsanız Turkish (Q) "Select" seçerek Enter’a basınız.

Seçimi onaylayıp devam etmek için "Continue with tr.kbd keymap" seçerek Enter’a basınız.

İsteğe bağlı sistem bileşenlerini yüklemek için boşluk tuşu yardımıyla seçip Enter’a basınız.

Herhangi bir seçim yapmak istemiyorsanız Enter’a basarak kurulumun diğer adımına geçiniz.

 "Auto (UFS)" Otomatik UFS(Unix File System) dosya sistemi yapılandırması için Enter’a basınız.

Tüm diskin kullanılmasını istiyorsanız "Entire Disk" seçerek Enter’a basınız.

Ön yüklenebilir disk bölümü yapılandırması için "MBR" seçerek Enter’a basınız.

Otomatik disk yapılandırmasını kabul ediyorsanız "Finish" seçerek Enter’a basınız.

Root kullanıcı parola belirleme işlemini tamamlayıp Enter’a basınız.

IPv4 yapılandırmasına devam etmek için Enter'a basınız.

DHCP üzerinden otomatik IP alarak yapılandırmak için Enter'a basınız.

Eğer kendi ağ topolojinize göre elle düzenlemek istiyorsanız "No" Enter'a basınız ve IP tanımlarını kaydediniz.

Ağ topolojinize göre DNS tanımla işlemini tamamlayıp Enter’a basınız.

Saat dilimi yapılandırmasını Türkiye olarak belirlemek için “Europe” seçerek Enter'a basınız.

Yön tuşları yardımıyla "Turkey" seçerek Enter'a basınız.

"+03" Saat dilimi kabul edip devam etmek için Enter'a basınız.

Geçerli tarih düzenlemelerini kontrol ederek Enter'a basınız.

Geçerli saat düzenlemelerini kontrol ederek Enter'a basınız.

Açılışta başlamasını istediğiniz servisleri seçmek için boşluk tuşu yardımıyla seçip Enter’a basınız.

Herhangi bir seçim yapmak istemiyorsanız Enter’a basarak kurulumun diğer adımına geçiniz.

Sistem güvenliği sıkılaştırma seçeneklerini seçmek için boşluk tuşu yardımıyla seçip Enter’a basınız.

Herhangi bir seçim yapmak istemiyorsanız Enter’a basarak kurulumun diğer adımına geçiniz.

Kullanıcı tanımlama işlemini yapılandırmak istiyorsanız Enter'a basınız.

Kullanıcı tanımla işlemini tamamlayıp Enter'a basınız. Tanımladığınız kullanıcının sistem yönetici haklarına sahip olmasını için "wheel ve operator" gruplarına eklemeyi unutmayanız.

Başka bir kullanıcı eklemek istiyorsanız "yes" Enter'a basınız. Eğer istemiyorsanız "no" Enter'a basınız.

Tüm yapılandırmalardan sonra kurulum tamamlandı. Kurulum sonrası ilk sistem açılışa geçiş için "Exit" Enter'a basınız. Eğer yapılandırmaları gözden geçirmek istiyorsanız ilgili başlığı seçip Enter'a basınız.

Yeni kurulmuş sistem üzerinde elle yapılandırma için "Yes" Enter'a basınız. Eğer istemiyorsanız "no" Enter'a basınız. 

Kurulum sonrası ilk sistem açılışı için Enter'a basınız.

Kurulum sırasında belirtiğiniz kullanıcı bilgileriyle sisteme giriş yapabilirsiniz.

Sisteminizin gerekli güncellemelerini

su -

freebsd-update fetch

freebsd-update install

ve belirtiğiniz kullanıcı parolasını girerek yapabilirsiniz.

Sisteminize ssh servisi üzerinden erişim sağlamak için ilgili servisi başlatmanız gerekmektedir. Servis durum kontrolü için service sshd status kullanabilirsiniz.

Eğer ssh servisi çalışmıyorsa ve sistem önyükleme süresinde etkinleştirilmemiş ise;

/etc/rc.conf içerisine sshd_enable="YES" eklenerek ssh servisi sistem önyükleme süresinde etkinleştirilir.

service sshd start              ile ssh servisi başlatılır.

service sshd status           ile ssh servis durum bilgileri görüntülenebilir.

Sisteminize ssh servisi üzerinden erişim sağlayabilirsiniz. Root güvenlik nedeniyle direk erişime engelli olduğunu unutmayın oluşturduğunuz kullanıcı ile oturum açıp sonra root kullanıcısına geçiş yapabilirsiniz.

Yaygınlaştırma projelerinde çok fazla karşılaştığımız bir durum olan kullanıcılara entegrasyonun nasıl yapılacağı konusu IT ekipleri için önem arz etmektedir.

Son zamanlarda bulunduğum Office 365 yaygınlaştırma projelerinde bu işi daha hızı nasıl yapabiliriz , kullanıcıya ve IT ekiplerine nasıl minumum iş yükü ile bu işi tamamlarız konusunda çalışmalar yapıyordum. Ufak olan yapılarda kullanıcılara manuel kurdurmak çözüm olabiliyorken büyük yapılarda bu işlem pek de mümkün olmuyor ki kullanıcıların Local administrator yetkisine sahip olmadığı ortamlarda bu işlem çok daha fazla durumu imkansız kılıyor. Teams yaygınlaştırmalarında öncelikle ürün testlerinde IT ekibi veya pilot kullanıcılar ile çalışarak onların deneyim kazanmasını hedefliyor ve sonrasında tüm organizasyona ürünü yaygınlaştırmamız gerekmektedir.

Teams şuan Office 365 Business ve Office 365 Pro Plus paketleri ile beraber gelmemektedir. Exe ve MSI paketi olmak üzere iki ayrı kurulum dosyası bulunmaktadır bu sebeple deployment için kullanabileceğimiz yöntemler aşağıdaki gibidir.

-SCCM

-Group Policy (Windows)

-MDM çözümleri (Ios + Android + Windows )

-Third-party yazılımlar

Microsoft tarafında yayınlanan güncel Teams MSI paketi ile beraber aslında bu işi Domain ortamlarında basit bir şekilde GPO ile bulk deployment yapabilir hale geldik. Adminler MSI paketleri ile kullanıcılara manuel download ettirmeden bu işi deployment ile otomatik yapabilirler. Bu konu ile ilgili yaptığım son projede uyguladığım adımları ve tecrübeleri sizlerle paylaşmak istedim.

Group policy ile deployment yaparken istediğim computer objelerine deployment yapabileceğim için bu konuda esnekliğimiz bulunmaktadır.

Microsoft Teams MSI paketleri ;

·         32 Bit : https://aka.ms/teams32bitmsi

·         64 Bit : https://aka.ms/teams64bitmsi

Önerilen Deployment prosedürü ;

·         Her zaman en son güncel paketi download ediniz

·         MSI paketinde herhangi bir değişiklik yapmayınız.

·         Eğer mümkünse computer objesine deployment yapınız.(Makine üzerindeki tüm yeni kullanıcılar teams’den yararlanabiliyor olsunlar)

Microsoft TEAMS MSI paketi nasıl çalışıyor.

Teams MSI paketi , deployment sonrası kurduğunuz versiyona göre “Program Files” veya “Program Files (x86)” klasörü altında yer alacak ve yeni bir kullanıcı ilgili bilgisayarda oturum açtığında bildiğiniz üzere sıfırdan bir “Windows User Profile” oluşturmaktadır.Yeni bir kullanıcı oturum açtığında Teams Installer çalışacak ve application’ı kullanıcının appdata folder’ı altına kopyalıyor olacak. Mevcuttaki bir kullanıcı oturum açtığında ise appdata folder’ı altına daha önce Teams app yüklenmişse bu kullanıcıları otomatik atlıyor olacak ve o kullanıcı için herhangi bir işlem işlem yapmayacak.

Burada MSI paketinin Teams updateleri için kullanılmaması gerekmektedir. Yani hali hazırda Teams deployment yaptınız , yeni versiyon Teams çıktığında tekrar bu paketi deployment yapmamanız gerekir. Çünkü Teams uygulaması yeni bir güncelleme çıktığında bunu otomatik Microsoft sunucularından algılar ve günceller. Eğer eski bir MSI paketi ile deployment yaptıysanızda Teams kullanıcılarda açılmadan önce kendini güncelliyor olacak. Eğer Re-Deployment yapmanız gereken bir durum varsa bunu makalenin en altında nasıl yapabileceğinizi bulabilirsiniz.

Teams MSI paketi ile deployment yapabilmemiz adına kullanıcı tarafında aşağıdaki gereksinimlere ihtiyacımız bulunmaktadır ;

-.NET framework 4.5 sürümü veya sonrası

-Windows 7 veya üstü

-3GB boş disk alanı her bir oturum açacak user profili için (Önerilen)

Group Policy ile nasıl dağıtacağımıza bir göz atalım

Active Directory yapısında Group Policy açıldıktan sonra öncelikle yapmamız gereken deploy etmek istediğimiz MSI paketini indirip sunucu’da client’ların erişebileceği bir alandan share etmeniz gerekmektedir. Burada önemli bir nokta , birden fazla domain controllerınız varsa ve dağıtık bir lokasyon yapısına sahipseniz kesinlikle MSI paketini sunucunun c:\ , d:\ gibi drive diskine atmayınız.

Merkez sunucusunda C:\ altındaki bir klasöre Teams MSI paketini koyar ve eğer group policy ayarlarında bu sunucuyu gösterirseniz bütün bölgelerde oturum açan bilgisayarlar ve kullanıcılarınız bu sunucuya erişmeye çalışacak ve aradaki network bağlantısında ciddi bir yüklenme meydana geliyor olacak.Peki ne yapmamız gerekiyor ?

Bu kısımda SYSVOL klasörü devreye giriyor.Sysvol yalnızca domaindeki her domain controller’da bulunan bir klasördür. İstemciler tarafından erişilmesi gereken ve domain controllerlar arasında senkronize edilen gerekli dosyaları barındırmaktadır.

Ben deploymentlar’da özellikle MSI ve scriptleri aşağıdaki lokasyon’da barındırmaktayım.

\\domain.com\sysvol\domain.com\scripts\TeamsMSI\Teams_windows_x64.msi

Yukarıdaki lokasyona scriptlerinizi veya MSI paketlerinizi atmanız durumunda tüm domain controllerlara bu paket sync oluyor olacak.

Gelelim Group policy kuralımıza...(Temel amacım group policy çalışma mantığını anlatmak olmadığı için basit bir şekilde nasıl yapılandırılır bunu göstereceğim.)

Computer objelerimin olduğu Organization Unit’e geldikten sonra yeni bir policy oluşturuyorum.

Sonrasında izlemem gereken yol ;

Computer Configuration\Policies\Software Settings\Software Installation kısmından yeni paket oluşturuyorum.

Bu bölümde yukarıdaki kısımlarda değindiğim paketin paylaşımda olan lokasyonunu gösteriyoruz. Eğer benim izlediğim yolu izliyorsanız paylaşım ayarlarını yaparken paylaşım path’inin doğru ve clientların erişebiliyor olduğundan emin olunuz.

Ben MSI paketi ile ilgili custom bir ayar yapmıyacağım için default “Assigned” seçeneği ile ilerliyorum.

Assigned seçeneğinden sonra Paketin oluşturulması 10 saniye kadar vakit almaktadır. Ekranda bir şey görmemeniz durumunda panik yapıp tekrar create etmeye çalışmayınız.

İpucu ! : İlk akla gelecek sorulardan biri olan bizim indirdiğimiz MSI paketi ingilizce ama benim kullanıcıların farklı dillerde işletim sistemlerine sahip ayrı ayrı MSI paketi mi indireceğim ?

Hayır! Yaptığım denemelerde client’lara kurulum sonrası Windows dili varsayılan ne ise Teams o dilde kuruluyor. Sonradan da bu dili değiştirmek Teams uygulamasının ayarlarından mümkün.

Server tarafında GPO ayarlarımızı tamamladıktan sonra computer objelerine GPO uyguladığımız için client makinelerinin policy’i almasına adına 1 kere reboot olması gerekmektedir.

İpucu ! : Ufak bir hatırlatma User policy’ler oturum kapatıp açma ile , Computer policy’ler restart ile uygulanır.

İpucu ! : GPO uygulaması sonrası eğer kullanıcılarda Teams kurulmadıysa ilk önce kullanıcı tarafında Windows Event Log’larını ve GPO policy’lerini alıp olmadığını “gpupdate /force” komutu ile kontrol etmenizi öneririm.

Policy sonrası client tarafını reboot edip durumu gözlemliyelim.

Teams kurulumu arka planda başladı ve kurulum tamamlandı.

Aşağıdaki kısımda görüleceği üzere makalenin üst kısımlarında bahsettiğim Teams kurulumu sonrası sunucu tarafını her seferinde kontrol etmekte ve yeni bir güncel versiyon varsa kullanıcının kullanımından önce update geçmektedir.

Login ekranında kullanıcı Office 365 account bilgileri ile login olması durumunda Teams hazır hale gelmiş olacak.

İpucu ! : Kullanıcı deneyimini arttırabilmek adına kullanıcıların her defasında uygulamalarına tekrardan password girmemeleri için ortama ADFS kurulmasını veya ADConnect ile gelen SSO özelliğinin enable edilmesini şiddetle önermekteyim. SSO olan ortamlarda deployment sonrası uygulama direk kullanıcı adı ve şifresi istemeden Teams uygulamasını açmaktadır.

Deployment sonrası masaüstü kısayolu’da kullanıcının masaüstünde gözüküyor olacak.

Deployment yaptığınız client işletim sistemleri eğer bir sanallaştırma platformu altında bulunuyorsa (Think Client , Remote Desktop Server vs)  GPO ayarları sonrası Teams uygulaması kurulmayabilir. İlgili Event Log altında aşağıdaki hatayı alıyorsanız eğer GPO tarafına eklemeniz gereken ufak bir ayar bulunmaktadır.

Teams Deployment için hazırlamış olduğum GPO içerisinde

Computer Configuration\Policies\Administrative Templates\System\Logon\ altındaki “Always wait for the network at computer startup and logon” seçeneğini enable ediniz.

Teams’in kalıntılarını temizleme ve yeniden deployment prosedürü

Kullanıcılarınızdan birinin profilin’den Teams uygulamasını uninstall etmesi durumunda GPO ile dağıtılan MSI installer uygulamanın kullanıcı tarafından kaldırıldığını algılayacak ve Teams uygulamasını tekrar o kullanıcı için kurmuyor olacak.Teams uygulamasını o kullanıcı için tekrar deploy edebilmek adına ilgili kullanıcıda aşağıdaki powershell script’inin çalıştırılması gerekmektedir.

Powershell Script 

<#

.SYNOPSIS

This script allows you to uninstall the Microsoft Teams app and remove Teams directory for a user.

.DESCRIPTION

Use this script to clear the installed Microsoft Teams application. Run this PowerShell script for each user profile for which the Teams App was installed on a machine. After the PowerShell has executed on all user profiles, Teams can be redeployed.

#>

$TeamsPath = [System.IO.Path]::Combine($env:LOCALAPPDATA, 'Microsoft', 'Teams')

$TeamsUpdateExePath = [System.IO.Path]::Combine($env:LOCALAPPDATA, 'Microsoft', 'Teams', 'Update.exe')

try

{

    if (Test-Path -Path $TeamsUpdateExePath) {

        Write-Host "Uninstalling Teams process"

        # Uninstall app

        $proc = Start-Process -FilePath $TeamsUpdateExePath -ArgumentList "-uninstall -s" -PassThru

        $proc.WaitForExit()

    }

    if (Test-Path -Path $TeamsPath) {

        Write-Host "Deleting Teams directory"

        Remove-Item –Path $TeamsPath -Recurse

    }

}

catch

{

    Write-Error -ErrorRecord $_

    exit /b 1

}

Umarım faydalı olmuştur , keyifli okumalar.

ADFS serverlarının kurulum , yönetim zorluğu , güvenlik ve yüksek erişilebilirlik için gereken donanım gereksinimlerinden ötürü Office 365 kullanan bir çok yapıda ADConnect ile gelen Pass-through özelliğinin kullanımı ile beraber bir dönüşüm başladı.Temel anlamda çok fazla complex ADFS özelliklerine ihtiyaç olmayacak ve kullanıcıların Office 365 , Azure AD SaaS gibi servislerinden publish edilen applicationlara erişirken şifre authentication işlemlerinin on-premise Active Directory yapısından olması ve kullanıcıyı deneyimini arttırmak adına SSO isteniyorsa Pass-Through bu konuda çok başarılı çalışmaktadır. Yaptığım projelerde öncelikle güvenlik adına ADConnect password synchronization yerine Pass-throughözelliğini tercih edip aktif etmekteyim. Entegrasyonlarda adconnect ile gelen “password hash synchronization” opsiyonu olsada şirket dışarısına password datasının çıkmasını istenmediği , güvenlikle ilgili kaygıların olduğu durumlarda pass-through ihtiyacımız olan çözümü sunmaktadır.

ADConnect pass-through çalışma mimarisi veya kurulum gereksinimlerini bir başka makalemde anlattığım için bu makalede anlatmıyor olacağım. Temel anlamda aşağıdaki gibi özelliği aktif edebilirsiniz. Peki Pass-through authentication özelliği ile nasıl ADFS’teki gibi farm yapısı kuracağız , kullanıcılarımıza nasıl yüksek erişebilirlik sağlayacağız ?

ADConnect ilk kurulumu tamamlandığında eğer pass-through özelliğini aktif ettiyseniz içinde pass-through agent varsayılan olarak gelmekte ve ortamda authentication işlemini sağlayacak ilk node (agent) olmaktadır. Yüksek erişilebilirlik için pass-through agentı farklı sunuculara kurarak elde edeceğiz.Azure Active Directory portalına eriştikten sonra ADConnect bölümü altında status’e göz atabilirsiniz.

Bu uyarıda Best Practices olarak agent’ın 3 farklı makineye kurulmasını önermektedir.

İpucu ! : Pass through agent maximum 12 taneye kadar support edilmektedir.

İçerisine göz attığımızda aktif olduğunu gözlemlemekteyiz , burada active statüsünden farklı bir durum varsa lütfen agent’ın kurulu olduğu sunucunun firewall tarafındaki internet erişimlerini kontrol ediniz. Bununla ilgili Microsof’un hazırlamış olduğu pass-through ve sso için gerekli olan portların check yapıldığı site bulunmaktadır. Troubleshooting ilk olarak kontrol etmeniz gereken agent’ın kurulu olduğu sunucu üzerinde aşağıdaki link’e erişip erişemediğiniz ve portların erişebilir olduğudur.

https://aadap-portcheck.connectorporttest.msappproxy.net/

Pass-through yüksek erişilebilirliği için ikinci hazırlamış olduğumuz sunucuya yukarıdaki ekrandaki download bölümünden pass-through agent install işlemini gerçekleştiriyoruz. Burada benim uyguladığım ve önerdiğim eğer müşteri birden fazla lokasyona sahipse ikinci veya üçüncü kurmak istediğiniz pass-through authentication agent’ını kesinlikle farklı bir lokasyondaki sunucuya install ediniz.

Pass-through agent sadece outbound olarak network trafiğinden çıkış yaparken aşağıdaki portlara ve URL’lere ihtiyaç duymaktadır.

·         80 portu - Sertifikasyonun doğrulama işleminde kullanılır. Firewall üzerinde 80 portundan dışarı tüm trafik açık değilse sadece bu URL’lere açmanız yeterlidir.

mscrl.microsoft.com:80 , crl.microsoft.com:80 , ocsp.msocsp.com:80 , www.microsoft.com:80

·         443 portu - Servis ile ilgili tüm iletişim trafiğini yönetir. Firewall üzerinde 443 portundan dışarı tüm trafik açık değilse sadece bu URL’lere açmanız yeterlidir.

*.msappproxy.net , *.servicebus.windows.net. , login.windows.net , login.microsoftonline.com

·         8080 (opsiyonel) portu - Authentication agent her 10 dakika da bir status raporunu Azure portalına 8080 portu üzerinden gönderir(Eğer 443 portundan ulaşılamıyorsa).8080 portu kullanıcının oturum açma işlemlerinde kullanılmamaktadır.

Minumum Windows Server 2012 R2 OS sahip sunucu üzerinde agent indirilir ve agent çalıştırılarak kurulum gerçekleştirilir. Kurulum esnasında Azure AD Global administrator kimlik bilgilerinin girilmesi gerekmektedir.

Azure portal’dan kontrolü yaptığımızda ikinci kurduğumuz agent’ında aktif olduğunu görmekteyiz.

Kurulum sırasında  0x80070643 kodlu bir hata alıyorsanız muhakkak yukarıda paylaşmış olduğum port , Url ve erişim testlerini gerçekleştiriniz. Port’ların erişilemiyor olması durumunda kurulum fail olacak ve  0x80070643 hatasını alıyor olacaksınız.

ADConnect Pass-Through Authentication server erişilemez duruma düşerse ne olur ?

Eğer makalede anlatıldığı gibi high available yapısı kurduysanız sunuculardan birine birşey olduğunda kullanıcı tarafında herhangi bir kesinti yaşamıyor olacaksanız fakat authentication için sadece ADConnect üzerinde varsayılan olarak gelen pass-through agentına sahipseniz ve sunucu’da yaşanacak bir kesinti’de Office 365 Portal ve SaaS uygulamalarını kullanan kullanıcılarda sign-in problemi yaşıyor olacaksınız.

Burada önemli bir detay pass-through ile beraber sso özelliğini kullanıyorsanız eğer network dışından portala erişmek istediğiniz , outlook profili kurmak istediğinizde , pass-through agent erişilemez durumdaysa aşağıdaki gibi hata ile karşılaşıyor ve oturum açamıyor olacaksınız.

İpucu ! : Pass-through agentının yüklü olduğu sunucu’da kesinti meydana gelmeden önce oturum açmış olan kullanıcılar’da bir sonraki oturum açma gereksinimine kadar herhangi bir kesinti yaşamıyor olacaksınız.

ADConnect Pass-Through Authentication sign-in problemlerinin troubleshooting edilmesi

Troubleshooting için kontrol edilmesi gereken log yolları aşağıdaki gibidir.

◾Authentication agent event log’ları için : Event Viewer altındaki Application and Service Logs \Microsoft\AzureAdConnect\AuthenticationAgent\Admin yoluna göz atabilirsiniz.

◾Agent’ların statüsleri için : Azure Active Directory altındaki AD Connect bölümünü kontrol ediniz.

◾Kurulum ile ilişkili ADConnect log’ları için : %ProgramData%\AADConnect\trace-*.log

◾Kullanıcıların oturum açma problemleri için : %ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\.

Örneklemek gerekirse bir kullanıcı ile Office 365 sayfasına az önce login olmayı denedim ve aldım , peki ne yapacağım sorun neden kaynaklanıyor olabilir ?

Yukarıda bahsettiğim gibi sing-in log’ları için pass-through agent’ının kurulu olduğu sunucuda %ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\. path’i altındaki tarih sıralamasındaki en üstteki log’u açınız.

Örnek’te görüldüğü üzere kullanıcının Active Directory hesabı kapalı olduğu için Office 365 Portalına sign-in olamadığı tespit edilmiştir.

ADConnect Pass-Through Authentication nasıl uninstall edilir ?

Pass-through agent’ını teknik sebeplerden ötürü tenant üzerinde uninstall etme ihtiyacınız olması veya yeni sunucuya kurup mevcut olan sunuculardan uninstall etme gibi bir planınız varsa best practices olarak öncelikle agent’ın kurulu olduğu sunucu üzerinde program ekle kaldır bölümünden aşağıdaki 3 bileşenin kaldırılması gerekmektedir.Agent uninstall edildikten sonra Azure üzerinde status’un “Inactive” durumuna düştüğünü göreceksiniz ve tenant üzerinden portal kısmından bir kaç gün sonra siliniyor olacak.

Umarım faydalı olmuştur , keyifli okumalar.

Kurumsal mail iletişiminde çok Büyük bir payı olan Office 365, günde 6,5 trilyon mailin üzerinden geçtiği bir platform için mutlaka güvenlik sağlamak zorunda. Tabiki %100 güvenlik diye bir kavram yoktur ancak özellikle minimum dışa bağımlı sistemler müşteriler tarafından tercih edilen bir modeldir. Yıllarca aslında bunu Exchange server’ ın her ne kadar varsayılan anti spam ve anti malware özelliği olsa da aslında çok başarı olmadığından dolayı mutlaka ya sunucu üzerinde çalışan ya da smtp gateway olarak sunucu önünde çalışan 3. Parti güvenlik üreticilerinin ürünlerini kullandık ve kullanmaya devam ediyoruz.

Her şirketin güvenlik disiplini ve beklentileri farklı olmak ile beraber ben genelde her ne kadar yönetim maliyeti hatta uzman personelin olmadığı durumlarda yönetim zafiyeti oluşturma riski olsa da güvenlik ürünlerinde tek elden korunmayı doğru bulmuyorum. Yani firewall üreticim ile anti spam üreticim hatta anti virüs üreticimin ayrı olması güvenlik noktasında bana daha avantajlı geliyor. Ancak tabiki bunun tam tersi durumların yani örneğin bir endpoint ile konuşan firewall’ un ne kadar proaktif çözüm üreteceğini veya tek bir ajan ile hem DLP hem AV yapmanın keyfini biliyorum. Zaten bu konu çok tartışılan bir konu, yani kesin bir doğrusu olmayan hatta benim bile farklı müşterilerimde müşteri dinamiklerinden kaynaklı farlı çözümler önerdiğim ve kurduğum oluyor.

İş mail güvenliğine gelince eğer imkânınız var ise mutlaka Office 365 EOP ve ATP yanında alternatif bir ürün kullanmanızı öneririm ancak eğer imkânınız yok veya mevcut ürünler neler yapabiliyor diyorsanız doğru yerdesiniz.

2010 yılından beri office 365 anlatmaya çalışan birisi olarak her ne kadar pek çok ürün içerse de exchange ve özelindeki konulara daha çok ilgi alanıma giriyor. Bu zamana kadar belki de Microsoft’ un güvenliği hiç bu kadar ciddiye aldığını hatırlamıyorum (eski bir forefront mvp si olarak forefront ürün ailesi de buna dahil). Ancak durum aşağıdaki gibi olunca bu işin pek şakası yok aslında;

Böylesi devasa bir network yöneten ekiplerinde devasa olması gerekiyor ki Microsoft bu konuda 3500’ den fazla güvenlik personeli çalıştırarak bu işi ne kadar ciddiye aldığını gösteriyor.

Microsoft’ ın Office 365 ile bize bütünleşik sunduğu EOP ve yine bütünleşik olmasına karşın ek olarak satılan ATP’ deki başarısının altında yatan detaya yakından bakmak gerekli;

Microsoft Intelligent Security Graph

Peki nedir Microsoft Intelligent Security Graph?

Aslında temel olarak yukarıda da gördüğünüz gibi milyarlarca posta kutusu üzerindeki büyük verinin makine öğrenme teknolojisi ile incelenip sonuçların yine entegre çalışan platformlar sayesinde kullanıcıları koruyacak tedbirlerin alınmasını sağlayan teknolojilerin bütünüdür, özetle aşağıdaki gibi 3 başlıkta toplanabilir;

Bunu 3500’ den fazla personel ile gerçekleştiriyor, rakamlar ise inanılmaz;

Evet bunlar reklam kokan hareketler, günün sonunda posta kutusuna spam veya kötü içerikli mail düşen çalışanlar yukarıdaki rakamlar ile pek ilgilenmeyebilir. Yukarıdaki giriş aslında tüm güvenlik üreticileri için geçerli, eğer dikkat ederseniz firewall üreticileri, proxy veya AV tarafında hep kurulu kutu veya kullanılan aktif kullanıcı sayılarını vermeye gayret gösterirler, tabiki eğer bu rakamlar yüksek ise. Bunun sebebi çok basit aslında, Microsoft’ un yaptığı gibi büyük veri var ise elinizde, dünyanın her bölgesinden yeterli veri alabiliyorsanız global bir koruma için bu veriyi izlemek, incelemek ve olası bir atağı algılayarak ilk sorun yaşayan kullanıcıların dışındakileri korumak kolaylaşıyor. Yani güvenlik sektöründe de bilgi güçtür. Tabiki bu tarz ürünler genel ataklar için çok başarılıdır, hedefli ataklarda durum farklı olup bu makalenin konusu değildir.

Peki Microsoft bu konudaki başarısını nasıl ölçüyor?

Bana sorarsanız mükemmel değil, bunu neye dayanarak söylüyorum? Öncelikle ücretiz olarak sunulan EOP çok çok iyi ama ücretsiz bir ürün için, tüm şirket mail güvenliğini EOP ile korumanız mümkün değil. Zaten böyle bir şey olsa ATP ürününü Microsoft ücretli olarak satmaz. EOP niye değerli? Pek çok mail kullanıcısı office 365’ e geçtiği andan itibaren ücretsiz olarak korunuyor bundan dolayı çok değerli bir hizmet ancak bazı kritik ataklar için ATP veya 3 parti ürünler kullanmanızı tavsiye ederim.

Evet Microsoft özellikle ATP ile sunduğu hizmeti sürekli ölçüyor, çünkü bu aslında 3 parti güvenlik ürünleri ile rekabet ediyor ve acaba verilecek para ATP ye mi yoksa 3 parti ürünlere mi verilecek büyük bir soru işareti?

Öncelikle yaygın senaryo aşağıdaki gibidir;

Yani öncelikle maillerinizi 3 parti bir güvenlik sağlayıcısına gönderip oradan temizlendiğini düşündüğünüz mailleri office 365’ e gönderiyoruz. Burada aslında kaçırılan maillerin olup olmadığını pek kontrol etmiyoruz. İlk kontrol noktası burasıdır. Yani rakip ürünlerin temizlemediği ama office 365’ in yakaladığı kaç mail oluyor? Bu genelde müşterilerin atladığı bir nokta olup bunu kontrol etmenizi tavsiye ediyorum. Bu nedenle zaten özellikle bulut mail güvenlik ürünleri için POC öneriyorum.

Peki burada ne tür teknolojiler kullanılıyor?

Zero-hour auto purge (ZAP)

Kullanıcılarınızın gelen kutularına daha önce gönderilen phishing, spam veya kötü amaçlı yazılım içeren mesajları tespit eden ve ardından kötü amaçlı içeriği zararsız hale getiren bir e-posta koruma özelliğidir. ZAP tüm office 365 posta kutuları için aktif olarak çalışan bir hizmet olup istenmesi halinde tenant bazlı kapatılabilir;

 Set-HostedContentFilterPolicy -Identity Test -ZapEnabled $false

ZAP varsayılan olarak çalışa bile müşteriler için aşağıdaki durumların olması şart olup bunların değişmesi durumun da aktif olarak çalışmadığını görebilirsiniz;

Öncelikle ZAP varsayılan olarak açık olduğu için sizin kişiselleştirilmiş yeni anti spam policy’ ler ZAP’ a göre baskın olur, bir nevi kullanıcı bazlı kurallarınız daha öncelikli çalışır.

Varsayılan olarak anti spam policy’ de spam mail bulunması durumunda action olarak “Move message to Junk Email folder” seçili olmalıdır.

Kullanıcıların junk mail koruması açık ve ayarları varsayılan olmalıdır.

Office 365 düzenli olarak anti-spam motorunu ve malware imzalarını günceller. Bu sayede ZAP hali hazırda bir kullanıcınızın posta kutusuna düşmüş ve bu güncelleme ile fark edilmiş maillerin taşınmasını sağlayabilir.

Örneğin okunmamış ancak spam olarak işaretlenmiş mailler otomatik junk klasörüne taşınır.

Eğer isterseniz okunmuş veya okunmamış olmasına bakmadan spam olarak işaretlenmiş mailler otomatik junk klasörüne taşınır

Eğer yeni algılanmış bir spam ise yine okunup okunmadığına bakmadan ekler posta’ dan silinebilir.

Bu ayarları https://protection.office.com ardından Threat managemenet - Anti Spam sekmesinden kontrol edebilirsiniz;

Anti Malware için ATP ile gelen safe attachment özelliği başlı başına çok başarı, bu konuda aşağıdaki videomu izlemenizi tavsiye ederim;

http://tv.cozumpark.com/video/792/Exchange-Online-Protection-EOP-ve-Advanced-Threat-Protection-ATP-Nedir-Nasil-calisir

Bir diğer konu ise Phishing mailleri;

Burada ise yukarıdaki gibi pek çok farklı yöntem kullanılmaktadır (header meta-data, message fingerprints ve URL listeleri gibi). Bu tarz bilinen teknolojilere ek ise kullanıcılardan gelen istihbarat, makine öğrenme teknolojisi, sürekli tarama teknolojisi gibi yetenekler ile daha gelişmiş bir phishing koruması sağlar. Buradaki en önemli kriter tüm bu sistemin tepesinde yetişmiş güvenlik personelinin olması. Çünkü hala AI veya ML gibi teknolojiler için insan kontrolü başarıyı arttırıyor.

Burada gördüğümüz bir sorun ise özellikle rakip 3 parti ürünlerden office 365 geçişi sonrası yapılandırma kopyalanma isteğidir. Yani eski üründeki ayarları birebir kopyalamak isteyen müşteriler her zaman başarılı bir sonuç elde edememiştir. Bunun nedeni ise her programda olduğu gibi Microsoft da kendi iş sisteminde çok ciddi bir algoritma ve ekip kullandığı için bu tarz farklılıklar başarı sonuçlarını etkilemektedir.

Son olarak özellikle bu tarz konularda pek çok test görebilirsiniz ancak yukarıda da bahsettiğim gibi en iyi test sizin gerçek ortamınızdaki testtir. Çünkü pek çok test merkezi veya bizim gibi sektör uzmanlarının yaptığı testlerde ( ben bu yüzden yapıp yayınlamıyorum, her müşterimde poc yapmayı tercih ediyorum çünkü her müşterinin mail alan, gönderen kullanıcı, müşteri ve partner profili ya da iş ihtiyaçları farklıdır) aşağıdaki gibi bazı eksiklikler bulunmaktadır;

Yukarıdaki her bir kutucuk bir test başlığını ifade ediyor, bunu genel olarak testlerde görebilirsiniz, ancak karşılaştırma testlerini gerçek ortam yerine test ortamında yaptığınız zaman kırmızı ve mavi kutuları aslında test etmemiş oluyorsunuz. Çünkü kırmızı kutular için gerçek gönderici, mavi kutular için ise gerçek alıcılar gereklidir.

Evet sözün özü, piyada da benim güvendiğim Microsoft dahil 3 marka var. Diğer ikisini buraya yazmaya gerek yok, ancak eğer bir mail güvenliği işi konuşuluyor ve işin içinde office 365 var ise mutlaka EOP + ATP veya iki bu konuda çok başarılı rakip ürün ile POC yapıp sonuca göre satın alım yaptırıyorum.

Peki on prem sistemler söz konusu ise? Her ne kadar bu makalenin konusu olmasa da bu durumda ürün sayısı biraz daha genişliyor, çünkü bazı çok başarılı ama office 365 desteği olmayan birkaç üretici var.

Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.

Kaynak;

https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/How-Microsoft-Measures-Effectiveness-of-Malware-amp-Phish-Catch/ba-p/263248

Geçen yıldan beri artan KVKK isteklerine pek çok müşterimde AIP ile cevap vermekteyim. Genel olarak süreç ve hukuk tarafını tanımlayan müşteriler teknoloji için kapımızı çalıyorlar, pek çok alanda teknik tedbirleri tamamlamak ve GDPR veya KVKK için hazır olmak istiyorlar. Bu noktada tabiki teknik tedbirlerde pek çok farklı çözüm veya ürün kullanabilirsiniz ancak en temel teknik tedbir verilerin sınıflandırılmasıdır. Bu noktada piyasada pek çok eski ve yeni ürün bulunmaktadır. Bu ürünlerden birisi ise Azure Information Protection’ dır.

Bu konuda pek çok kaynak paylaştığım için bunlardan en özet ve anlaşılanı aşağıdaki video olup izlemenizi tavsiye ederim.

http://tv.cozumpark.com/video/851/Azure-information-Protection

Bu makalemde ise AIP ile beraber gelen AIP scanner yüklemesinden bahsedeceğim. Kullanıcı makinelerine yüklediğimiz agent sayesinde burada üretilen ve işlenen verileri sınıflandırabiliyoruz ancak file server gibi sharepoint ve benzeri ortamlardaki kütüphanelerin taranması ve sınıflandırma ihtiyacı için aip scanner adını verdiğimiz ayrı bir agent – ürün kullanıyoruz.

Yukarıda gördüğünüz gibi bir sunucu üstüne scanner servisini kuruyoruz, internet üzerinden sınıflandırma ilkelerini alıyor, SMB veya http/HTTPS servisleri ile sınıflandırılacak kütüphanelere bağlanıp sonuçları SQL veri tabanında saklamaktadır.

Bu makalemde ben de bu ürünün nasıl yükleneceğinden bahsedeceğim. Aslında ürünün yüklenmesinde pek bir sıkıntı yok daha çok kullanımında uzmanlık gerektiren konular olup bunu da uygun olduğum bir başka hafta sonu yazmayı düşünüyorum.

Bu arada bu ürünle gerçekten çok büyük ve global birkaç firmada KVKK kapsamında veri sınıflandırma yaptığım için ciddi bir tecrübeye sahip oldum. O yüzden özellikle rakip ürünlere göre artıları ve eksilerini bilerek bu tarz ürünleri müşterilere aldırmak biz danışmanların en büyük sorumluluğu olsa gerek.

Peki kurulum için ne gerekli?

İşletim sistemi olarak 2012 R2 veya 2016 kullanabilirsiniz. Minimum 4 Core CPU ve 4GB Ram gerekmektedir. Ancak burada büyük veri yığınlarını tarayacağınızı düşünüyorsanız öncelikle CPU ve RAM miktarını arttırmanız tarama hızınızı doğrudan etkiler. RAM özellikle çok önemli olup tarama yapacağınız her bir dosya için ortalama 2.5 veya 3 kat RAM harcar. Yani ne kadar çok RAM verirseniz eş zamanlı o kadar çok dosyayı tarayabilir.

Sunucunun mutlaka internete çıkması lazım, burada dosyaları internete yüklüyor gibi bir şey aklınıza gelmesin zaten trafiği isterseniz takip edebilirsiniz, buradaki amaç bulut üzerinde olan yönetim konsolu ve orada tanımladığınız etiket kurallarına ulaşmak.

Veri tabanı için SQL 2012 ve üstü Express edition yeterlidir.

Konsolide bir SQL kullanmak istiyorsanız sysadmin rolüne ihtiyaç duyacağını belirtmek isterim, ondan kendisine özel Express güvenlik anlamında işlerinizi kolaylaştırır.

On-prem ortamda yetkili bir servis hesabına ihtiyaç duyar.

Burada genelde tarama yapılacak file server için local admin kullanılabilir.

Öncelikle aşağıdaki linkten agent’ ı indiriyoruz

https://www.microsoft.com/en-us/download/details.aspx?id=53018

Öncelikle SQL Express kurulumunu tamamlayın ve AIP servis hesabı için sysadmin yetkisi verin, çünkü kurulumda SQL instance bilgisi verilip veri tabanının otomatik oluşturulması sağlanacak. Bu nedenle önce veri tabanı kurulumunu tamamlayın.

Daha sonra Azure Information Protection client kurulumunu tamamlayın

Daha sonra powershell de aşağıdaki komutu yazın

Install-Module AzureADPreview

Eğer yüklü bir makine üzerinde kurulum yapıyorsanız bu adımı atlayabilirsiniz.

SQL kurulumu tamamlandı ise aşağıdaki komut ile AIPScanner yüklemesini başlatabiliriz;

Install-AIPScanner

Buradaki hesap hem sql de hem de taranacak klasörlerde yetkili AIP servis hesabı olmalıdır.

Daha sonra SQL sunucu ismi sorulmaktadır;

Eğer herhangi bir sorun yaşamazsanız kısa bir sürede yüklemenin olduğunu göreceksiniz;

Eğer bir sorun yaşarsanız yükleme ekranındaki log dosyasının mutlaka incelemenizi öneririm.

SQL Veri tabanındaki durum aşağıdaki gibidir;

Servislerde ise AIP scanner servisini görebiliyoruz;

Evet kurulum sonra derece kolay ve hızlı bir şekilde tamamlandı. Bundan sonra ise taranacak file server veya sharepoint kütüphanelerinin tanımlanması, tarama için sadece raporlama mı yoksa değişiklik yapılacak mı karar verilmesi gerekli.

Bir sonraki bölümde de umarım bu konulara değineceğim.

Bir sonraki makalemde görüşmek üzere.

Kaynak

https://techcommunity.microsoft.com/t5/Azure-Information-Protection/Azure-Information-Protection-Scanner-Express-Installation/ba-p/265424

BSD (Berkeley Software Distribution) ailesinin diğer üyelerinden biri olan OpenBSD, açık kaynaklı ve güvenlik odaklı Unix benzeri bir işletim sistemidir. 20 yılı aşkın süredir aktif ve geliştirilen bir işletim sistemi olan OpenBSD, açık kaynak ve BSD dünyasına birçok yenilik getirmiş ve destek olmuştur. Güvenlik odaklı geliştirilmesi nedeniyle birçok sektörde aktif olarak rol almaktadır. Günlük hayatta sıkça kullandığımız ve karşılaştığımız OpenSSH ve LibreSSL gibi güvenlik odaklı projeler OpenBSD tarafından geliştirilmektedir.

OpenBSD 6.4 Sistem Gereksinimleri

https://www.openbsd.org/faq/faq4.html

https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/install64.iso dosyasını amd64 mimarisi için indirebilirsiniz. Farklı bir mimari için https://www.openbsd.org/faq/faq4.html#Download adresine göz atabilirsiniz.

Kurulum:

Karşımıza OpenBSD kurulum menüsü gelmektedir. Kuruluma devam etmek için "I" yazıp Enter'a basınız.

Ön tanımlı İngilizce klavye kullanmak için Enter'a basınız. Eğer Türkçe klavye kullanmak istiyorsanız "tr" yazıp Enter'a basınız.

Bilgisayar adını belirterek Enter'a basınız.

Kablolu ağ yapılandırmasına devam etmek için Enter'a basınız.

IPv4 yapılandırmasına DHCP üzerinden otomatik IP alarak yapılandırmak için Enter'a basınız.

Eğer kendi ağ topolojinize göre elle düzenlemek istiyorsanız IP adresini belirterek Enter'a basınız.

Ağ topolojinize göre ağ maskesini belirterek Enter'a basınız.

IPv6 yapılandırmasına devam etmek için "autoconf" yazıp Enter'a basınız. Eğer yapılandırmak istemiyorsanız "none" yazıp Enter'a basınız.

Kablolu ağ yapılandırmasına devam etmek için Enter'a basınız.

Ağ topolojinize göre ağ geçidinizi belirtip Enter'a basınız.

Ağ topolojinize göre DNS etki alan adını belirterek Enter'a basınız.

Ağ topolojinize göre DNS sunucusu bilgilerini belirterek Enter'a basınız.

Root kullanıcı parola belirleme işlemini tamamlayıp Enter'a basınız.

Ön tanımlı olarak ssh servisinin çalışması için "yes" Enter'a basınız.

X Masaüstü Sistemini kullanmak için "yes" Enter'a basınız.

X Masaüstü Sistemini xenodm ile başlatmak için "yes" Enter'a basınız. Eğer yapılandırmak istemiyorsanız "no" yazıp Enter'a basınız.

Tanımlamak istediğiniz kullanıcı adını belirterek Enter'a basınız.

Tanımladığınız kullanıcı için Ad Soyadı bilgilerini belirterek Enter'a basınız.

Tanımladığınız kullanıcı için parola belirleme işlemini tamamlayıp Enter'a basınız.

Root ssh girişine izin vermek için "yes" Enter'a basınız. Eğer ssh girişine izin vermek istemiyorsanız "no" Enter'a basınız. Güvenlik nedeniyle direk root ssh kullanımı önerilmemektedir.

Saat dilimi yapılandırmasını "Asia/Istanbul" olarak belirlemek için Enter'a basınız.

Kurulumun yapılmasını istediğiniz diski belirterek Enter'a basınız.

Tüm diskin kullanılmasını istiyorsanız "whole" seçerek Enter'a basınız.

Otomatik disk yapılandırmasını kabul ediyorsanız "a" seçerek Enter'a basınız.

Kurulum kaynağı olarak "cd0" belirterek Enter'a basınız.

Kaynak yol tanımı olarak "6.4/amd64" Enter'a basınız.

Kurulacak paketleri kabul ederek devam etmek için Enter'a basınız.

SHA256.sig Doğrulaması olmadan devam etmek için "yes" Enter'a basınız.

Kurulumun bir sonraki adıma geçmek için "done" Enter'a basınız.

Zaman düzenlemesini kabul ederek devam etmek için "yes" Enter'a basınız.

Kurulum sonrası ilk sistem açılışı için "Reboot" Enter'a basınız.

Kurulum sırasında belirtiğiniz kullanıcı bilgileriyle sisteme giriş yapabilirsiniz.

Sisteminizde kurulu olan paketleri güncellemek için

su -

pkg_add -u

root parolasını girerek yapabilirsiniz.

OpenBSD taban sistemi yamalarını yüklemek için syspatch komutunu kullana bilirsiniz.

Sisteminize ssh servisi üzerinden erişim sağlamak için ilgili servisi başlatmanız gerekmektedir. Servis durum kontrolü için rcctl check sshd kullanabilirsiniz.

Eğer ssh servisi çalışmıyorsa ve sistem önyükleme süresinde etkinleştirilmemiş ise;

rcctl enable sshd         ile ssh servisi sistem önyükleme süresinde etkinleştirilir.

rcctl start sshd             ile ssh servisi başlatılır.

rcctl check sshd           ile ssh servis durum bilgileri görüntülenebilir.

Sisteminize ssh servisi üzerinden erişim sağlayabilirsiniz.

Önceki yüzyılın sonlarından beri gücünü ıspatlamış sınırlı sayıda network cihaz üreticilerinin tekelinde olan kapalı güncel teknolojiler zamanla daha açık hale geliyor. Geçmiş yüzyıllardaki yeniliklerin her birinin bir zamanlar tekel kontrolden çıktığı gibi. Bilgiye erişme gücünün artmasıyla her gün yenilikçi buluşlar yapılarak yeni şirketler, bilgiye erişme gücünü daha kullanışlı, daha verimli ve herkesin rahatça ulaşabileceği bir noktaya getiriyor.

Buna örnek olarak 2009 da kurulan Force10 markasını gösterebiliriz. Odak alanını 10G 40G bağlantı hızlarına çevirmiş ve yeni güçlü ürünler geliştirerek mevcut üreticilere güçlü alternatif olmuştur. DellEMC bu markayı 2013 yılında bünyesine katmış ve cihazların gücüne güç katmıştır.

Ülkemizde de adını hızla duyurmakta olan DellEMC Networking ürünlerini incelemekte fayda görüyorum.

Bu ürünleri iki parça halinde kampüs ve datacenter olarak inceleyelim.

Öncelikle kampüs alanında iki seri bulunmaktadır.

X-Series

Web managed 10/100/1000 olarak çalışan bu ürünler küçük projelerde kullanılabilir.

Aranacak özellik olarak 8 portlu da sfp uplink yuvası bulunmamakta. 16 ve 24 de 2 adet 1G sfp yuvası bulunmakta, 48 portlularda 4 adet 10G sfp+ yuvası bulunmakta.

N-Series

N-Serisi, kampüs içerisinde tüm ihtiyacı karşılayacak fotoğraftaki gibi 5 aileye sahiptir. Bu serinin tamamının uplink portları 10G dir. Uplink portlarda, layer 3 görevlerde vs harici lisans gerekmesi gibi bir durum yoktur. Cihazın özelliği neyse tamamı açık halde gelir. Tüm switchlerde olduğu gibi broadcom işlemci setine sahip, os6 versiyonuyla çalışır. Dell support kalitesini Server-Storage dan bilirsiniz, network ürünlerinde de aynı support yapısına sahiptir. Şuana kadar ki geri dönüşler, devreye alındıktan sonra support a pek ihtiyaç olmadığı yönünde, oldukça stabil çalışan ürünler. Poe özelliğine sahip switchlerde her porttan 30.8 watt a kadar güç sağlanabilir, bazı modellerde harici veya dahili yedek, psu ile bu değer daha da artmakta. Bu cihazlarla kablosuz, cctv, ıp telefon gibi projelerde güç sıkıntısı yaşanmamaktadır. –ON uzantısına sahip modeller open network özelliği taşımaktadır. Ayrıca marka bağımsız çalışan DellEMC network yönetim yazılımı olan OMNM (Open Manage Network Manager) yazılımın olduğunu da burada söyleyelim.

Kısaca aile aile detay özellikleri;

N1100 Serisi

8, 24, 48 portlu poe+ ve non-poe modelleri vardır. (N1124T,N1124P..)

Poe+ modellerin hepsinde port sayısının yarısı poe+ özellik taşır. (örn; 24 portlu poe modelin 12 portu poe, 12 portu poe değildir.

Standart Layer 2 görevlerin tamamını yapar.

4 adet 10G SFP+ uplink vardır.

4 adete kadar stack yapılabilir.

Poe olmayan modeller fansız dır. Yüksek ve düşük sıcaklıklarda verimli şekilde sessiz çalışabiliyorlar. Elektrik kullanımından da tasaruf sağlıyor. Oda içerisinde konumlandırılacak switch ler için sessiz olması bazen aranan bir özellik olabiliyor.

N1500 Serisi

24 ve 48 portlu poe+ ve non-poe modelleri vardır. (N1524, N1524P, N1548, N1548P)

750W lık ve 1000W lık harici güç kaynağıda yanında verilebilir. Poe de güç yetmeme derdi hiç bir şekilde olmuyor.

Layer 3 lite, yani static route ve RIP özelliklerine sahiptir.

4 adet 10G SFP+ uplink vardır.

4 adete kadar stack yapılabilir.

N2000 Serisi

24 ve 48 portlu poe+ ve non-poe modelleri vardır. (N2024, N2024P, N2048, N2048P)

Poe modellerde aynı şekilde her porttan 30.8 w güç sağlayabiliyor ve harici güç kaynağı destekliyor.

Layer 3 standart, yani static route, RIP ve OSPF özelliklerine sahiptir.

84 Gbps stack bant genişliğine sahip 2 adet ayrı stack portuna sahiptir. 12 adet switche kadar stack yapabilir.

2 adet 10G sfp+ yuvası vardır.

N3000E Serisi

24 ve 48 portlu poe+ ve non-poe modelleri ile 24 portlu full 1G fiber olan modeli vardır (N3024EF-ON, N3024E, N3024EP, N3048E, N3048EP)

Dahili yedek güç kaynağı vardır. Poe modellerde yine güç sıkıntısı yaratmaz.

Layer 3 distribution, yani static, rip, ospf, vrrp, pbr, nssa, bgp layer 3 özelliklerine sahiptir. Rahatlıkla omurga tarafında kullanılabilecek bir cihazdır.

84 Gbps stack bant genişliğine sahip 2 adet ayrı stack portuna sahiptir. 12 adet switche kadar stack yapabilir.

2 adet 10G sfp+ uplink port

2 adet 1G sfp media combo port (son iki bakır porttan kullanır)

1 adet arka modül yuvasına; 2 port 10G Base-T ve 2 port 10G SFP+ modül de eklenebilir.

Ayrıca bakmamız gereken farklı projelerde kullanılabilecek N2000 ve N3000 serisi altında bulunan N2128PX-ON ve N3132PX-ON modelleri;

Bu modeller fark yaratan modellerden dir. Fotoğrafta görülen ayrı duran 4 adet ve 8 adet olan portlar auto-sensing 10/100/1000/2500/5000MB hız sağlayabilir ve 60W poe özelliği taşır. Yeni nesil kablosuz access point cihazlarında daha fazla güç ihtiyaçlarıyla bu hızları destekleyen portlar mevcuttur. Bir projede böyle özellikler gerektiren cihazlardan kullanılıyorsa maliyet bakımından da performans bakımından da tercih edilebilir.

Ayrıca 2-4 adet 10G sfp+ uplink yuvalarıyla beraber N3132PX modelinde arka modül yuvasına 2 port 40G modül takılarak omurgada bile kullanılabilecek çok amaçlı cihazlar haline gelebiliyor.

N4000 Serisi

Kampüs omurga da kullanılan bu modelde tüm portlar 10G bakır veya SFP+, uplinkler 2 veya 4 adet 40G QSFP+ desteği var.  Bu 40G portlarda 4x10G breakout kablo ile 10G olarakta kullanılabilir. Bu sebeble isimleri 32 ve 64 olarak anılmaktadır. (N4032, N4032F, N4064, N4064F)

Yedek güç kaynağı direk üzerinde geliyor.

Layer 3 distribution, static, rip, ospf, vrrp, pbr, nssa, bgp layer 3 özelliklerine sahiptir.

Her hangi bir portu bir komutla stack portu olarak belirlenebilir. 40G ve 10G olarak kullanılabilir. 12 adete kadar stack olabilir.

Üzerinde bulunan modüllere ayrıca; 4 port 10G SFP+, 4 port 10G base-T bakır, 2 port 40G QSFP+ modül takılabilir.

DellEMC kampüs tarafında C9010 model 10 slotlu şasi cihaz bulunmaktadır. Yeni çözüm alternatiflerinin olmasıyla beraber network topolojilerinde şasi kullanılmasını pek anlamlı bulmuyorum.Mevcut teknolojide tüm marka şasi çözümleri artık hantal, yedekliliği verimli olmayan, yüksek güç tüketimi ve yüksek maliyetlere sahip olan sistemlerdir.

Bunun yerine N4000 veya aşağıda inceleyeceğimiz Datacenter S-serisi cihazlarla stack mimaride veya leaf-spine mimaride omurgada konumlandırmamız çok daha verimli olacaktır. Hem esneklikte, hem yedeklilikte, hem enerji tasarrufunda ve maliyetler bakımından pek çok avantajı vardır. İstediğimiz model cihazları bir araya getirerek istediğimiz yoğunlukta ve performansta, istediğimiz yedeklilikte bu cihazları kullanabiliriz. 

Bu açıklamayla beraber datacenter tarafında neler olduğuna bakalım.

Yeni anlayış network gelişimini takip edersek leaf-spine mimarisine sıklıkla rastlıyoruz ve network teknolojilerinin closed geleneksel çözümlerden, açık, esnek, özgür çözümlere doğru hızla yaygınlaştığını görüyoruz. Bir süre sonra tüm büyük topolojilerde böyle mimarilerle çalışacağız.

Ve bu mimaride büyüme sınırının şimdilik olmadığını söylebiliriz çünkü sınır büyüklüğe sahip bir sistem henüz yok. Büyüdükçe sistemin yönetiminin zorlaşmasının önüne de bazı büyük yönetim yazılım ürünleri ile geçilebiliyor ve işleri kolay hale getirebiliyor.

Cihazlara geçmeden önce open network olayına da bakarsak.

Artık switch i de bir server gibi ve o server üzerinde sanallaştırmayla kullanılabilecek, kendi içinde farklı görevler üstlenecek cihazlara bölebileceğiz. Tek bir switch üzerinde bir kısmını firewall, bir kısmını router bir kısmınıda top of rack switch olarak kullanabileceğimiz dönemler open network anlayışıyla birlikte geliyor.

DellEMC de geleceği böyle teknolojiler oluşturacağı için yatırımının büyük kısmını bu konuda yapıyor ve oldukça iddialılar.

Şuan da bir switch üzerine linux kurarak dilediğiniz güvenlik önlemiyle, dilediğiniz şekilde kullanabilirsiniz veya başka bir marka sisteme sahipsiniz, open network özelliğine sahip cihaz alarak istenen markanın işletim sistemini kurarak o cihaza sahip oluyorsunuz. Artık daha özgür, marka bağımsız sistemler geliyor ve maliyetler düşüyor. Closed bir sistemde tek bir yere bağlı kalınmaktaydı ve fiyatların oldukça yükselmesine sebeb oluyordu. Açık sistemler zaman geçtikçe yaygınlaşarak giriş cümlelerinde belittiğim gibi marka bağımlılığının önüne geçecek.

Bu özelliklere sahip DellEMC nin datacenter ürünlerinde 2 aile bulunmaktadır. S-Series ve Z-Series. Modellerden bir kaçı FC Switch ihtiyacını da karşılıyor. Open network özelliğinin yanında OS9 ve OS10 işletim sistemlerini de sunuyor.

S-Seriesürünleri 1G, 10G, 25G, 40G, 50G ve 100GbE sahip portlara göre ayrılmış durumdadır. Tek tek üzerinden geçsek uzun olacağı için sadece seri isimlerinden bahsedeceğim.

·         1 GbE için S3000-ON , S3100 serileri

·         10 GbE için S4000-ON , S4100-ON , S4200-ON serileri

·         25/40/50/100 GbE için S5000-ON , S5100-ON , S5200-ON , S6010-ON , S6100-ON

Z-Seriesürünleri 100 GbE

·         Z9100-ON

·         Z9264F-ON

Fiyat bakımından da performans bakımından oldukça avantajlı ürünlerdir. Özelliklerine bakınca ve rakipleriyle kıyaslayınca yüksek fiyatlı olması beklenirken özellikle bir kaç model de şaşırtıcı fiyatlar çıkabiliyor.

Bir kaç cihazın görüntüsü;

S4112T-ON (12x10GbE,3x100GbE) ve S4112F-ON (12x10Gbase-T,3x100GbE)

S4148F-ON (48x10GbE, 2x40GbE, 4x100GbE) (72x10GbE, 16x25G, 6x40G, 8x50G, 4x100GbE)

S5296F-ON (96x25GbE, 8x100GbE) (128x10G/25GbE, 8x40GbE, 16x50GbE, 8x100GbE)

Z9100-ON (32x100GbE) (64x50Gbe, 32x40Gbe, 128x25Gbe, 128x10GbE)

Çoğu cihazı sanal kabin üzerinde görebileceğimiz arkalı önlü görselleri ve özet teknik bilgilerine ulaşabileceğimiz güzel bir arayüz mevcut, bağlantı linki;

https://esgvr.dell.com/ 

Tüm özelliklere bakabileceğimiz DellEMC Networking sayfa bağlantısı;

https://www.dell.com/en-us/work/shop/networking/sc/networking-products/switches

Office 365 üzerinde dynamic distribution group’larını organizasyona yeni katılan veya bazı kriterleri karşılayan mailbox kullanıcılarının belirlediğimiz gruba otomatik olarak katılabilmesi adına sık sık kullanmaktayız. Bazı özel durumlarda Dynamic Distribution group’larından bir veya birden fazla kullanıcının mailboxlarının dışlanması (exclude) edilmesi istenebilir. Office 365 üzerinde organizasyonlar user’larını ve group’larını ister cloud ister local Active Directory’den ADConnect tool’u ile sync ederek kullanabilirler. Mailboxların dışlanması (exclude) ihtiyacı her 2 metot da mümkün olmakla beraber izlenecek yol farklıdır.

1-Office 365 üzerinde kullanıcılarınızı Active Directory’den ADConnect aracı ile sync ediyorsanız aşağıdaki yöntem ile Dynamic Distribution Group üzerinden kullanıcı veya kullanıcılarınızın mailboxlarını exclude edebilirsiniz.

Not : Office 365 Portal arayüzünden bu işlem yapılamamaktadır.

Office 365 Exchange Online PowerShell ile bağlantı kurulur.

Import-Module MSOnline

$O365Cred = Get-Credential

$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection

Import-PSSession $O365Session

Connect-MsolService –Credential $O365Cred

Not : Powershell komutlarını uygulamadan önce komutlar’da kalın siyah olarak işaretlediğim değerlere kendi ortamınızdaki değişiklik yapmak istediğiniz dynamic distribution group’un bilgisini giriniz.

İşlemin başarılı olup olmadığını anlamak adına öncelikle mevcuttaki Dynamic Distribution group üzerindeki member sayısına bakacağız.

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

8

Dynamic Distribution group kuralına öncelikle göz atalım ve içerisinde yapacağımız değişiklik için “RecipientFilter” değeri üzerinde değişiklik yapacağız.

Get-DynamicDistributionGroup -Identity “All Company | HM” | fl Name,RecipientFilter

Get-DynamicDistributionGroup -Identity “All Company | HM” | fl Name,RecipientFilter

Name            : All Company | HM

RecipientFilter : ((RecipientType -eq 'UserMailbox') -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and

                  (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq

                  'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and

                  (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'GuestMailUser')))

User objelerini Active Directory üzerinden sync ettiğimiz için Exclude yapacağımız kullanıcı veya kullanıcılara on-premise Active Directory üzerinden bir kriter belirlememiz gerekmektedir. Exclude etmek istediğim kullanıcının Active Directory üzerinde attribute’lerinden istediğiniz bir “custom attribute” kullanarak bir değer giriniz. Örneğin ben kullanmadığım CustomAttribute15 bölümüne “Exclude” değerini girdim ve bir sonraki sync cycle’da ilgili attribute kullanıcının Azure AD üzerindeki attribute kısmına sync oldu.

İpucu ! : Eğer Active Directory üzerinde CustomAttribute değerlerini göremiyorsanız AD ortamında Exchange Schema genişletme işlemi yapmanız veya hali hazırda sync olan attributelerden birini kullanmanız gerekmektedir.

Powerhell’de ki siyah kısımda belirttiğim CustomAttribute15 değerini siz kendinize göre özelleştirebilirsiniz. CustomAttribute15 attribute bölümünde Exclude yazan kullanıcının belirlediğimiz Dynamic Distribution group üzerinden exclude olması adına alttaki alanları düzenledikten sonra powershell’i çalıştırıyoruz.

Set-DynamicDistributionGroup -Identity “All Company | HM” -RecipientFilter {((RecipientType -eq "UserMailbox") -and (-not (CustomAttribute15 -like "Exclude")) -and (-not(Name -like "SystemMailbox{*")) -and (-not(Name -like "CAS_{*")) -and (-not(RecipientTypeDetailsValue -eq "MailboxPlan")) -and (-not(RecipientTypeDetailsValue -eq "DiscoveryMailbox")) -and (-not(RecipientTypeDetailsValue -eq "PublicFolderMailbox")) -and (-not(RecipientTypeDetailsValue -eq "ArbitrationMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuxAuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "SupervisoryReviewPolicyMailbox")) -and (-not(RecipientTypeDetailsValue -eq "GuestMailUser")))}

Set-DynamicDistributionGroup -Identity “All Company | HM” -RecipientFilter {((RecipientType -eq "UserMailbox") -and (-not (CustomAttribute15 -like "Exclude")) -and (-not(Name -like "SystemMailbox{*")) -and (-not(Name -like "CAS_{*")) -and (-not(RecipientTypeDetailsValue -eq "MailboxPlan")) -and (-not(RecipientTypeDetailsValue -eq "DiscoveryMailbox")) -and (-not(RecipientTypeDetailsValue -eq "PublicFolderMailbox")) -and (-not(RecipientTypeDetailsValue -eq "ArbitrationMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuxAuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "SupervisoryReviewPolicyMailbox")) -and (-not(RecipientTypeDetailsValue -eq "GuestMailUser")))}

Grup üyelerini tekrar listelemek istediğimde gördüğünüz gibi kullanımın ilgili grup’ta member sayısının düştüğünü görmekteyim.

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

7

Dynamic Distibution grouplarının üyelerini kontrol ettiğimde Exclude ettiğim kullanıcıyı üye olarak görememekteyim.

$DDGMembers = Get-DynamicDistributionGroup "All Company | HM"

Get-Recipient -RecipientPreviewFilter $DDGMembers.RecipientFilter

$DDGMembers = Get-DynamicDistributionGroup "All Company | HM"

Get-Recipient -RecipientPreviewFilter $DDGMembers.RecipientFilter

Name           RecipientType

----           -------------

HakanMARANGOZ  UserMailbox 

Hakan MARANGOZ UserMailbox 

Burak MARANGOZ UserMailbox 

Hasan DANIS    UserMailbox 

Hasan GURAL    UserMailbox 

Umit SEYHAN    UserMailbox 

Emre ERBULMUS  UserMailbox  

2-Office 365 üzerinde kullanıcılarınızı Azure Active Directory’de barındırıyorsanız aşağıdaki yöntem ile Dynamic Distribution Group üzerinden kullanıcı veya kullanıcılarınızın mailboxlarını exclude edebilirsiniz.

Not : Office 365 Portal arayüzünden bu işlem yapılamamaktadır.

Office 365 Exchange Online PowerShell ile bağlantı kurulur.

Import-Module MSOnline

$O365Cred = Get-Credential

$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection

Import-PSSession $O365Session

Connect-MsolService –Credential $O365Cred

İşlemin başarılı olup olmadığını anlamak adına öncelikle mevcuttaki Dynamic Distribution group üzerindeki member sayısına bakacağız.

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

8

Dynamic Distribution group kuralına öncelikle göz atalım ve içerisinde yapacağımız değişiklik için “RecipientFilter” değeri üzerinde değişiklik yapacağız.

Get-DynamicDistributionGroup -Identity “All Company | HM” | fl Name,RecipientFilter

Get-DynamicDistributionGroup -Identity “All Company | HM” | fl Name,RecipientFilter

Name            : All Company | HM

RecipientFilter : ((RecipientType -eq 'UserMailbox') -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and

                  (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq

                  'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and

                  (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'GuestMailUser')))

User objelerini Azure Active Directory üzerinde barındırdığım için Exclude yapacağımız kullanıcı veya kullanıcıların Azure Active Directory üzerindeki attribute’lerinden istediğiniz bir “custom attribute” kullanarak bir değer giriniz. Örneğin ben başka bir iş için kullanmadığım CustomAttribute15 bölümüne “Exclude” değerini girdim.

Powerhell’de ki siyah kısımda belirttiğim CustomAttribute15 değerini siz kendinize göre özelleştirebilirsiniz. CustomAttribute15 attribute bölümünde Exclude yazan kullanıcı veya kullanıcıların belirlediğimiz Dynamic Distribution group üzerinden exclude olması adına alttaki alanları düzenledikten sonra powershelli çalıştırıyoruz.

Set-DynamicDistributionGroup -Identity “All Company | HM” -RecipientFilter {((RecipientType -eq "UserMailbox") -and (-not (CustomAttribute15 -like "Exclude")) -and (-not(Name -like "SystemMailbox{*")) -and (-not(Name -like "CAS_{*")) -and (-not(RecipientTypeDetailsValue -eq "MailboxPlan")) -and (-not(RecipientTypeDetailsValue -eq "DiscoveryMailbox")) -and (-not(RecipientTypeDetailsValue -eq "PublicFolderMailbox")) -and (-not(RecipientTypeDetailsValue -eq "ArbitrationMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuxAuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "SupervisoryReviewPolicyMailbox")) -and (-not(RecipientTypeDetailsValue -eq "GuestMailUser")))}

Set-DynamicDistributionGroup -Identity “All Company | HM” -RecipientFilter {((RecipientType -eq "UserMailbox") -and (-not (CustomAttribute15 -like "Exclude")) -and (-not(Name -like "SystemMailbox{*")) -and (-not(Name -like "CAS_{*")) -and (-not(RecipientTypeDetailsValue -eq "MailboxPlan")) -and (-not(RecipientTypeDetailsValue -eq "DiscoveryMailbox")) -and (-not(RecipientTypeDetailsValue -eq "PublicFolderMailbox")) -and (-not(RecipientTypeDetailsValue -eq "ArbitrationMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "AuxAuditLogMailbox")) -and (-not(RecipientTypeDetailsValue -eq "SupervisoryReviewPolicyMailbox")) -and (-not(RecipientTypeDetailsValue -eq "GuestMailUser")))}

Grup üyelerini tekrar listelemek istediğimde gördüğünüz gibi kullanımın ilgili grup’ta member sayısının düştüğünü görmekteyim.

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

$members = Get-DynamicDistributionGroup -Identity “All Company | HM”

(Get-Recipient -RecipientPreviewFilter $members.RecipientFilter).count

7

Dynamic Distibution grouplarının üyelerini kontrol ettiğimde Exclude ettiğim kullanıcıyı üye olarak görememekteyim.

$DDGMembers = Get-DynamicDistributionGroup "All Company | HM"

Get-Recipient -RecipientPreviewFilter $DDGMembers.RecipientFilter

$DDGMembers = Get-DynamicDistributionGroup "All Company | HM"

Get-Recipient -RecipientPreviewFilter $DDGMembers.RecipientFilter

Name            RecipientType

----            -------------

HakanMARANGOZ   UserMailbox 

Hakan MARANGOZ  UserMailbox 

Caner CETINKAYA UserMailbox 

Burak MARANGOZ  UserMailbox 

Hasan DANIS     UserMailbox 

Hasan GURAL     UserMailbox 

Umit SEYHAN     UserMailbox 

Emre ERBULMUS   UserMailbox 

Umarım faydalı olmuştur , keyifli okumalar.

Bu makalede, fidye yazılımlarına karşı korunmak için sonicwall cihazınız üzerinde alınabilecek önlemler anlatılmaktadır.

CryptoWall ve CryptoLocker türü fidye yazılımları, genellikle e-posta yoluyla bulaşan ransomwares(fidyeci yazılım)'tir. Microsoft işletim sistemlerini hedef alan bu yazılımlar virüslü e-pota eklerinden bilgisayara bulaşır. Bir bilgisayara bu virüs bulaştığında, kötü amaçlı yazılım bilgisayarda ve bilgisayarın bağlı olduğu ağda depolanan belirli dosyaları şifreler daha sonra, kötü amaçlı yazılım dosyaların şifresini çözmek için ödeme talep eden bir mesaj gösterir.

Ödeme aracı olarak Bitcoin kullanılır. Mağdur kişiye belli bir süre tanınır ve bu süre içinde ödeme yapılmazsa dosyaların bir daha geri getirilemeyeceği tehdidinde bulunulur.

CryptoWall 2.0, CryptoWall 3.0, CryptoWall 4.0, CryptoLocker, Brazilian Ransomware, CryptoTorLocker gibi çeşitli isimlerde birçok türevleri vardır.

Bunların yanı sıra windows işletim sisteminin bir açığını kullanarak dosyalarınızı şifreleyen ve fidye talep eden popüler ransomware türü yazılımlardan biride WannaCry virüsüdür. İşletim sistemindekiEternalBlueaçığını kullanan ve bulaştığı anda dosyalarınızı şifreleyen bu zararlı yazılım başta 300 dolar talep eder, ödenmez ise bu fiyat 600 dolara çıkarılır ve bir hafta sonra hala ödeme yapılmaz ise şifrelenmiş tüm dosyalar kalıcı olarak silinir.

Bu yazılımlar şifrelemede RSA-4096 / AES-256 benzeri çok güçlü şifreleme algoritmaları kullanmaktadır. Günümüz şartlarında bu şifrelemelerin kırılması mümkün değildir. Bu yüzden çözüm geliştirdiğini söyleyen internetteki birçok dolandırıcıya karşı dikkatli olunmalıdır.

Fidye yazılımlarına karşı en başta kullanıcılar şu konularda bilgilendirilmelidir;

-Önemli dosyalar farklı ortamlara düzenli olarak yedeklenmeli,

-İşletim sisteminin güvenlik güncellemeleri yapılmalı,

-Bilinmeyen veya emin olunamayan kaynaklardan gelen e-posta ekleri açılmamalı,

-Yüksek tutarlı e-fatura şeklinde gelen e-postalardaki linklere tıklanmamalı,

-".exe" ile biten e-posta ekleri açılmamalı.

Sonicwall UTM cihazınız İle Alınacak Önlemler

SonicWall Gateway Anti-Virus ve SonicWall IPS aşağıdaki imzalar aracılığıyla bu tehditlere karşı koruma sağlar:

Sonicwall "Application Control" ağınızdaki I2P tünellerini aşağıdaki imzalarla engelleyebilir:

• 5 Encrypted Key Exchange -- Random Encryption (Skype, UltraSurf, Emule)
• 7 Encrypted Key Exchange -- UDP Random Encryption(UltraSurf)
• 10817 I2P -- HTTP Proxy Access 1 [Reqs SID 5 & 7]
• 10817 I2P -- HTTP Proxy Access 2 [Reqs SID 5 & 7]
• 10817 I2P -- HTTP Proxy Access 3 [Reqs SID 5 & 7]

Sonicwall Üzerinde Uygulanacak Adımlar

1.Gateway Anti-Virus (GAV)

• Gateway Anti-Virus servisinin en son imzalarla güncellendiğinden emin olunmalıdır.
• GAV etkinleştirilmelidir.
• Cloud GAV etkinleştirilmelidir.
• HTTP, FTP, IMAP, SMTP, POP3, CIFS / Netbios ve TCP Stream gelen ve giden trafik denetimi etkinleştirilmelidir.

Her bir protokolün altındaki Settings butonunu tıklayıp, aşağıdaki onay kutuları etkinleştirilir.

• Restrict Transfer of password-protected ZIP files
• Restrict Transfer of MS-Office type files containing macros (VBA 5 and above)
• Restrict Transfer of packed executable files (UPX, FSG, etc.)

Network / Zonessayfası altında tüm LAN ,WAN bölgelerdeGAVetkinleştirilir.

“Block files with multiple levels of zip/gzip compression” seçeneği işaretlenir.

Security services / Gateway Anti-Virus sayfasında global settings bölümünde"Configure Gateway AV Settings"butonu tıklanır.

Açılan sayfada“Block files with multiple levels of zip/gzip compression”seçeneği işaretlenir ve OK butonu tıklanarak kaydedilir.

2.Intrusion Prevention Service (IPS)

• IPS servisinin en son imzalarla güncellendiğinden emin olunmalıdır. Update butonu tıklanarak manuel olarak güncelleme kontrolü sağlanabilir.
• MediumveHigh Priority Attacks  seçenekleri etkinleştirilir. Bu orta ve yüksek  seviyede saldırıların önlenmesini sağlayacaktır. İsteğe bağlı olarak"Low Priority Attacks"seçeneği de etkinleştirilebilir. Bu seçeneklerin tümü, kötü amaçlı yazılım için imzaları otomatik olarak içerecektir.
• Network / Zones altında LAN ve WAN zone için IPS etkinleştirilir. İsteğe bağlı olarak tüm zone'lar için etkinleştirilebilir.

3.Geo-IP Filter

Geo-IP Filter, çeşitli ülkelerden gelen trafiği kontrol etmenizi sağlar.

• Geo-IP Filter aktif edilir.
• Bu "Tüm Bağlantılar" veya "Firewall Kuralları" için uygulanabilir.
• Firewall / AccessRulesayfasında, ilgili kurallar üzerinde servisin etkinleştirilmesi gerekir. WAN to WAN, WAN to LAN, ve LAN to WAN kuralları için aktif edilmelidir.
• Ülke seçeneklerinden bilinmeyen ülkelerin seçili olmasına dikkat ediniz. “Anonymous Proxy / Private IP”
• “Block all UNKNOWN subnets” seçeneği işaretlenir.

4.Botnet Filter

Botnet filtresinin etkinleştirilmesi, kötü amaçlı yazılımın bilinen komut ve kontrol sunucularına erişimi engelleyecektir.

• Security Services | Botnet Filter sayfasında,Block connections to/from Botnet Command and Control Servers onay kutusu etkinleştirilir.
• Enable Logging onay kutusunu işaretlenir.
• Firewall / Access Rule sayfasında, ilgili kurallar üzerinde servisin etkinleştirilmesi gerekir. WAN to WAN, WAN to LAN, ve LAN to WAN kuralları için aktif edilmelidir.

5.Content Filter Service (CFS)

Content Filter Service kategori bazlı yasaklamalar ile“kötü amaçlı yazılım”ve“Hacking / Proxy"siteleri engellemek için yapılandırılabilir. CFS yapılandırmak için "Sonicwall Content Filter Service(CFS) yapılandırma" isimli makalemi inceleyiniz.

Filtrleme servisinde ilk 12 kategori varsayılan olarak block durumdadır. Bunların dışında

"Malware","Hacking / Proxy Avoidance", ve"Not Rated"kategorilerinin block olduğundan emin olunmalıdır. Burada Not Rated kategorisine dikkat edilmelidir zira bu kategorinin bloklanması zararlı olmasa bile kategorilendirilmemiş tüm WEB sitelerine erişiminizi de engelleyecektir. Bu durumda erişilmek istenen WEB siteler için bir URL list oluşturularak allowed URL list böümünde gösterilerek izin verilmelidir. Ayrıca bu kategorinin kapalı olması cihaz üzerinde işlem yoğunluğuna da sebep olacaktır.

Not Rated siteler için taleplerinizi  mysonicwall.comüzerinden support ekibine iletebilirsiniz.

6.App Control Advanced

Zararlı yazılımlardan korunmak için application control servisinin aktif edilmesi ve yapılandırılması gereklidir. Özellikle fidye yazılımlarına karşı "Proxy Access" , "SSH" ve "DNS" kısıtlaması önerilir.

Fidye yazılımları dosyaları şifrelemek için kullanılan şifreleme anahtarlarını elde etmek için TOR kullandığı bilinmektedir. Bu nedenle, TOR'u engellemek için "App Control Advanced" kullanılmalıdır. Cryptowall virüsü böylece bulaştığı bilgisayara zararı azaltılmış ve dosyaları şifrelemek için gerekli anahtarları elde etmesi mümkün olmayacaktır.

• Firewall | App Control AdvancedsayfasıdaPROXY-ACCESSkategorisi seçilir.
• Application olarakTORseçilir.
• TOR seçiliyken configüre ikonu tıklanır.
• BlockveLogseçenekleriEnableyapılır.
• Kaydetmek içinOKbutonuna tıklanır.

Torbunu engellemek için,Encrypted key exchangeuygulamasını kullanacaktır bu yüzden yukarıda tor uygulaması için yaptığımız adımlarıEncrypted key exchangeuygulaması içinde yapılır.

Protocols kategorisinde DNS Protocol application seçilerek block edilmesi ve sadece güvenilen DNS adresleri bir address object group altında toplanarak hariç tutulması önerilir.

SSH bağlantıları güvenilir kaynak ve kullanıcılar ile sınırlandırılmalıdır. Application control advanced sayfasında"protocols"kategorisinde SSH protocol block edilerek sadece güvenilen bağlantılara izin verilmesi önerilir.

TümProxy-Accesskategorisindeki imzaları kısıtlamak kötü amaçlı yazılımlara karşı korunmak için iyi bir yoldur. Ancak bu kategoriyi block yapmanın kötü sonucu, yasal ve kullanılması gereken uygulamaların da stabil çalışmaması veya kesilmelere sebep olmasıdır. Bu yüzden kontrollü olarak, gerekli durumlarda belirli uygulama ve hedeflerin hariç tutularak erişim sağlanması daha güvenli olacaktır.

7.DPI-SSL

Sonicwall güvenlik duvarının DPI-SSL özelliği, birden fazla protokol ve uygulamadaki şifreli iletişimler içinde inceleme yeteneği sunar. DPI-SSL, güvenlik duvarının webmail, sosyal medya ve HTTPS bağlantılarını kullanan diğer WEB bağlantıları gibi şifreli iletişimleri denetlemek için bir vekil olarak hareket etmesini sağlar.

DPI-SSL 'i etkinleştirme, zorunlu bir önlem olmasa da, ek güvenlik sağlayacaktır çünkü;

1)Hemen hemen tüm WEB ve e-posta trafiği SSL üzerindedir. Örneğin, SSL üzerinden bir spam e-postası alınırsa, sonicwall, varsa, kötü amaçlı yazılım içeriğini algılayamaz.

2)Tor ağ geçidine ilk bağlantı SSL üzerindedir. DPI-SSL'yi etkinleştirmek, sonicwall cihazınızın bu trafiğin şifresini çözmesine ve kötü amaçlı yazılım için taramasına izin verecektir.

Sonicwall güvenlik duvarında DPI-SSL’i etkinleştirin

Hizmetlerin aşağıdakiler de dahil olmak üzere tüm alt işlevler için etkinleştirildiğinden emin olun:

• Intrusion Prevention
• Gateway Anti-Virus
• Gateway Anti-Spyware
• Application Firewall
• Content Filter

DPI-SSL / Client SSL sayfasında SSL Client Inspection seçeneğini etkinleştirilir. Viriüs koruması için özellikle Gateway Anti-virus ve Intrusion Prevention onay kutuları etkinleştirilir. İsteğe bağlı olarak diğer seçenekler de aktif edilebilir. Burada DPI SSL servisine kısaca değinilmiştir. DPI SSL tam konfigürasyonu için ilgili dökümanını inceleyebilirsiniz.

Dikkat: SonicOS 5.6 ve üzeri yazılımı ile NSA 220 üzeri cihazlarda desteklenir.

8. Capture ATP

Dinamik ve sürekli yeni bir kötü amaçlı yazılım oluşturulması göz önüne alındığında, Sonicwall Capture çözümünün kullanılması tavsiye edilir. Bu servisin AGSS (Advanced Gateway Security Suite) lisansı gerektirdiği unutmamalıdır.

Servis etkinleştirilir ve Gateway Anti-Virus'üntüm hizmetler üzerinde etkin olduğundan emin olunur.

Tüm dosya türlerinin inceleme için seçildiğinden emin olunur.

En iyi uygulama için, Capture işlevinin karar verilene kadar dosya indirmeyi engelle("Block file download until a verdict is returned") seçeneğini etkinleştirmesi önerilir. Bu, kötü amaçlı yazılımların test edilmeden sisteme geçmesini önler.
Capture ATP servisi tarafından bir karara varıncaya kadar dosya indirmeyi geciktirir. Bu, yasal dosyaların yanı sıra potansiyel olarak zararlı dosyaları da etkiler ve kullanıcıların indirmeyi yeniden denemelerini gerektirebilir.
 
NOT: Fidye virüsü her zaman İnternet üzerinden gerçekleşmeyebilir.
Paylaşılan dosyalar ve / veya sürücüler veya USB flash diskler ve harici diskler gibi paylaşılan çıkarılabilir ortamların üzerinde oluşabilir. Bu nedenle, ağdaki bilgisayarlara virüs bulaşmasını önlemek için LAN üzerinde de güvenlik önlemleri alınmalıdır.
 
Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.

Her geçen gün artan office 365 kullanıcı sayısı ile beraber bu kullanıcıların yaşadıkları sorunlar, bu sorunların çözüm süreleri, kullanım deneyimi gibi kavramları çok daha büyük önem taşımaktadır. Hali hazırda Microsoft kullanıcıların office 365 üzerindeki posta kutularına bağlanırken yaşadıkları sorunları çözmek için aşağıdaki araçları kullanabilirsiniz;

The Support and Recovery Assistant (SARA)

Outlook ETL dosyaları

Ve 3. Olarak Fiddler eklentisi.

Daha önce yukarıdaki konulara ait paylaşımlar yaptığım için bu makalemde 3. Sorun çözme aracı olan ki aslında sektördeki değerli meslektaşlarım bilir özellikle web sorunlarını çözmek için kullandığımız fiddler eklentisini Exchange online bağlantılarındaki sorunları çözmek için nasıl kullanacağımızı anlatacağım.

SARA için aşağıdaki yazılımı inceleyebilirsiniz;

http://www.hakanuzuner.com/index.php/microsoft-office-365-support-and-recovery-assistant.html

Peki öncelikle Fiddler’ ı hiç tanımayanlar için aşağıdaki yazı yararlı olacaktır;

https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/InstallFiddler

Hızlı bir şekilde kurup aslında web trafiğini takip edebilirsiniz;

https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureBrowsers

Ürünü indirmek için aşağıdaki linki kullanabilirsiniz;

https://www.telerik.com/download/fiddler

Kurulum bittikten sonra ise aşağıdaki eklentiyi kuruyoruz;

https://github.com/jprknight/EXOFiddlerExtension/releases

Not: Çok yaygın bir kurulum dosyası olmadığı için henüz AV yazılımınız uyarı verebilir.

Kurulumlar tamamlandıktan sonra Fiddler uygulamasını açınca karşınıza aşağıdaki gibi Exchange Online eklentisi çıkacaktır;

Evet hali hazırda web trafiği için sorun çözmek amacı ile kullanmaya alışkın olduğumuz program için Exchange Online eklentisi geliştirildi. Bu sayede sorunları çok daha kesin ve hızlı bir şekilde çözebileceğiz.

Peki bu eklenti tam olarak bizlere neler sağlıyor?

Bilinen herhangi bir hata durumuna göre oturum listesinde oturumları renklendirir.

Özellikle yararlı bilgileri vurgulamak için mevcut trafiğe ek sütünler ekleyerek süreci anlamamızı kolaylaştırır. Nedir bu sutunlar;

Elapsed time

Response Server

Exchange type

Authentication

Host Ip

Exchange Online ve Office 365 Auth için ayrı araştırma sekmesi sunar.

Eklenti güncellemelerini kolayca kontrol edebilirsiniz.

Eklenti ayarlarını kolayca yapılandırabilirsiniz.

Peki ne tür sorunlar için çözüm üretebiliriz;

Authentication

Outlook istemcisinin Basic veya Modern Authentication desteğinin olup olmadığını görebilirsiniz

Exchange Online için Basic veya Modern Authentication’ ın açık olup olmadığını görebilirsiniz

Outlook kimlik doğrulama oturumunda kullanılan ve SAML cevabının bir parçası olan UserPrincipalName, ImmutableID ve signing certificate’ yı görebilirsiniz.

Autodiscover

Mevcut Exchange sunucusunun Exchange Online yönlendirmesini görebilirsiniz.

IIS olmayan herhangi bir sunucudan gelen Autodiscover cevabını görebilirsiniz.

Network Connectivity

En çok kullanılan özelliklerden birisi bu bölüm aslında, Outlook trafiğini kesen proxy server veya farklı bir aygıt var ise bunu rahatlıkla görebilirsiniz.

Outlook’ un Exchange Online posta kutusuna bağlanamadığı durumlarda kullanabilirsiniz.

Outlook’ ın Mevcut Exchange sunucusun bağlanamama durumlarında da kullanabilirsiniz.

Performance information

Oturum sürelerini kontrol edebilirsiniz.

'Server Think Time' olarak geçen Exchange Online’ ın isteği yerine getirme süresini ölçebilirsiniz.

Yanıtın Fiddler' a geri gönderilmesi ve Fiddler' in yanıtı istemci uygulamasına geri göndermesi için geçen sürenin uzunluğunu kontrol edebilirsiniz.

Other

OWA, bir Exchange Online posta kutusuna bağlanamıyor durumundaki trafiği izleyebilirsiniz.

Outlook veya OWA, posta kutusuyla belirli bir işlevi gerçekleştiremez durumundaki trafiği izleyebilirsiniz.

Exchange Free/Busy ve diğer EWS isteklerindeki sorunları görebilirsiniz.

Peki gelelim nasıl kullanıyoruz kısmına?

Öncelikle programı açalım ve ayarlar menüsüne girelim;

Daha sonra açılan menüden HTTPS sekmesine gelelim;

Buradaki “Decrypt HTTPS traffic” kutucuğunu işaretleyelim

Burada bir sertifika oluşturmak isteyecektir sistem. Bunu kabul edip ardından outlook programını açabilirsiniz.

Bu sertifikaların gerçekten eklendiğini görebilirsiniz

Peki program açık şimdi outlook programını açın ve biraz bekleyin, aşağıdaki gibi paketler akmaya başlayacaktır;

Bu kısma çok takılmadan yapmak istediğiniz testi yapın, örneğin outlook’ u açıp kapatın.

Daha sonra bu oturumu file menüsünden kayıt edin ve fiddler programını kapatıp bu kayıt üzerine çift tıklayarak kaydın açılmasını sağlayın.

Bu sefer karşınıza bizim amacımıza daha uygun şekilde renklendirilmiş ve yeni kolonlar eklenmiş bir sonuç gelecektir.

Örnek son derece uzun süren bir kayıt var onun üzerine tıklıyoruz

Hemen sağ bölümde ki bunu siz ayarlardan değiştirmiş olabilirsiniz inspectors sekmesine tıklayın.

Bu bölüme tıkladığınız zaman alt bölümde Exchange Online için ek bir araştırma sekmesi olduğunu göreceksiniz ve onun üzerine tıklayabilirsiniz.

İşte eklenti burada kendisini çok daha net bir şekilde gösteriyor. http 401: Unauthorized / Authentication Challenge.

Buradaki tabiki tüm hataları ezbere bilmeniz mümkün değil ancak en kötü bir arama motoru yardımı ile ne tür bir sorun ile uğraştığınızı bulabilirsiniz.

Bundan sonrası artık sizin uzmanlığınıza kalıyor. En çok Autodiscover tarafındaki sorunların çözümü için kullansamda özellikle network ve güvenlik ekiplerinin ayrı olduğu ortamlarda outlook bağlantılarının başarılı olmaması durumunda çok işe yarıyor. Çünkü genelde internal olarak tanımlı Exchange Server için protokol noktasında belirli portların açılması sonucu sorunsuz çalışan iç mesajlaşma durumun buluta yönelmesi ile network ve güvenlik ekiplerini zorluyor. Onlarda bazen gerçekten trafiğin onlara mı takıldığını görmek zorundalar.

Böyle bir durumda aşağıdaki gibi ekran görüntüleri görebilirsiniz;

Evet bu son bilgi ile makalemin sonuna geldim, umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.

Kaynak

https://blogs.technet.microsoft.com/exchange/2018/12/11/introducing-the-exchange-online-fiddler-extension/

Günümüzün vazgeçilmez İletişim araçlarının başında e-posta gelmektedir. Gerek bireysel gerekse Kurumsal İletişim için çok önemli bir yeri olan e-posta için ne yazık ki en büyük problem sürekli büyüyen posta kutularının yönetilemiyor olmasıdır.

Özellikle bizim gibi danışman veya sistem yöneticileri için 10GB, 20GB, 30GB veya üstü posta kutusu olan kullanıcılar favorilerimizdir. Kendilerine sorduklarında tabiki tüm verinin önemli olduğunu ve silinemeyeceğini söylerler. Hali hazırda zaten kurumsal müşterilerde Litigation hold adı altında tabi olduğu kanun, tüzük, regülasyon veya sahip olduğu sertifikasyon ya da en kötü şirketin kurumsal politikası gereği tüm maillerin bir kopyasını saklar. Ancak bir yandan da kullanıcıların sık kullandığı posta kutularının küçültülmesi istenmektedir.

Mail arşivleme başta olmak üzere pek çok alternatif olmasına karşın büyüyen verilere karşı arama, saklama, taşıma sorunları hala devam etmektedir.

Bulut bilişim ile aslında bu konuda büyük veri merkezlerinin kurumsal müşterilere de artık hizmet etmesi nedeni ile 100GB gibi bir posta kutusunun bile sorunsuz kullanılabildiğini görüyoruz.

Ancak veri boyutu ya da saklama boyutu ne olur ise olsun, nerede saklanır ise saklansın en büyük sorun item yani posta kutusu içerisindeki öğe, mail sayısının artmasıdır. Bu nedenle Microsoft güzel bir özellik geliştirmiş. “Conversation Clean Up” olarak isimlendirilen bu özellik temel olarak bir birinin aynısı olan maillerin silinmesi ile posta kutusu içerisinde daha az öğe tutmaya yarıyor.

Peki tam olarak nasıl çalışıyor?

Öncelikle “conversation” nedir ona bir bakalım?

Aynı mail başlığı içeren mailleri eğer outlook görünümlerinden ayarlarsanız tek bir konuşma şeklinde gruplanmış olarak saklar;

Bu kutucuk işaretli ise eğer bu durumda aynı başlığı içeren mailleri aşağıdaki gibi gruplanmış olarak görebilirsiniz;

Yukarıda basit bir örneği yer alıyor;

Burada ben ve Webcast verecek değerli bir meslektaşım konuyu geliştiriyoruz, ancak gördüğünüz gibi 7 tane mail var burada ve bu yeni özelliğin amacı en son güncel maili tutup geriye kalan maillerin silinmesi olarak özetlenebilir.

Aslında bu konuda son derece anlaşılır bir video var bunu izlemenizi tavsiye ederim;

https://www.microsoft.com/en-us/videoplayer/embed/RWfztn?pid=ocpVideo0-innerdiv-oneplayer&postJsllMsg=true&maskLevel=20&market=en-us

Peki nasıl çalışıyor?

Home tabında, delete grubunda Clean Up bölümüne tıklıyoruz;

Karşımıza 3 tane seçenek çıkıyor

Clean Up Conversation

Seçili olan mailler için temizleme yapar.

Clean Up Folder

Seçili klasördeki tüm redundant maillerin silinmesini sağlar.

Clean Up Folder & Subfolders

Seçili klasör ve alt klasörlerdeki redundant tüm maillerin silinmesini sağlar.

Eğer bu özellik için yapılandırma ayarlarını kontrol etmek istiyorsanız aşağıdaki yolu izleyebilirsiniz;

File-Options-Mail altında Conversation Clean Up bölümüne geliyoruz;

Bu Bölüm temizleme işlemi için bir takım harici durumları tanımlamanıza yardımcı olur.

Örneğin silinen mailler normalde Deleted items olarak bildiğimiz varsayılan silinmiş maillerin tutulduğu klasöre koyulurken siz bunu değiştirebilirsiniz.

Veya okumadığınız maillerin silinmemesini isteyebilirsiniz. Ya da varsayılan olarak işaretli olan ve bence de çok önemli olan işaretlenmiş maillerin yine benzer şekilde taşınmasını engelleyebilirsiniz. Buradaki seçenekler bence son derece yeterli.

Evet amacım özellikle büyük posta kutusu olan kullanıcılarınız için arşivleme seçeneği dışında kullanabileceğiniz alternatif bir yöntemi paylaşmaktadır. Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.

Exchange Online, Exchange ve Office deployment projeleri yaparken geçiş sonrası kullanıcı tarafından gelen talepler arasında ilk sırayı eski mailleri göremiyorum case’ i oluşturuyor. Exchange mailboxlarını Outlook üzerinde yapılandırırken hepinizin bildiği Account ayarları altında bulunan cache mode seçeneği bulunmaktadır. Bu cache mode seçeneğinin temel amacı posta kutunuzun bir kopyasını bilgisayarınıza kaydetmektir. Böylece bu kopya data ile internet olmadığında mailboxınıza erişebilir ve verilerinizi hızlı erişim sağlarsınız. Özellikle Internet hatlarının yavaş olduğu lokasyonlar’da cache mode hayat kurtarmaktadır.  Çünkü online mode kullanımında mailler tamamen sunucu üzerinden her seferinde canlı olarak gidip getirilmekte, dolayısıyla bu trafik internet alt yapısının ciddi anlamda iyi olmasını gerektirmektedir.

İpucu! Bu özellik POP ve IMAP hesaplarında geçerli değildir.

Outlook 2010 Cache Mode

Outlook 2013 & 2016 Cache Mode

Office 2013’in çıkması ile beraber ile bu cache mode seçeneğinde bir yenilik daha eklenerek son hangi tarihli datanın cache’leneceğine karar verebilir hale geldik. Herhangi bir değişiklik yapmamanız durumunda default olarak artık sadece 1 yıllık datayı indirecek şekilde account yapılandırmasını tamamlamaktadır. Outlook 2010 ve öncesinde bu ayarı değiştiremediğimiz için Exchange mailboxına sahip olan kullanıcıların makinelerinin yeniden kurulması durumunda, yeni profil ile beraber bu OST dosyalarını network’ ten veya ofis dışındaysa İnternet’ten tekrar download edilmesi Bandwidth anlamında bizi düşündüren konular arasındaydı.

Not: Client işletim sistemlerinde yeniden kurulum öncesi OST datası alınıp kurulum sonrası tekrar gösterilebilir fakat bu önerilen bir yöntem değildir belirli bir zaman sonra Outlook profillerinin corrupt olduğunu birçok defa şahit oldum.

Peki cache mode önemi nerede çıkıyor, hangi durumlarda ihtiyaçlarımızı çözüyor onlara bir göz atalım.

Benimde müşterilerim arasında halen aktif olarak Outlook 2010 kullanan yapılar bulunmaktadır. Exchange Online tarafına geçiş sonrası mailbox sunucusunun On-Premise yapısından kaldırılması sonucu her yeni makine kurulumu sonrası bu mailbox ların tekrar tekrar internetten download edilmesi network alt yapısını ciddi yormakta ve servisler’ de kesinti meydana getirmektedir. (Öncelik çözüm olarak kesinlikle Outlooklarını yeni versiyona upgrade etmelerini ve cache mode özelliğini kullanmalarını istiyoruz.)

Outlook 2013& 2016 kullanan müşteriler’ de ise sürekli yeniden kurulumlar’ da 30,40,50 GB gibi yüksek mailboxına boyutuna sahip kullanıcılarda son 1 yıllık datanın indirilmesi hem zaman hemde Internet bant genişliği açısından networkü yormaktadır. (Cache mode zaman ayarını düşürerek bunun önüne geçebiliriz.)

Kullanıcıların sahip olduğu 40GB 50GB OST dataları Outlook performansı ciddi anlamda düşürmektedir.

Outlook 2013& 2016 kullanan müşteriler ’de default olarak 1 yıllık OST datasının client tarafında tutulmasından dolayı çoğu zaman kullanıcılar IT ekiplerine 1 yıldan önceki datalarını göremediği için talepler oluşturmaktadır.  (Outlook üzerinden eski datayı search etmesi durumunda ilgili mail sunucuda bulunarak Outlook’ta gösterilmektedir fakat kullanıcılar bunu bilmediği için direk IT ekiplerine bu case ile gelmektedir.)

Online Mode kullanımında Outlook’un çok yavaş çalışması (Outlook performansı için cache mode üzerinde çalıştırılması önerilmektedir.)

Remote Desktop serverına bağlanan kullanıcılarda Outlook uygulamasını kullanan firmalarda 1 yıllık OST datasının büyüklüğü Remote Desktop Server üzerinde ciddi yer kaplamakla beraber performansı düşürmektedir. (Çözüm olarak Cache mode settings ayarlarını 1 ay gibi süreye düşürerek hem performans hem storage anlamında yer kazanabiliriz.)

Bu gibi durumların bir nebze daha önüne geçmek adına ufak birkaç ayar ile hem network Bandwidth tüketimi azaltabilir hemde bu tarz gelebilecek case’leri daha azaltabilirsiniz. Örneğin çok fazla kritik mail işi yükü oluşturmayan ve sürekli geçmiş tarihli mailler’ de işi olmayan departmanlar için Outlook cache mode ayarını 1 ay gibi bir süreye, kritik iş yüküne sahip veya müdür seviyesindeki departmanlarda bu süreyi 2 yıl gibi bir süreye uzatarak çözüm sağlayabilirsiniz. Active directory kullanılan ortamlarda bu işi Group policy ile her bir departmana farklı farklı policyler uygulayarak cache mode tarih ayarını kontrol edebilirsiniz.

Bu makalede Outlook 2016 ADMX yönetim araçlarını kullanarak Active Directory Group Policy aracı üzerinden kullanıcıların Outlook Cache zamanlarının ayarlanmasın hedefledim. Bu makale hem Exchange Online hemde Exchange On-premise kullanan müşterilerde uygulanabilir, basit adımlar ile bu işlemi nasıl yöneteceğinizi anlatıyor olacağım. Aşağıda uyguladığım ayarlar birebir Outlook 2013 içinde geçerlidir.

1-Aşağıdaki linkte bulunan ihtiyacınız olan versiyonun ADMX dosyasını içeren dosyayı Domain Controller sunucusunda indiriniz. Hem 2016 hem de 2013 Outlook tarafında bu ayarı yapacaksanız her 2 dosyayı sunucuya indirip aşağıdaki adımları her bir version için takip ediniz.

Office 365 ProPlus, Office 2019 ve Office 2016:https://www.microsoft.com/en-us/download/details.aspx?id=49030

Outlook 2013:https://www.microsoft.com/en-ie/download/details.aspx?id=35554

2-Active directory sunucusu üzerinde masaüstüne indirdiğimiz Setup’ ı çalıştırıyoruz.

3-Dosyaların çıkacağı location olarak masaüstünü seçenek extract etmesini sağlıyoruz.

4-Masaüstünde açılan dosyaların içine girdikten sonra aşağıdaki işaretlenmiş olan .admx uzantılı dosyaların hepsini kopyalıyoruz.

5-Kopyaladığımız dosyaları eğer tek bir domain controllerınız varsa C:\Windows\PolicyDefinitions altındaki bölüme yapıştırıyoruz.

İpucu! Burada önemli bir nokta , birden fazla domain controllerınız varsa kesinlikle dosyaları “C:\Windows\PolicyDefinitions” lokasyonuna atmayınız. C:\Windows\PolicyDefinitions altına atmanız durumunda bu ADMX dosyası dosyaları attığınız domain controller sunucusundaki Group policy’i altında gözüküyor olacak. Bunun yerine tüm domain controller’lar altında bu ADMX datalarının etkin olabilmesi adına central store özelliğini kullanacağız.

Birden fazla domain controller yapınız olması durumunda ilgili ADMX dosyalarını Sysvol altına koymanız durumunda tüm domain controller’ lara sync olarak ADMX’in aktif olmasını sağlayacağız.

\\hakanmarangoz.com\SYSVOL\hakanmarangoz.com\policies\PolicyDefinitions

İpucu! İlk defa GPO central store mantığını kullanacaksanız \\hakanmarangoz.com\SYSVOL\hakanmarangoz.com\policies\ altında PolicyDefinitions adlı klasörünü elle oluşturunuz.

Not: Yukarıdaki URL kısmında hakanmarangoz.com olan kısma sizin sunucunuzun domain ismini girmeniz gerekmektedir.

GPO ADMX Central Store mantığı hakkında daha fazla bilgi için tıklayınız.

6-Masaüste tekrar geri dönerek çıkarmış olduğumuz klasör içerisindeki en-us klasörünün içerisindeki dosyaları kopyalıyoruz.

7- Kopyaladığımız dosyaları tek bir domain controllerınız varsa C:\Windows\PolicyDefinitions\ altında en-us adlı bir klasör açarak içerisine yapıştırıyoruz.

Birden fazla domain controller yapınız olması durumunda ilgili ADMX dosyalarını Sysvol altına koymanız durumunda tüm domain controller’lara sync olarak ADMX’in aktif olmasını sağlayacağız.

Birden fazla domain controllerınız olması durumunda \\hakanmarangoz.com\SYSVOL\hakanmarangoz.com\policies\PolicyDefinitions altında en-us adlı bir klasör açarak içerisine yapıştırıyoruz.

8-Domain Controller üzerinde Group Policy’imizi açıyoruz ve Outlook Cache gününü hangi OU (User policy olacak) üzerinde uygulayacaksak ilgili OU’ya geldikten sonra “Create a GPO in this domain, and Link it here…” seçeneğini seçiyoruz.

9- Policy’imize isim tanımlıyoruz.

10-Policy’imizde ayarları gerçekleştirmek için sağ tıklayıp “Edit” seçeneğini seçiyoruz.

11- Outlook 2016’lar için: User Configuration\Administrative Templates Policy Definition\Microsoft Outlook 2016\Exchange\Cached Exchange Mode bölümüne geldikten sonra sağ tarafta bulunan “Cached Exchange Mode Sync Settings” seçeneğine çift tıklıyoruz ve Policy’imizi etkin hale getiriyoruz. Policy içerisinde Outlook OST dosyalarının son kaç ayı download edeceğini kendi ihtiyacınıza göre belirleyiniz.

12- Outlook 2013’ler için: User Configuration\Administrative Templates Policy Definition\Microsoft Outlook 2013\Exchange\Cached Exchange Mode bölümüne geldikten sonra sağ tarafta bulunan “Cached Exchange Mode Sync Settings” seçeneğine çift tıklıyoruz ve Policy’imizi etkin hale getiriyoruz. Policy içerisinde Outlook OST dosyalarının son kaç ayı download edeceğini kendi ihtiyacınıza göre belirleyiniz.

13-Policy sonrası örnek yeni bir Outlook kurulum ekranı aşağıdaki gibidir.

Not:

1-Policy uygulanması sonrası bilgisayarlarda oturum açılıp kapatıldığında mevcut profil ayarları yukarıda belirlediğimiz Policy’deki ayarlar olarak güncellenecektir.

2-Her departman için Outlook Cache zamanını istediğiniz gibi belirleyebilirsiniz. Yeni bir Policy daha yaratarak içerisindeki tarih ayarını değiştirdikten sonra ilgili OU’ya uygulamanız yeterlidir.

Umarım faydalı olmuştur, keyifli okumalar.

Merhabalar, son kullanıcılar için farkındalık eğitimi verdikten sonrası paylaştığım yazıyı çözümpark okuyucuları ile ’de paylaşmak istiyorum.

 Öncelikle son zamanlarda gelen zararlı yazılım, zararlı link ve ekli dosya olan şüpheli mailer için her ne kadar bizler yani BT çalışanları önlem alsalar da zararlı ekli dosya ve linkler durmak bilmeden gelmeye devam ediyor. Burada biz BT çalışanlarına düşen, bilgisayar kullanıcılarını eğitmek ve bilgilendirmek. Bir nevi balık tutmak değil de balık tutmayı öğretmek gibi düşünebiliriz

Yukarıdaki maili incelediğimizde;

Ben muhammet.bektas@igc.com.tr adresinden herhangi bir mail beklemiyordum, mail başlığına baktığımızda pek de kurumsal bir dil olmayan “merhabalar siparişlerimize bakarmısınız …” yazdığını görüyorum.

Mail eki olarak Bel_54.xls adında bir dosya göndermiş, bana bu isim pek bir şey çağrıştırmıyor.

Mail içeriğine baktığımızda ise Türkçe karakter formatının bozuk olduğu bir font tipi kullanılmış.

Bu tür mailler benim için her zaman şüphe uyandıran maillerdir, genellikle eğer buradaki mail atan kullanıcıyı tanıyorsam arar sorarım, hem bir halini hatırını sormuş olurum hem de siparişi ile ilgili maili onun gönderip göndermediğini öğrenmeye çalışırım, ya da şüpheli olarak gördüğüm mailleri zaman kaybetmeden direk silerim.

Eğer silemiyorsanız yazının devamında nasıl analiz edebileceğimize dair detayları bulabilirsiniz.

Benim zararlı ek ve yazılımları analiz amacıyla kullandığım 2 web site var

1-     www.virustotal.com

2-     www.hybrid-analysis.com

virustotal.com genel olarak eğer exe formatında bir dosya alınmışsa kabaca taratılıp virüs var mı yok mu gibi kontrolleri yapabileceğimiz bir sitedir.

Hybrid-analysis.com ise sandbox dediğimiz teknoloji ile çalışmaktadır.

Peki, o zaman kısaca sandbox nedir?

Sandbox, Bilgisayarınızdan farklı bir alanda yalıtılmış sanal ortam üzerinde güvensiz ve güvenli dosyaların çalıştırılabildiği bir ortam olarak düşünebiliriz.

Bu örneğimizde ekli dosyayı bu sandbox ortamında açarak sonuçları görüntülüyor olacağız.

Şüpheli ekli dosyayı bilgisayarımıza indirerek (açmadan, sadece eki kaydet diyerek) masaüstüne kaydediyoruz. Hybrid-analysis.com da üst ok ile işaretli alana zararlı ek dosyayı sürükleyebilirsiniz ya da alt kısımdaki ataç işareti olan alana tıklayarak ekli dosyayı göstererek yükleyelim.

Üst kısma email adresinizi yazabilirsiniz, opsiyoneldir. Bu bölüme mail yazarsanız sonuçları sizin mail adresinize atılır.

Allow community members to Access sampleve I consent to the Terms & COnditions and Data Protection Policy seçeneklerini işaretliyoruz.

Ben robot değilim seçeneğine tıkladığınızda çıkan doğrulama seçeneklerini işaretleyerek doğrula butonuna basarak bu bölümü geçebiliriz.

Bu bölümde hazırda kurulmuş, bulut üzerinde bulunan yalıtılmış bir alanda üzerinde MS Office uygulamaları, Adobe Flash Player, Adobe Reader olan temel uygulamaların yer aldığı bilgisayarlar bulunmakta. Burada bilgisayarınızın işlemci modeline ya da işletim sistemine göre bir seçim yapabilirsiniz. Örneğin genellikle 64 bit Windows işletim sistemi kullanıyoruz, bu yüzden Windows 7 64 bit seçeneğini seçerek devam edebiliriz. VMs kısmında o andaki sıra bekleme sayısını bize göstermektedir. Bizim bu örneğimizi yaptığımız sırada 11 adet sanal makine varmış, biz 1. Sıradaymışız.

Generate Public Report seçeneği ile devam ediyorum. Bu seçenek seçildiğinde ayrıca, çıkan sonuçlar virüs programı firmalarının da veritabanına gitmekte, bir sonraki virüs programı güncelleştirmesinde virüs programları size gönderilen zararlı yazılımı keşfetmiş ve engelliyor olacaktır.

Birkaç dakika bekledikten sonra dosyamızın MALICIOUS yani zararlı bir dosya olduğunu görüyoruz.

Dosya 4 virüs firması algoritması tarafından zararlı olarak görülmüş. Bakalım gerçekten zararlı mı?

Excel 2010 sembolü olan resimlere tıklıyorum (buradaki resim dosyaya göre değişiklik gösterebilir)

Dosyamız sandbox ortamında açılarak yazılımın zarar vermeye çalışan bir dosya olduğu komutların çalıştırılmaya çalışıldığı, linklere gitmek istediği gibi birçok detayı buradan görüntüleyebilirseniz.

Bu gibi mailleri bu şekilde analiz ettikten sonra hem maili hem de analiz etmek için masaüstüne kaydettiğiniz dosyayı direk olarak açmadan siliniz.

Eğer mail adresinizi yazmışsanız yazının ilk başında zararlı yazılım ya da ek incelendikten sonra size ekteki gibi bir link göndereceklerdir.

Daha güvenli bir iletişim için temel olarak dikkat etmemiz gereken konular;

Zararlı olabilecek eklere ve dosyalara her zaman şüphe ile bakarak yaklaşın.

Ekli dosyaları açarken dikkatli olun.

Gönderici mail adresi ile imza’da yazan ismin/adresin birbiri ile uyuştuğuna dikkat edin. Başka bir deyişle sahte hesaplara dikkat edin.

Virüs Programının ve İşletim sisteminizin güncel olmasına dikkat edin.

Güçlü parolalar kullanın

Eğer kullanabiliyorsanız çift katmanlı erişim kullanın (2 factor authentication)

Spam maillere cevap vermeyin.

E-Postalardaki linklere tıklarken gidilecek adres ile link’in aynı olduğuna veya gönderilen mail ile anlamlı bir adres olduğuna dikkat edin; örneğin mail suphelibank.com dan gelmiş olabilir gidilecek link supheliibank.com a gidiyor olabilir, eğer adres farklı ise bağlantıyı açmayın.

Kredi kartı ya da kişisel bilgilerinizi mail ile paylaşmayın.

İnternetten alışveriş yapıyorsanız, kredi kartı bilgilerinizi direk olarak girmeyin, sanal kart tanımlayarak alışverişiniz kadar limit tanımlayın.

Sık sık kredi kartı harcamalarınızı kontrol edin.

Ortak alanlarda wifi ile bağlanmayın, bağlanıyorsanız da bağlandıktan hemen sonra vpn ile şirketinize bağlanarak aradaki veriyi şifreleyin, ortadaki adam saldırısı ile parolanızı çaldırmayın.

Dosyalarınızı sık sık yedekleyin

Mobil cihazlarınızda güçlü parola ve virüs programı kullanın

Kurumlar için;

Çalışanlar için yılda en az bir kez farkındalık eğitimleri yapın.

Zafiyetlerinizi öğrenmek için yılda bir kez penetrasyon testi yaptırın.

Güvenli günler dilerim

Bazı senaryolar ’da Office 365 veya Azure üzerindeki servislerde kullandığınız cloud kullanıcı account bilgilerini local Active Directory ile eşleştirmeniz gerekebilir.Office 365 üzerinde yeni oluşturduğunuz bir tenant üzerinde Azure AD Connect tool vasıtasıyla directory synchronization yapısının kurulmasını birkaç adımda basitçe tamamlayabilmekteyiz. Sıfır’dan açılan tenant’larda herhangi bir kullanıcı olmadığı için On-Premise Active Directory üzerindeki kullanıcıların Cloud’a sync olması sırasında her bir user , group ve contact için yeni obje oluşturularak local Active Directory’den attributeler sync olmaktadır.

Peki halihazırda Office 365 üzerinde Exchange Online servisini kullanıyorsam ve kullanıcılarımı cloud user olarak barındırıyorsam local Active Directory’deki kullanıcıları nasıl eşleştireceğim? Bir diğer senaryoda Office 365 üzerinde kullanıcılarım olduğunu ve sadece PowerBI servisini kullandığımı varsayarsak yeni yatırımlar sonucu On-Premise yapımda bulunan Exchange serverımı Exchange Online platformuna hybrid yapısı ile taşıyacağım bunun öncesi local Active Directory objelerimi Azure Active Directory’e PowerBI kullanıcılarına zarar vermeden hangi yöntem ile sync etmem gerekmektedir?

Azure AD Connect kurulumunu tamamlayıp senkronizasyonu başlattığınızda Azure AD sync (Azure AD üzerindeki) servisi her bir yeni kullanıcıyı kontrol eder ve varolan kullanıcıların bulunarak eşleşmesini sağlar. Bu işlemler gerçekleştirilirken temelde 3 attributeden yararlanılır. Bu attributeler userPrincipalName, proxyAddresses ve sourceAnchor/immutableID ‘dir.

userPrincipalName ve proxyAddressesüzerindeki bir eşleşme SOFT match olarak bilinir.SourceAnchor attribute üzerindeki bir eşleşme ise Hard match olarak bilinir.

Azure AD eğer Local’den gelen bir objenin attribute değerleri ile Azure AD üzerindeki objenin değerlerinin aynı olduğunu tespit ederse obje değerlerinin Local’den devralınmasını sağlar.” Cloud-managed” olarak gözüken obje “Synced with Active Directory” olarak işaretlenir. On-premise Active Directory üzerinden gelen attribute değerleri Azure AD üzerindeki objenin attribute değerlerinin üzerine yazılır.

Uyarı ! : On-Premise Active Directory’den gelen değerlerin Azure AD üzerindeki objenin değerlerinin üzerine yazılacağı için On-Premise yapınızdaki Active Directory üzerindeki obje değerlerinin güncel olduğundan muhakkak emin olunuz.

Uyarı ! : Password sync özelliğinin kullanılımının tercih edilmesi durumunda Azure AD'deki şifrenin yerine On-Premise AD'den gelen şifre Azure AD üzerine yazılır. Local Group Policy ile gelen Password Policy’leri Azure AD üzerindeki Password Policy’i ezer.

Objelerinizi Azure Active Directory ile eşleştirmek istiyorsanız bunun için 2 yöntem bulunmaktadır.

·         Soft Match (SMTP)

·         Hard Match (ImmutableID)

Yeni bir AD Connect kurulumunda aslında Soft Match ve Hard Match arasında pratikte bir fark bulunmamaktadır. Fakat AD Connect kullanılan bir ortamda Disaster recovery durumunda AD Connect sunucusunu kaybettiyseniz, veri kaybetmeden yeni bir AD Connect’i yeniden yükleyebilirsiniz. Burada devreye SourceAnchor ile hard match kavramı devreye girmektedir. SourceAnchor değerine sahip objeler yeniden AD Connect sunucusunun kurulup sync başlatılması ile beraber eşleşir.

Soft Match (SMTP)

Office 365 üzerinde Exchange Online yapısına geçerken IMAP , Cutover yada taşıma yapmadan kullanıcıları Cloud üzerinde oluşturarak geçiş yapmış olabilirsiniz ya da Office 365 üzerinde sadece PowerBI , CRM gibi uygulamaları kullanıyorsunuz bununla beraber ilerleyen zamanlarda kullanıcıların match edilme işleminde en basit uygulanacak yöntemlerden biri olan “SMTP match” işlemi kullanılmaktadır. Burada bir açıklama yaparak konuyu toparlamak istiyorum match etmeden kastım Cloud üzerinde kullanıcılarınız ve şifreleri var aynı şekilde bu kullanıcılar sizin Active Directory üzerinde mevcut fakat aralarında herhangi bir bağlantı yok. Buda demektir ki her 2 platformdaki kullanıcılarda değişiklik yapmak istediğinizde ayrı ayrı uğraşıyorsunuz bu durum sebebiyle bir bakıma IT tarafındaki kullanıcı iş yükünüzüde arttırıyorsunuz demektir. SMTP Soft Match yöntemi , Exchange Online üzerinde SMTP adresi olan her kullanıcı ’da uygulanabilir. Bu yöntemin temel amacı Local’de bulunan Proxy Address attribute’ne girilen değer ile Exchange Online üzerinde bulunan SMTP attributelerinin aynı olması durumunda kullanıcıyı dumplicate etmeden merge etmesidir.

Bunun için yapılması gereken adımların başında Exchange Online üzerindeki her bir kullanıcının SMTP adres bilgisinin On-Premise Active Directory yapısında bulunan ilgili kullanıcının Proxy Address attribute içerisine girilmesi gerekmektedir.

Exchange Online

On-Premise Active Directory

İpucu ! : Büyük SMTP: varsayılan Email adresini küçük smtp: ise ikincil Email adresini temsil eder. Exchange Online üzerinde ikincil Email adresleriniz varsa bunlarıda Active Directory tarafında küçük smtp kullanarak eklemeniz gerekmektedir.

Bir diğer dikkat edilmesi gereken noktaların başında SYNC edilecek kullanıcı objelerinin UPN bilgisinin ’de eşleşmesi gerekmektedir. Bu konuya da özellikle dikkat etmeniz gerekmektedir. Siz SMTP adres bilgisini aynı tutsanız ’da kullanıcı UPN bilgisinin farklı olması durumunda farklı kullanıcı kimlikleri oluşacağı için eşleşme sağlanmayacaktır.

Microsoft 365 Admin Center\Active Users

On-Premise Active Directory

Attribute tanımlamaları yapıldıktan sonra AD Connect kurulumu yapılarak sync işlemi başlatılabilir. Sync işleminden sonra match işleminin başarılı olup olmadığını anlamak adına Office 365 üzerindeki Active Users bölümünü kontrol edebilirsiniz.

“Synced with Active Directory”

User name / Email address bilgisinin Local’den sync edilerek doğru geldiğini doğrulamaktayız.

SMTP match konusunda dikkat edilmesi gereken konular:

-SMTP adresiunique olduğu için bir SMTP adres bilgisini Active Directory üzerinde birden fazla kullanıcı’da kullanmadığınıza emin olunuz. Birden fazla kullanıcı’da aynı SMTP adresinin girili olması durumunda AD Connect sync tool uygulamasında aşağıdaki hatayı alıyor olacaksınız.

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:hakan.marangoz@hakanmarangoz.com;]. Correct or remove the duplicate values in your local directory.

-SMTP match işleminden sonra Cloud kullanıcılarının SMTP adres bilgisi Cloud üzerinden bir daha değiştirilememektedir. Yönetim işini Local Active Directory devralmaktadır.

-Match işlemi sonrası Cloud üzerindeki kullanıcıların passwordleri geçerliliğini kaybediyor olacak.Local Active Directory’de bulunan kullanıcının şifresi geçerli olacak ve Cloud üzerindeki eşleştiği account’ın üzerine Local GPO’dan gelen policy kurallarını yazıyor olacak.

Makelenin 2.bölümünde ise Hard Match kavramını anlatıyor olacağım.

Makalenin ilk bölümünde anlattığım Directory eşleştirme senaryoları ve Soft Match (SMTP) kavramından sonra şimdide Hard Match konusunu ele alacağım.

Hard Match (ImmutableID)

AD Connect sunucumuzda yaşanacak bir geçici kesinti’de , Active Directory veya AD Connect sunucularından birini tamamen kaybetmemiz durumunda neler oluyor bunlara bir bakalım.

Öncelikle ADConnect sunucusunun kapanması veya sunucuyu tamamen kaybetmeniz durumunda herhangi br sistem kesintisi yaşamazsınız (Password Hash sync veya Pass-through HA kullanılması durumunda) sunucuya erişilememe sürecinde Active Directory üzerinde oluşturulan , değiştirilen objeler sadece Azure AD’ye sync olamıyor olacak. Sunucuyu ayağa kaldırmanız durumunda kaldığı yerden sync tüm yapılan değişiklikleri algılayarak görevine devam edecek. Sunucudaki bir problemden dolayı sunucuyu kaybetmeniz durumunda ise bu sefer yeni AD Connect sunucusu kurarak eşitlemeyi tekrardan devralmaya başlamanız gerekmektedir. İşte bu nokta’da devreye Hard match kavramı girmektedir. Yani benim daha önceden local’deki bir kullanıcım Cloud’da mevcut aradaki sync toolunu tekrardan kurarak bu Local ve Cloud yapısındaki kullanıcılarının aynı kullanıcı olduğunu ispatlamamız gerekmektedir.Bunuda yapacak kişi aslında AD Connect tool’udur.

Bunun için öncelikle yapmanız gereken işlerin başında yeni bir AD Connect sunucusu kurup AD Connect tool’unu ilgili sunucuya indirip tekrardan senkronizasyonu başlatınız. AD Connect sunucusunu kaybettiğiniz için yeniden kurulum sonrası daha önceki sync olan kullanıcıların bilgisi veritabanında bulunmayacağı için ilk önce bir Full sync dediğimiz metot ile sync başlıyor olacak her obje tek tek hem Local hem Azure AD üzerinde tespit edilip birbirleri ile eşleştirilerek hangisinin sync edilip hangisinin edilmeyeceğine sistem kendi karar veriyor olacak.

Directory üzerindeki her kullanıcının kendine özgü benzersiz bir ObjectGUID değeri bulunmaktadır. Objelerin eşleştirilmesinde bu sefer devreye ImmutableID (Cloud Attribute ) ve ObjectGUID (On-Premise Attribute) attribute değerleri devreye giriyor olacak.On-Premisedeki kullanıcının ObjectGUID değeri AD Connect aracılığıyla okunacak ve yeniden kurulumdaki ilk full sync sırasında Cloud üzerinde daha önceden aynı değer ile sync olan kullanıcıyla eşleşme yapılacaktır.

On-Premise Active Directory üzerinde bulunan kullanıcının ObjectGUID değeri Base-64 olarak sistem tarafından convert edilerek öncelikle AD Connect üzerinde tanımlı SourceAnchor değerine oradan ise Azure Active Directory de bilinen ImmutableID attributine eşlenmektedir.

Uyarı ! : ObjectGUID ve ImmutableID attributeleri değiştirilemezdir.

ADConnect’in ilk kurulumu sırasında aslında biz değeri default olarak Azure AD yönetimine bırakmaktayız. Dilersenizde SourceAnchor değerini custom bir attribute olarakta belirleyebilirsiniz.

Üstte çalışma mantığını anlattığım topolojinin AD tarafındaki kontrolünü sağlayalım.

·         On-Premise Active Directory üzerinden kullanıcının ObjectGUID değeri kontrol edilir.

Get-ADUser hakan.marangoz | fl objectguid

·         ObjectGUID değerinin Base-64 olarak convert edilerek Azure AD üzerinde geçerli olan ImmutableID değerine dönüştürülmesi gerekmektedir. AD Connect bunu sync işlemi yaparken kendi yapıyor ama ben bu değerin doğru olup olmadığını anlamak adına , bu convert işlemi kendim yaparak technette bulunan hazır bir script’ten yararlanarak ilerliyeceğim. Aşağıdaki örnekteki gibi scripti indirip kullanıcının ObjectGUID değerini vererek convert edilmiş ImmutableID değerini alabiliriz.

Script download

·         Office üzerine Powershell ile bağlanılarak Azure Active Directory üzerindeki kullanıcısının Immutable ID değerini Local’deki kullanıcımın değeri ile eşleşip eşleşmediğini kontrol edeceğim.

Office 365 Exchange Online PowerShell ile bağlantı kurulur.

Import-Module MSOnline

$O365Cred = Get-Credential

$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection

Import-PSSession $O365Session

Connect-MsolService –Credential $O365Cred

Get-MsolUser -UserPrincipalName hakan.marangoz@hakanmarangoz.com | Select immutableid

Yukarıdaki Azure Active Directory değeri ile benim Local Active Directory’de bulunan kullanıcımın ObjectGUID’den Base-64‘e çevrilmiş ImmutableID değeri birebir tutmaktadır.

Toparlamak gerekirse ;

1.      AD Connect sunucumuzu kaybetmemişsek , ADConnect sunucusunun yeniden kurulması sonrası objeler daha önce’den Cloud’a sync edildiyse hard match yöntemindeki Object GUID ve ImmutableID değerinden birbirlerini tanımakta ve tekrar sync kaldığı yerden devam etmektedir.

2.      Active Directory sunucunuzu kaybettiyseniz ve yeni bir Active Directory kurup kullanıcıları yeniden oluşturduysanız bu sefer her bir kullanıcı için ObjectGUID değeri değişeceği için AD Connect sync sırasında değerleri eşleştiremeyerek kullanıcıları dumplicate ediyor olacak. Active Directory sunucunuzu kaybetmeniz durumunda öncelikle

                                                       i.            AD Connect sync işlemini Tenant üzerinde turn off ediniz.

                                                     ii.            Sonrasında Azure Active Directory üzerindeki objelerin Cloud objesine convert olmasını bekleyiniz.

                                                    iii.            Her bir kullanıcının ImmutableID değerlerini powershell ile temizleyiniz.

                                                    iv.            Yeni Local Active Directory üzerindeki her bir kullanıcının ObjectGUID değeri Base-64 convert edilerek alınan ImmutableID değerini Azure AD üzerindeki aynı kullanıcıya set ediniz. Set-MsolUser -UserPrincipalName hakan.marangoz@hakanmarangoz.com -ImmutableId EOi8OHnqKUuusvZ/J6X5SA==

                                                      v.            Tekrar’dan AD Connect kurulumu yapılarak sync işlemini yapınız.

Umarım faydalı olmuştur , keyifli okumalar.

Exchange server pek çok şirketin Kurumsal bir doküman yönetim sistemine sahip olmaması nedeni ile tüm şirket bilgilerini bulabileceğiniz son derece değerli bir veri ambarıdır.

Aslen mesajlaşma sistemi olarak tasarlanmış olan exchange server ne yazık ki pek çok şirket için en kritik dokümanların dahil paylaşıldığı bir platform olunca pek çok kötü niyetli kişi için ilk saldırı odağı olabiliyor. Biz sistem ve güvenlik yöneticilerinin de görevi tam olarak burada neler döndüğünü izliyor olmamızdır.

Her ne kadar exchange online başlığı altında bunu yazıyor olsam da aslında pek çok müşterimde yaptığım sağlık taraması raporlarında daha temel açıklar tespit etmiştim. “Managed Full Access” izinleri olarak tanımladığımızın izinlerin bilgi işlem personeli bilgisi dahilinde veya bazen bilgisi dışında kullanıldığını, yani bir veya birden çok kişinin yine bir veya bir den çok kişi için posta kutusuna izinsiz eriştiğini gördüm. Bunun önüne geçmek için en temel yöntemin mailbox Audit açmak olduğunu ve bu sayede gerek izinsiz erişimler gerekse kullanıcının hali hazırda kendi yaptığı ama inkâr ettiği işlemleri raporlayabilirsiniz;

http://www.cozumpark.com/blogs/exchangeserver/archive/2016/05/22/exchange-server-admin-audit-log-deep-dive.aspx

http://www.cozumpark.com/blogs/exchangeserver/archive/2012/11/25/exchange-server-2013-mailbox-audit-logging.aspx

http://www.cozumpark.com/blogs/exchangeserver/archive/2014/10/19/exchange-server-2013-mailbox-audit-ayarlari-ve-silinen-tasinan-mailleri-audit-loglar-ile-tespit-etme.aspx

https://www.lepide.com/how-to/track-who-accessed-mailboxes-in-exchange-server-2016.html

Peki benzer bir durumu exchange online için nasıl gerçekleştiriyoruz?

Office 365 tarafındaki yenilikleri yakından takip edenler hatırlayacaktır, uzun süredir müşterilerin istediği bir özellik olan mailbox Audit exchange online üzerinde varsayılan olarak açık değildir. Haziran 2018 sonrasında ise artık Microsoft yeni posta kutuları için artık mailbox Audit özelliğinin varsayılan olarak açık geleceğini açıkladı. Bu aslında konuya bakış açısını ve özellikle güvenliğin önemini gösteriyor. Bana göre çok geç kalınmış bir karar ancak her zaman olaylara iki taraflı bakmaya çalışan birisi olarak, on prem exchange sunucusunda bile müşteriye konuyu anlatırken bu Audit bilgilerinin her bir kullanıcının kendi posta kutusu içerisinde saklandığını bu nedenle ortalama %10 büyüme yapacağını ifade ediyorum. Yani 1TB olan bir veri tabanı için 1.1TB yani 100GB Audit log’ dan bahsediyoruz. Aynı şeyi milyonlarca posta kutusu tutan exchange online için düşünürseniz bunun için ciddi bir storage hazırlığı olması gerektiğini de kabul ediyorum.

Peki öncelikle mevcut durumu bir kontrol edelim;

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

Get-Mailbox | fl *Audit*

Gördüğünüz gibi “AuditEnabled” false durumda, yani açık değil.

Tek bir kullanıcıda Mailbox Audit açmak için aşağıdaki gibi bir komut kullanabilirsiniz;

Set-Mailbox -Identity "Hakan Uzuner" -AuditEnabled $true

İsim yerine mail adresini de yazabilirsiniz.

Eğer tüm kullanıcılarda açmak veya kapatmak istiyorsanız;

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditEnabled $true

Tüm kullanıcıları çağırıp hepsinde Mailbox Audit açabilirsiniz.

Tabiki Audit açmak yeterli değil, posta kutusunun sahibi, admin ve delege edilmiş kullanıcı olmak üzere 3 ana sınıf için alt sınıflandırmaları ayarlayabilirsiniz. Bunun için aşağıdaki makaleyi inceleyebilirsiniz.

https://docs.microsoft.com/en-us/office365/securitycompliance/enable-mailbox-auditing

Not: Bu bölüm için ÇözümPark üzerindeki makalelerimde çok daha detaylı bilgi var, hatta önerilerim de var, yani admin için hangi loglama başlıklarını, posta kutusu sahibi için hangi loglama başlıklarını, delegasyon yapılan kullanıcılar için hangi loglama başlıklarını açacağınızı görebilirsiniz.

Örneğin benim kullanıcım için kendi yaptığım hareketler, admin hareketleri ve delegasyon verdiğim kullanıcı için bunları logluyorum, siz bunları benim makalemdeki gibi değiştirebilirsiniz;

Peki biraz daha detaya girelim;

Ocak 2019 itibari ile artık biz bu logların içerisinde Session ID isminde bir değer görebiliyoruz. Bu yeni değer sayesinde hesap aktivitelerini daha iyi anlayabiliyoruz.

Session ID, mailbox Audit ve Admin Audit log’ un bir parçasıdır. Bir kodlanmış GUID olan Session ID, Azure AD token’ ı temsil etmektedir.

Session ID sayesinde her bir logon işlemi içerisindeki tüm aktiviteleri takip etmemizi sağlar. Her bir yeni şifre girişinde ise yeni bir session ID tanımlanır.

Ancak burada önemli bir detay yer almaktadır. Özellikle son dönemde office 365 kullanıcı şifrelerinin çaldırılması gibi durumları session id sayesinde çok kolay yakalayabiliyoruz. Ancak kötü niyetli kişi eğer kullanıcının makinesini ele geçirmiş ise bu durumda session id, kötü niyetli kişinin aktivitelerini yakalayamaz çünkü ilgili kişi hali hazırda kullanıcı AD token kullandığı için tek bir session id üzerinden işlem yaparlar.

Session ID’ nin temsil ettiği token sadece Azure AD tarafından üretilmektedir. Bunun kullanabilmek için temel şart ortamınızda basic authentication ile logon işlemini yasaklamanız. Eğer bunu yapmazsanız Session ID ile kötü niyetli kişileri takip etmeniz mümkün olmaz.

Bunun için aşağıdaki makaleyi inceleyebilirsiniz;

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Conditional-Access-support-for-blocking-legacy-auth-is/ba-p/245417

Peki tam olarak nasıl takip ediyoruz?

Öncelikle kolay olan yöntem admin center üzerinden aşağıdaki gibi bu logları export etmektedir;

Ama ben daha çok PS kullanıyorum, çünkü daha net sonuçlara ulaşmanızın en kolay yolu bence.

Aşağıdaki bir örnek yer almaktadır;

Search-MailboxAuditLog -Identity hakan -LogonTypes Admin,Delegate -StartDate 1/1/2019 -EndDate 12/31/2019 -ResultSize 2000

Hakan kullanıcısı için 2019 yılı içerisinde yönetici ve delegasyon verdiğim kullanıcılara ait olan logları listelemek için kullanabilirim.

Eğer aynı komut içerisinde birden çok kullanıcı için sorgu çekmek istiyorsanız aşağıdaki gibi yan yana yazabilirsiniz;

Search-MailboxAuditLog -Identity hakan, serkan -LogonTypes Admin,Delegate -StartDate 1/1/2019 -EndDate 12/31/2019 -ResultSize 2000

Ya da benim en çok kullandığım komutu paylaşmak isterim.

Malum kullanıcılar genelde böyle bir mail geldi ama silinmiş ben silmedim noktasında kullanıcı destek ekiplerine çok soru yöneltiyorlar. Klasik bir durum aslında, mail kendi kendine silinmez. Bir kural vardır, genelde kural çıkar. Ama kural yok ise de genelde kullanıcının çıktığını görüyoruz. Peki nasıl görüyoruz? Aşağıdaki komut yardımı ile;

Search-MailboxAuditLog -Identity hakan -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq "HardDelete"}

Yani shift delete ile geri dönüşüm kutusuna gitmeden silme operasyonuna biz “HardDelete” ismini veriyoruz. Bu işlemi eğer kullanıcı kendisi yapmış ise “Logon type bölümüne owner yazdık yani kullanıcının kendi hareketleri arasında arama yaptığımızı görebiliriz.

Peki sonuçlarda bizim takip etmemiz gereken session ID yi nasıl gözlemliyoruz;

PS ile öncelikle session ID leri aşağıdaki gibi bir tabloda birleştirirsek hızlıca bir anormallik olduğunu anlayabiliriz;

Yeşil olanlar kullanıcının kendi hareketleri olup kırmızı olanların kötü niyetli kişiler olduğunu varsayıyoruz. Hızlıca bir kural yazdıklarını fark ediyoruz. Bu office 365 de ne yazık ki son dönemde gördüğümüz bir atak yöntemi, şifreyi alıyor, mail trafiğini kendisi yönetmek için maillerin bir kopyasını kendisine gönderip gelen maili direkt siliyor. Bu nedenle kullanıcıya ilgili kişiden mail gelmiyor gibi duruyor hatta hiç mail gelmiyor, tüm trafiği kötü niyetli kişi yönetiyor.

Peki bu ID leri nasıl buluyoruz, eğer mailbox audit açık ise aşağıdaki gibi bir komut seti ile bunlara kolaylıkla ulaşabilirsiniz;

Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq "Update"}

Yukarıdaki komutun çıktısında pek çok log gelecektir, bir tanesini örnek olarak inceliyorum;

Gördüğünüz gibi ikinci bölümde (ben resmi iki parça aldığım için) sessionId detayını görebiliyoruz. O zaman bu çıktıyı biraz daha sadeleştirelim;

Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq "Update"} | select ClientIPAddress,OperationResult,Operation,FolderPathName,LastAccessed,SessionId

Ajanda için yapılan güncellemeleri tarih ve sessionid olacak şekilde sınıflandırdım;

Gördüğünüz gibi farklı tarihler var ancak SessionID aynı.

Biraz daha geniş bakabilirsiniz;

Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | select ClientIPAddress,LastAccessed,SessionId

Tabi bunun için en temiz yöntemi ürün kullanmak.

https://www.logbinder.com/

Bu ürün sayesinde bu logları sahip olduğunuz SIEM’ e kolayca entegre edebilirsiniz.

Ya da ben uğraşmak istiyorum derseniz bu PS ile 24 saatlik logları bir dizine alır oradan import edersiniz

https://practical365.com/exchange-server/powershell-script-report-mailbox-audit-log-entries/

Ek olarak bir şekilde birileri posta kutusunu ele geçirir ise ilk yapacağı işlerden birisi yönlendirme kuralı oluşturmaktır, bu konuda Microsoft Office 365 üzerinde otomatik bir alert de görebilirsiniz. Yani organizasyon içerisinde herhangi birisi bir inbox rule oluşturur ise bunu alet bölümünde görebiliyoruz. Hatta ilgili ayarları yapmışsanız da bu uyarılar size mail olarak düşecektir.

Evet belki gündelik hayat için çok yorucu bir makale oldu ama ne yazık ki danışmanlık işimizin bir parçası da güvenlik olduğu için böyle case’ leri çözmek için bu teknolojileri kullanıyor ve sizler içinde makale haline getiriyoruz.

Makalemin sonuna geldik, umarım faydalı bir makale olmuştur.

Kaynak

https://blogs.technet.microsoft.com/exchange/2019/01/04/contextualizing-attacker-activity-within-sessions-in-exchange-online/

Makalemize giriş yaparken artık Ofis 365 nedir, Ne Değildir? Gibi giriş bilgilerine yer vermeyeceğim. Kurumsal olarak mail sunucularla ilgilenen her bir birey artık Ofis 365 ürününü geniş yelpazeden tanıdı.

Biz makalemizde Ofis 365 Self Servis Parola Sıfırlama özelliğini ele alacağız. Birkaç kişinin çalışmış olduğu yerlerde yöneticilerin parola değişimi sağlaması kolay olurken sayının ve iş yükünün fazla olduğu yerlerde bu işlemler biraz zaman ve iş gücü kaybına yol açabilir. Bu nedenle Ofis 365 kullanan yapılarda, kullanıcıların kendi parolalarını sıfırlayabileceği platform olan Office 365 Self Service Password Reset özelliğini ele alacağız.

Öncelikle Ofis 365 admin center ekranını açalım. Açılan ekranda Yönetim Merkezleri başlığı altından Azure Active Directory linkine tıklayalım.

Açılan ekranımızda Self servis parola sıfırlama linkine tıklayalım.

Bu ekrana bu özelliğin sağladığı avantajlar hakkında bilgiler sunulmakta. Yapılandır butonuna tıklayarak yapılandırma adımlarını başlatalım.

Yapılandırma esnasında bizden ilk olarak bir grup ismi istenmekte. Mantık olarak zaten arka planda bir grup oluşturulup, bu gruba dahil olanlara kendi parolalarını sıfırlama imkanı sunulacaktır. Grup ismini verdikten sonra Etkinleştir ile bu özelliği devreye alabiliriz. Bu yöntem ile organizasyon üzerinde tüm kullanıcılar için bu özellik açılmış olur. Biz belirli kişilere bu hakkı sağlayacağımız ve bu kişileri belirlememiz gerektiği için Kullanıcı seçilmedi linkine tıklayalım.

Aşağıdaki ekranda mevcut yapıdaki kullanıcılar listelenmekte. Biz Self Service Password Reset özelliğini aktif edeceğimiz kullanıcıları seçerek seçim ekranına aktaralım.

Seçimi yapılan kullanıcılar ilgili alt ekrana aktarıldı. Seç butonuna tıklayarak bu ekrandaki işlemimizi tamamlayalım.

Bu işlemden sonra Etkinleştir butonuna tıklamamız ile özelliğimiz bu kadar basit bir iki işlemden sonra devreye girmiş oldu.

Şu anda gerekli özelliğimiz aktif hale geldi.

Bahsetmiş olduğumuz grup otomatik olarak oluşturuldu. Sonradan bu grup içerisine kullanıcı ekleme ve çıkarma yapabiliriz. Ofis 365 Admin Center üzerinden yapılacak olan işlemler bu kadar. Bundan sonraki adımlar kullanıcıların uygulayacağı adımlar. Admin Center işlemlerimiz bittiğine göre kullanıcı tarafında meydana gelen aksiyonları incelemeye başlayabiliriz.

Öncelikle mevcut hesaplarımdan bir tanesi ile oturum açmaya çalışıyorum.

Admin Center üzerinden parola sıfırlama ilkesi oluşturduğumuz için burada bizden güvenlik amaçlı bazı bilgileri doldurmamız isteniyor. İleri butonu ile sonraki adıma geçelim.

Bu ekranda bizden Mobil telefon bilgisi ve Kurtarma postası bilgisi istenmekte. Bu istenilenleri sırası ile doğrulayalım. Telefonumuz kullanıcı tanımlarında yer aldığı için otomatik olarak geldi. Doğrula linkine tıklayalım.

Açılan ekrana telefon numaramızı tekrar girerek bana mesaj gönder linkine tıklayalım.

Cep telefonumuza gelen doğrulama kodunu ilgili alana girerek doğrula butonuna tıklayalım.

Bu adım başarı ile tamamlandı. Kimlik doğrulama parolası yapılandırılmamış adımının yanında yer alan Şimdi Ayarlayın linkine tıklayalım.

Burada kurtarma postası için ayrı bir hesap bilgisi girerek bana e-posta gönder butonuna tıklayalım.

Yukarıda belirttiğimiz mail adresimize gelen kodu ilgili alana girerek doğrula butonuna tıklayalım.

Bizden istenen iki bilgiyi sisteme işlediğimize göre bitir ile bu adımları tamamlayalım.

Şimdi tekrardan hesabımıza giriş yapmaya çalışalım. Bu adımda parolamızı unuttuğumuzu ve sıfırlama yapmak istediğimizi düşünerek test yapalım. Parolamı unuttum linkine tıklayalım.

Robot olmadığımızı doğrulamak için ekranda bulunan resimdeki kodu ilgili alana girerek ileri butonuna tıklayalım.

Parola sıfırlama işlemlerini yapabilmemiz için yukarıda vermiş olduğumuz bilgilere göre bize doğrulama maili ve mesajı gelecektir. Bunları temin ederek ilgili ekranlara girmeliyiz. E-posta butonuna tıklayarak daha önce belirlediğimiz kurtarma adresine doğrulama kodunun gelmesini sağlayalım.

Mail adresimize gelen kodu ilgili ekrana girerek İleri butonuna tıklayalım.

İkinci adımda ise ******* ile maskelenen telefon numaramızın tamamını ilgili ekrana girerek Mesaj gönder butonuna tıklayalım.

Telefonumuza mesaj olarak gelen kodu ilgili ekrana girerek İleri butonuna tıklayalım.

Adımları sorunsuz olarak geçip gerekli doğrulamaları yapabildiğimiz için unuttuğumuz parolamızı sıfırlama imkanı elde ettik. Yeni parolamızı oluşturalım ve Bitir butonuna tıklayalım.

Parolamız başarılı şekilde değiştirildi.

Şimdi tekrardan oturum açmak için hesap bilgimizi girelim.

Açılan ekranda unuttuktan sonra değiştirmiş olduğumuz parolamızı girerek Oturum Aç butonuna tıklayalım.

Ofis 365 portal üzerinde başarılı şekilde oturum açtık.

Makalemizin sonuna geldik. Umarım yararlı olur. Bir başka makalede görüşmek dileğiyle.

OpenSUSE projesi SUSE Linux ve diğer şirketler tarafından desteklenen bir topluluk programıdır. Dünyada yaygın olarak kullanılmaktadır. Gelişiminin odak noktası, yazılım geliştiricileri ve sistem yöneticileri için kullanılabilir açık kaynak araçları oluştururken, kullanıcı dostu bir masaüstü ve zengin özelliklere sahip sunucu ortamı sağlamaktır. 10 yılı aşkın süredir aktif ve geliştirilen bir Linux dağıtımı olan openSUSE, açık kaynak ve Linux dünyasına birçok yenilik getirmiş ve destek olmuştur.

openSUSE Leap 15.0 Sistem Gereksinimleri

https://software.opensuse.org/distributions/leap

https://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64.iso

DVD kurulum dosyasını indirebilirsiniz.

Kurulum:

Kuruluma başlamak için "Installation" seçip Enter'a basınız.

Kurulum dil ayarı ve klavye yapılandırmasını İngilizce (A.B.D) / İngilizce (A.B.D) olarak devam etmek için "Next"'e basınız. Eğer farklı bir dil yapılandırmak istiyorsanız ilgili dili seçebilirsiniz.

openSUSE Server olarak yapılandırmak için "Server" seçip "Next"'e basınız.

Otomatik disk yapılandırmasını kabul ederek devam etmek için "Next"'e basınız.

Saat dilimi yapılandırmasını Türkiye olarak belirlemek için "Europe" ve "Turkey" seçerek "Next"'e basınız.

Kullanıcı tanımla işlemini tamamlayıp "Next"'e basınız. Tanımladığınız kullanıcının sistem yöneticisi haklarına sahip olması için "Use this password for system administrator" seçeneğini aktif etmeyi unutmayınız.

"Installation Settings" Ekranında kuruluma geçmeden önce tüm yapılandırmaları gözden geçirebilirsiniz.

"Firewall and SSH" Ekranında ssh servisinin sistem ön yükleme sürecinde başlatılmasını istiyorsanız "Enable SSH Service"’i seçerek "OK"'e basınız.

“Installation Settings" Ekranında kuruluma başlamak için "Install"'a basınız.

Kurulumu onaylayıp devam etmek için "Install"'a basınız.  

Verdiğimiz onayın ardından kurulum başladı.

Kurulum sırasında belirtiğiniz kullanıcı bilgileriyle sisteme giriş yapabilirsiniz.  

Kurulum esnasında openSUSE tüm ağ yapılandırmasını ön tanımlı olarak DHCP üzerinden yapılandırmıştır. Kendi ağ topolojinize göre yapılandırmak için

/etc/sysconfig/network/configs

/etc/sysconfig/network/ifcfg-eth0

/etc/resolc.conf

Dosyalarını düzenlemeniz gerekmektedir.

Eğer elle düzenlemek istemiyorsanız yast komutu aracılığıyla YaST Control Center üzerinden System / Network Settings erkanından kendi ağ topolojinize göre yapılandırma yapabilirsiniz.  

Sisteminizin gerekli güncellemelerini zypper update komutuyla yapabilirsiniz.

Sisteminize ssh servisi üzerinden erişim sağlamak için ilgili servisi başlatmanız gerekmektedir. Servis durum kontrolü için systemctl status sshd kullanabilirsiniz.

Eğer ssh servisi çalışmıyorsa ve sistem önyükleme süresinde etkinleştirilmemiş ise;

systemctl enable sshd              ile ssh servisi sistem önyükleme süresinde etkinleştirilir.

systemctl start sshd                 ile ssh servisi başlatılır.

systemctl status sshd               ile ssh servis durum bilgileri görüntülenebilir.

Sisteminize ssh servisi üzerinden erişim sağlayabilirsiniz.

Makalemin sonuna geldik, umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.