Kategori arşivi: Active Directory

Windows 10 ve ya Server 2016 Başlat Menüsü Çalışmıyor – Start button does not work

Bu konuda aslında internet üzerinde pek çok ipucu var, muhtemel onlar işinizi görecektir fakat benim gibi kurumsal platformda danışmanlık yapan ve genellikle efsane GPO yönetimine sahip müşterilerde yeni kurduğununuz sunucularda start menüsü çalışmayabilir. Şanslı iseniz aşağıdaki gibi bir uyarı alır ve durum uyanırsınız

Bunu almıyor olsanız bile eğer makineyi domain’ e aldıktan sonra bir sorun olduğunu düşünüyorsanız muhtemel admin belki bilmeden belki de önceki sistem yöneticisi App Locker GPO yapmış olabilir. Tabiki bunu rsop.msc veya gpresult komutları ile kontrol edebilirsiniz. Çözüm ise hızlı bir şekilde aşağıdaki yapılandırmayı değiştirmek olacaktır.

Gpedit.msc yani local policy düzenleyicide aşağıdaki yola ulaşın

Computer Configuration / Policies / Windows Settings / Security Settings / Application Control Policies / Applocker

Daha sonra AppLocker üzerine sağ tıklayın ve özellikler bölümünü açın

Daha sonra yukarıdaki gibi Packaged app Rules kutucuğunu işaretleyin ve ok düğmesine basın.

Son olarak ise Packaged app Rules bölümüne sağ tıklayıp “Create Default Rules” oluşturun.

Ardından makineyi açıp kapatabilirsiniz.

Umarım faydalı bir ipucu olmuştur.

Failed to open the Group Policy object. You may not have appropriate rights

Bir Group Policy objesini düzenlemek istediğiniz zaman yukarıdaki gibi bir hata alabilirsiniz. Bu hatanın pek çok nedeni olabilir. Öncelikle alan adınızın hakanuzuner.com olduğunu varsayarsak aşağıdaki gibi alan adınıza ulaşmaya çalışın;

\\hakanuzuner.com

Normalde burada beklentimiz aşağıdaki gibi sysvol ve netlogon paylaşımlarını görmenizdir.

Not: Benim demo ortamımda DC üzerinde ek olarak iki paylaşım daha yer almaktadır.

Eğer bu noktada sistem bir hata veriyor ise öncelikle DNS konusuna yoğunlaşmanız gereklidir.

Eğer bu sayfa açılıyor ancak siz giriş yapamıyorsanız bu durumda yetki sorunu olabilir.

Varsayılan olarak paylaşım izinleri aşağıdaki gibidir;

Everyone – Read

Authenticated User – Full Control

Administrators – Full Control

Dosya izinleri ise aşağıdaki gibidir

Bu bölümdeki izinleri aşağıdaki komut ile listeleyebilirsiniz

icacls c:\windows\SYSVOL

İzinleri bu şekilde düzenlerseniz büyük ihtimal sorun çözülecektir.

Eğer sorun hala devam ediyor ise aşağıdaki komutun çıktısındaki PDC makinesinden erişmeyi deneyebilirsiniz

netdom query fsmo

Umarım faydalı bir yazı olmuştur. Bir sonraki paylaşımım da görüşmek üzere.

KRB_AP_ERR_MODIFIED Event ID 4

Domain controller üzerinde aşağıdaki gibi bir hata alıyor olabilirsiniz;

Event ID 4 — Kerberos Client Configuration

Bunun temel nedeni Kerberos protokolünün çalışma mantığındaki bir şifreleme sorunundan kaynaklıdır.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733987(v=ws.10)

Bir makine eğer domain join ise login olurken domain controller üzerinde çalışan Kerberos Key Distribution Center (KDC) servisinden ticket-granting tickets (TGTs) istemektedir. Bu kerberos ticket güvenlik amacı ile istemci makinenin hesabının domain şifresi ile şifrelenir. Bilgisayar hesapları da aynı kullanıcılar gibi birer password kullanır, fakat kullanıcılardan farkı bunu biz bilemeyiz ve varsayılan olarak 30 günde bir otomatik olarak güncellenir. Eğer bilgisayar hesabına ait bu şifre değişir ve kimlik doğrulama olmaz ise bu ticket da açılamaz.

Okumaya devam et

Windows 10 Pro Sürümü için GPO ile Lock Screen Yönetimi- Configure Windows Spotlight on the lock screen

