active directory federation services nedir ?

AD FS – Active Directory Federation Services, kullanıcıların farklı uygulama ve organizasyonlara tek bir kimlik doğrulama süreciyle erişmesini sağlayan, claims tabanlı bir federation ve Single Sign-On çözümüdür.

AD FS özellikle şirket içerisindeki Active Directory kimliklerini web uygulamalarına, iş ortaklarına veya farklı güvenlik sınırları içerisindeki sistemlere taşımak için kullanılır.

Temel amaç kullanıcının her uygulama için ayrı bir kullanıcı hesabı ve parola kullanması yerine, kendi organizasyonundaki kimliğiyle güvenilen uygulamalara erişebilmesini sağlamaktır.

AD FS Nedir?

Active Directory Federation Services, Windows Server üzerinde çalışan bir federated identity servisidir.

AD FS, kullanıcının kimliğini doğruladıktan sonra uygulamanın anlayabileceği bir güvenlik token’ı üretir. Bu token içerisinde kullanıcının kimliği ve gerektiğinde yetkilendirme amacıyla kullanılabilecek çeşitli claim bilgileri bulunur.

Örneğin:

• kullanıcı adı,
• e-posta adresi,
• UPN,
• grup üyeliği,
• rol bilgisi

gibi bilgiler claim olarak uygulamaya gönderilebilir.

Microsoft’un claims tabanlı kimlik modelinde claim, kullanıcı hakkında yapılan bir beyan olarak düşünülebilir. Uygulama bu claim’leri kullanarak kullanıcıyı tanıyabilir ve kendi authorization kararlarını verebilir.

AD FS Neden Kullanılır?

AD FS’in klasik kullanım senaryosu farklı güvenlik sınırları arasında Single Sign-On sağlamaktır.

Örneğin kullanıcı hesaplarının contoso.com Active Directory ortamında bulunduğunu, uygulamanın ise farklı bir organizasyonda veya ayrı bir güvenlik alanında çalıştığını düşünelim.

Uygulamada ayrıca ikinci bir kullanıcı hesabı oluşturmak yerine, uygulama AD FS’e güvenebilir. Kullanıcı kendi organizasyonundaki hesabıyla kimliğini doğrular, AD FS bir security token üretir ve uygulama bu token’a güvenerek kullanıcıya erişim sağlar.

Böylece kullanıcı aynı kimliği farklı uygulama ve organizasyon sınırlarında kullanabilir.

Federation Nedir?

Federation, iki farklı güvenlik veya organizasyon sınırı arasında kimlik bilgilerinin güven ilişkisi üzerinden paylaşılmasıdır.

Burada kullanıcı hesabının diğer organizasyona kopyalanması gerekmez. Kullanıcı hesabı kendi organizasyonunda kalır ve her organizasyon kendi kimliklerini yönetmeye devam eder.

Taraflar birbirlerinin ürettiği güvenlik token’larına güvenerek kimlik bilgisini paylaşırlar.

AD FS Nasıl Çalışır?

AD FS çalışma mantığını basitleştirerek aşağıdaki şekilde düşünebiliriz:

1. Kullanıcı bir web uygulamasına erişmek ister.
2. Uygulama kullanıcıyı AD FS’e yönlendirir.
3. AD FS kullanıcının kimliğini doğrular.
4. AD FS kullanıcının kimliği ve gerekli claim’leri içeren bir security token oluşturur.
5. Token kullanıcı üzerinden uygulamaya iletilir.
6. Uygulama token’ın güvenilir bir AD FS tarafından üretildiğini doğrular.
7. Uygulama claim bilgilerine göre kullanıcıya erişim verir.

Böylece uygulama kullanıcının parolasını bilmek zorunda değildir. Uygulama AD FS’in yaptığı authentication işlemine ve ürettiği token’a güvenir.

AD FS Single Sign-On Nasıl Sağlar?

