İstifadəçilər Azure AD (Microsoft Entra ID) ilə vahid giriş (SSO) zamanı tez-tez yenidən parol daxil etməli olur və ya sessiyaları gözlənilmədən sona yetir. Məsələn: – İstifadəçi bir SaaS tətbiqinə SSO ilə daxil olur, lakin hər 1-2 gündən bir təkrar giriş tələb edilir (parol yenidən soruşulur) – normaldan tez zamanda sessiya etibarsızlaşır. – Brauzeri bağlayıb açdıqdan sonra yenidən MFA/giriş sorğusu gəlir, halbuki “remember me” işarələnmiş idi. – Bəzi cihazlarda (xüsusən hibrid Azure AD join olan Windows cihazları) istifadəçilər parol daxil etmədən SSO gözlədikləri halda, “Verify your password” və ya oxşar mesajla qarşılaşırlar. Sign-in logs-da 50089 – Flow token expired xətası görünə bilər. – Tətbiqlər arası keçiddə SSO işləmir: eyni istifadəçi portal.office.com-da girişi açıqdır, amma digər Azure AD federasiyalı tətbiqə keçəndə yenidən login pəncərəsi çıxır.
Bu əlamətlər tokenlərin və ya sessiyaların vaxtından əvvəl bitdiyini yaxud SSO üçün tələb olunan biletin (PRT – Primary Refresh Token) düzgün ötürülmədiyini göstərir.
Mümkün kök səbəblər:
- Seans tokeninin vaxtının bitməsi (Max Inactive Time): Azure AD, təhlükəsizlik məqsədilə sessiya tokenlərinə müəyyən ömür təyin edir. Non-persistent (davamsız) brauzer sessiya tokeninin default Max Inactive müddəti 24 saatdır; persistent (davamlı, “Stay signed in” seçilmiş) token üçün 90 gündür. Əgər istifadəçi uzun müddət aktiv deyilsə, bu müddət keçdikdən sonra token “flow token expired” xətası ilə qəbul edilmir və istifadəçidən yenidən giriş tələb olunur. Məsələn, Seamless SSO qurğusunda domain joined cihazdakı Kerberos biletinin ya da PRT-nin müddəti bitərsə, yenidən parol sorğusu görülə bilər. Hər 1-2 gündən bir təkrar parol soruşulması, adətən, persistent sessiya olmadığını və 24 saat non-persistent limitindən qaynaqlandığını göstərir.
- Conditional Access siyasətləri (Session control) tətbiqi: Şirkətinizdə Conditional Access ilə “Sign-in Frequency” və ya “Persistent browser session” kimi ayarlar müəyyən edilibsə, onlar token ömrünü qısalda bilər. Məsələn, bir CA qaydası təyin edilib ki, hər 48 saatda bir dəfə yenidən autentikasiya olunsun – bu, default-lardan daha aqressivdirsə, istifadəçilər normaldan tez parol girişi ilə qarşılaşar.
- Primary Refresh Token (PRT) problemləri (Hybrid Azure AD Join): Domain-join olmuş Windows cihazlarda Azure AD PRT cihaz login zamanı alınır və SSO üçün istifadə edilir. Əgər PRT yenilənə bilmirsə (məsələn, cihaz uzun müddət domain şifrəsini sinkronizasiya etmir, ya da cihazın zamanı Azure AD-dən kənara çıxır), PRT etibarsız olur. Bu baş verərsə, cihaz kiliddən açıldıqda SSO alınmır, yenidən parol sorğu pəncərələri gələ bilər. PRT-nin 14 gün (default) ömrü var, background-da hər 4 saatdan bir yenilənməyə cəhd edilir; bu yenilənmələr uğursuzdursa (məsələn, şəbəkə problemi, SSO konfiq. xətası), PRT expire olur və SSO pozulur.
- Fərqli brauzer sessiyaları / Third-party cookies bloklanması: Bəzi hallarda SSO probleminin səbəbi texniki ayarlar ola bilər. Məsələn, brauzerdə üçüncü tərəf kukilərin bloklanması Azure AD-nin sessiya kukisini paylaşmasına mane olur. Və ya eyni brauzerdə bir neçə Azure AD hesabı ilə login olunubsa, qarışıqlıq yarana bilər, doğru session seçilməyə bilər.
- Token lifetime konfiqurasiyaları (köhnə): Keçmişdə Azure AD Configurable Token Lifetime siyasətləri ilə Access/ID token ömrü dəyişdirilə bilirdi (1 saat default, bəlkə daha qısa). Bu siyasətlər refresh/session tokenlərinə artıq tətbiq olunmasa da (2021-dən etibarən), əgər köhnədən konfiq edilib qalmışsa, qarışıqlıq yarada bilər. Hal-hazırda web sessiya ömrünü idarə etməyin düzgün yolu Conditional Access Sign-in Frequency-dir.
- SAML tətbiqlərində kənar sessiya parametrləri: Azure AD-dən SAML token alan bəzi tətbiqlərin öz sessiya idarəsi də ola bilər. Məsələn, Salesforce kimi xidmətlər Azure AD token alsa da, öz tərəflərində session timeout-u qısa tuta bilərlər, bu da SSO sonrası tez yenidən login tələb edə bilər. Bu halda problem Azure AD deyil, həmin tətbiqin sessiya ayarıdır.
Diaqnostika üsulları:
İlk növbədə Azure AD Sign-in Logs üzərində araşdırma aparın. Müəyyən bir istifadəçinin yenidən girişə məcbur qaldığı vaxtların loglarını filtr edin: – Sign-in logunda “Authentication Details” bölməsi: Burada Token issuer (Azure AD), Authentication requirement və Result detail kimi məlumatlar olur. Əgər Result detail = Refresh token expired və ya Token lifetime exceeded kimi bir şeydisə, problem token vaxtı ilə bağlıdır. Məsələn, 50089 kodlu səhvlər (Flow token expired) görünürsə, bu açıqca sessiya tokeninin müddəti bitdiyinə işarədir. – Conditional Access events: Həmin log qeydlərində aşağıya doğru “Policies” bölməsi olur. Orada hansısa CA qaydası “Sign-in frequency” = X gün kimi tətbiq edilibsə, onu görəcəksiniz. Məsələn, “Session expired due to security policy” kimi bir detail, CA-nin sessiya tələbinə görə tokenin atıldığını göstərir. – Azure AD portalında Diagnose and solve problems (SSO) bölməsinə də baxmaq olar, orada ümumi SSO check-ləri edir. Həmçinin Microsoft Entra ID > Monitoring > Reports > Sign-in frequency hesabatları mövcuddur. – Device diagnostics (PRT): Əgər problem hibrid Azure AD join cihazlarda SSO-nun alınmaması ilə bağlıdırsa, həmin cihazda dsregcmd /status əmrini Command Prompt ilə çalıştırın. Nəticədə SSO State bölməsinə baxın. AzureAdPrt : YES olmalıdır (NO çıxırsa, PRT yoxdur). AzureAdPrtExpiryTime dəyərinə və AzureAdPrtUpdateTime-a diqqət edin. UpdateTime 4 saatdan çoxdur yenilənməyibsə, PRT refresh problemi var deməkdir. Bundan əlavə, dsregcmd çıxışında Attempt Status error kodu görünə bilər (21H1+ Windows versiyasında). Orada səhv kod (məsələn, 0xc000006d – yanlış şifrə) və ya AADSTS xətası (“invalid_grant” kimi) varsa, PRT niyə yenilənməyib onu anlamağa kömək edəcək. – Token lifetimes & config check: Get-AzureADPolicy (AzureAD PowerShell modulu) və ya MS Graph komutları ilə tenantınızda köhnə token lifetime siyasəti qalıbmı yoxlayın. Çox güman yoxdur, çünki Microsoft onları retire edib 2021-dən. Amma yenə də Conditional Access-> Session Management bölməsini yoxlayın. – App logları: Tutaq ki, istifadəçilər bir Veb SSO inteqrasiyasında problem yaşayır. Tətbiqin özü “Auth token expired” kimi bir mesaj veribsə, bəlkə Azure AD-dən aldığı ID token-in default 1 saat ömrü məsələsidir (ID token-lər 1 saat etibarlıdır, sonra silent refresh lazımdır). Bəzi tətbiqlər silent refresh etmədiklərindən 1 saat sonra yenidən login tələb edirlər. Bu, xüsusən köhnə SAML-bazlı inteqrasiyalarda görülə bilər. – User experience sondajı: Bəzi suallar diaqnoza yardım edər: Bu problem hamıya aiddir yoxsa tək-tük istifadəçiyə? Yalnız domain-joined PC-lərdə olur, yoxsa şəxsi cihazlarda da? Yalnız xaricdən (off-network) edəndə olur, yoxsa hər yerdə? Məsələn, yalnız ofis xaricində tez login istənilir – o zaman bəlkə Conditional Access-lə “persistent cookie” bloklanıb or outside network.
Sınaqdan keçmiş həll yolları:
- Sessiya müddətini uzatmaq (Conditional Access ilə): Əgər default 24 saat non-persistent sessiya çox qısa gəlirsə və təhlükəsizlik siyasətiniz icazə verirsə, istifadəçilərin brauzer sessiyasını persistent edin. Yəni, “Stay signed in” seçimini aktiv strategiya halına gətirin. Azure AD bununla bağlı bir prompt göstərir: “Stay signed in?” – bunu təsdiqlətsəniz, 90 gün inaktivlik müddəti olacaq. Və ya daha yaxşısı, Conditional Access-də Persistent browser session siyasətini “Always persistent” olaraq konfiqurasiya edin ki, istifadəçilər həmişə uzunmüddətli cookie əldə etsinlər. Bu yolla brauzeri bağlayıb açanda token hələ keçərli olacaq (24 saat yerinə 90 gün).
- Bundan əlavə, Sign-in frequency CA siyasətini nəzərdən keçirin. Əgər istifadəçilərin tez login olmasını istəmirsinizsə, bu parametri Every time və ya X saat kimi sərt dəyərlərə qoymamağınız məsləhətdir. Əks halda, siz Azure AD-nin default adaptiv token refresh mexanizmini kəsmiş olursunuz. CA olmadan, Azure AD refresh tokenləri normalda imkan verdiyi qədər saxlayır (cihaz və risk amillərinə görə). Sign-in frequency policy yalnız xüsusi hallarda (məsələn, yüksək riskli məlumat üçün qısa sessiya) tətbiq olunmalıdır.
- SSO (Primary Refresh Token) problemlərinin aradan qaldırılması: Əgər PRT-nin vaxtından əvvəl bitməsi problemidirsə (50089 xətaları ilə təzahür edən), bunun bir səbəbi cihazların uzun müddət offline qalması ola bilər. Domain şifrəsi dəyişib, lakin cihaz Connect olmayıb – belə vəziyyətdə PRT yenilənə bilməz, çünki etibarnamə səhvdir. Həlli: istifadəçidən cihazı internetə (və domain controller-lara) qoşub yenidən login etsin, yəni cihazın Azure AD device key və ya Kerberos biletini yeniləyin. Bundan əlavə, cihaz saatının (~5 dəq+ fərqi varsa) uyğunsuzluğu SSO-ya mane olur – Time sync-i düzəldin.
- Windows cihazlarda Credential Guard və ya digər siyasətlər SSO-ya təsir edə bilər – amma Seamless SSO üçün kritik deyil. Seamless Single Sign-On konfiqurasiya qaydalarına baxın: doğru SPN-lərin (AZUREADSSOACC) domain-də olduğu, Kerberos baş tutduğu. Hibrid join cihazda dsregcmd /status çıxışı problemin harada olduğunu söyləyər. Məsələn, AzureAdPrt : NO isə cihaz Azure AD-dən ayrı düşüb – bəlkə maşın Unregistered olub, onu yenidən join etmək lazımdır.
- İstifadəçi təcrübəsi və brauzer tövsiyələri: İstifadəçilərə tövsiyə edin ki, eyni vaxtda fərqli tenant hesabları ilə eyni brauzerdə işləyərkən Private window istifadə etsinlər. Bəzi SSO qarışıqlıqları bir brauzer profilində çoxlu girişdən olur. Chrome/Edge üçün üçüncü tərəf cookie-lərin Azure AD üçün bloklanmadığına əmin olun (Azure AD SSO, login.microsoftonline.com cookie-si üçün third-party cookie-yə ehtiyac duyur bəzən, xüsusən iframed SSO hallarında).
- Token lifetimes modern üsulla: Azure AD artıq refresh token lifetime-ı sabit saxlayır (90 gün sliding). Tuning üçün Conditional Access-dən başqa yol yoxdur. Yəni, köhnə Set-AzureADPolicy ilə AccessTokenLifetime 4 saat edim kimi şeylər web app-lər üçün tövsiyə olunmur (yalnız SharePoint Online üçün xüsusi hal istisna). Əgər sovet dövründən qalma bir TokenLifetimePolicy tapsanız, bilin ki, 2021-dən bəri refresh/session tokenlərə təsir etmir. Onu silmək də zərər verməz, confusion aradan qalxar.
- “Stay signed in?” prompt’unun düzgün idarəsi: Azure AD tenant səviyyəsində bir setting var (Company Branding altında) – “Show stay signed-in prompt?”. Əgər mütəmadi olaraq istifadəçilər bu prompt-u “No” edirsə, persistent cookie almırlar. Bunu avtomatik Yes cavab verilməsi üçün prompt-u disable etmək olar (Microsoft-un son tövsiyəsi budur ki, Conditional Access persistent session siyasətindən istifadə et, manual prompt-u söndür, çünki insanlar çaşır). Bu, birbaşa həll yolu deyil, lakin persistent login qəbul faizini artırır.
- SAML tətbiqetmələrində SSO timeout: Məsələn, SharePoint on-prem və Azure AD federasiyası varsa, SharePoint-də default sessiya qısadır. Onun Web SSO parametrlərini qaldırmaq lazımdır ki, Azure AD-nin verdiyi token hesabına local sessiya daha uzun yaşasın. Eyni cür, bəzi SAML/WS-Fed integrasiyalarında Azure AD-nin verdiyi token 1 saat valide, amma app refresh token mexanizmi istifadə etmir, nəticədə 1 saatda bir yenidən login olur. Həlli: müvafiq tətbiqin SSO modulunda konfiqurasiya – məsələn, wtrealm parametri və ya session cookie ömrü artırılmalıdır.
- MFA və cihaz şərtləri: Qeyd edək ki, bəzən yenidən giriş istənilməsi MFA yenilənməsi tələbi üzündən olur. Conditional Access-lə “require MFA every X days” kimi bir şey qurmusunuzsa, təbii ki, istifadəçilər periodik yenidən autentikasiya etməlidirlər. Bu, normaldır; əgər aradan qaldırılması istənilmirsə, həmin CA qaydasını yumşaltmaq lazımdır.
Bu tədbirlərlə, gözləmək olar ki: – İstifadəçilər daha uzun müddət fasiləsiz SSO təcrübəsi yaşayacaqlar. Məsələn, əvvəl hər gün Outlook Web app parol istəyirdisə, indi 90 günə qədər soruşmaya bilər (əgər persistent SSO aktivdirsə). – Sign-in Logs-da Flow token expired və ya oxşar error-ların sayı azalacaq. Məsələn, 50089 xətaları davamlı qeydə alınırdısa, Persistent session sayəsində bunlar demək olar görülməməlidir, çünki inaktiv tokenlər tez bitməyəcək. – Hybrid cihazlarda PRT problemi həll olunduqda, həmin cihazlarda artıq birbaşa SSO baş tutacaq (yenidən parol pəncərəsi çıxmayacaq). Bunun testini bir test istifadəçi ilə apara bilərsiniz: öncə problemli cihazda dsregcmd ile PRT “NO” idi, fix-dən sonra “YES” və expiry future tarixi olmalıdır, Sign-in loglarında həmin cihaz üçün Primary Refresh Token authentication entries successful görünməlidir.
Nəticə etibarilə, Azure AD-nin SSO davranışı dizayn olunduğu kimi işləyəcək – yəni istifadəçilər eyni etimadnaməni bir dəfə daxil etdikdən sonra icazəli bütün tətbiqlərə fasiləsiz keçid edə biləcəklər, və təyin etdiyiniz təhlükəsizlik parametrlərindən (MFA, tezlik) kənar əlavə maneələrlə üzləşməyəcəklər.
