Office 365 için ADFS 3.0 ile Single Sign On – Part 7

ADFS kurulumunun tamamlanmasının ardından ADFS Proxy’nin konfigürasyonu yapılacaktır. Bunun için Server Manager’da bayrak ikonunun altında yer alan ünlem işaretine tıklanarak “Open the Web Application Proxy Wizard” seçeneği ile devam edilir.


“Welcome” başlığı altında Web Application Proxy’e ait özet bilgi yer alır. “Next” seçeneği ile devam edilir.


“Federation Server” bölümünde ADFS Proxy’e ADFS sunucunun bilgileri girilmelidir. Burada ADFS servis adı ve ADFS sunucularında lokal administrator yetkisine sahip kullanıcı bilgisini girilecektir.


ADFS Proxy konfigğrasyonu için public bir sertifikaya ihtiyaç vardır. Bunun için ADFS sunucusunda kullanılan sertifika kullanılabilineceği gibi farklı public sertifika da gösterilebilinmektedir. Buradaki sertifikanın adına public DNS’e kayıt açılması gerekmektedir.


Yapılan işlemlere dair Powershell’de kullanılabilecek komut arayüzde görülmektedir. “Configure” ile devam edilmelidir.


Konfigürasyonun başarılı şekilde tamamlanmasının ardından “Close” seçeneği ile devam edilir.


ADFS Proxy işleminin sağlıklı çalıştığına dair kontrol Remote Access Management Konsolundan sağlanabilmektedir.


Gerekli konfigürasyonun tamamlanmasının ardından public DNS’e ADFS Proxy’i point edecek kayıtın girilmesi sağlanacaktır.


Konfigürasyonların tamamlanmasının ardından şirket dışındaki networkten Office 365 portalına girilmesi sağlanacaktır. Office 365 otomatik olarak kullanıcıların hesap bilgilerini girecekleri ekrana yönlendirilmesi sağlanır ve ADFS’e ait web form açılacaktır. Kullanıcılar gerekli bilgileri de girdikten sonra Office 365 portalına giriş sağlayabileceklerdir.




Yapılan yönlendirmeyi gözlemleyebilmek için Office 365 portalına girdikten sonra F12 tuşuna basılır ve kullanıcı hesabını girdikten sonraki yönlendirmeler şekilde de görüldüğü üzere web sitesinin altından gözlemlenebilecektir.


Böylelikle ADFS 3.0 ile Office 365 platformlarında Single Sign On yapısı kurgulanmıştır.

 

Office 365 Exchange Online Distribution Group

Exchange Admin Center’daki “Groups” bölümünde mail atmakta kullanılacak olan grupların tanımlanması yapılır. Burada 3 çeşit grup vardır. Bunlar “Distribution group”, “Security group” ve “Dynamic distribution group”tur. Her grubun kendi özel yapabilirlikleri vardır. “Distribution group” mail atmakta kullanılırken “Security group” hem mail hem de hak atamasında kullanılmaktadır. “Dynamic Distribution Group” ise kullanıcıların özelliklerine göre grup üyelerini belirleyen grup çeşididir. Haliyle her grubun ortak buluştuğu özellikleri var iken farklı özelliklere de sahiptirler. Şekildeki arayüzde grupların oluşturulması, ayarları ile ilgili değişikliklerin yapılması, silinmesi, grupların özelliklerine göre export edilmesi gibi işlemler gerçekleştirilir.


Distribution Group ve Özellikleri

“Distribution Group” mail atmak için kullanılan gruptur. Bu gruba ait üyeler Office 365 yönetici tarafından belirlenmeli ve eklenmelidir. Exchange Admin Center’daki “Groups” başlığı altından oluşturulur. “+” işaretine tıklanarak grup çeşitlerinden “Distribution Group” seçeneği ile devam edildiğinde yeni grubun oluşturulma işlemi gerçekleştirilir. Yeni distribution group oluşturulurken girilmesi gereken bazı parametreler şekildeki gibidir. Grup ismi, alias bilgisi, email adresi, açıklama bölümü, owner bilgisi girilmelidir. Burada girilmesi gereken bölümler * ile gösterilmiştir.


Yeni distribution group’un oluşturulurken yukarıdaki verilerin girilmesi dışında şekildeki özelliklerde konfigüre edilebilmektedir. Burada “Members” başlığı altında grup üyelerinin belirlenirken, “Add group owners as a members” ile grup sahibinin de grup üyesi yapılacağına dair ayar yapılır. “+” işareti ile yeni üyelerin eklenmesi sağlanır. “Choose whether owner approval is required to join the group” bölümünde belirlenen gruba üye eklenmesi durumunda grup sahibinin onayından geçip geçmeyeceği ile ilgili ayar yapılır. “Open” seçeneğinin işaretlenmesi ile herhangi bir onay mekanizmasından geçmeden gruba kullanıcıların üye olabilmeleri sağlanırken, “Closed” seçeneği ile grup sahipleri tarafından grup üyelerinin eklenebileceği ve “Owner approval” seçeneği ile de üye olmak adına gelen tüm taleplerin grup sahipleri tarafından kabul ya da iptal edileceğine ilişkin konfigürasyonlar yapılır. “Choose whether the group is open to leave” ile de gruptan çıkmak isteyen grup üyelerine ilişkin ayarlar yapılır. “Open” seçeneği ile grup sahipleri tarafından herhangi onay mekanizması olmadan üyelerin ayrılabileceğine dair izin veilir. “Closed” seçeneği ile de üyeler sadece grup sahipleri tarafından ilgili gruptan çıkarılabilineceğine ilişkin ayar yapılır.


Oluşturulan distribution gruba dair detaylı ayarlar yapmak için ilgili gruba çift tıklanır ya da ilgili grubun üstüne gelinerek Exchange Admin Center’daki “Groups” başlığındaki kalem ikonuna tıklanmalıdır. Gerekli aksiyonun alınmasından sonra şekildeki arayüz kullanıcıyı karşılamaktadır. Burada sol bölümdeki başlıkların herbirinde çeşitli ayarlar yer almaktadır. “General” bölümünde distribution grubun oluşturulması sırasında girilen isim,alias ve email adres gibi bilgiler görülmektedir. İstenildiği takdirde bu bilgiler düzenlenebilir. “Hide this group from address lists” ise bu grubun adres listesinden gizlenmesidir. Böylelikle adres defterinde herhangi bir arama yapıldığı zaman bu email adresini göremeyeceklerdir.


“Ownership” başlığında distribution grubuna sahiplik yapacak hesap bilgisi girilmelidir. Varsayılanda grubu oluşturan kullanıcı grubun sahibidir. Sahibi demek, ilgili grup ile ilgili her türlü ayarı yapabilmektir.


