सिंगल साइन-ऑन (एसएसओ) से जुड़ी समस्या हल करना

इस दस्तावेज़ में, Google Workspace के साथ सिंगल साइन-ऑन (एसएसओ) को इंटिग्रेट करने या उसका इस्तेमाल करने के दौरान मिलने वाले सामान्य गड़बड़ी के मैसेज को ठीक करने का तरीका बताया गया है. इसमें यह माना गया है कि Google, सर्विस प्रोवाइडर (एसपी) है.

कॉन्फ़िगरेशन और चालू करना

"इस डोमेन को सिंगल साइन-ऑन का इस्तेमाल करने के लिए कॉन्फ़िगर नहीं किया गया है."

आम तौर पर, यह गड़बड़ी तब दिखती है, जब Google Workspace के ऐसे वर्शन का इस्तेमाल किया जा रहा हो जिसमें एसएसओ की सुविधा काम नहीं करती. जैसे, G Suite का लेगसी मुफ़्त वर्शन. Workspace के मौजूदा सभी वर्शन में, तीसरे पक्ष के आइडेंटिटी प्रोवाइडर (आईडीपी) के ज़रिए एसएसओ की सुविधा काम करती है.

अगर Google Workspace के ऐसे वर्शन का इस्तेमाल किया जा रहा है जिसमें एसएसओ की सुविधा काम करती है, तो इन अन्य तरीकों को आज़माएं:

पुष्टि करें कि आपके IdP के एसएसओ कॉन्फ़िगरेशन में, Google Workspace के सही डोमेन नेम का इस्तेमाल किया जा रहा हो.
अगर आपको एसएसओ प्रोफ़ाइलें सेट अप करने के बाद यह गड़बड़ी दिखती है, तो हो सकता है कि आपका आईडीपी, एसएएमएल असर्शन को लेगसी एसएसओ प्रोफ़ाइल के एंडपॉइंट पर भेजने के लिए कॉन्फ़िगर किया गया हो. अगर आपके आईडीपी में लेगसी एसएसओ एंडपॉइंट हार्ड-कोड किया गया है, तो कृपया यह तरीका अपनाएं:
1. लेगसी एसएसओ सेट अप करें.
2. अपने IdP वेंडर से, Google इंटिग्रेशन को अपडेट करने के लिए कहें.

"इस खाते को ऐक्सेस नहीं किया जा सकता, क्योंकि डोमेन को गलत तरीके से कॉन्फ़िगर किया गया है. कृपया बाद में फिर से कोशिश करें."

इस गड़बड़ी का मतलब है कि आपने Google Admin console में एसएसओ को सही तरीके से सेट अप नहीं किया है. इस समस्या को ठीक करने के लिए, यह तरीका अपनाएं:

Admin console में, सुरक्षा तीसरे पक्ष के IdP की मदद से सिंगल साइन-ऑन (एसएसओ) सेट अप करें पर जाएं. इसके बाद, तीसरे पक्ष की पहचान देने वाली सेवा के साथ एसएसओ (SSO) सेट अप करें को चुनें.
अपने संगठन के साइन-इन पेज, साइन-आउट पेज, और पासवर्ड बदलने वाले पेज के यूआरएल, उनसे जुड़े फ़ील्ड में डालें.
पुष्टि करने के लिए सर्टिफ़िकेट की कोई मान्य फ़ाइल चुनें और उसे अपलोड करें.
सेव करें पर क्लिक करें. इसके बाद, बदलावों के लागू होने में कुछ मिनट लग सकते हैं. इसके बाद, इंटिग्रेशन को फिर से टेस्ट करें.

Google Tenant को ऐसे प्रीफ़िक्स के साथ कॉन्फ़िगर किया गया है जिसका इस्तेमाल नहीं किया जा सकता

iOS ऐप्लिकेशन के लिए, जब एसएसओ साइन-इन पेज का यूआरएल "google." से शुरू होता है (या कुछ और), तो Google iOS ऐप्लिकेशन को Safari पर रीडायरेक्ट कर दिया जाता है. इस वजह से, एसएसओ की प्रोसेस पूरी नहीं हो पाती. जिन प्रीफ़िक्स का इस्तेमाल नहीं किया जा सकता उनकी पूरी सूची यहां दी गई है:

googl.
Google पर टैप करें.
www.googl.
www.google.

