Ana içeriğe geç

Kurumsal Hesapla Giriş (SSO)

Kullanıcılar panele ve istemciye kendi kurumsal hesaplarıyla (Microsoft Entra ID, Google Workspace, Okta — OIDC konuşan her sağlayıcı) girebilir. Böylece ayrı bir VPN parolası olmaz; işten ayrılan bir çalışanın hesabı kurumsal tarafta kapandığında VPN erişimi de kapanır.

İki yol var: panel ya da sunucu

Sağlayıcıyı panelden ekleyebilirsiniz (Kimlik Sağlayıcıları sayfası, yalnız yöneticiler) — değişiklik hemen etkindir, servis yeniden başlamaz. Kurulumu betikle yapıyorsanız aynı şeyi sunucudan da tanımlayabilirsiniz; o yol yapılandırmaya yazar ve panelde "sunucudan" rozetiyle salt okunur görünür. Birini seçin: sunucudan gelen bağlayıcı panelden değiştirilemez (bilinçli; kimlik sunucusu da reddediyor).

1. Geri dönüş adresini not edin

Sağlayıcı tarafında uygulama kaydı açarken istenen redirect URI budur:

https://access.firmaniz.com.tr/oauth2/callback

Kendi alan adınızı yazın. Panelin adresi değil, kimlik sunucusunun adresidir ve /oauth2/callback ile biter. Yanlış adres, girişin "redirect_uri mismatch" ile düşmesi demektir.

2. Sağlayıcı tarafında uygulama kaydı

  1. Entra yönetim merkezi → App registrations → New registration.
  2. Ad: örn. Netsoft Access VPN. Hesap türü: genelde Single tenant.
  3. Redirect URI: platform Web, adres yukarıdaki /oauth2/callback.
  4. Kayıttan sonra Overview sayfasından iki değeri alın:
    • Application (client) ID → İstemci kimliği
    • Directory (tenant) ID → issuer adresinde kullanılacak
  5. Certificates & secrets → New client secret → değeri (Value sütunu, Secret ID değil) kopyalayın → İstemci sırrı. Bu değer bir daha gösterilmez; bitiş tarihini de not edin.
  6. API permissions → openid, profile, email (Microsoft Graph, delegated) yeterlidir.

Issuer adresi:

https://login.microsoftonline.com/<tenant-id>/v2.0
  1. Google Cloud Console → APIs & Services → Credentials.
  2. Create Credentials → OAuth client ID → tür Web application.
  3. Authorized redirect URIs: yukarıdaki /oauth2/callback adresi.
  4. Client ID ve Client secret değerlerini alın.

Issuer adresi:

https://accounts.google.com
  1. Okta yönetim panelinde Applications → Create App Integration → OIDC - Web Application.
  2. Sign-in redirect URIs: yukarıdaki /oauth2/callback adresi.
  3. Client ID / Client secret değerlerini alın.

Issuer adresi genelde https://<firma>.okta.com biçimindedir; emin değilseniz bir sonraki adımdaki doğrulama komutu söyler.

3. Issuer adresini önce doğrulayın

Adres yanlışsa kimlik sunucusu ayakta kalır ama kurumsal giriş denemesi başarısız olur — yani hata, tam giriş anında ortaya çıkar. Onun yerine şimdi bakın; şu adres bir JSON döndürmeli:

curl -s https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration | head -3

4. Bağlayıcıyı tanımlayın

  1. Panelde Kimlik Sağlayıcıları sayfasını açın.

  2. Sağlayıcı ekle deyin ve alanları doldurun:

    • Kimlik: entra gibi kısa bir ad (küçük harf, rakam, tire). Giriş adresinde görünür ve sonradan değişmez.
    • Giriş sayfasındaki ad: kullanıcının gördüğü metin ("Microsoft").
    • Issuer, İstemci kimliği, İstemci sırrı.

  3. Kaydedin. Sunucu önce issuer adresini sınar; ulaşamazsa kayıt yapılmaz ve nedenini söyler. Kayıt geçerse bağlayıcı anında etkindir — kimlik servisi yeniden başlamaz, açık oturumlar etkilenmez.

Sonradan düzenlerken istemci sırrı yeniden istenir: sunucu sırrı geri vermiyor ve yapılandırma bütün olarak yazılıyor.

Bu yolla tanımlanan bağlayıcı panelde salt okunur görünür; kimlik servisi yeniden başlar (birkaç saniye, açık oturumlar etkilenmez).

sudo helmqet reconfigure qetra-vpn \
    --set idp_type=oidc \
    --set idp_name="Microsoft" \
    --set idp_issuer=https://login.microsoftonline.com/<tenant-id>/v2.0 \
    --set idp_client_id=<uygulama-kimligi> \
    --set idp_client_secret=<istemci-sirri>

idp_name, giriş sayfasındaki düğmenin metnidir ("Microsoft ile giriş yap").

Sır nerede tutulur