“Membership” başlığında ise grup üyeleri belirlenir. Varsayılanda grup sahibi grup üyesi iken, yeni üyenin eklenme işlemi “+” işareti ile kullanıcıların seçilmesi ile gerçekleşir. “-” işareti ile kullanıcıların gruptan çıkarılmasına ilişkin konfigürasyon yapılır.


“membership approval” ile distribution grubun oluşturulması sırasında da anlatıldığı üzere gruba yeni üyenin eklenmesi ya da var olan üyenin gruptan çıkarılma işlemi onay mekanizması ile gerçekleştirilebilir ya da grup sahipleri tarafından bu işlemlerin gerçekleştirileceğine ilişkindir. Yeni oluşturulan distribution grup sırasında yapılan bu konfigürasyon sonradan değiştirilmek istenildiğinde şekildeki arayüzdeki seçenekler ile gerçekleştirilecektir.


“Delivery management” arayüzünde ilgili grubun şirket içi ve şirket dışından mail alabileceğine dair ayar yapılır. Hatta sadece belirli kullanıcılardan mail alması sağlanabilir. “Only senders inside my organization” seçeneğinin seçilmesi ile ilgili grubun sadece şirket içerisinden mail alması sağlanır. “Senders inside and outside of my organization” bölümünde ise şirket içinden ve şirket dışı mail adreslerinden mail almasına izin verilir. “+” işaretine tıklanarak belirli kullanıcıların ya da mail hesaplarının belirlenmesi ile grubunun burada belirlenen mail hesaplarından mail alması sağlanabilir. Böylelikle kullanıcı bazlı kısıtlama yapılmış olunur.


“Message Approval” bölümü gruba atılan mailler için moderatorün belirlendiği arayüzdür. Buradaki moderatorün rolü gruba gelen maillerin burada belirlenen kullanıcı ya da kullanıcıların onayından geçtikten sonra grup üyelerine iletilmesinin sağlanmasıdır. Önce bu özelliğin etkinleştirilmesi için “Messages sent to this group have to be approved by a moderator”ün seçilmesi gerekir. Bu özelliğin aktif edilmesinden sonra “Groups moderators” başlığı altından moderator kullanıcıların seçimi yapılır. “Senders who don’t require message approval” başlığı altında seçilen kullanıcıların gruba mail atmaları durumunda herhangi onay mekanizmasına takılmadan direkt mail atmaları sağlanabilir. Böylelikle moderator onayından bazı kişilerin hariç tutulması da sağlanmış olunur. Örneğin satış grubuna gelen mailler satış müdürünün onayından geçsin ancak kendi attıkları ve genel müdürlerin attıkları mailler onay mekanizamasından geçmeden direkt iletilsin gibi.


“email options” seçeneğinde ise distribution grubunun mail atarken kullanacağı SMTP adresi yer alacaktır. Burada alt SMTP adresleri de oluştutulabilir. Böylelikle bu SMTP adreslerine gelen mailleri grup alacaktır ama bu SMTP adresinden mail atamayacaktır. Mail atacağı SMTP adresi için mail adresinin oluşturulması sırasında “Make this the reply address seçeneğinin seçilmesi gerekmektedir.” Daha sonradan da mail atacağı SMTP adresinin değiştirilmesi söz konusudur.


“MailTip” bölümünde gruba mail atacak kullanıcılar için not amaçlı uyarı metninin girilir. Böylelikle gereksiz ya da gönderilmemesi gereken maillerinde bu uyarı ile kullanıcıları uyararak önüne geçilmiş olunacaktır. Buradaki arayüze maksimum 175 karakter metin girilebilir.


“group delegation” başlığı altında “Send As” ve “Send On Behalf” seçenekleri yer almaktadır. Bu iki seçenekteki temel amaç grup üzerinde delegasyon işleminin yapılmasıdır. “Send As” bölümünde belirli kullanıcılara bu gruba ait mail adresinden mail atma yetkisinin verilir. Böylelikle bu maili alan kullanıcılar bu gruptan mailin geldiğini göreceklerdir. Örneğin IK distribution grubuna ait mail adresi üzerinde “Send As” yetkisi “A” kullanıcısına verilmesi durumunda “A” kullanıcı IK mail adresinden mail atabilecek ancak maili alan kullanıcılar bunun IK mail adresinden geldiğini görebileceklerdir. “Send on Behalf” ise belirli kullanıcıların bu grup adına mail atmalarına izin verilmesidir. Ancak burada kimin bu grup adına mail attığı maili alan kişiler tarafından gözlemlenecektir.


Sway Uygulaması & Kullanıcı Bazlı Lisanslama & Yönetici Kontrolü

Agustos ayında GA (generally available) olan Sway uygulaması gerek iş gerekse de eğitim kanallarında dünya genelinde kullanılmaya başlandı. Microsoft tarafından birçok müşteri feedbackleri toplandı ve gelen feedbackler doğrultusunda ise Sway uygulamasına dair yetenekler arttırılmaya başlanıldı. Dijital ortamda online sunumlar hazırlanmasına ve gerek sosyal medyadan içerik kullanma gerekse de hazırlanan sunumların sosyal medyalarda yayınlamasını sağlayan Sway uygulamasına bir yetenek daha kazanıldı. Artık Sway uygulaması yöneticiler tarafından belirli çerçevelerde yönetilebilecek, kullanıcı bazında lisans ataması yapılarak kullanılabilecektir.

Sway ve Kullanıcı Bazlı Lisanslama

Sway uygulaması artık kullanıcı bazlı lisanslama modeline geçmiştir. Office 365 yöneticileri tarafından kullanıcılara Sway lisansları atanarak kullanılabilecektir. Böylelikle organizasyon bazlı olması dışında kuruluşlara daha fazla kontrol imkanı da sağlamaktadır. Bu sayede tüm kullanıcılarda açmak yerine pilot kullanıcılarda aktif edilip kullanılabilecektir. Örneğin firmadaki belirli kullanıcılarda açılıp onların tüm testleri yapmasından sonra organizyondaki diğer kullanıcıların kullanımına açılabilir. Sway uygulaması pasif olan kullanıcılar Office 365 App switcher ya da ana sayfada Sway uygulamasını görüntülemeyeceklerdir. Lisans atanan kullanıcılar ise uygulamaların olduğu bölümde ve ana sayfa da görebilecek ve Sway ile sunumlarını hazırlayabileceklerdir. Lisans atama işlemi Office 365 Admin panelinden yapılabileceği gibi Powershell komutları ile de yapılabilmektedir.

Eskiden tenant bazında Sway uygulaması atanan firmalarda otomatik olarak kullanıcı bazlı lisanslama modeline geçebileceklerilerdir. Sway lisanslarını yönetmek için ilgili kullanıcının üzerine gelinir ve “Edit” sekmesine tıklanır.