Windows Spotlight, farklı arka plan görüntülerini görüntüleyen ve bazen kilit ekranında öneriler sunan kilit ekranı arka planı için bir seçenek olarak Windows 10 da sunulan bir özelliktir. Bu özellik tüm Windows 10 masa üstü sürümlerinde yer almaktadır.

Bazı şirketlerin iş ihtiyacı nedeni ile lock screen olarak ifade ettiğimiz işletim sistemi ekranının kilitlendiğinde ortaya çıkan bu görselleri kurumsal görseller ile değiştirmek isteyebilir. Bu durumda aşağıdaki makale ile kolaylıkla yapılabilir;

https://docs.microsoft.com/en-us/windows/configuration/windows-spotlight

Fakat bu yöntem Windows 10 Enterprise ve Windows 10 Education sürümleri için çalışan bir yöntemdir.

Aşağıdaki yolu takip edebilirsiniz;

“Computer Configuration\Administrative Templates\Control Panel\Personalization\Force a specific default lock screen and logon image”

Okumaya devam et

Active Directory Kullanılmayan Bilgisayar ve Kullanıcı Hesaplarının Silinmesi

Malum pek çok kez iş yoğunluğu nedeni ile makine ve kullanıcı hesaplarının gerçekten aktif olup olmadığını kontrol edemiyoruz. IDM gibi otomasyona yönelik sistemler ise yüksek bütçeleri ile herkes tarafından alınamayabiliyor. Yine Manage Engine, Lepide ve benzeri 3 parti pek çok üründe benzer işleri yapsa da günün sonunda kobi ve bütçesi bu tarz işler için uygun olmayan müşterilerime kolaylık olması için bir kaç komut paylaşmak istiyorum. Aslında bunu düzenli aylık yapmaları bile güvenlik sıkılaştırmaları için iyi birer adım olacaktır.

Öncelikle son X gündür aktif olmayan kullanıcıları nasıl tespit ederiz?

dsquery user -inactive 10 -limit 0 > c:\komut\stale_account_70gun.txt ( 10= hafta cinsinden yani 70 gün )

Bu bir cmd komut seti olup run-as admin ile çalıştırmanızı öneririm.

Tabiki burada disable olan kullanıcılar da gelecektir ki eğer güvenlik için bakıyorsanız çok anlamlı olmaz. Eğer temizlemek için ise ok çalıştırın ve sonra çıkan sonuçları silin.

Ancak güvenlik için bakıyorsanız aşağıdaki komut daha doğru olacaktır. Bu komut disable olan hesapları getirmeyecektir.

dsquery user -inactive 10 -limit 0 | dsget user -fn -ln -samid -disabled | find /v “dsget” | find /v “samid” | find /v “yes” >>c:\komut\stale_account_70gun.txt

Benzer şekilde bilgisayar hesapları içinde cmd komut seti kullanabilirsiniz;

dsquery computer -inactive 10 -limit 0 ( 10= hafta cinsinden yani 70 gün )

1 Soru 1 Cevap: LastLogon ve LastLogonTimeStamp

Soru: LastLogon ve LastLogonTimeStamp arasındaki fark nedir?

Cevap: Lastlogon kimlik doğrulamayı gerçekleştiren domain controller makinenin kayıt ettiği son logon olma zamanı olup bu kayıt diğer dc makineleri ile replike edilmez.

https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-lastlogon

LastLogonTimeStamp ise 14 günde bir replike olan öznitelik olup tüm dc makinelerinden bu değer okunabilir.

https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-lastlogontimestamp

Azure Active Directory Domain Services Nedir?

Active Directory Microsoft firmasının en eski ve en çok bilinen ürünlerinden birisidir. Durum böyle olunca da aslında pek çok firmada yerleşik bir dizin yapısı görmek son derece normal. Bundan dolayı da istemci makineler windows olmasa bile pek çok Microsoft uygulaması veya AD ile entegre uygulama görebiliyoruz. Zaten uygulama üreticileri de bu yaygın kullanım nedeni ile AD entegre ürünler çıkarmaktadır. Hatta uygulamaların yanında alacağınız bir firewall bile bugün AD entegre çalışıyor. Temelde kullanıcı yönetimi nerede ise aslında kullanıcı deneyimini artıracak olan en temel SSO için AD uyumu bir nevi artık endüstri Standartı olmuş durumda. Hatta ilginç bir şekilde bunun standart olmasından dolayı bugün kaleme aldığım Azure AD DS servisinin rakip bir bulut servis sağlayıcının üzerinde uzun yıllardır olması beni biraz şaşırttı doğrusu.

