Mac पर Kerberos SSO और VPN: दो साइन-इन रास्तों की तुलना करें

दो तंत्र Mac पर एक ही सुखद परिणाम देते हैं और अंदर से बिल्कुल अलग व्यवहार करते हैं। एक SSO एक्सटेंशन के ज़रिए Kerberos टिकट लेता है और उन्हें भाग लेने वाले अनुप्रयोगों को देता है। दूसरा किसी पहचान प्रदाता के साथ ब्राउज़र सत्र रखता है और वेब अनुप्रयोगों को उसे स्वीकार करने देता है। वे इस बात में भिन्न हैं कि उन्हें नेटवर्क पर क्या चाहिए, उनके क्रेडेंशियल कितने समय टिकते हैं, और जिस पल सुरंग गिरती है तब क्या होता है।

दो तंत्र, एक साइन-इन स्क्रीन

टिकट आधारित रास्ता Kerberos डोमेन, कुंजी वितरण केंद्र और उससे मेल खाने वाली घड़ी पर निर्भर है। ब्राउज़र का रास्ता एक पहुँच योग्य पहचान प्रदाता, कुकी या टोकन, और उस जारीकर्ता पर भरोसा करने वाले अनुप्रयोग पर निर्भर है। दोनों को साइन-इन पर शुरू होने के लिए कॉन्फ़िगर किया जा सकता है, इसलिए इन्हें एक ही सुविधा समझ लिया जाता है। अनुप्रयोग तय करते हैं कि दोनों में से किसे स्वीकार करना है, और Mac कानूनी रूप से दोनों एक साथ चला सकता है।

उनकी तुलना यह पूछकर करें कि उपयोगकर्ता के अनुप्रयोग खोलने पर वह क्या जाँचता है। Kerberos डोमेन से जुड़ी फ़ाइल सेवा को सेवा टिकट चाहिए, और ब्राउज़र सत्र की कोई भी मात्रा उसे संतुष्ट नहीं करेगी। आधुनिक पहचान प्रदाता के पीछे का वेब अनुप्रयोग उस प्रदाता का टोकन चाहता है और Kerberos टिकट को पूरी तरह नज़रअंदाज़ करता है। एक बार जान लेने पर कि कौन-सी जाँच होती है, तैनाती के प्रश्न सामान्य के बजाय विशिष्ट हो जाते हैं।

Kerberos एक्सटेंशन को नेटवर्क पर क्या चाहिए

Apple की Kerberos SSO एक्सटेंशन मार्गदर्शिका सक्रिय टिकट प्राप्ति के साथ मूल Active Directory प्रमाणीकरण का वर्णन करती है, जो डोमेन बाइंडिंग के बजाय स्थानीय खातों के साथ जोड़ा गया है। जो यह नहीं कर सकती वह है डोमेन नियंत्रकों तक कोई रास्ता गढ़ना। Mac को ऐसा रिज़ॉल्वर चाहिए जो Kerberos सेवा रिकॉर्ड का उत्तर दे, और ऐसा मार्ग चाहिए जो स्वीकृत सुरंग से उन तक पहुँचे। जो प्रोफ़ाइल साफ़ तौर पर इंस्टॉल होती है वह तब तक कुछ साबित नहीं करती जब तक डोमेन वास्तव में क्लाइंट से खोजा न जा सके।

क्रेडेंशियल जाँचने से पहले खोज जाँचें: Kerberos डोमेन के SRV रिकॉर्ड हल होने चाहिए, और उनके लौटाए पते VPN चालू होने पर पहुँच योग्य होने चाहिए। समय भी पहुँच जितना ही महत्वपूर्ण है, क्योंकि Kerberos उस घड़ी से आए अनुरोध अस्वीकार करता है जो उसकी सहनशीलता से आगे बढ़ चुकी हो, और जो त्रुटि उत्पन्न होती है वह प्रमाणीकरण विफलता जैसी दिखती है। जो Mac सुरंग बंद होने पर समय स्रोत तक नहीं पहुँच सकता वह लौटते ही फिर विफल होगा। घड़ी के स्रोत को घटना प्रतिक्रिया के बजाय तैनाती के हिस्से के रूप में ठीक करें।

klist
sudo sntp -sS time.apple.com

प्रति-ऐप VPN तय करता है कि एक्सटेंशन काम कर सकता है या नहीं

पूरी सुरंग सब कुछ रूट करती है और इस समस्या को छिपा देती है। प्रति-ऐप कॉन्फ़िगरेशन केवल VPN प्रोफ़ाइल में नामित अनुप्रयोगों को रूट करता है, और SSO एक्सटेंशन स्वयं ऐसी प्रक्रिया है जिसे टिकट लाने के लिए नेटवर्क चाहिए। यदि यह मैपिंग में नहीं है, तो स्थानीय साइन-इन सफल होता है, ब्राउज़र के लिए सुरंग ऊपर आती है, और टिकट प्राप्ति फिर भी विफल होती है।