Edit sekmesinden sonra ilgili kullanıcı ile ilgili ayarların yer aldığı pencere açılacaktır. Burada “Licenses” sekmesine gelinir ve atanan lisansa tıklanarak detaylarının görüntülenmesi sağlanır. Şekilde de görüldüğü üzere E3 lisansının altındaki detaylar yani servisler gözlemlendiğinde Sway sekmesinin aktif ya da pasif edildiği kutucuk bulunur. Böylelikle Sway uygulaması kullanacak ya da kullanmayacak kullanıcılar kullanıcı bazlı lisanslama ile Office 365 Admin panelinden yönetilebilecektir.


Sway Ekle (Insert) Sekmesinin Yönetimi

Sway uygulamasının en önemli özelliklerinden biri de 3rd party uygulamalardan içeriklerin sunumlara eklenmesidir. Bunun için kullanıcılar Sway uygulamasında Ekle (Insert) sekmesine gelir işgili 3rd party uygulamalarına ait seçenekleri gözlemler. Şekilde de görüldüğü üzere burada OneDrive, Flickr, Bing, PicHit, YouTube, Twitter gibi seçenekler yer almaktadır. Böylelikle kullanıcılar bu uygulamalara bağlanarak buradaki içerikleri Sway sunumlarında kullanabileceklerdir.


Artık Sway uygulamasındaki “Ekle” sekmesindeki seçeneklerin kontrolü Office 365 Admin’leri tarafından yönetilebilmektedir. Organizasyon bazında ilgili 3rd party uygulamanın aktif ya da pasif edilmesi Office 365 Admin panelindeki “Service Settings” bmlümündeki “Sway” sekmesinden yapılır. “Add Content Sources” başlığında ilgili 3rd party uygulamalar görünmektedir. Bunlar Sway uygulamasının “Ekle” sekmesindeki uygulamalar olup, aktif ya da pasif edilme işlemi yandaki scroll sayesinde sağlanmaktadır.


Sway Uygulaması ve Health Dashboard

Office 365 uygulamasının kullanıcılara sunduğu hizmetlerin durumları “Service Health” bölümünden gözlemlenmektedir. Bu başlık altında Office 365 hizmetlerinin sağlıklı durumda olup olmadığında bilgi alınmaktadır. Hizmetlere ait sorunların olması durumunda ise gerekli detaylara erişime yine bu bölümden erişilebilinmektedir. Artık Sway uygulamasına ait durum bilgisine bu bölümden erişilebilinmektedir. Tarih bazlı uygulamanın sağlıklı çalışıp çalışmadığı ya da Microsoft mühendisleri tarafından çalışmanın olup olmadığı gibi bilgiler gözlemlenebilir. Böylelikle Sway uygulamasına ait servis raporlarına erişilecektir.


Office 365 için ADFS 3.0 ile Single Sign On – Part 6

ADFS Proxy Konfigürasyonu

Şirket içerisinde ADFS’e dair konfigürasyonun tamamlanmasının ardından, şirketin networkü dışında public networkten bağlanacak kullanıcıların ADFS ile kimlik doğrulamasından geçmesi için ADFS Proxy’nin konfigüre edilmesi gerekmektedir. Gerek güvenlik gerekse de sağlıklı SSO topolojisi için ADFS proxy’nin konumlandırılması gerekmektedir. Faiover senaryolara karşında en az 2 tane NLB ile konumlandırılması gerekmektedir. ADFS Proxy sunucuları firmalarda DMZ networklere konumlandırılır ve domaine join edilmezler. Ancak ADFS sunucu ile görüşebilmeleri için isim çözümlemesi yapması gerekmektedir. Haliyle DNS olarak lokaldeki DNS sunucusu bilgisinin girilmesinin yanında ya DNS suffix eklenmeli ya da host dosyasına ADFS sunucusuna erişirken kullanılan ismin adı ve IP adresi girilmelidir. Bu işlem ADFS Proxy konfigürasyonu sırasında ADFS servisini belirildiği için gereklidir.


Windows Server 2012 R2 ile ADFS Proxy kurulumu için Web Application Proxy ile sağlanmaktadır. Kurulum yapmak için ADFS Proxy sunucusunda Server Manager açılarak “Add Roles and Features” ile devam edilecektir.


Şekildeki arayüz bu wizardın kullanımına dair detayları gösterir. “Skip this page by default” seçeneği seçilerek bir dahaki rol ya da özelliğin kurulumunda bu arayüzün atlanılması sağlanacaktır.


“Select destination server” başlığı altında ise “Select a server from the server pool” seçeneği ile kurulum yapılacak sunucunun server manager havuzunda bulunan sunuculardan seçilmesi gerçekleştirilecektir.


“Select Server Roles” bölümünde “Remote Access” seçilmelidir. ADFS Proxy için gerekli olan “Web Application Proxy” bu başlık altında yer almaktadır.


“Features” başlığında ise sunucu rolleri dışında istenilen özelliğinde kurulması sağlanabilir. “Next” ile devam edilecektir.


Şekildeki arayüzde Remote Access seçilmesi ile alt başlıklarının DirectAccess, VPN ve Web Application olduğuna ve bu başlıklara ait bilgilerin verildiği özet ekranı gözlemlenmektedir.


“Web Application Proxy” kurulumunda gerekli olan CMAk gibi bazı özelliklerin kurulması gerekmektedir. Şekildeki arayüzde “Web Application Proxy”nin işaretlenmesinin ardından gerekli olan özelliklerin kurulmasına arayüz görülmektedir. “Add Features” ile bu özelliklerin de kurulması sağlanır.


Gerekli rollerin ya da özelliklerin seçilmesinin ardından “Confirm installation selections” ile kuruluma başlanılacaktır. “Restart the destination server automatically if required” ile rolün kurulmasından sonra ihtiyaç duyulduğu takdirde makinanın yeniden başlatılma işleminin yapılacağına dair seçenek yer almaktadır. Bu seçeneğin işaretlenmesi ile makina ihtiyaç duyması halinde yeniden başlayacaktır. “Install” ile kuruluma başlanılacaktır.


Kurulumun tamanlanmasının ardından “Close” ile konfigürasyona geçilecektir.


 

Office 365 ile Office On Demad

Office 365’in şirketlere sağlamış olduğu en büyük avantajlarından birisi de Office uygulamalarını Office Enterprise E3, E4 ve midsize gibi paketlerde 5 farklı cihaza herhangi Office lisansı ödemeden kurabilmeleridir.Bunun dışında Office Online ve Office On Demand ile de dökümanları üzerinde çalışabilme imkanı sağlayacaktır. Office Online web platformunda desteklenen web browserlar ile eriim sağlayacak ve gerekli işlemlerini yapabileceklerdir. Office On Demand özelliği ise yine kullanıcıların makinalarına herhangi bir uygulama kurmadan Office uygulaması üzerinde çalışma imkanı veren bir teknolojidir.

