👥 Kullanıcı Yönetimi

SecTrail CM; lokal kullanıcı yönetimi, LDAP/Active Directory entegrasyonu, RADIUS kimlik doğrulama ve OAuth/SSO desteği ile kurumsal kimlik yönetimi sağlar. Bu sayede kullanıcılarınızı kolayca yönetebilir ve kurumsal dizin ile kimlik hizmetlerinizle entegre edebilirsiniz.

Kullanıcı Türleri

SecTrail CM dört farklı kullanıcı türünü destekler:

1. Lokal Kullanıcılar

Lokal kullanıcılar, SecTrail CM'in kendi veritabanında tanımlanan ve yönetilen kullanıcılardır.

Özellikler:

• SecTrail CM içerisinde oluşturulur ve yönetilir
• Kullanıcı adı, şifre ve e-posta adresi ile tanımlanır
• Rol bazlı yetkilendirme desteği
• API erişimi için özel kullanıcı oluşturma imkanı
• API hesapları için yapay zekâ istemcilerine yönelik MCP Server token'ları

2. LDAP/Active Directory Kullanıcıları

Kurumsal Active Directory veya LDAP sunucularınızla entegre edilerek merkezi kimlik yönetimi sağlar.

Özellikler:

• Merkezi kullanıcı yönetimi
• Mevcut kurumsal kimlik bilgileriyle giriş
• Grup bazlı yetkilendirme
• Kullanıcı bazlı yetkilendirme
• Grup üyelerinin, giriş yapmalarını beklemeden otomatik senkronize edilmesi (LDAP Grup Üyesi Senkronizasyonu)

3. RADIUS Kullanıcıları

RADIUS sunucularınız üzerinden kimlik doğrulama yapılarak yönetilen kullanıcılardır. Başarılı ilk girişte SecTrail CM üzerinde otomatik olarak oluşturulurlar.

Özellikler:

• RADIUS sunucusu üzerinden merkezi kimlik doğrulama
• OTP/MFA (Access-Challenge) ile iki faktörlü doğrulama desteği
• İlk girişte otomatik kullanıcı oluşturma
• Varsayılan rol veya politika (grup attribute) bazlı rol ataması
• Sunuculara erişilemediğinde Lokal/LDAP doğrulamaya geri dönüş (fallback) seçeneği

4. OAuth Kullanıcıları

Kurumsal OAuth 2.0 / OpenID Connect (SSO) sağlayıcıları üzerinden giriş yapan kullanıcılardır.

Özellikler:

• Tek tıkla kurumsal SSO girişi
• Desteklenen sağlayıcılar: Entra ID / Microsoft, Keycloak, GitHub, Google, SecTrail MFA, Custom (OpenID Connect)
• İlk girişte otomatik kullanıcı oluşturma (Auto-create users)
• Entra ID grupları üzerinden grup bazlı rol eşleme (Microsoft Graph veya id_token groups claim)
• MFA, kimlik sağlayıcı (IdP) tarafında uygulanır

Lokal Kullanıcı Yönetimi

Yeni Kullanıcı Oluşturma

1. Users menüsünden Local Users sekmesine gidin
2. Create butonuna tıklayın
3. Add New Panel Users formunda aşağıdaki bilgileri doldurun:

Form Alanları

• Name: Kullanıcının adı ve soyadı
• Username: Sisteme giriş için kullanılacak kullanıcı adı (benzersiz olmalıdır)
• E-mail: Kullanıcının e-posta adresi (geçerli format: name@mail.com)
• User Role: Kullanıcıya atanacak rol
• Password: Kullanıcı şifresi
• Confirm Password: Şifre tekrarı

1. Submit butonuna tıklayarak kullanıcıyı oluşturun

ipucu

API entegrasyonları için özel API rolüne sahip kullanıcılar oluşturun. Bu kullanıcılar sadece API erişimi için kullanılmalıdır.

Kullanıcı Listesi

Users ekranı, sistemdeki tüm kullanıcıları tablo formatında gösterir.

Bu ekranda:

Sütun Bilgileri:

• Name: Kullanıcının tam adı
• Username: Sisteme giriş için kullanılan kullanıcı adı
• E-mail: Kullanıcının e-posta adresi
• Role: Kullanıcıya atanmış rol

Kullanıcı İşlemleri

Her kullanıcı satırının sağ tarafında işlem butonları bulunur:

• Edit (✏️): Kullanıcı bilgilerini düzenleme
• Delete (🗑️): Kullanıcıyı sistemden silme

uyarı

Aktif oturumu olan kullanıcıları silerken dikkatli olun. Kullanıcı silme işlemi geri alınamaz.

MCP Server

SecTrail CM, yapay zekâ istemcilerinin (Claude Code, Claude Desktop, MCP Inspector vb.) sertifika envanterine ve PKI süreçlerine güvenli şekilde erişebilmesi için bir MCP Server (Model Context Protocol) barındırır. MCP Server, /mcp adresinde Streamable HTTP üzerinden hizmet verir.

İstemciler, bir API hesabı adına oluşturulan token ile kimlik doğrular. İstemcinin hangi işlemleri yapabileceği, bu API hesabının sahip olduğu mcp-* izinleriyle belirlenir.

Güvenli Tasarım