Peki öncelikle mevcut duruma bir bakalım. Yani yerleşik bir Active Directory yapısı olan bir müşteri bunu bulut ortamına taşımak ister ise ne yapabilir?

Öncelikle en kolay yöntem IaaS olarak Azure üzerinde bir sanal makine açıp, daha sonra yerleşik firewall ile azure veri merkezleri arasında bir VPN yapar ve bilindik Additional domain controller kurulumu yapar. Bunu hali hazırda pek çok müşteri zaten yapıyor. Temel kullanım alanları ise, öncelikle azure üzerindeki diğer servislerin yerleşik AD makinelerine gelme ve gitme sürelerinin şu an itibari ile anlık 100ms leri bulması nedeni ile olası gecikmeleri engellemektir. Ek olarak ise olası bir on prem kesintisinde azure dc makineleri felaket senaryoları için kullanıma devam edecektir.

Yukarıdaki şekil karışık mı geldi? Aslında özetle durum aşağıdaki gibidir;

Yani uzak bir şubede ADC kurmaktan hiçbir farkı yok aslında.

Peki başka bir alternatif var mı? Evet, Azure Active Directory servisini kullanabilirsiniz.

Azure Active Directory (Azure AD), Microsoft’un bulut tabanlı kimlik ve erişim yönetimi hizmetidir. Aslında yerleşik AD’ nin yaptığı temel görevleri yerine getirir. Ancak GPO gibi temel olarak yönetebileceğimiz esnek servisleri sunmaz. Burada en temel sorun aslında Windows Server Active Directory web temelli servisleri yönetmek için tasarlanmamıştır. Azure Active Directory ise, Office 365, salesforce ve benzeri REST (Representional State Transfer) API ara birimlerini kullanan web tabanlı hizmetleri desteklemek üzere tasarlanmıştır. Bu nedenle tamamen farklı protokolleri kullanır.

Buradaki amaç temel dizin ve kimlik hizmetlerini -yönetimini, uygulama erişim yönetimi, denetleme ve raporlama, multi-factor authentication, self servis şifre resetleme ve benzeri ek hizmetler ile zenginleştirmektir. Ek hizmetler dememin sebebi bulut hakkında makale yazarken başımıza çok gelen bir olay. Bugün olmayan ancak yarın iş ihtiyaçları nedeni ile sunulacak özellikler olabilir.

Herkesin kullanım motivasyonu farklılık gösterebilir. Örneğin bir IT yöneticisi için yerleşik AD yönetim araçlarına göre Azure portal sayesinde erişim kontrollerini daha görünür (raporlama ve uyarılar gibi) veya MFA sayesinde daha güvenilir yapabilirsiniz. Tabiki yerleşik sistemler için 3 parti ürünler ile MFA özelliğini kullanabilirsiniz. Ancak bu tarz ürünlerin kurulumları son derece kompleks ve maliyetleri yüksektir. Oysaki Azure Active Directory entegrasyonu sonrasında istediğiniz kullanıcılar için MFA açarak kritik hesapların güvenliğini bir üst seviyeye çekmiş oluşunuz.

Ayrıca yine kullanıcı açma ve yönetme gibi işlemlerin provizyon işlemlerini otomatize edebilirsiniz. Yine dahili güvenlik ürünleri sayesinde kimlik avı dolandırıcılığı başta olmak üzere kimlik kaynaklı ataklara karşı çok daha güvenli bir alt yapıya sahip olursunuz.

Bir yazılımcı gözünden bakarsanız;

Bir uygulama geliştiricisi olarak Azure AD, bir kullanıcının önceden var olan kimlik bilgileriyle çalışmasına izin veren standartlara dayalı bir yaklaşım sunar (SSO). Azure AD ayrıca, mevcut kurumsal verileri kullanarak kişiselleştirilmiş uygulama deneyimleri oluşturmanıza yardımcı olabilecek API’ ler sağlar.

Peki neden Azure Active Directory Kullanıyoruz?

