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 डोमेन जुना होतो। जी साखळी कोणीही वर्णन करू शकत नाही ती साखळी कोणीही डीबग करू शकत नाही।