Office On Demand Office deployement oluğ aslında geçici olarak Office uygulamalarından Word, Excel, powerpoint, Publisher, Access subscriptionlarının içerisinde varsa Project ve Visio uygulamaları üzerinde çalışma imkanı veren teknolojidir. Burada son kullanıcı geçici Office kurulumu yapıp işlemlerini bitirdikten sonra cihazında herhangi bir Office uygulaması yer almayacaktır. Böylelikle kullanıcılar istedikleri zaman Office uygulamaları cihazlarında yüklüymüş gibi çalışabilecekler ancak stabil bu Office uygulamaları cihazlarında kurulu olmayacaktır. Bu teknolojiyi kullanmak için kullanıcının herhangi yönetici yetkisine sahip olmasına gerek yoktur. Arka planda App-V teknolojisi ile çalışmaktadır. Office Pro Plus kurulumundaki gibi ClickToRun(C2R) ile kurulum yapılmaktadır fakat daha önceden de belirtildiği gibi bu kalıcı bir kurulum değildir.

Temel olarak yapılan işlem aslında kullanıcı Office 365 portalındaki Onedrive ya da Sharepoint gibi servislerde yer alan ilgili dökümanı açtıktan sonra düzenleme işlemini Word uygulamasında yapacağını belirtiyor. Fakat cihazında uygulama olmadığı için Office On Demand teknolojisi ile geçici Office uygulamasını kuruyor ve işlemlerini gerçekleştiriyor. İşlemi bittikten sonra kullanıcı cihazında herhangi office uygulaması gözlemlenmiyor. Bu teknolojide Office 2013 Pro Plus’ın cihaza yüklenme sayısının 5 olması gibi herhangi bir kısıtlama yoktur. İstenilen cihazda kolaylıkla çalışılabilinmektedir.

Sistem Gereksinimleri:

· Windows 7 veya Windowd 8 işletim sistemi

· En az Internet Explorer 9, en az Modzilla Firefox 12, en az Apple Safari 5 veya en az Google Chrome 18

· Yönetici yetkisine gerek yoktur

Şekildede görüldüğü üzere kullanıcılar ilgili dökümanlarını OneDrive ya da Sharepoint gibi servislerden erişim sağladıktan sonra, dökümanı hangi yöntem ile editleyeceğine karar vermeleri gerekmektedir. Cihazlarında Office uygulaması olması durumunda indirip üzerinde çalışabilirler. Office uygulaması yok ise şekilde görülen iki seçenek üzerinden ilerleyebilirler. Bunlardan Office Online kullanarak diğeri ise Office On Demand’dır. “Edit in Word” seçilmesi ile Office On Demand teknolojisi kullanılacaktır.


“Edit in Word” denildiği durumda makinada Office uygulaması olmadığı algılanır ve şekilde de görüldüğü üzere Office On Demand kullanılmasının herhangi Office uygulaması yüklemeden gerçekleştirilebilineceğine dair onay ekranı kullanıcıyı karşılamaktadır. “Yes,lets go!” ile devam edilerek yükleme işlemine başlanılır.


Şekildeki arayüzde browser yükleme yapacağı için kullanıcıdan onay istiyor. İster direkt “Run” denilerek kuruluma başlanabilir ya da “Save” ile kaydedilerek sonrasında kuruluma başlanılabilir.


Şekilde kullanıcı artık Office On Demand’ı kullanmaya hazır olduğuna dair bir arayüz görünmektedir.


“Close” seçeneği ile devam edilmesi durumunda ilgili Office uygulamanın hızlıca yükleme işlemi gerçekleşecektir.


Uygulanmanın yüklenmesinden sonra kullanıcı hesap bilgilerinin girileceği ve onaylanacağı “Sign in” arayüzü kullanıcıyı karşılayacaktır.


Cihaza herhangi Office uygulaması yüklenmeden Word uygulamasında dökümanın açıldığı gözlemlenmektedir. Haliyle artık Office On Demand teknolojisi ile kullanıcılar cihazlarında Office uygulamaları olmadan Word ,Excel gibi Office uygulamalarından App-V teknolojisi mantığında dökümanlarında çalışabileceklerdir.


Office 365′de EWS ile Uygulama Bazlı Yasaklama

Office 365 hizmetlerinden Exchange Online ile ilgili birçok firma güvenlik ile ilgili özel ayarlar talep etmektedirler. Bunlardan bazıları mobil cihazların yönetimi ile ilgili olup bazıları protokollerin kapatılması yönünde olmaktadır. Bu ve ya buna benzer birçok kontrol Office 365 arayüzlerinden sağlanmakta olup özel uygulamalara dair kısıtlamaların yapılması gibi senaryolarda da EWS ayarlarının değiştirilmesi söz konusudur. Böylelikle belirlenen spesifik uygulamalara Exchange Online ile ilgili kurulumlar yasaklanabilmektedir.

Temelde PowerShell komutları ile yapılan bu ayar ile ilgili varsayılanda gelen özelliklerin gözlemlenmesi için Get-OrganizationConfig komutu kullanılmalıdır. Akabinde yapılacak ayarlar için Set-OrganizationConfig komutu kullanılmaktadır. Set-OrganizationConfig komutunun çalıştırılmasının ardından EWS uygulamaları ile ilgili yasak ve izin vermek adına 2 ana parametre bulunmaktadır. Tabi bu komutlar çalıştırılmadan önce Azure Active Directory PowerShell ile Exchange Online’a bağlantı kurulması gerekmektedir. Bunun için aşağıdaki komutların çalıştırılması gerekmektedir. Bu komutlarda Exchange Online’da yetkili olan kullanıcı hesabına ihtiyaç duyulmaktadır.

$UserCredential = Get-Credential

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

Import-PSSession $Session


Aşağıdaki komut satırının çalıştırılması ile beraber EWS ile ilgili izin verilen ya da yasaklanan uygulamaların listelenmesi sağlanmaktadır. Böylelikle spesifik uygulamalar ile ilgili yasak ya da izin verilecek organizasyona ait var olan kuralların gözlemlenecektir. Şekilde de görüldüğü üzere EwsApplicationAccessPolicy ile ilgili herhangi kuralın ayarlanmadığı gözlemlenmektedir.

Get-OrganizationConfig ,ft Name,EwsApplicationAccessPolicy,EwsBlockList,EwsAllowList