Değişen ve gelişen teknoloji ile artık uygulamalar daha kompleks ve yaygın bir erişim ihtiyacına sahip, durum böyle olunca yerleşik ve kapalı olan dizin hizmetlerimizi internete açmak son derece tehlikeli sonuçlar doğurabilir. Durum böyle olunca aslında bu sürekli olarak gelişen iş ihtiyaçlarını karşılamak için mevcut bilgiyi bulut üzerindeki bu servis ile paylaşıp onun sunduğu yeni nesil protokol ve hizmetleri ise bu iş ihtiyaçlarına ihtiyaç duyan sistemlere güvenli ve kararlı bir şekilde sunabilirsiniz.

Peki başka ne var? Sıra geldi aslında makalemizin konusuna.

Malum PaaS kavramı hayatımıza çok fazlaca dokundu. Örneğin IIS veya Apache kurayım, onun güvenlik ayarları, temel yapılandırma ayarları, yedekleme şu bu ile uğraşacağıma bir webapp yaparım atarım buluta bitti. Veya OS kur, yamaları yükle, SQL kur, yapılandır, yedek al şu bu yerine geçerim PaaS SQL’ e oh mis gibi. Tabi şimdi soruyorsunuzdur madem bu kadar her şey güzel neden herkes geçmiyor? Klasik olarak yazdığınız veya tasarladığınız bu uygulamaları tabiki güncellemeniz gerekli. Kurumsal pek çok müşterimdeki web uygulamalarını IaaS yani klasik OS, App Server DB Server’ dan WebApp + PaaS SQL’ e çevirerek inanılmaz hız, güvenlik, kararlılık ve tabiki karlılık sağlıyoruz. Ancak bunun için şirketin bir parça danışmanlık ücreti ödemesi gerekiyor ki mevcut yazılımı PaaS sistemlerde çalışsın. Genelde Türkiye de danışmanlığa pek değer verilmediği için de kazanımdan çok danışmana verilecek para göze battığı için hala klasik mimari ile çalışan binlerce müşteri var.

Madem PaaS’ a giriş yaptık aslında herkesin sorduğu bir şey, pek çok klasik servisin PaaS modeli var, yani yönetimi, bakımı, güvenliği vs bulut sağlayıcısına ait olan bu sistemler üzerinde Active Directory Servisi yok mu? VAR

Azure Active Directory (AD) Domain Services

Peki nedir Azure Active Directory (AD) Domain Services?

Şirket içerisindeki pek çok geleneksel uygulama- Line-of-business (LOB) Active Directory dizin yapısına duyarlı uygulamalardır. Çünkü bunların sağlıklı bir şekilde çalışabilmesi için Windows ile Tümleşik bir şekilde çalışan kimlik doğrulama sevislerine (Kerberos, NTLM) ihtiyaç duymaktadır. Doğal olarak yerleşik sistemlerdeki uygulamaları buluta çıkarmak veya bulut entegrasyonu sayesinde mevcut alt yapınızın daha güvenlik, esnek, çevik olması için bu bağımlılıkları ortadan kaldırmanız gereklidir.

Hali hazırda Dünya üzerinde pek çok hybrid çalışan it alt yapısı görürsünüz. Peki bunlar nasıl başardı?

Mevcut uygulamalar genellikle müşteri veri merkezleri ile azure veri merkezleri arasında site-to-site vpn yaparak azure üzerindeki iş yüklerinin merkezi dizin hizmetlerine erişmesini sağlamaktadır. Bazen bu süreci hızlandırmak için azure üzerinde sanal makine açılır ve bu sayede bir site yapısı ile dizin hizmetleri yönetilir.

Bilinen en iyi yöntem bu olmasına karşın sanal makine, vpn, bakım, yönetim, yedekleme gibi ek maliyetler yüzünden bir alternatif arayışı içerisine girilmiştir.

Tam bu noktada Microsoft daha esnek bir alternatif sunmak için AD Domain servisini tasarlamıştır.

AD Domain servisi temel olarak yerleşik AD sistemlerinin sunduğu domain join, group policy, LDAP, Kerberos/NTLM authentication gibi özellikleri bulut üzerinde sunan bir servistir. Yani Azure Active Directory’ den farklı olarak karakteri on-prem AD servisine benzemektedir. Tek farlı bunun için aşağıdaki hiçbir sorumluluğun size ait olmayışıdır;

Sanal makine yine var ama sizin yönetiminizde değil. Yani aslında IaaS olarak bir sanal kurup, VPN yapıp onu ADC yaptığınız zaman alacağınız tecrübeyle karşı karşıyasınız (tabiki %100 o kadar esnek değil, örnek RDP yapıp DC ye bağlanamıyorsunuz).