VPN कॉन्फ़िगरेशन पढ़ें और हर उस अनुप्रयोग को सूचीबद्ध करें जिसे इसे कवर करना है, फिर बंडल पहचानकर्ता का अनुमान लगाने के बजाय प्रलेखित मैपिंग तंत्र से SSO घटक जोड़ें। दिखाई देने वाले क्लाइंट को मैप करना और उसके पीछे के घटक को नहीं, इस त्रुटि का उत्कृष्ट उदाहरण है। मैपिंग को एक्सटेंशन के साथ उसी प्रबंधित प्रोफ़ाइल में रखें, ताकि एक में बदलाव दूसरे को चुपचाप अमान्य न कर सके। ऐसे उपयोगकर्ता के साथ जाँचें जिसने उस Mac पर कभी साइन-इन नहीं किया, क्योंकि कैश किया गया टिकट टूटे रास्ते को स्वस्थ दिखा सकता है, फिर पासवर्ड बदलने के बाद दोबारा जाँचें।

ब्राउज़र पहचान सत्र एक अलग अनुबंध है

ब्राउज़र सत्र में कोई Kerberos डोमेन नहीं, कोई सेवा टिकट नहीं और Kerberos अर्थ में कोई घड़ी सहनशीलता नहीं होती। इसमें एक जारीकर्ता, टोकन का जीवनकाल और रिफ़्रेश मार्ग होता है, और इसकी विफलता के तरीके ऐसे रीडायरेक्ट हैं जो कभी पूरे नहीं होते और ऐसी कुकीज़ हैं जिन्हें निजी विंडो फेंक देती है। इसे टिकट रास्ते का विकल्प मानना केवल वहाँ सुरक्षित है जहाँ अनुप्रयोग स्वयं उस जारीकर्ता को स्वीकार करता है। VPN पोर्टल से प्रमाणीकरण प्रतिक्रिया को किसी असंबंधित सेवा में कॉपी करना एकीकरण नहीं है, शॉर्टकट कितना भी सुविधाजनक लगे।

जब दोनों तंत्र तैनात हों, तो प्रलेखित करें कि कौन-से अनुप्रयोग किसका उपयोग करते हैं, क्योंकि सहायता बातचीत इसी पर निर्भर है। जो उपयोगकर्ता कहता है कि वह साइन-इन है पर फ़ाइल शेयर नहीं खोल सकता, वह दो सिस्टम बता रहा है, और उत्तर यह है कि टिकट रास्ता कभी चला ही नहीं। जो उपयोगकर्ता शेयर खोल सकता है पर इंट्रानेट पोर्टल नहीं, वह उलटा बता रहा है, और टिकट में तंत्र का नाम लेने से प्रश्नों का एक दौर बचता है।

क्रम से चलें, टुकड़ों से नहीं

सामान्य नामांकित खाते के साथ पूरी श्रृंखला चलें: स्थानीय साइन-इन, सुरंग, टिकट प्राप्ति, फिर किसी सेवा के विरुद्ध एक वास्तविक क्रिया। सुरंग के फिर से जुड़ने के बाद और जानबूझकर पासवर्ड बदलने के बाद इसे दोहराएँ, क्योंकि इनमें से हर स्थिति जीवनकाल तर्क का अलग हिस्सा आज़माती है। हर चरण का अकेले पास होना श्रृंखला के काम करने के बराबर नहीं है। श्रृंखला वही है जो उपयोगकर्ता अनुभव करता है, और वही स्वीकृति मामले को कवर करना चाहिए।

प्रोफ़ाइल स्वामी, VPN प्रमाणीकरण विधि, डोमेन खोज मार्ग और एक्सटेंशन की अनुप्रयोग मैपिंग एक ही जगह दर्ज करें। वही रिकॉर्ड प्रवाह को ऐसे व्यक्ति के लिए पुनरुत्पाद्य बनाता है जिसने इसे बनाया नहीं। फिर सबसे संभावित विफलता जाँचें, सुरंग बंद होने पर समाप्त टिकट, और पुष्टि करें कि क्लाइंट रीबूट के बिना उबर जाता है, क्योंकि केवल ठंडी शुरुआत से चलने वाली तैनाती पूरी नहीं हुई।

हर चरण के स्वामी को भी दर्ज करें, क्योंकि जिस Kerberos डोमेन की कोई देखभाल नहीं करता वह पुराना हो जाता है। जिस श्रृंखला को कोई बता नहीं सकता, वह ऐसी श्रृंखला है जिसे कोई डिबग नहीं कर सकता।