Uygulamaların kısıtlama işlemi 2 farklı method ile yapılabilmektedir. Bunlardan uygulamaların hepsine yasak koymak EnforceAllowList’dekilere izin vererek olurken, diğer yöntem tüm uygulamalara izin verip EnforceBlockList’deki uygulamaları yasaklamaktır. Firmalar genellikle tüm uygulamalara izin verip yasaklanacak uygulamaları EnforceBlockList’e ekleyerek yapılandırmaktadırlar.

-EwsApplicationAccessPolicy

Yukarıda görüldüğü üzere EwsApplicationAccessPolicy parametreleri yer almaktadır. EnforceAllowList parametresi ayarlandığı durumda tüm uygulamalar yasaklanmış sadece izin listesinde yer alacak uygulamalar kullanılacaktır. Eğer EnforceBlockList parametresi ayarlanırsa her uygulamaya izin verilmiş BlockList’te yer alanlara yasak konulmuş olunacaktır. Burada tanımlanacak uygulamalar Entourage, Mac Outlook ve Outlook dışında olmalıdır.

Sadece belirli uygulamanın yasaklanacağı senaryoda aşağıdaki komut dizini kullanılmalıdır. Aşağıdaki komutta da gözlemlendiği üzere kullanıcılar tüm uygulamalar ile erişim sağlayabilecek iken aşağıda belirtilen uygulamaya Exchange Online ile ilgili yasak konulmuş olunacaktır.

Set-OrganizationConfig –EwsApplicationAccessPolicy:EnforceBlockList –EwsBlockList:”CloudMagic*”


EwsApplicationAccessPolicy ile uygulama bazlı Exchange online ile ilgili yasak ya da izinlerin verilmesi gibi özel ayarlamaların yapılacağı böylelikle de firmaların güvenlik tabanlı çalışmalarında firmaya özel ayarların yapılması sağlanacaktır. Buna benzer güvenlik ayarlarına dair özelleştirmeler Office 365 portallarında ya da ADFS farm mimarilerindeki claim rule’lar ile de yapılabilmektedir.

 

Office 365 için ADFS 3.0 ile Single Sign On – Part 5

ADFS kurulumunun tamamlanmasının ardından ADFS servisinin sağlıklı çalıştığına dair kontroller gerçekleştirilebilir. Bunlardan birisi federationmetadata.xml dosyasını açabilmektir. Aşağıda da görüldüğü ilgili linki girdikten sonra sağlıklı şekilde federationmetadata.xml’ine erişilir.

https://fs.lab08699.o365ready.com/federationmetadata/2007-06/federationmetadata.xml


Aynı şekilde kullanıcıların Office 365’in log in sayfasına gelip giriş yapmak istediklerinde ADFS sunucusuna yönlendireceği sayfaya dair ADFS sunucusu üzerinde kontrolü gerçekleştirilebilir. Bunun için aşağıdaki link yazılması gerekmektedir. Buradaki fs.lab08699.o365ready.com değeri konfigürasyon sırasında girilen ADFS servisinin adıdır.

https://fs.lab08699.o365ready.com /adfs/ls/idpinitiatedsignon.htm


ADFS sunucusunda gerekli konfigürasyonların yapılmasının ardından Office 365 platformuna ilgili domainin federe edildiğinin belirtilmesi ve bu domain suffixi ile gelen kullanıcıların da ADFS sunucusuna yönlendirilmesi gerektiğine dair ayarlamaların yapılması gerekmektedir.

Office 365 ile ilgili ayarların yapılması için ADFS sunucusuna Azure Active Directory Powershell Module’un yüklenmesi gerekmektedir. Bu modülün yüklenmesi için Microsoft Online Sign-In Assisrance(SIA)’nın da yüklenmesi gerekmektedir.

ADFS sunucusuna yüklenen Azure Active Directory Powershell Module ile Office 365’e bağlantı sağlanması için gerekli komutlar çalıştırılır. Bu komutlar şekilde de görülmektedir. “Get-MsolDomain” komutu ile Office 365’e tanıtılmış olan domainler gözlemlenir.


Gerekli bağlantının sağlanmasının ardından ADFS sunucusunun Office 365 için tanımlanması işlemi ve domainin federe edildiğine dair bilgi girilecektir. Böylelikle Office 365 portalına federe edilen domain ile talep geldiği zaman otomatik olarak konfigüre edilen ADFS sunucusuna erişim sağlayarak authentication işlemi gerçekleşecektir.



Gerekli ayarların yapılmasının ardından iç networkte kullanıcı hesabı ile Office 365 portalına girmak istediğinde ADFS arayüzüne yönlendirildiği gözlemlenecektir.




Bu aşamaya kadar iç network için SSO topoloji kurulmuştur. Lokal network dışında Office 365 portalına gelen talepler için ise ADFS Proxy’nin konfigüre edilmesi gerekmektedir. Burada ADFS sunucusu direkt dış networke publish de edilebilir ancak bu sağlıklı ve güvenli bir işlem olmayacaktır.

 

Office 365 Exchange Online Dynamic Distribution Group

Dynamic Distribution Group ile kullanıcıların özelliklerine göre grup üyelerinin belirlendiği grup tipidir. Örnek vermek gerekirse buradaki üyeler, kullanıcı hesaplarının eklenmesi yerine kullanıcıların sahip oldukları özelliklere göre filtrelenmesi ve grup üyesi olarak eklenmesi sağlanır. Mesela departmanı muhasebe olan kullanıcılar denildiğinde kullanıcıların özellikleri bölümündeki departman bilgisi muhasebe olarak girilen tüm kullanıcıları alacaktır. Böylelikle kullanıcıların hesap bilgilerine göre tek tek girilmesi yerine var olan özelliklerine göre üyelerin eklenmesi sağlanır. Adı da üstünde dinamik gruptur. Çünkü yeni bir kullanıcının eklenmesi sırasında burada belirtilen özellikte bir kullanıcı ise gruba otomatik olarak üye olacaktır. Aynı şey silinen kullanıcı için de geçerlidir.

“Dynamic Distribution Group”, Exchange Admin Center arayüzünde bulunan “Groups” başlığı altından oluşturulur. “+” işaretinin tıklanmasının ardından yeni dynamic distribution grubun oluşturulması için şekildeki arayüz kullanıcıları karşılamaktadır. Bu arayüzde “Dynamic Distribution Group”a ait display name, alias, açıklama veya owner bilgisi gibi veriler girilir.