• MCP Server üzerinden sertifika doğrudan üretilemez. Sertifika ve yenileme talepleri yalnızca onay kutusuna (approval inbox) düşer; bir yetkili SecTrail CM panelinden onaylayana kadar hiçbir sertifika düzenlenmez.
• Onaylama, reddetme veya iptal (revoke) için bir araç bulunmaz.
• Özel anahtarlar ve CA/entegrasyon kimlik bilgileri hiçbir yanıtta döndürülmez.
• Her araç çağrısı, izin verilsin veya verilmesin, denetim kaydına (Audit Log) [MCP] etiketiyle yazılır.

Ön Koşullar

1. API hesabı: Token'lar yalnızca API rolüne sahip lokal kullanıcılar için oluşturulabilir. Gerekirse Yeni Kullanıcı Oluşturma adımlarıyla bir API hesabı açın.
2. MCP izinleri: API hesabının rolüne gerekli mcp-* izinlerini verin. Salt okunur erişim için hazır gelen MCP-Reader rolünü kullanabilirsiniz. Yazma izinleri hiçbir hazır role dahil değildir; hesap bazında ayrıca verilmelidir.
3. Template ayarı (yalnızca talep açılacaksa): MCP üzerinden sertifika veya yenileme talebi açılacak template'lerde Allow MCP Requests seçeneği etkinleştirilmelidir. Bu template'lerle açılan talepler, template'in onay ayarından bağımsız olarak her zaman onaylayıcıyı bekler.

Token Oluşturma

1. Users menüsünden Local Users sekmesine gidin
2. API hesabının satırındaki MCP Server Tokens (🔑) butonuna tıklayın. Bu buton yalnızca API hesaplarında görünür.
3. Create Token formunda aşağıdaki bilgileri doldurun:

Form Alanları

• API Account: Token'ın oluşturulacağı API hesabı. Bu alan değiştirilemez; başka bir hesap için Local Users listesinden ilgili hesabın token ekranına gidin.
• Token Name (zorunlu): Token'ın nerede kullanıldığını belirten ad (örn. istemcinin veya onu kullanan kişinin adı)
• Lifetime (zorunlu): Token'ın geçerlilik süresi: 30, 90 (varsayılan), 180, 365 gün veya Never expires. Süre dolduğunda token çalışmaz.

4. Create Token butonuna tıklayın

Token Yalnızca Bir Kez Gösterilir

Oluşturulan token (stm_ ile başlar) ekranda yalnızca bir kez gösterilir ve sonradan görüntülenemez. Kopyala butonuyla hemen kopyalayıp istemci yapılandırmanıza kaydedin. Token kaybedilirse iptal edip yenisini oluşturun.

Token Listesi

API hesabına ait token'lar aynı ekrandaki MCP Server Tokens tablosunda listelenir:

Sütun	Açıklama
Name	Token adı
Token	Token'ın ilk karakterleri (örn. stm_rBCqUo0W…). Token'ın tamamı saklanmaz.
Status	Active, Expired (süresi dolmuş) veya Revoked (iptal edilmiş)
Expire Date	Token'ın geçerlilik bitiş tarihi
Last Used	Token'ın en son kullanıldığı tarih ve istemci IP adresi. Hiç kullanılmamışsa - görünür.
Created At	Token'ın oluşturulma tarihi
Actions	Aktif token'lar için Revoke butonu

Revoke butonuna tıklandığında, bu token'ı kullanan istemcinin erişimi hemen kesilir. Artık kullanılmayan token'ları gecikmeden iptal edin.

Kullanılmayan Token'ların Takibi

Last Used sütunu, hangi token'ların aktif olarak kullanıldığını gösterir. Uzun süredir kullanılmayan veya hiç kullanılmamış token'ları iptal ederek gereksiz erişimleri kapatabilirsiniz.

MCP Araçları ve İzinler

İstemciye yalnızca API hesabının izinlerinin kapsadığı araçlar listelenir:

İzin	Araçlar	Açıklama
mcp-certificates-read	search-certificates, get-certificate, list-expiring-certificates	Envanterde sertifika arama, sertifika detayı (isteğe bağlı PEM ve zincir) ve süresi yaklaşan sertifikalar
mcp-certificates-all	—	Sertifika araçlarının tüm sertifikaları görmesini sağlar. Bu izin yoksa yalnızca API hesabının kendi sertifikaları görünür.
mcp-catalog-read	list-certificate-authorities, list-templates	Tanımlı CA'lar ve sertifika template'leri
mcp-approvals-read	list-pending-approvals, get-request-status	Onay bekleyen talepler ve bir talebin durumu
mcp-enrollment-read	list-enrollment-profiles, list-enrollment-transactions	SCEP/CMP profilleri ve işlem kayıtları (cihaz kayıt sorunlarının incelenmesi için)
mcp-audit-logs-read	search-audit-logs	Denetim kayıtlarında arama (varsayılan son 7 gün, en fazla 90 gün)
mcp-discovery-read	search-discovered-certificates, list-discovered-hosts, get-discovered-host, list-discovery-scans, list-discovery-runs	Keşif (discovery) sonuçları, taramalar ve çalıştırma geçmişi
mcp-certificate-request	request-certificate, get-request-status	CSR ile yeni sertifika talebi açma (onaya düşer)
mcp-certificate-renewal	request-renewal, get-request-status	Envanterdeki bir sertifika için yenileme talebi açma (onaya düşer)
mcp-discovery-scan	start-discovery-scan	Tanımlı bir taramayı veya tek seferlik bir hedef taramasını başlatma