Yama yönetimi otomatik, her zaman en güncel güvenlik ayarları ile korunur, her zaman erişilebilir, otomatik hata denetimi ve düzeltme, otomatik yedekleme ve felaket kurtarma, izlemeye ihtiyaç duymayan ve HA yapısı sunan bir servis. Bayağı alında IaaS gibi çalışan ama PaaS sorumluluklarında bir servis diyebiliriz.

Peki nasıl kullanıyoruz?

Aslında iki temel senaryomuz var

Azure AD Domain Services for cloud-only organizations

Kullanıcı, grup ve benzeri tüm kimlik yönetimi cloud üzerinde olan şirket senaryosudur. Yani bu şirketin yerleşik sistemleri yoktur. Hali hazırda Azure Active Directory kullanmaktadır.

Bu senaryoda mevcut Azure AD bilgilerini Azure AD Domain Servis ile entegre edip tüm özelliklerini yukarıdaki şekle göre Virtual network içerisindeki sanal makineler ve üzerinde çalışan servisler için kullanabilir. Yani yeni bir Azure AD Domain Servisi açıyorsunuz ancak mevcut kullanıcı ve grup bilgileri bu domain’ a mevcut Azure Active Directory içerisinden düzenli olarak replike ediliyor. Bu sayede örneğin yeni bir sanal makine açıp Azure AD Domain servisi sayesinde onu domain’ e aldıktan sonra. Mevcut kullanıcı veya gruplarınız ile remote login yapabilirsiniz.

Azure AD Domain Services for hybrid organizations

Hybrid IT alt yapılarına sahip olan kurumlar, bulut kaynakları ve şirket içi kaynaklarının karışımını kullanırlar. Bu tür kuruluşlar şirket içi dizin hizmetlerindeki bilgileri Azure AD Tenant ile eşitlerler. Bu tarz kurumlar genelde uygulamalarını orta veya uzun vadede buluta taşıyarak bulutun avantajlarından yararlanmak ister. Veya mevcut iş ihtiyaçları için gerekli olan yeni yazılım, çözüm veya bilgisayar gücü ihtiyacını bulut üzerinden karşılarken tek bir kimlik doğrulama mekanizmasını tüm bu çözümler için kesintisiz sunabilir.

Azure AD Connect şu anda bu tarz kuruluşlar için kimlik bilgilerini eşitlemek için kullanılmaktadır.

Yukarıdaki senaryoda “Litware” şirketinin azure üzerindeki sanal makineleri ve uygulamaları aynı on-prem deki gibi kimlik doğrulama ve domain hizmetine ihtiyaç duyuyor ise eğer öncelikle on-prem üzerindeki bilgiler Azure AD, daha sonra ise Azure AD Domain Services üzerinden bu isteklere cevap verecek şekilde kullanılabilir. Bir nevi yerleşik AD hizmetleri azure üzerine genişletilmiş olacaktır.

Ancak burada bazı kavram karmaşalarının da önüne geçmek gereklidir. Bu “Managed Domain” aslında stand-alone ayrı bir domaindir. Yani sizin domain için ek bir domain controller kurulması gibi değildir. Çünkü bu domain controller ve domain’ i siz değil Microsoft yönetir. Size sadece bu ara domain sayesinde on-premdeki domain ihtiyaçlarını azure ortamına yönetilen bir hizmet olarak sunar.

Yukarıdaki tanım çok önemli, yani hali hazırda zaten siz azure üzerine bir sanal makine kurup onu ADC olarak tanımlayabilirsiniz. Buradaki yapı biraz farklı. Domain’ i yeniden panel üzerinden kuruyorsunuz ancak bu managed domain oluyor ve sizin yerleşik domain üzerindeki bilgilere sahip olabiliyor ( düzenli eşitleme sayesinde).

Peki neden böyle bir yapıya ihtiyaç duyarız?

Aslında makalemin başında bu konuda çok güzel bir görsel paylaştım. Tamamen Microsoft’ un yönetiminde olan bir domain ama sizin iş ihtiyaçlarınızı karşılıyor.

Tabiki bu yapının birtakım Limitasyonları var, bunlar için mutlaka aşağıdaki linki incelemenizi tavsiye ederim;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-faqs

Peki gelelim asıl kritik noktaya.