Single Sign-On – SSO, kullanıcının bir kez kimlik doğrulaması yaptıktan sonra güven ilişkisi bulunan diğer uygulamalara yeniden kullanıcı adı ve parola girmeden erişebilmesini sağlar.

Domain’e bağlı kurumsal bilgisayarlarda Integrated Windows Authentication kullanıldığında kullanıcı çoğu durumda AD FS oturum açma ekranını bile görmeden uygulamaya erişebilir.

İnternet üzerinden gelen kullanıcılarda ise kullanılan authentication yöntemi ve AD FS politikalarına göre Forms Authentication, certificate authentication veya başka yöntemler devreye girebilir.

AD FS Claims Nedir?

AD FS mimarisinin merkezinde claim kavramı bulunur.

Claim, kullanıcı hakkında bir bilgiyi temsil eder. Örneğin:

Email = hakan@contoso.com
Department = IT
Role = Administrator

gibi bilgiler application’a claim olarak gönderilebilir.

Application daha sonra bu claim’leri kullanarak authorization kararı verebilir.

Örneğin uygulama yalnızca Department = IT claim’ine sahip kullanıcılara belirli bir modülü gösterebilir.

Relying Party Trust Nedir?

AD FS üzerinde kullanıcı authentication bilgisini kabul eden uygulamalar Relying Party olarak adlandırılır.

AD FS ile uygulama arasındaki güven ilişkisi ise Relying Party Trust olarak tanımlanır.

Bu yapı içerisinde:

• uygulamanın adresi,
• identifier bilgisi,
• endpoint’ler,
• token signing sertifikası,
• claim kuralları

gibi ayarlar yapılandırılır.

AD FS ile ilgili troubleshooting çalışmalarında benim ilk baktığım alanlardan biri Relying Party Trust yapılandırmasıdır. Çünkü application URL, identifier veya claim rule tarafındaki küçük bir hata authentication başarılı olsa bile uygulamanın kullanıcıyı kabul etmemesine neden olabilir.

Claims Provider Trust Nedir?

Claims Provider Trust, AD FS’in kullanıcı kimlik bilgisini hangi identity provider üzerinden kabul edeceğini belirleyen güven ilişkisidir.

Standart bir Active Directory ortamında AD FS kendi Active Directory yapısını Claims Provider olarak kullanabilir.

Daha karmaşık federation senaryolarında başka bir AD FS, SAML identity provider veya farklı bir güvenilir kimlik sağlayıcı da Claims Provider olabilir.

AD FS Hangi Protokolleri Destekler?

AD FS yıllar içerisinde farklı federation ve modern authentication protokollerini destekleyecek şekilde gelişti.

• SAML 2.0
• WS-Federation
• OAuth 2.0
• OpenID Connect

Özellikle eski AD FS uygulamalarında WS-Federation ve SAML sık görülürken, daha modern uygulamalarda OAuth 2.0 ve OpenID Connect kullanılabilir.

AD FS Federation Server Nedir?

Federation Server, AD FS servisinin çalıştığı Windows Server sistemidir.

Bu sunucu kullanıcı authentication işlemini gerçekleştirir, claim’leri işler ve security token üretir.

Production ortamlarında tek bir AD FS sunucusu yerine genellikle birden fazla federation server kullanılarak farm yapısı oluşturulur.

Böylece hem yüksek erişilebilirlik sağlanır hem de tek bir sunucunun servis kesintisine neden olması engellenir.

Web Application Proxy Nedir?

Eski AD FS sürümlerinde dış erişim için Federation Service Proxy adı verilen ayrı bir rol kullanılıyordu.

Modern Windows Server mimarisinde bu rolün yerini Web Application Proxy – WAP aldı.

WAP genellikle perimeter network veya DMZ üzerinde konumlandırılır ve internetten gelen AD FS isteklerini iç network üzerindeki federation server’lara proxy eder.

Bu sayede AD FS sunucularını doğrudan internet üzerine yayınlamak zorunda kalmazsınız.

AD FS Authentication Akışı