Sunucudan tanımlarsanız istemci sırrı yapılandırma dosyasına yazılmaz (o dosya, kimlik sunucusunun okuyabilmesi için herkesçe okunabilir olmak zorunda): sır yalnız root erişimli dex.env (0600) içinde durur. Komut çıktısında ve fark listesinde de maskeli görünür.

Panelden tanımlarsanız sır kimlik sunucusunun kendi veritabanında tutulur ve yedeklere girer.

Her iki yolda da sır hiçbir ekranda ve hiçbir API yanıtında geri gösterilmez.

5. Doğrulayın

  1. Giriş sayfasını gizli bir pencerede açın: artık iki düğme olmalı — kurumsal sağlayıcı ve yerel hesap. (Gizli pencere, bir aksilikte paneldeki açık oturumunuzu kaybetmemeniz için.)
  2. Kurumsal düğmeyle bir kullanıcıyla girin.
  3. Kimlik Sağlayıcıları sayfasının altındaki dağılım, kullanıcıların hangi kaynaktan geldiğini gösterir.

6. Grupları eşleyin (isteğe bağlı)

Kurumsal gruplarınızı VPN gruplarına bağlayabilirsiniz: kullanıcı kurumsal hesabıyla cihazını kaydettiğinde, sağlayıcının bildirdiği gruplara karşılık gelen yerel gruplara kendiliğinden girer. Böylece işe alım ve ayrılma kurumsal dizinde yapılır, VPN'e yansır.

Kimlik Sağlayıcıları sayfasında, sağlayıcı kartının altındaki Sağlayıcı grubu → yerel grup bölümünden ekleyin:

Alan Örnek
Sağlayıcıdaki grup adı Finans
Yerel grup finans-erisim

Kurallar (ölçülmüş davranış):

  • Eşleme her girişte uygulanır; cihaz zaten her girişte kendini tazeliyor.
  • Yalnız eşlenmiş gruplar yönetilir. Kullanıcı sağlayıcıda artık o grupta değilse eşlenmiş yerel gruptan çıkarılır; operatörün elle verdiği üyeliklere dokunulmaz.
  • Büyük/küçük harf farkı önemsizdir (Finans = finans).
  • Eşleme kaldırılınca var olan üyelikler düşmez; o grup yalnız bundan sonraki girişlerde yönetilmez. Erişimi hemen kesmek istiyorsanız üyeliği ayrıca elle kaldırın.
  • Üyelik cihaz düzeyindedir: kullanıcının her cihazı kendi girişinde gruba girer.

Sağlayıcı grupları göndermiyorsa eşleme çalışmaz

Giriş sırasında groups bilgisi istenir, ama çoğu sağlayıcı grup iddiasını varsayılan olarak göndermez (Entra ID'de uygulama kaydında grup iddialarını açmanız, Google Workspace'te ayrıca yetkilendirme yapmanız gerekir). Eşleme eklediğiniz hâlde cihaz gruba girmiyorsa önce sağlayıcı tarafında grup iddiasının gönderildiğini doğrulayın: bir cihazla giriş yapın ve Cihazlar sayfasında o cihazın gruplarına bakın.

Yerel yönetici hesabı kapanmaz

Kurumsal sağlayıcı açıkken de yerel parola girişi açık kalır. Bu bilinçlidir: sağlayıcı tarafında bir arıza (yanlış sır, süresi dolmuş istemci sırrı, tenant kesintisi) olduğunda panele girebilmenin tek yolu yerel yönetici hesabıdır. Bu hesabın parolasını bir parola kasasında tutun.

Kaldırma

Panelden eklediyseniz: Kimlik Sağlayıcıları → satırın sağındaki menü → Sil. Sunucudan tanımladıysanız:

sudo helmqet reconfigure qetra-vpn --set idp_type=yok

İkinci yolda bağlayıcı yapılandırmadan düşer ve sır dosyası silinir. Sırrı sağlayıcı tarafında da iptal etmeyi unutmayın. Kurumsal hesapla girmiş kullanıcılar panelde kalır ama artık giriş yapamaz; gerekiyorsa onlara yerel hesap açın.

Sık karşılaşılanlar

Belirti Sebep
Giriş sayfasında kurumsal düğme yok Sağlayıcı kaydedilmemiş ya da silinmiş — panelde listeye bakın
Kaydederken "issuer adresine ulaşılamadı" Adres yanlış ya da sunucudan erişilemiyor (3. adımdaki curl)
"redirect_uri mismatch" Sağlayıcıdaki adres /oauth2/callback ile bitmiyor ya da alan adı farklı
"invalid_client" Client id/secret yanlış veya sırrın süresi dolmuş
Kurumsal giriş "Failed to open connector" Issuer adresi yanlış ya da sunucudan erişilemiyor (3. adımdaki curl)
Kullanıcı giriyor ama yetkisi yok Giriş kimlik doğrulamadır; yetki panelde rol/grup ile verilir