Şirket olarak azure üzerinde bir kimlik doğrulama hizmetine ihtiyacınız var ve Azure Active Directory sizin için yeterli değil. Yani on-prem de olduğu gibi temel protokol ve iş ihtiyaçlarınız var ise iki seçeneğiniz var;

Azure Active Directory Domain Services

AD in Azure VMs – DC vm in Azure

Burada karar vermek için her iki hizmetin size neler sunduğunu karşılaştırmak gerekli;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison

Artık karar sizin. Şirketiniz için en doğru çözüme karar verebilirsiniz.

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

Kaynak;

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-overview

Azure Active Directory AAD Nedir?

Azure Active Directory (Azure AD), Microsoft’un bulut tabanlı kimlik ve erişim yönetimi hizmetidir. Aslında yerleşik AD’ nin yaptığı temel görevleri yerine getirir. Ancak GPO gibi temel olarak yönetebileceğimiz esnek servisleri sunmaz. Burada en temel sorun aslında Windows Server Active Directory web temelli servisleri yönetmek için tasarlanmamıştır. Azure Active Directory ise, Office 365, salesforce ve benzeri REST (Representional State Transfer) API ara birimlerini kullanan web tabanlı hizmetleri desteklemek üzere tasarlanmıştır. Bu nedenle tamamen farklı protokolleri kullanır.

Buradaki amaç temel dizin ve kimlik hizmetlerini -yönetimini, uygulama erişim yönetimi, denetleme ve raporlama, multi-factor authentication, self servis şifre resetleme ve benzeri ek hizmetler ile zenginleştirmektir. Ek hizmetler dememin sebebi bulut hakkında makale yazarken başımıza çok gelen bir olay. Bugün olmayan ancak yarın iş ihtiyaçları nedeni ile sunulacak özellikler olabilir.

Herkesin kullanım motivasyonu farklılık gösterebilir. Örneğin bir IT yöneticisi için yerleşik AD yönetim araçlarına göre Azure portal sayesinde erişim kontrollerini daha görünür ( raporlama ve uyarılar gibi) veya MFA sayesinde daha güvenilir yapabilirsiniz. Tabiki yerleşik sistemler için 3 parti ürünler ile MFA özelliğini kullanabilirsiniz. Ancak bu tarz ürünlerin kurulumları son derece kompleks ve maliyetleri yüksektir. Oysaki Azure Active Directory entegrasyonu sonrasında istediğiniz kullanıcılar için MFA açarak kritik hesapların güvenliğini bir üst seviyeye çekmiş oluşunuz.

Ayrıca yine kullanıcı açma ve yönetme gibi işlemlerin provizyon işlemlerini otomatize edebilirsiniz. Yine dahili güvenlik ürünleri sayesinde kimlik avı dolandırıcılığı başta olmak üzere kimlik kaynaklı ataklara karşı çok daha güvenli bir alt yapıya sahip olursunuz.

Bir yazılımcı gözünden bakarsanız;

Bir uygulama geliştiricisi olarak Azure AD, bir kullanıcının önceden var olan kimlik bilgileriyle çalışmasına izin veren standartlara dayalı bir yaklaşım sunar (SSO). Azure AD ayrıca, mevcut kurumsal verileri kullanarak kişiselleştirilmiş uygulama deneyimleri oluşturmanıza yardımcı olabilecek API’ ler sağlar.

Peki neden Azure Active Directory Kullanıyoruz?

Değişen ve gelişen teknoloji ile artık uygulamalar daha kompleks ve yaygın bir erişim ihtiyacına sahip, durum böyle olunca yerleşik ve kapalı olan dizin hizmetlerimizi internete açmak son derece tehlikeli sonuçlar doğurabilir. Durum böyle olunca aslında bu sürekli olarak gelişen iş ihtiyaçlarını karşılamak için mevcut bilgiyi bulut üzerindeki bu servis ile paylaşıp onun sunduğu yeni nesil protokol ve hizmetleri ise bu iş ihtiyaçlarına ihtiyaç duyan sistemlere güvenli ve kararlı bir şekilde sunabilirsiniz.

Daha fazla bilgi için

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis

https://www.cozumpark.com/blogs/cloud_computing/archive/2017/07/23/azure-active-directory-domain-services-bolum-1.aspx

Resim Kaynağı;

https://www.varonis.com/blog/wp-content/uploads/2017/10/difference-venn.png