Örneğin dışarıdaki bir kullanıcının şirket uygulamasına eriştiğini düşünelim:

1. Kullanıcı application URL’ine gider.
2. Application kullanıcıyı AD FS endpoint’ine yönlendirir.
3. İstek internet üzerinden geliyorsa Web Application Proxy üzerinden AD FS’e ulaşır.
4. AD FS kullanıcıyı doğrular.
5. Gerekli claim kuralları çalıştırılır.
6. AD FS security token üretir.
7. Kullanıcı token ile application’a geri yönlendirilir.
8. Application token’ı doğrular ve kullanıcıya erişim verir.

AD FS Sertifikaları

AD FS mimarisinde sertifikalar kritik öneme sahiptir.

Temel olarak üç farklı sertifika türüyle karşılaşırız:

• Service Communications Certificate
• Token-Signing Certificate
• Token-Decrypting Certificate

Service Communications sertifikası HTTPS iletişiminde kullanılır.

Token-Signing sertifikası AD FS tarafından oluşturulan token’ların imzalanmasını sağlar. Relying Party uygulamalar bu imzayı doğrulayarak token’ın gerçekten güvenilir AD FS tarafından oluşturulduğunu anlar.

Bu nedenle sertifika expiration ve rollover işlemleri AD FS operasyonunda özellikle takip edilmesi gereken konulardır.

Federation Metadata Nedir?

AD FS ve uygulamalar arasındaki güven ilişkisinin yapılandırılmasında Federation Metadata önemli bir kolaylık sağlar.

Metadata içerisinde federation service endpoint’leri, token signing certificate bilgileri ve desteklenen protokoller gibi yapılandırma bilgileri bulunur.

AD FS için standart federation metadata adresi genellikle aşağıdaki yapıdadır:

https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml

Relying Party veya diğer federation bileşenleri bu metadata üzerinden gerekli yapılandırma bilgilerini otomatik alabilir.

AD FS Kurulumu Nasıl Yapılır?

AD FS Windows Server üzerinde bir Server Role olarak kurulabilir.

Server Manager üzerinden:

Add Roles and Features
> Active Directory Federation Services

rolü yüklenebilir.

PowerShell üzerinden ise:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

komutu kullanılabilir.

Ancak rolü yüklemek tek başına yeterli değildir. Ardından federation service name, service account, SSL sertifikası ve AD FS farm yapılandırmasının yapılması gerekir.

AD FS Hâlâ Kullanılmalı mı?

Burada günümüzde önemli bir değişiklik var.

AD FS halen Windows Server 2016, 2019, 2022 ve 2025 üzerinde desteklenen bir Microsoft ürünüdür. Yani “AD FS artık çalışmıyor” veya “desteklenmiyor” demek doğru değildir.

Ancak Microsoft artık yeni identity projelerinde AD FS’i geliştirmek veya en son sürüme yükseltmek yerine mümkün olan uygulamalarda Microsoft Entra ID’ye migration yapılmasını kuvvetle öneriyor.

Bu nedenle bugün yeni bir SSO veya federation projesine başlıyorsam ilk sorum “AD FS’i nasıl kurarım?” değil, “Bu uygulama doğrudan Microsoft Entra ID ile entegre olabilir mi?” olur.

AD FS ile Microsoft Entra ID Arasındaki Fark Nedir?

Özellik	AD FS	Microsoft Entra ID
Çalışma modeli	On-premises Windows Server	Cloud identity service
Sunucu yönetimi	Müşteri yönetir	Microsoft yönetir
SSO	Destekler	Destekler
SAML	Destekler	Destekler
OAuth / OpenID Connect	Destekler	Destekler
Conditional Access	Sınırlı / farklı yaklaşım	Gelişmiş
Passwordless	Sınırlı	Modern authentication yöntemleriyle geniş destek
Altyapı işletimi	AD FS, WAP, sertifika ve HA yönetimi gerekir	Cloud managed

Microsoft Entra ID hakkında detaylı bilgi için Microsoft Entra Nedir? makaleme göz atabilirsiniz.