Yeni Dynamic Distribution grubun oluşturulması sırasında “Members” başlığı yer almaktadır. Bu başlık ile grup üyelerinin hangi türdeki mailbox’ların olacağına ilişkin seçim yapılır. Burada “All receipent types” ile grup üyelerinin hepsinden mail alınabileceği, “Only the following receipent types” ile de resource mailbox’larından, Exchange kullanıcı mailbox’larından, external adrese sahip mail kullanıcılarından, external mail kontaktlarından, mail atabilen gruplardan herhangi biri ya da birkaç tanesinin seçilmesi ile grup üyelerinin mailbox türlerinden mail alınabilineceğine dair ayarlar yapılır. “Membership in this group will be determined by the rules you set up below” seçeneği ile de grup üyelerinin için kullanılacak kural belirlenir.


“Membership in this group will be determined by the rules you set up below” başlığında yer alan “Add a rule” butonu tıklandığı durumda filtreleme yapılacak özelliğin seçilmesi ve bu özelliğin alacağı değerin girilecektir. Örneğin “Company” özelliğinin seçilmesinin ardından, şirket bilgisinin ne olacağı verisi girilir. Böylelikle aslında grup üyelerinin kim olacapı da belirlenmiş olunur. Company bilgisi burada girilen veriye eşit olan tüm kullanıcılar grubun üyesi olacaktır.


Oluşturulan dynamic Grup ile detaylı konfigürasyon ayarları ilgili grubun üstüne çift tıklanarak ya da Exchange Admin Center’daki “Groups” başlığı altında yer alan kalem ikonu ile yapılabilinecektir. “general” başlığı altında gruba ait display name, alias, açıklama ve “Hide this group from address lists” başlıkları yer almaktadır. Bu değerlerin bazıları grubun oluşturulması sırasında girilir.


“Owner” başlığı altında grub sahipliği yetkisi verilecek kullanıcının seçilir. Burada “browse” seçeneği ile ilgili kullanıcı bilgisi değiştirilebilir.


“Membership” başlığı altından grubun oluşturulması sırasında grup üyelerine dair ayarların yapılır. Burada grup üyesi olabilecek mailbox’lar ve bu mailbox’ların sahip olması gereken özellik ya da özellikler belirlenir.


“Delivery management” arayüzünde ilgili grubun şirket içi ve şirket dışından mail alabileceğine dair ayar yapılır. Hatta sadece belirli kullanıcılardan mail alması sağlanabilir. “Only senders inside my organization” seçeneğinin seçilmesi ile ilgili grubun sadece şirket içerisinden mail alması sağlanır. “Senders inside and outside of my organization” bölümünde ise şirket içinden ve şirket dışı mail adreslerinden mail almasına izin verilir. “+” işaretine tıklanarak belirli kullanıcıların ya da mail hesaplarının belirlenmesi ile grubunun burada belirlenen mail hesaplarından mail alması sağlanabilir. Böylelikle kullanıcı bazlı kısıtlama yapılmış olunur.


“Message Approval” bölümü gruba atılan mailler için moderatorün belirlendiği arayüzdür. Buradaki moderatorün rolü gruba gelen maillerin burada belirlenen kullanıcı ya da kullanıcıların onayından geçtikten sonra grup üyelerine iletilmesinin sağlanmasıdır. Önce bu özelliğin etkinleştirilmesi için “Messages sent to this group have to be approved by a moderator”ün seçilmesi gerekir. Bu özelliğin aktif edilmesinden sonra “Groups moderators” başlığı altından moderator kullanıcıların seçimi yapılır. “Senders who don’t require message approval” başlığı altında seçilen kullanıcıların gruba mail atmaları durumunda herhangi onay mekanizmasına takılmadan direkt mail atmaları sağlanabilir. Böylelikle moderator onayından bazı kişilerin hariç tutulması da sağlanmış olunur.


“email options” seçeneğinde ise dynamic distribution grubunun mail atarken kullanacağı SMTP adresi yer alacaktır. Burada alt SMTP adresleri de oluştutulabilir. Böylelikle bu SMTP adreslerine gelen mailleri grup alacaktır ama bu SMTP adresinden mail atamayacaktır. Mail atacağı SMTP adresi için mail adresinin oluşturulması sırasında “Make this the reply address seçeneğinin seçilmesi gerekmektedir.” Daha sonradan da mail atacağı SMTP adresinin değiştirilmesi söz konusudur.


“MailTip” bölümünde gruba mail atacak kullanıcılar için not amaçlı uyarı metninin girilir. Böylelikle gereksiz ya da gönderilmemesi gereken maillerinde bu uyarı ile kullanıcıları uyararak önüne geçilmiş olunacaktır. Buradaki arayüze maksimum 175 karakter metin girilebilir.


“group delegation” başlığı altında “Send As” ve “Send On Behalf” seçenekleri yer almaktadır. Bu iki seçenekteki temel amaç grup üzerinde delegasyon işleminin yapılmasıdır. “Send As” bölümünde belirli kullanıcılara bu gruba ait mail adresinden mail atma yetkisinin verilir. Böylelikle bu maili alan kullanıcılar bu gruptan mailin geldiğini göreceklerdir. Örneğin IK dynamic distribution grubuna ait mail adresi üzerinde “Send As” yetkisi “A” kullanıcısına verilmesi durumunda “A” kullanıcı IK mail adresinden mail atabilecek ancak maili alan kullanıcılar bunun IK mail adresinden geldiğini görebileceklerdir. “Send on Behalf” ise belirli kullanıcıların bu grup adına mail atmalarına izin verilmesidir. Ancak burada kimin bu grup adına mail attığı maili alan kişiler tarafından gözlemlenecektir.


 

Microsoft Office 365 Support and Recovery Assistant (SaRA)

Office 365 alt yapısına geçen firmalarda alt yapıları, performans ya da son kullanıcı ile ilgili karşılaşılan hatalara karşı sorun kaynağını bulmaya odaklı olarak çeşitli toollar bulunmaktadır. Bu tool’ların temel amacı root analizler yaparak sorun kaynağını tespit etmek akabinde de bunların loglanması ve de çözümler üretilmesidir. Bu tool’lar sayesinde IT çalışanları sorunlara çözümleri hızlıca bulabilecek ve aksiyon alabileceklerdir.

Microsoft Office 365 Support and Recovery Assistant(SaRA), Outlook tarafında son kullanıcı tarafında sorunlara dair analizler yapmaktadır. Böylelikle Office 365 kullanıcılarının bilgisayarlarına kurulan Microsoft Office 365 Support and Recovery Assistant ile yaşanan Outlook sorunlarının tespitinde ve çözümlerinde hızlıca aksiyon alınabilir hale gelmiştir.

Bu tool’un kullanımı için sistem gereksinimleri aşağıdaki gibidir:

  • Platform: x86 veya x64
  • Desteklenen İşletim Sistemleri: Windows 8.1, Windows 8, Windows 7 ServicePack 1 (SP1), Windows Vista Service Pack 2 (SP2)
  • .NET Framework 4.5
  • Microsoft Office: Office 2013,Office 2010, Office 2007 Service Pack 3 (SP3)