MCP-Reader rolü; mcp-certificates-read, mcp-catalog-read, mcp-approvals-read, mcp-enrollment-read, mcp-audit-logs-read ve mcp-discovery-read izinlerini içerir.

Kullanım Limitleri

• Her token için dakikada en fazla 120 istek kabul edilir.
• Yazma araçları (sertifika ve yenileme talepleri) her API hesabı için saatte en fazla 20 kez çağrılabilir.
• İstek gövdesi en fazla 64 KB olabilir.

İstemci Yapılandırma Örnekleri

Aşağıdaki örneklerde cm.sectrail.local yerine kendi SecTrail CM adresinizi, stm_... yerine oluşturduğunuz token'ı kullanın.

Claude Code

claude mcp add --transport http sectrail https://cm.sectrail.local/mcp \
  --header "Authorization: Bearer stm_..."

Claude Desktop

Claude Desktop, uzak MCP sunucusuna mcp-remote üzerinden bağlanır. claude_desktop_config.json dosyasına şunu ekleyin:

{
  "mcpServers": {
    "sectrail": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://cm.sectrail.local/mcp",
        "--header",
        "Authorization:${SECTRAIL_TOKEN}"
      ],
      "env": {
        "SECTRAIL_TOKEN": "Bearer stm_..."
      }
    }
  }
}

Bağlantı Testi

curl -s https://cm.sectrail.local/mcp \
  -H "Authorization: Bearer stm_..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'

Başarılı bir yanıtta sunucu adı SecTrail Certificate Manager olarak döner. Geçersiz, süresi dolmuş veya iptal edilmiş bir token ile yapılan istekler 401 invalid_token yanıtı alır.

LDAP/Active Directory Entegrasyonu

SecTrail CM, Active Directory veya LDAP sunucularınızla entegre edilerek kurumsal kimlik yönetimi sağlar.

LDAP Sunucu Yapılandırması

Yeni LDAP Profili Oluşturma

Add New Ldap Server formu ile yeni bir LDAP/AD profili oluşturabilirsiniz.

Form Alanları

• LDAP Name: LDAP profilinin benzersiz adı
• LDAP Server: LDAP/AD sunucusunun IP adresi veya hostname. Add More butonu ile birden fazla sunucu eklenebilir
• Connection Type: Bağlantı türü seçimi
  • In Secure: Şifrelenmemiş bağlantı (Port 389, test/geliştirme için)
  • Secure: SSL/TLS şifreli bağlantı (Port 636, üretim için)
• LDAP Port: Bağlantı portu numarası (varsayılan: 389 veya 636)
• User DN: LDAP bağlantısı için yönetici DN
• Admin Password: User DN'de belirtilen yöneticinin şifresi
• Base DN: Kullanıcı aramalarının başlayacağı temel DN
• Manage Role: LDAP yöneticileri için varsayılan rol
• User Role: LDAP kullanıcıları için varsayılan rol
• Group Member Sync Interval (zorunlu): Bu profile bağlı LDAP gruplarının üyelerinin dizinden ne sıklıkla okunacağı. Seçenekler: 5, 10, 15, 30, 45 dakika veya 1, 2, 3, 6, 12, 24 saat (varsayılan: 6 saat). Bir gruba eklenen veya gruptan çıkarılan kullanıcı, onay ve bildirim e-postalarına bir sonraki senkronizasyondan sonra yansır. Ayrıntılar için LDAP Grup Üyesi Senkronizasyonu bölümüne bakınız.
• Test User: Bağlantıyı test etmek için kullanıcı adı

uyarı

LDAP bağlantılarınızı mutlaka test edin. Yanlış yapılandırma kullanıcı girişlerini engelleyebilir ve sisteme erişimi imkansız hale getirebilir.

ipucu

İlk LDAP yapılandırmanızı yapmadan önce, sisteme giriş yapabileceğiniz bir lokal admin hesabınızın olduğundan emin olun. Böylece LDAP sorununda sisteme erişebilirsiniz.

LDAP Profil Yönetimi

LDAP Profiles tablosu, tanımlı tüm LDAP sunucularını gösterir.

Tablo Sütunları:

• LDAP Name: Profil adı
• IP Address: LDAP sunucu IP adresi
• User DN: Bağlantı için kullanılan yönetici DN

Profil İşlemleri:

Her profil satırının sağında iki işlem butonu bulunur:

• Edit (✏️): LDAP profil ayarlarını düzenleme
  • Tüm yapılandırma alanlarını güncelleyebilirsiniz
  • Sunucu adresi, port, DN bilgileri değiştirilebilir
  • Şifreyi yeniden girmeniz gerekebilir
• Delete (🗑️): LDAP profilini silme
  • Silme işlemi geri alınamaz
  • Bu profille ilişkili Remote Authentication Policy'ler etkilenebilir

uyarı

Aktif olarak kullanılan bir LDAP profilini silmeden önce, o profil ile giriş yapan kullanıcıların başka bir yöntemle sisteme erişebildiğinden emin olun.