AD FS’ten Microsoft Entra ID’ye Geçiş

Mevcut AD FS ortamlarında geçiş işlemini tek seferde tüm uygulamaları taşıyarak yapmak zorunda değilsiniz.

Ben böyle bir projede önce mevcut Relying Party Trust’ları envantere alarak ilerlerim:

1. AD FS üzerinde yayınlanan uygulamaları listeleyin.
2. Hangi protokolü kullandıklarını belirleyin.
3. Claim rule ve özel authentication gereksinimlerini tespit edin.
4. Microsoft Entra ID tarafından doğrudan desteklenen uygulamaları belirleyin.
5. Önce basit SAML ve OpenID Connect uygulamalarını taşıyın.
6. Test kullanıcılarıyla authentication akışını doğrulayın.
7. Production geçişini aşamalı gerçekleştirin.
8. Son AD FS bağımlılığı kaldırıldıktan sonra federation altyapısını devreden çıkarın.

Microsoft’un güncel AD FS migration araçları mevcut relying party application’ları keşfedebiliyor, migration uygunluğunu değerlendirebiliyor ve bazı temel SAML ayarlarını Microsoft Entra ID tarafında otomatik oluşturabiliyor.

AD FS’ten Hemen Vazgeçmek Mümkün mü?

Her ortam için aynı cevap geçerli değil.

Özel authentication yöntemleri, karmaşık claim rule’ları, air-gapped network’ler veya Microsoft Entra ID’nin karşılamadığı özel federation senaryoları nedeniyle bazı şirketlerde AD FS kullanılmaya devam edebilir.

Bu nedenle mevcut AD FS sistemini “eski teknoloji” diyerek doğrudan kapatmak yerine uygulama bağımlılıklarını analiz edip kontrollü migration planı hazırlamak gerekir.

AD FS Troubleshooting Sırasında Neleri Kontrol Ediyorum?

AD FS authentication problemi yaşadığımda benim genel kontrol sıram şu şekilde:

1. Federation Service URL DNS üzerinden doğru resolve oluyor mu?
2. SSL sertifikası geçerli mi?
3. AD FS servisi çalışıyor mu?
4. İstek iç network’ten mi yoksa WAP üzerinden mi geliyor?
5. Relying Party Trust yapılandırması doğru mu?
6. Application identifier ve reply URL değerleri doğru mu?
7. Claim rule’lar beklenen claim’leri üretiyor mu?
8. Token-Signing sertifikası uygulama tarafından güvenilir mi?
9. AD FS Admin ve Security event loglarında hata var mı?
10. Sorun authentication tarafında mı, yoksa application authorization tarafında mı?

Özellikle son ayrım önemli. Kullanıcı AD FS üzerinde başarıyla authentication olmuş olabilir ancak uygulama gerekli claim’i alamadığı için erişimi reddedebilir. Bu durumda problem authentication değil, claim veya application authorization yapılandırmasıdır.

Özet

AD FS, Active Directory kimliklerini farklı uygulamalara ve organizasyon sınırlarına taşıyan claims tabanlı bir federation ve Single Sign-On çözümüdür.

Kullanıcı AD FS tarafından doğrulanır, gerekli claim’leri içeren bir security token oluşturulur ve uygulama bu token’a güvenerek kullanıcıya erişim sağlar.

Relying Party Trust, Claims Provider Trust, claims, certificates, federation metadata ve Web Application Proxy AD FS mimarisinin temel kavramlarıdır.

Ancak günümüzde yeni identity projelerinde AD FS’i otomatik olarak ilk seçenek kabul etmemek gerekir. Microsoft mevcut AD FS ortamlarının mümkün olan senaryolarda Microsoft Entra ID’ye taşınmasını öneriyor. Bu nedenle yeni bir uygulama için önce Entra ID entegrasyonunu değerlendirir, mevcut AD FS ortamlarında ise kontrollü bir migration planı oluştururdum.