Kurulumu ve kullanımı kolay olan SaRA aracını indirmek için linke tıklamanız yeterli olacaktır. İndirilen SetupM.exe dosyasını çalıştırarak kurulum yapılabilmektedir.
Şekilde de görüldüğü üzere “Çalıştır” ile devam edildiğinde son kullanıcıya uygulama hakkında bilgiler sunan arayüz gelmektedir. Bu arayüzdeki “Install” seçeneği ile devam edildiği takdirde kuruluma başlanılacaktır.

Kurulma ait dosyaların indirilmesi ve kurulmasının ardından Microsoft’un sözleşmesinin yer aldığı bir arayüz kullanıcıları karşılayacaktır. ” I Agree” seçeneği ile devam edildiği takdirde lisans ile ilgili sözleşmeye izin verilmiş olacaktır.

Şekilde de görüldüğü üzere Microsoft Office 365 Support and Recovery Assistant hakkında genel bilgilendirme ekranı yer almaktadır. Outlook hesapları, Outlook bağlantısı, paylaşılan mail kutuları ve mobil cihaz bağlantısını kontrolü gibi analizler yapıp var olan sorunları monitor etmek ve çözümler bulmaya yaradığına dair bilgilerin yer aldığı arayüz yer almaktadır. “Start” ile gerekli mail adresi ile ilgili test işlemine başlanacaktır.

Analizlerin yapılacağı mail adresine dair bilgi şekildeki arayüzde girilmelidir. Burada kullanıcı mail adresi ve parolası gibi bilgiler girmelidir. İstenilirse yapılacak her analizde bu bilgilerin girilmemesi adına “Keep me signed in” denilerek gerekli bilgilerin tool tarafından tutulması sağlanacaktır. Bu bilgiler güvenli ortamda saklanmakta olup bunun ile ilgili güvenlik detaylarına ait bilgilere “Privacy Statement” bölümünden erişilebilir. “Next” seçeneği ile devam edilecektir.

Yaşanılan problemin Outlook ya da Mobil Cihazlar ile ilgili mi seçiminin yapıldığı arayüz aşağıdaki gibidir. Yaşanılan sıkıntı Outlook mail dosyaları ya da farklı Outlook öğeleri ile ilgili ise “Outlook” seçeneği, yapılacak analiz  mobil cihazdaki mail hesabı ile ilgili ise “Mobil Device” seçeneği seçilmelidir. Buradaki örnekte Outlook ile ilgili analiz yapılacağı için “Outlook” seçeneği ile devam edilecektir.

Problemin kaynağına dair seçeneklerin yer aldığı “Select the problem you have” bölümüdür. Sorun kullanıcı hesabının Outlook uygulamasına kurulmaması ile ilgili ise “I can’t set up Outlook with my Office 365 account”, kullanıcıya ait parola bilgisinin Outlook uygulaması tarafından devamlı sorulması durumunda “My Outlook keeps asking for password”, Outlook uygulamasının devamlı “trying to connect…” ve ya “disconnected” göstermesi durumunda “Outlook shows “trying to connect…” or “disconnected””, paylaşılan mail kutusu ile ilgili ise “I’m having problems with shared mailbox”, paylaşılan takvim ile ilgili ise “I’m having problems with shared calendars” seçenekleri ile devam edilmelidir.  İstenilirse “Watch our how-to videos” ile video izlenerek bilgi de alınabilir. Aynı zamanda sorun yukarıda belirtilen seçenekler ile ilgili olmaması durumunda “My problem isn’t listed here” ile devam edilecektir. Örnekte kullanıcı hesabının Outlook uygulamasına kurulmaması ile ilgili seçenek seçilecektir.

Kullanıcı hesabının Outlook uygulamasına kurulmaması durumu ile ilgili aşağıdaki arayüz kullanıcıları karşılayacaktır. Bu analizin yapılması için sorun yaşanılan bilgisayarda SaRA uygulamasının çalıştırılması gerektiği ve sorun yaşanılan cihazın tool’un çalıştırılan cihaz olup olmadığına dair soru yer almaktadır. “Yes” seçeneği ile devam edildiği takdirde gerekli analizlere başlanılacaktır.

Office 365 kullanıcı hesaplarının Outlook uygulamasına kurulması için gerekeli olan network testinden, autodiscover kaydına kadar tüm detayların kontrol edilmesinin ardından testler ile ilgili durum bilgisinin gözlemlendiği arayüz aşağıdaki gibidir. Bu arayüzde hatalı sonuç çıkmış olsaydı sorunun ne ile ilgili olduğu detayına erişmek de mümkün olacaktır. Örnekte başarılı şekilde sonuçlanan durumlar ve yapılan testlere ait özet rapor bilgisi gözlemlenmektedir. “Copy Result” seçeneği ile test sonuçları kopyalanabilir. İstenilirse örnekteki kullanıcı hesabının Outlook uygulamasında tanımlanması da SaRA tool ile yapılabilmektedir. Bunun için “Yes” seçeneği ile devam edilmesi gerekmektedir.

Şekildeki arayüzde tool ile ilgili sorunun çözümüne erişim durum seçenekleri yer almaktadır. Eğer sorun çözümlendi ise “My problem’s fixed” seçeneği, sorun çözümlenmedi ancak tool yardımcı oldu ise “My problem’s not fixed, but the tool helped” seçeneği, tool yararlı olmadı ise “The tool didn’t help at all” seçeneği seçilmelidir. Aynı zamanda yıldız ikonlarına tıklanarak memnuniyet durumu ile ilgili feedback Microsoft tarafına da iletilecektir. Ek olarak Microsoft tarafına feedback verilmek istenildiği takdirde  “Glad to hear that your problem’s fixed. Anything else you’d like to tell us” başlığının altına gerekli yorumlar yazılabilir. Microsoft’un kullanıcılar ile kontakt kurma talebini işaretleyebileceği seçenek de yer almaktadır. Gerekli bilgilerin girilmesinden sonra “Submit” seçeneği ile devam edilecektir.

Bu tool sayesinde gerek Outlook gerekse de mobil cihazlarda son kullanıcı hesaplarında yaşanılan problemlere karşın analizler yapılması ve sorunların çözümleri ile ilgili feedbackler alınabilir. Her testin kendine ait özellikleri tek tek kontrol edilip kullanıcıların bu test sonuçları ile ilgili detaylı bilgilere ulaşması söz konudur.
 

Office 365 için ADFS 3.0 ile Single Sign On – Part 4

ADFS Konfigürasyonu