आपको एसएसओ साइन-इन पेज के उन सभी यूआरएल को बदलना होगा जिनमें ये प्रीफ़िक्स मौजूद हैं.

एसएएमएल रिस्पॉन्स को पार्स करना

"ज़रूरी रिस्पॉन्स पैरामीटर SAMLResponse मौजूद नहीं था"

इस गड़बड़ी के मैसेज का मतलब है कि आपका आइडेंटिटी प्रोवाइडर, Google को किसी तरह का मान्य SAML रिस्पॉन्स नहीं दे रहा है. यह समस्या, आइडेंटिटी प्रोवाइडर में कॉन्फ़िगरेशन से जुड़ी गड़बड़ी की वजह से हो सकती है.

अपने आइडेंटिटी प्रोवाइडर के लॉग देखें और पक्का करें कि कोई ऐसी समस्या न हो जिसकी वजह से SAML रिस्पॉन्स सही तरीके से न मिल रहा हो.
पक्का करें कि आपका आइडेंटिटी प्रोवाइडर, Google Workspace को एन्क्रिप्ट (सुरक्षित) किया गया SAML रिस्पॉन्स न भेज रहा हो. Google Workspace सिर्फ़ ऐसे एसएएमएल रिस्पॉन्स स्वीकार करता है जिन्हें एन्क्रिप्ट (सुरक्षित) नहीं किया गया है. खास तौर पर, कृपया ध्यान दें कि Microsoft की Active Directory Federation Services 2.0, अक्सर डिफ़ॉल्ट कॉन्फ़िगरेशन में एन्क्रिप्ट (सुरक्षित) किए गए SAML रिस्पॉन्स भेजती है.

"ज़रूरी रिस्पॉन्स पैरामीटर RelayState मौजूद नहीं था"

SAML 2.0 स्पेसिफ़िकेशन के मुताबिक, पहचान देने वाली कंपनियों को संसाधन उपलब्ध कराने वाली कंपनियों (जैसे, Google Workspace) से RelayState यूआरएल पैरामीटर को वापस पाना और भेजना होता है. Google Workspace, इस वैल्यू को एसएएमएल अनुरोध में आइडेंटिटी प्रोवाइडर को देता है. साथ ही, हर लॉगिन में कॉन्टेंट अलग-अलग हो सकता है. पुष्टि की प्रोसेस पूरी करने के लिए, SAML रिस्पॉन्स में सटीक RelayState वैल्यू वापस मिलनी चाहिए. एसएएमएल के स्टैंडर्ड स्पेसिफ़िकेशन के मुताबिक, लॉगिन फ़्लो के दौरान आइडेंटिटी प्रोवाइडर को RelayState में बदलाव नहीं करना चाहिए.

लॉग इन करने की कोशिश के दौरान, एचटीटीपी हेडर कैप्चर करके इस समस्या का पता लगाएं. SAML अनुरोध और जवाब, दोनों के साथ एचटीटीपी हेडर से RelayState निकालें. साथ ही, पक्का करें कि अनुरोध और जवाब में RelayState की वैल्यू मेल खाती हों.
व्यावसायिक तौर पर उपलब्ध या ओपन-सोर्स वाले ज़्यादातर एसएसओ आइडेंटिटी प्रोवाइडर, डिफ़ॉल्ट रूप से RelayState को आसानी से ट्रांसमिट करते हैं. हमारा सुझाव है कि आप बेहतर सुरक्षा और भरोसेमंद तरीके से काम करने के लिए, इनमें से किसी एक मौजूदा समाधान का इस्तेमाल करें. हम आपके कस्टम एसएसओ सॉफ़्टवेयर के लिए सहायता नहीं दे सकते.

एसएएमएल रिस्पॉन्स का कॉन्टेंट

"इस सेवा को ऐक्सेस नहीं किया जा सकता, क्योंकि आपके लॉगिन अनुरोध में [destination|audience|recipient] की अमान्य जानकारी शामिल है. कृपया लॉग इन करें और फिर से कोशिश करें."

इस गड़बड़ी से पता चलता है कि SAML असर्शन में मौजूद destination, audience या recipient एलिमेंट में अमान्य जानकारी मौजूद थी या वे खाली थे. सभी एलिमेंट को SAML असर्शन में शामिल करना ज़रूरी है. हर एलिमेंट की जानकारी और उदाहरण देखने के लिए, एसएसओ असर्शन की ज़रूरी शर्तें में दी गई ये टेबल देखें:

"इस सेवा को ऐक्सेस नहीं किया जा सकता, क्योंकि आपके लॉगिन अनुरोध में पाने वाले की कोई जानकारी शामिल नहीं है. कृपया लॉग इन करें और फिर से कोशिश करें."

आम तौर पर, इस गड़बड़ी का मतलब है कि आपके आइडेंटिटी प्रोवाइडर से मिले SAML रिस्पॉन्स में, Recipient एट्रिब्यूट की वैल्यू ऐसी है जिसे पढ़ा नहीं जा सकता. इसके अलावा, यह भी हो सकता है कि Recipient एट्रिब्यूट की वैल्यू गलत हो. Recipient वैल्यू, एसएएमएल रिस्पॉन्स का एक अहम हिस्सा होती है.

लॉग इन करने की कोशिश के दौरान, एचटीटीपी हेडर कैप्चर करके इस समस्या का पता लगाएं.
एचटीटीपी हेडर से एसएएमएल अनुरोध और जवाब को एक्सट्रैक्ट करें.
पक्का करें कि SAML रिस्पॉन्स में Recipient वैल्यू मौजूद हो और वह SAML अनुरोध में मौजूद वैल्यू से मेल खाती हो.

ध्यान दें: यह गड़बड़ी का मैसेज, "इस सेवा को ऐक्सेस नहीं किया जा सकता, क्योंकि आपके लॉगिन अनुरोध में अमान्य ईमेल पते की जानकारी शामिल है. कृपया लॉग इन करें और फिर से कोशिश करें."

इस गड़बड़ी का मतलब है कि पुष्टि करने के फ़्लो पर हस्ताक्षर करने के लिए इस्तेमाल किए जा रहे सर्टिफ़िकेट में कोई समस्या है. इसका आम तौर पर मतलब यह होता है कि SAML रिस्पॉन्स पर हस्ताक्षर करने के लिए इस्तेमाल की गई निजी कुंजी, Google Workspace के पास मौजूद सार्वजनिक कुंजी के प्रमाणपत्र से मेल नहीं खाती.

ऐसा तब भी हो सकता है, जब आपके SAML रिस्पॉन्स में Google खातों का मान्य उपयोगकर्ता नाम न हो. Google Workspace, NameID नाम के एक्सएमएल एलिमेंट के लिए, एसएएमएल रिस्पॉन्स को पार्स करता है. साथ ही, यह उम्मीद करता है कि इस एलिमेंट में Google Workspace का उपयोगकर्ता नाम या पूरा Google Workspace ईमेल पता शामिल हो.

पक्का करें कि आपने Google Workspace में मान्य सर्टिफ़िकेट अपलोड किया हो. अगर ज़रूरी हो, तो सर्टिफ़िकेट बदलें. Google Admin console में, सुरक्षा तीसरे पक्ष के IdP की मदद से सिंगल साइन-ऑन (एसएसओ) सेट अप करें पर जाएं. इसके बाद, सर्टिफ़िकेट बदलें पर क्लिक करें.
अगर आपने अपने NameID एलिमेंट में पूरे ईमेल पते का इस्तेमाल किया है, तो पक्का करें कि NameID एलिमेंट के Format एट्रिब्यूट में यह बताया गया हो कि पूरे ईमेल पते का इस्तेमाल किया जाना है. अगर आपने एक से ज़्यादा डोमेन वाले Apps एनवायरमेंट के साथ एसएसओ का इस्तेमाल किया है, तो आपको पूरे ईमेल पते का इस्तेमाल करना होगा. यहां दिए गए उदाहरण में, Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress". का इस्तेमाल किया गया है.
पक्का करें कि NameID एलिमेंट में, मान्य उपयोगकर्ता नाम या ईमेल पता डाला गया हो. पक्का करने के लिए, Google Workspace को भेजे जा रहे SAML रिस्पॉन्स को एक्सट्रैक्ट करें. इसके बाद, NameID एलिमेंट की वैल्यू देखें.
NameID केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होता है: पक्का करें कि SAML रिस्पॉन्स, NameID को ऐसी वैल्यू के साथ पॉप्युलेट कर रहा हो जो Google Workspace के उपयोगकर्ता नाम या ईमेल पते के केस से मेल खाती हो.
अगर आपका आइडेंटिटी प्रोवाइडर, आपके SAML असर्शन को एन्क्रिप्ट (सुरक्षित) कर रहा है, तो एन्क्रिप्शन की सुविधा बंद करें.
पक्का करें कि SAML रिस्पॉन्स में कोई भी नॉन-स्टैंडर्ड ASCII वर्ण शामिल न हों. यह समस्या आम तौर पर, AttributeStatement में मौजूद DisplayName, GivenName, और Surname एट्रिब्यूट में होती है. उदाहरण के लिए:
- <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
  <AttributeValue>Blüte, Eva</AttributeValue> </Attribute>