Uzak Kimlik Doğrulama Politikaları

Remote Authentication Policy, LDAP/AD kullanıcılarına grup veya kullanıcı bazında özel rol ataması yapmanızı sağlar. Bu sayede AD grup üyeliklerine göre farklı roller atayabilirsiniz.

Yeni Politika Oluşturma

Add New Remote Authentication Policy formu ile yeni bir politika oluşturabilirsiniz.

Form Alanları

• Policy Type: Politika türü
  • Group: AD grup bazlı politika
  • User: Bireysel kullanıcı bazlı politika
• Policy Name (opsiyonel): Grup politikası için kolay okunur bir ad (örn. PKI Onaylayıcıları). Bu ad, politika bir Sahiplik Grubuna bağlanırken Linked LDAP groups listesinde gösterilir; boş bırakılırsa grup DN'i gösterilir.
• Policy Value: Politika değeri (Policy Type'a göre değişir)
  • Group seçiliyse: AD grup DN girilir (örn. CN=PKI-Approvers,CN=Users,DC=example,DC=com)
  • User seçiliyse: Sadece kullanıcı adı girilir
• User Role: Bu politikaya uyan kullanıcılara atanacak rol

Politika Listesi

Remote Authentication Policy tablosu, tanımlı tüm politikaları gösterir.

Tablo Sütunları:

• Policy Type: Politika türü (Group veya User)
• Policy Value: Grup DN'i veya kullanıcı adı
• Role: Atanan rol

Tablo Üstü Butonlar:

• Create: Yeni politika oluşturma
• Sync group members now: Tüm LDAP profillerindeki Group tipindeki politikaların üyelerini, zamanlanmış senkronizasyonu beklemeden hemen dizinden okur. İşlem tamamlandığında kaç grup, kaç kullanıcı ve kaç sahiplik grubunun güncellendiği bildirilir. Bkz. LDAP Grup Üyesi Senkronizasyonu.
• Delete: Seçili politikaları silme
• Export: Listeyi dışa aktarma

Politika İşlemleri:

Her politika satırının sağında iki işlem butonu bulunur:

• Edit (✏️): Politika ayarlarını düzenleme
  • Policy type, value veya role değiştirilebilir
  • Aktif kullanıcılar için dikkatli düzenleme yapın
• Delete (🗑️): Politikayı silme
  • Politika silindiğinde kullanıcılar LDAP profilindeki varsayılan role döner

Politika Öncelik Sırası

Bir kullanıcı için birden fazla politika geçerliyse, öncelik sırası şu şekildedir:

1. User (Kullanıcı) Politikaları: En yüksek öncelik
2. Group (Grup) Politikaları: İkinci öncelik

LDAP Grup Üyesi Senkronizasyonu

Normalde bir LDAP kullanıcısı SecTrail CM'de ancak ilk girişinden sonra oluşur. Grup üyesi senkronizasyonu ile Group tipindeki politikalarda tanımlı grupların üyeleri, sisteme hiç giriş yapmamış olsalar bile önceden SecTrail CM'e aktarılır. Böylece bu kullanıcılar onaylayıcı olarak seçilebilir ve onay/bildirim e-postalarını alabilir.

Nasıl Çalışır

Her LDAP profili için, profildeki User DN / Admin Password bilgileriyle dizine bağlanılır ve profilin tenant'ına ait her Group politikası için:

1. Policy Value alanındaki DN ile grup kaydı okunur. DN ile bulunamazsa değer, grup adı (cn) olarak aranır.
2. Grubun doğrudan üyeleri (member / uniqueMember attribute'ları) okunur. Active Directory ve FreeIPA/389 Directory Server desteklenir.
3. Her üye, LDAP türünde kullanıcı olarak oluşturulur veya güncellenir:
   • Username: sAMAccountName (AD) veya uid (FreeIPA/389)
   • Name: cn
   • E-mail: mail
   • Role: Politikanın User Role değeri
4. Gruptan çıkarılan üyelerin o grupla ilişkisi kaldırılır. Kullanıcının rolü, aynı rolü veren başka bir grubun üyesi değilse geri alınır. Kullanıcı kaydı silinmez.
5. Son olarak, bu gruplara bağlı Sahiplik Gruplarının e-posta listeleri güncellenir.

Senkronizasyonun Çalışma Zamanı

• Otomatik: Her LDAP profili, kendi Group Member Sync Interval değerine göre (varsayılan 6 saat) zamanlanmış olarak senkronize edilir.
• Manuel: Remote Authentication Policy ekranındaki Sync group members now butonu, tüm profilleri beklemeden hemen senkronize eder. Yeni bir grup politikası ekledikten veya dizinde grup üyeliğini değiştirdikten sonra bu butonu kullanın.

RADIUS Entegrasyonu

SecTrail CM, RADIUS sunucularınızla entegre olarak merkezi kimlik doğrulama ve OTP/MFA desteği sağlar. RADIUS ekranlarına Users menüsü altındaki Radius Authentication bölümünden erişilir. Bu bölümde üç sekme bulunur:

• Profiles: RADIUS sunucu profili yapılandırması
• Policy: Rol atama politikaları
• Users: RADIUS ile giriş yapan kullanıcıların listesi

RADIUS Profili Oluşturma

Add New RADIUS Profile formu ile RADIUS sunucu profili oluşturabilirsiniz.

Form Alanları

• Name: RADIUS profilinin adı
• Primary Host: Birincil RADIUS sunucusunun IP adresi veya hostname (örn: 192.168.1.10)
• Secondary Host: (Opsiyonel) Yedek RADIUS sunucusu. Birincil sunucu yanıt vermezse otomatik olarak yedek sunucu denenir (failover)
• Auth Port: Kimlik doğrulama portu (varsayılan: 1812)
• Shared Secret: RADIUS sunucusuyla paylaşılan gizli anahtar. Veritabanında şifreli saklanır; düzenleme sırasında boş bırakılırsa mevcut değer korunur
• NAS IP Address: (Opsiyonel) NAS IP adresi (örn: 127.0.0.1)
• NAS Identifier: (Opsiyonel) RADIUS isteklerinde NAS-Identifier (attribute 32) olarak gönderilen tanımlayıcı (örn: sectrail-cm)
• Timeout: Sunucu yanıt bekleme süresi, saniye cinsinden (varsayılan: 5)
• Local/LDAP Auth Fallback: İşaretlenirse, RADIUS sunucularına erişilemediğinde lokal/LDAP kimlik doğrulamaya geri dönülür
• Manage Role: Rol atama modu
  • Default: Tüm RADIUS kullanıcılarına sabit bir rol atanır
  • Policy: Roller, RADIUS kimlik doğrulama politikalarına göre atanır
• User Role: (Yalnızca Default modunda görünür) RADIUS kullanıcılarına atanacak varsayılan rol
• Group Attribute: (Yalnızca Policy modunda görünür) Grup bilgisinin okunacağı RADIUS attribute'u (varsayılan: 11 / Filter-Id). Numerik ID, attribute adı (Filter-Id) veya VSA notasyonu (26:VendorId:VendorType) girilebilir

not

Aynı anda yalnızca bir RADIUS profili tanımlanabilir. Profil oluşturulduktan sonra Create butonu gizlenir; yeni bir profil oluşturmak için mevcut profili silmeniz gerekir.

not

Kullanıcının e-posta adresini iletmek isterseniz, RADIUS sunucunuzun bunu varsayılan olarak Reply-Message attribute'u ile göndermesini bekleriz: e-posta formatında bir değer gelirse doğrudan kaydedilir, gelmezse geçici bir adres atanır ve bunu sonradan kullanıcıyı düzenleyerek güncellemeniz gerekir. Group Attribute de 18 / Reply-Message olarak ayarlanabilir: RADIUS sunucusu iki ayrı Reply-Message değeri gönderiyorsa, e-posta adresi formatında olan değer e-posta için, diğeri grup kontrolü için kullanılır.

RADIUS Profil Listesi

RADIUS Profiles tablosu, tanımlı RADIUS profilini gösterir.

Tablo Sütunları:

• Name: Profil adı
• Primary Host: Birincil sunucu adresi
• Secondary Host: Yedek sunucu adresi
• Auth Port: Kimlik doğrulama portu
• Manage Role: Rol atama modu
• Local/LDAP Auth Fallback: Fallback durumu (Active/Passive)

Her satırın sağında Edit (✏️) butonu bulunur; profil silme işlemi Delete butonu ile yapılır. Liste Excel/CSV/PDF olarak dışa aktarılabilir.

RADIUS Giriş Akışı ve OTP/MFA

1. RADIUS profili tanımlıysa, giriş denemeleri önce RADIUS sunucusu üzerinden doğrulanır

   

2. Sunucu Access-Challenge yanıtı dönerse kullanıcı Two-Factor Authentication ekranına yönlendirilir ve OTP kodu istenir (Verify OTP). OTP'nin geçerlilik süresi RADIUS sunucunuzun kendi yapılandırmasına bağlıdır

   

3. Access-Accept yanıtında kullanıcı sisteme alınır; kullanıcı SecTrail CM'de yoksa RADIUS türünde otomatik oluşturulur. E-posta adresi, RADIUS sunucusunun gönderdiği Reply-Message attribute'undan okunur; gönderilmiyorsa kullaniciadi@radius.local biçiminde geçici bir adres atanır

4. Access-Reject yanıtında veya sunuculara erişilemediğinde, Local/LDAP Auth Fallback açıksa lokal/LDAP doğrulama denenir; kapalıysa giriş reddedilir

ipucu

Kullanıcı e-postalarının otomatik dolması için RADIUS sunucunuzu, e-posta adresini Reply-Message attribute'u ile gönderecek şekilde yapılandırın.

RADIUS Kimlik Doğrulama Politikaları

Manage Role alanı Policy olarak seçildiğinde roller, RADIUS Authentication Policy kayıtlarına göre atanır.

Form Alanları

• Policy Type: Politika türü
  • User: Belirli bir RADIUS kullanıcı adıyla eşleşir (örn: johndoe)
  • Group: RADIUS grup attribute değeriyle eşleşir (örn: kron-admin-group)
• Policy Value: Eşleştirilecek değer (Policy Type'a göre kullanıcı adı veya grup değeri)
• User Role: Bu politikaya uyan kullanıcılara atanacak rol

Politika Listesi

RADIUS Authentication Policy tablosu, tanımlı tüm politikaları gösterir.

Politika Öncelik Sırası

1. User (Kullanıcı) Politikaları: En yüksek öncelik
2. Group (Grup) Politikaları: İkinci öncelik — RADIUS sunucusundan dönen Group Attribute değeriyle eşleştirilir

uyarı

Policy modunda, kullanıcı için eşleşen bir politika bulunamazsa giriş reddedilir. Politikalarınızı yapılandırmadan Policy moduna geçmeyin.

RADIUS Kullanıcıları

RADIUS Users ekranı, RADIUS ile giriş yaparak otomatik oluşturulan (RADIUS türündeki) tüm kullanıcıları listeler.

Tablo Sütunları:

• Name: Kullanıcının tam adı
• User Name: Kullanıcı adı
• Email: E-posta adresi
• Role: Atanmış rol
• Type: Kullanıcı türü

OAuth Entegrasyonu

SecTrail CM, OAuth 2.0 / OpenID Connect tabanlı kurumsal kimlik sağlayıcılarıyla (SSO) entegre olur. Desteklenen sağlayıcılar:

• Entra ID / Microsoft (Azure)
• Keycloak
• GitHub
• Google
• SecTrail MFA
• Custom (OpenID Connect): Standart OIDC discovery desteği sunan (/.well-known/openid-configuration uç noktasını yayınlayan) herhangi bir kimlik sağlayıcı — Okta, Auth0, ADFS (2016+), Authentik vb. — bu tiple bağlanabilir

OAuth ekranlarına OAuth Authentication menüsünden erişilir. Bu bölümde üç sekme bulunur:

• Profiles: OAuth sağlayıcı profili yapılandırması
• Policy: Rol atama politikaları
• Users: OAuth ile giriş yapan kullanıcıların listesi

OAuth Profili Oluşturma

Add OAuth Profile formu ile OAuth sağlayıcı profili oluşturabilirsiniz. Aynı form, profil düzenlenirken (mevcut değerlerle) de kullanılır.

Form Alanları

• Name: OAuth profilinin adı. Custom (OpenID Connect) tipinde bu ad, giriş ekranındaki butonun ipucu metninde de kullanılır (örn. "Sign in with Okta"); bu profiller giriş ekranında marka simgesi yerine ortak/generic bir OAuth rozetiyle gösterilir
• Provider: Kimlik sağlayıcı seçimi (Entra ID / Microsoft, Keycloak, GitHub, Google, SecTrail MFA, Custom (OpenID Connect))
• Client ID: Sağlayıcı tarafında kayıtlı uygulamanın Client ID değeri
• Client Secret: Uygulamanın gizli anahtarı. Düzenleme sırasında boş bırakılırsa mevcut değer korunur
• Server URL: (Keycloak, SecTrail MFA ve Custom (OpenID Connect) için zorunlu) Sunucu adresi (örn: https://keycloak.example.com). Bu adresten /.well-known/openid-configuration uç noktası otomatik olarak sorgulanıp token/userinfo adresleri buradan çözülür
• Tenant ID / Realm: (Yalnızca Azure ve Keycloak için zorunlu) Entra ID'de Tenant ID, Keycloak'ta Realm değeri
• Auto-create users: İşaretlenirse, OAuth ile ilk kez giriş yapan kullanıcılar otomatik olarak oluşturulur (JIT provisioning)
• Manage Role: Rol atama modu
  • Default: Kullanıcılara profildeki sabit rol atanır
  • Policy: Roller, OAuth kimlik doğrulama politikalarına göre atanır
• User Role: (Yalnızca Default modunda görünür) Kullanıcılara atanacak rol
• Group-based role mapping: (Yalnızca Entra ID / Microsoft + Policy modunda görünür) İşaretlendiğinde kullanıcının Entra ID gruplarını ayrıca Microsoft Graph üzerinden de okur (GroupMember.Read.All izni ve admin onayı gerektirir), bu sayede Graph'tan gelen grup görünen adlarıyla (display name) da eşleştirme yapılabilir. Bu kutu yalnızca Entra ID'ye özeldir; grup eşleştirmenin kendisi ise sağlayıcıdan bağımsız çalışır — hangi provider olursa olsun (Keycloak, Custom OIDC vb.), IdP'nin id_token'ında bir groups claim dönüyorsa bu değerler otomatik okunur ve Graph izni gerekmeden Group tipi politikalarla eşleştirilir
• Callback URL: Sabit https:// ve /auth/{provider}/callback parçaları arasında düzenlenebilir bir adres alanı içerir (varsayılan olarak panele o an erişilen adresle doldurulur). Panele birden fazla adresten (IP, özel alan adı) erişiliyorsa bu alanı sağlayıcıya kayıtlı Redirect URI ile birebir eşleşecek şekilde ayarlayın

not

Her sağlayıcı tipinden (Entra ID, Keycloak, GitHub, Google, SecTrail MFA, Custom) yalnızca bir profil oluşturulabilir — callback URL'in sağlayıcı başına benzersiz olması gerekir. Farklı sağlayıcı tiplerinden birden fazla profil aynı anda tanımlı olabilir; her profilin kendi rol atama politikaları vardır ve birbirini etkilemez.

ipucu

Rol ataması yalnızca ilk girişte değil, her girişte yeniden uygulanır: profildeki varsayılan rolü veya bir politikayı değiştirdiğinizde, ilgili kullanıcının bir sonraki OAuth girişinde yeni rol otomatik olarak devreye girer. E-posta ile eşleşen LOCAL/LDAP hesapların rolleri OAuth girişinde asla değiştirilmez.

Microsoft Entra ID Yapılandırma Örneği

Aşağıdaki adımlar, Azure Portal üzerinden bir App Registration oluşturup SecTrail CM ile eşleştirmeyi gösterir.

1. Microsoft Entra ID → App registrations → New registration ekranından yeni bir uygulama kaydı oluşturun.

   • Supported account types: Genellikle Single tenant (yalnızca bu organizasyon) seçilir
   • Redirect URI: Web platformu seçilip, SecTrail CM'deki profilin Callback URL alanındaki değer (örn. https://cm.sirketiniz.com/auth/azure/callback) birebir girilir

   

2. Certificates & secrets → Client secrets → New client secret ile bir gizli anahtar oluşturun ve Value sütunundaki değeri kopyalayın (Secret ID değil — bu değer yalnızca oluşturulduğu an görünür). Bu değeri profildeki Client Secret alanına yapıştırın.

   

   ipucu

   Client secret'lar seçtiğiniz süre sonunda (6/12/18/24 ay) otomatik olarak geçersiz olur. Süre dolmadan önce yeni bir secret oluşturup profildeki Client Secret alanını güncelleyin; aksi halde ilgili sağlayıcıdan giriş yapılamaz hale gelir.

3. Overview sayfasından Application (client) ID değerini Client ID, Directory (tenant) ID değerini Tenant ID alanına kopyalayın.

4. API permissions ekranından izinleri yapılandırın:

   • User.Read (Delegated, Microsoft Graph) genellikle varsayılan olarak eklidir ve temel giriş (ad, e-posta) için yeterlidir
   • Grup bazlı rol ataması için GroupMember.Read.All (Delegated) iznini ekleyip Grant admin consent butonuyla onaylayın (Global Administrator veya Privileged Role Administrator yetkisi gerektirir)

   

5. (İsteğe bağlı, Graph izni gerektirmeyen alternatif) Token configuration → Add groups claim ile grup bilgisinin ID token'a eklenmesini sağlayabilirsiniz (Security groups veya All groups). Bu durumda kullanıcının grup ID'leri (GUID) id_token üzerinden gelir ve SecTrail CM bunları herhangi bir Graph izni olmadan otomatik okur — GroupMember.Read.All onayı alınamayan ortamlar için pratik bir alternatiftir.

   

6. (Önerilir) Enterprise applications altında yeni kaydınızı bulun, Properties sayfasında Assignment required? seçeneğini Yes yapın, ardından Users and groups ekranından SecTrail CM'e giriş yapabilecek kullanıcı/grupları atayın. Bu, Entra ID tarafında ekstra bir erişim kontrolü katmanı sağlar.

Sık Karşılaşılan Hatalar

• AADSTS50011 (redirect URI uyuşmazlığı): Uygulama kaydındaki Redirect URI, profildeki Callback URL ile şema/host/path dahil birebir aynı olmalıdır
• AADSTS50105 (kullanıcı atanmamış): 6. adımda Assignment required açıksa, giriş yapacak kullanıcının Enterprise Application'a atanmış olması gerekir
• AADSTS65001 / "Yönetici onayı gerekiyor": Tenant'ta kullanıcı onayı kapalıysa, 4. adımdaki izin için bir yöneticinin Grant admin consent yapması gerekir
• id_token boş/eksik geliyorsa: Uygulama kaydında Authentication → Implicit grant and hybrid flows altında ID tokens seçeneğinin işaretli olduğundan emin olun

OAuth Profil Listesi

OAuth Profiles tablosu, tanımlı OAuth profilini gösterir.

Tablo Sütunları:

• Name: Profil adı
• Provider: Kimlik sağlayıcı (örn: Entra ID / Microsoft)
• Auto-create users: Otomatik kullanıcı oluşturma durumu (Yes/No)
• Manage Role: Rol atama modu

Profil İşlemleri:

Her profil satırının sağında Edit (✏️) butonu bulunur; profil silme işlemi tablonun üstündeki Delete butonuyla (satır seçilerek) yapılır.

• Edit (✏️): Profil ayarlarını düzenleme
  • Tüm alanlar güncellenebilir; Client Secret boş bırakılırsa mevcut değer korunur
  • Callback URL'deki adres kısmı, panele yeni bir adresten (örn. özel bir domain) erişilmeye başlandığında burada güncellenmelidir
• Delete: Profili silme
  • Profille ilişkili tüm OAuth Authentication Policies kayıtları da otomatik olarak silinir
  • Bu profille daha önce giriş yapmış kullanıcılar sistemden silinmez, yalnızca o profille tekrar giriş yapamazlar

uyarı

Aktif olarak kullanılan bir OAuth profilini silmeden önce, o profille giriş yapan kullanıcıların başka bir yöntemle (LOCAL, LDAP veya başka bir OAuth profili) sisteme erişebildiğinden emin olun.

OAuth Giriş Akışı

1. Etkin bir OAuth profili varken giriş ekranında, ilgili sağlayıcının simgesiyle küçük bir buton görüntülenir (üzerine gelindiğinde "Sign in with {Provider}" ipucu gösterilir)
2. Butona tıklayan kullanıcı, sağlayıcının giriş sayfasına yönlendirilir ve kimlik doğrulama sağlayıcı tarafında yapılır
3. Başarılı doğrulama sonrası kullanıcı SecTrail CM'e geri yönlendirilir ve hesap eşleştirmesi yapılır:
   • Önce sağlayıcının değişmez kullanıcı kimliği ile eşleştirilir
   • Eşleşme yoksa e-posta adresiyle (büyük/küçük harf duyarsız) eşleştirilir — bu, mevcut bir LOCAL/LDAP hesabına da OAuth kimliğini kalıcı olarak bağlar
   • Aynı e-postayla birden fazla hesap eşleşirse giriş güvenlik nedeniyle reddedilir
4. Rol ataması yapılır (mevcut OAuth kullanıcıları için her girişte yeniden uygulanır): Default modda profildeki rol, Policy modda eşleşen politikanın rolü atanır
5. Kullanıcı sistemde yoksa ve Auto-create users açıksa, OAUTH türünde yeni hesap oluşturulur

ipucu

Çok faktörlü kimlik doğrulama (MFA), kimlik sağlayıcı (IdP) tarafında zorunlu kılınmalıdır. OAuth girişlerinde SecTrail CM tarafında ayrıca OTP sorulmaz.

uyarı

Hesap eşleştirmesi e-posta adresine dayandığından, kimlik sağlayıcının e-posta doğrulamasına güvenilmelidir. Kurumca tam denetlenmeyen bir Custom (OpenID Connect) IdP ekliyorsanız, kullanıcıların e-posta adreslerinin sağlayıcı tarafında doğrulanmış (verified) olduğundan emin olun.

OAuth Kimlik Doğrulama Politikaları

Manage Role alanı Policy olarak seçildiğinde roller, ilgili profile ait OAuth Authentication Policies kayıtlarına göre atanır — politikalar profile özeldir, bir profilin politikaları başka bir profili etkilemez. Politika oluştururken ve düzenlerken aynı form kullanılır.

Form Alanları

• Profile: Politikanın uygulanacağı OAuth profili
• Policy Type: Politika türü
  • User: Kullanıcının e-posta adresi veya UPN değeriyle eşleşir
  • Group: Kimlik sağlayıcının id_token'ında dönen groups claim değeriyle eşleşir (sağlayıcıya göre GUID veya isim olabilir); Entra ID'de ayrıca Microsoft Graph üzerinden gelen grup görünen adlarıyla (display name) da eşleştirme yapılır
• Policy Value: Eşleştirilecek değer (Policy Type'a göre değişir)
• User Role: Bu politikaya uyan kullanıcılara atanacak rol

Politika Listesi

OAuth Authentication Policies tablosu, tanımlı tüm politikaları gösterir.

Politika İşlemleri:

Her politika satırının sağında Edit (✏️) butonu bulunur; silme işlemi tablonun üstündeki Delete butonuyla yapılır.

• Edit (✏️): Policy Type, Policy Value, Role veya bağlı Profile değiştirilebilir
• Delete: Politika silindiğinde, o politikaya uyan kullanıcılar bir sonraki girişte profildeki hiçbir politikaya uymuyor sayılır (Policy modunda girişleri reddedilir, Default moda geçilmediği sürece)

Politika Öncelik Sırası

1. User (Kullanıcı) Politikaları: En yüksek öncelik
2. Group (Grup) Politikaları: İkinci öncelik

uyarı

Grup bazlı politikalar, IdP'nin id_token'ında groups claim dönmesi koşuluyla her sağlayıcıda çalışabilir; Microsoft Graph üzerinden isimle eşleştirme ise yalnızca Entra ID / Microsoft'a özeldir (bkz. yukarıdaki yapılandırma örneği). Policy modunda eşleşen politika bulunamayan OAuth kullanıcılarının girişi reddedilir; bu kural yalnızca OAUTH türündeki hesapları etkiler, e-posta ile eşleşen LOCAL/LDAP hesapları asla engellenmez.

OAuth Kullanıcıları

OAuth Users ekranı, OAuth ile giriş yaparak oluşturulan (OAUTH türündeki) tüm kullanıcıları listeler. Bu ekran salt görüntüleme amaçlıdır; liste Excel/CSV/PDF olarak dışa aktarılabilir.

Tablo Sütunları:

• Name: Kullanıcının tam adı
• User Name: Kullanıcı adı
• Email: E-posta adresi
• Role: Atanmış rol
• Provider: Giriş yapılan kimlik sağlayıcı

Kullanıcı Rolleri

SecTrail CM'de kullanıcılar rol tabanlı yetkilendirme ile yönetilir. Her kullanıcıya bir veya daha fazla rol atanabilir.

Varsayılan Roller

• Admin: Tam yönetici yetkisi
• API: API erişimi için özel rol
• MCP-Reader: MCP Server'ın salt okunur izinlerini içeren API rolü

Roller ve izinleri hakkında detaylı bilgi için Rol ve İzinler bölümüne bakınız.