Kullanıcıların senkronizasyonundan sonra ADFS yapılandırılmasına geçilecektir. Burada iç networkteki Single Sign On(SSO)yapısı için ADFS kurulumu gerçekleştirilecektir. Sağlıklı ADFS yapısı için en az ortama 2 tane ADFS sunucusu ve bunlar arasında NLB topolojisi kurulmalıdır. Buradaki lab ortamında Server 2012 R2 işletim sistemindeki Active Directory Federation Services rolü yapılandırılarak SSO sağlanacaktır. Server 2012 R2 üzerinde ADFS 3.0 yer almakta olup ADFS ile ilgili birçok yenilikler gelmiştir. Bunlar ADFS’in IIS’e bağımlılığının kaldırılması, “Single server installation” seçeneğinin kaldırılması ve farm yapısı ile ilerlenmesi, ADFS başlığı ile gelen ADFS Proxy özelliğinin ayrılması ve ADFS Proxy’nin “Web Application Proxy” olarak kurulması gibi sıralanabilir.

Office 365 ile ADFS topolojilerinde “Service Communication Certificate” için public sertifikaya ihtiyaç vardır. Bu sertifika ile Office 365, ADFS yapısına güvenecek ve SSO gerçekleştirecektir.

ADFS, Server 2012 R2’de “Server Manager”a gelinerek “Add Roles and Features Wizard” ile kurulacaktır. Şekildeki arayüz bu wizardın kullanımına dair detayları gösterir. “Skip this page by default” seçeneği seçilerek bir dahaki rol ya da özelliğin kurulumunda bu arayüzün atlanılması sağlanacaktır.


“Select destination server” başlığı altında ise “Select a server from the server pool” seçeneği ile kurulum yapılacak sunucunun server manager havuzunda bulunan sunuculardan seçilmesi gerçekleştirilecektir.


“Server Roles” başlığında ise sunucunun rollerinden “Active Directory Federation Services” seçilerek ADFS’in kurulma işlemine başlanılacaktır.


“Features” başlığında ise sunucu rolleri dışında istenilen özelliğinde kurulması sağlanabilir. “Next” ile devam edilecektir.


Şekildeki arayüzde ADFS rolüne ait bilgiler yer almaktadır. ADFS rolünün SSO topolojilerinde kullanılacağı, domaine join edilmesi gerekliliği gibi gerek ön gereksinimleri gerekse de ADFS rolünün ne işe yaradığına dair özet ekranı yer almaktadır.”Next” seçeneği ile devam edilmelidir.


Gerekli rollerin ya da özelliklerin seçilmesinin ardından “Confirm installation selections” ile kuruluma başlanılacaktır. “Restart the destination server automatically if required” ile rolün kurulmasından sonra ihtiyaç duyulduğu takdirde makinanın yeniden başlatılma işleminin yapılacağına dair seçenek yer almaktadır. Bu seçeneğin işaretlenmesi ile makina ihtiyaç duyması halinde yeniden başlayacaktır. “Install” ile kuruluma başlanılacaktır.


Gerekli kurulumun tamamlanmasından sonra ADFS’e dair konfigürasyon işlemi yapılır. Bunun için bayrak ikonundaki ünlem işaretine tıklanılarak “Configure the federation service on this server” ile devam edilmelidir.


“Welcome” başlığında Active Directory Federation Services için gereksinimlere dair bilgi yer almaktadır. Bunlar ADFS kurulumu yapılacak olan makinanın domaine join edilmesi ve public sertifikadır. “Select an option below” başlığında ise “Create the first federation server in a federation server farm” ve “Add a federation server to a federation server farm” seçenekleri yer almaktadır. “Create the first federation server in a federation server farm”seçeneği ile yeni farm ve bu farma yeni sunucu eklenmesi gerçekleşirken, “Add a federation server to a federation server farm” ile de önceden oluşturulan farm’a konfigüre edilecek ADFS’in eklenmesi gerçekleştirilir.


“Connect to Active Directory Domain Services” ile de domain administrator yetkisine sahip kullanıcı hesabının ADFS konfigürasyonu için girilmesi gerekmektedir. Hesabın girilmesinin ardından “Next” ile devam edilecektir.


“Specify Services Properties” başlığında ADFS’in ön gereksinimlerinden biri olan public sertifikanın tanımlanması gerçekleştirilir. “SSL Certificate” bölümünde önceden import edilmiş sertifikalar listelenebileceği gibi “Import” seçeneği ile ilgili sertifikanın içeriye aktarılma işlemi de gerçekleştirilecektir. “Federation Service Name” bölümünde ise ADFS için kullanılacak olan sertifikanın içerisinde yer alan isimlerden biri seçilir. Buradaki seçilecek olan servis adı ile Office 365 ile ADFS servisi arasında trust ilişkisi de kurulacaktır. Haliyle burada belirtilen isime ait DNS’e kayıt girilmesi gerekmektedir. Bu DNS kaydı da ADFS sunucusunu göstermelidir. “Federation Service Display Name” bölümünde kullanıcılar ADFS’e ait web formuna girdiklerinde görecekleri isim belirlenir. Genellikle burada Şirket isimleri girilmektedir.


“Specify Service Account” başlığında ise “Managed Service Account”a belirtilmelidir. İlgili kullanıcı bilgileri girildikten sonra “Next” seçeneği ile devam edilmelidir.


“Specify Database” bölümünde Active Directory Federation Service konfigürasyonlarına ilişkin bilgilerin tutulacağı veritabanının kurulması ki burada Windows Internal Database oluşturulacaktır ya da varolan SQL veritabanına ait bilgilerin girilmesi gerekmektedir.


Gerekli konfigürasyonların tamamlanmasının ardından istenilirse yapılan ayarlara ait scriptin gözlemlenmesi için “View Script” seçeneği ile devam edilir. Burada yapılan ayarların bulunduğu Windows Powershell scripti yer almaktadır. “Review Options” başlığında yapılan ayarlara dair özet ekranı yer almaktadır.


“Pre-requisite Checks” başlığında ise yapılan konfigürasyonlara ve ADFS’e ait ön gereksinimlerin kontrolleri yapılır. Ön gereksinimlere başarılı şekilde tamamlanmış ise “Configure” seçeneği ile devam edilerek ADFS yapılandırılması gerçekleştirilir.


ADFS kurulumu sırasında belirtlen ADFS servisine erişirken kullanılacak sertifikanın ve adının belirtildiği bölümdeki isime dair DNS’a kayıt açılması gerekmektedir. ADFS servisi iç networkteki kullanıcılara hizmet vereceği için ADFS servisinin adına dair kayıt girilmesi gerekmektedir. Bu kayıt ADFS’in IP adresini göstermeli, kayıtın adı da ADFS  konfigürasyonu sırasında gösterilen sertifikanın içerisinde yer alan isim olmalıdır.