- <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
  <AttributeValue>Blüte</AttributeValue> </Attribute>

NameID एलिमेंट को फ़ॉर्मैट करने के तरीके के बारे में ज़्यादा जानने के लिए, एसएसओ असर्शन से जुड़ी ज़रूरी शर्तें देखें.

"इस सेवा को ऐक्सेस नहीं किया जा सकता, क्योंकि आपके लॉगिन क्रेडेंशियल की समयसीमा खत्म हो गई है. कृपया लॉग इन करें और फिर से कोशिश करें."

सुरक्षा कारणों से, एसएसओ लॉगिन फ़्लो को तय समयसीमा में पूरा करना ज़रूरी है. ऐसा न होने पर, पुष्टि नहीं हो पाएगी. अगर आपके आइडेंटिटी प्रोवाइडर पर मौजूद घड़ी गलत है, तो लॉगिन करने की ज़्यादातर या सभी कोशिशें, तय समयसीमा से बाहर दिखेंगी. साथ ही, पुष्टि करने की प्रक्रिया पूरी नहीं होगी और आपको ऊपर दिया गया गड़बड़ी का मैसेज दिखेगा.

अपने Identity Provider के सर्वर पर मौजूद घड़ी देखें. यह गड़बड़ी, पहचान देने वाली सेवा के गलत समय की वजह से होती है. इससे SAML रिस्पॉन्स में गलत टाइमस्टैंप जुड़ जाते हैं.
पहचान देने वाली कंपनी के सर्वर की घड़ी को, इंटरनेट पर समय बताने वाले भरोसेमंद सर्वर के साथ फिर से सिंक करें. जब प्रोडक्शन एनवायरमेंट में अचानक यह समस्या होती है, तो आम तौर पर ऐसा इसलिए होता है, क्योंकि पिछली बार सिंक नहीं हो पाया था. इस वजह से, सर्वर का समय गलत हो जाता है. समय सिंक करने की प्रोसेस को दोहराने से, इस समस्या को तुरंत ठीक किया जा सकता है. इसके लिए, किसी ज़्यादा भरोसेमंद टाइम सर्वर का इस्तेमाल किया जा सकता है.
यह समस्या तब भी हो सकती है, जब पिछली बार लॉगिन करने की कोशिश के दौरान भेजे गए एसएएमएल को फिर से भेजा जा रहा हो. एसएएमएल अनुरोध और जवाब की जांच करने से, इस समस्या को ठीक करने में मदद मिल सकती है. यह अनुरोध और जवाब, लॉगिन करने की कोशिश के दौरान कैप्चर किए गए एचटीटीपी हेडर लॉग से मिलता है.

"इस सेवा को ऐक्सेस नहीं किया जा सकता, क्योंकि आपके लॉगिन क्रेडेंशियल अब भी मान्य नहीं हैं. कृपया लॉग इन करें और फिर से कोशिश करें."

अपने Identity Provider के सर्वर पर मौजूद घड़ी देखें. यह गड़बड़ी, पहचान देने वाली सेवा के गलत समय की वजह से होती है. इससे SAML रिस्पॉन्स में गलत टाइमस्टैंप जुड़ जाते हैं.
पहचान देने वाली कंपनी के सर्वर की घड़ी को, इंटरनेट पर समय बताने वाले भरोसेमंद सर्वर के साथ फिर से सिंक करें. जब प्रोडक्शन एनवायरमेंट में अचानक यह समस्या होती है, तो आम तौर पर ऐसा इसलिए होता है, क्योंकि पिछली बार सिंक नहीं हो पाया था. इस वजह से, सर्वर का समय गलत हो जाता है. समय सिंक करने की प्रोसेस को दोहराने से, इस समस्या को तुरंत ठीक किया जा सकता है. इसके लिए, किसी ज़्यादा भरोसेमंद टाइम सर्वर का इस्तेमाल किया जा सकता है.