Mac मा Kerberos SSO र VPN: दुई साइन-इन मार्गको तुलना गर्नुहोस्
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 डोमेन पुरानो हुन्छ। जो श्रृंखला कसैले वर्णन गर्न सक्दैन त्यो शृंखला कसैले डिबग गर्न सक्दैन।