Protected Users असलेल्या लॅपटॉपला साइन-इनपूर्वी VPN का आवश्यक आहे

लॅपटॉप, चालणारे खाते आणि हॉटेल नेटवर्क मिळून असा साइन-इन फेरा तयार होतो जो कोणत्याही पुनःप्रयत्नाने तुटत नाही. खाते Protected Users मध्ये आहे, जे Windows ला वापरकर्त्याची ऑफलाइन पडताळणी करण्यासाठी लागणारा पडताळणीकारक साठवू देत नाही. «आधी साइन इन करा, नंतर टनेल जोडा» अशा प्रकारच्या कोणत्याही योजनेत क्रम उलटा असतो, आणि संरक्षण अगदी जे वचन दिले आहे तेच करत असते. पुढील मजकूर समर्थित Windows होस्टवरील पारंपरिक Active Directory खाते गृहीत धरतो.

संरक्षण प्रत्यक्षात काय काढून टाकते

सामान्यतः Windows पडताळणीकारक कॅश करते जेणेकरून डोमेन खाते डोमेन नियंत्रक उपलब्ध नसतानाही साइन इन करू शकेल. Protected Users खात्यासाठी ते अडवते, ज्यामुळे ऑफलाइन डोमेन साइन-इन अविश्वसनीय करण्याऐवजी शक्यताच काढून टाकली जाते.

ही जुन्या कॅशेची नेहमीची अडचण नाही, आणि नेहमीचे उपाय इथे लागू होत नाहीत. वारंवार ऑनलाइन साइन इन करणे, अजून एकदा पासवर्ड बदलणे किंवा कॅश केलेल्या साइन-इनची संख्या वाढवणे यामुळे क्षमता परत येणार नाही, कारण यांपैकी कोणतीही क्रिया धोरण साठवण्यास नकार देते तो पडताळणीकारक तयार करत नाही. खाते रचनेनुसार वागत आहे, आणि रचना असे गृहीत धरते की Windows विचारते तेव्हा नेटवर्क उपस्थित असते. लक्षणाला कॅशे दोष मानणे हा तो मार्ग आहे ज्यामुळे संघ कधीही न तुटलेले प्रोफाइल पुन्हा बनवतात.

टनेल डेस्कटॉपपूर्वी का असणे आवश्यक आहे

Windows मागणी करते त्या क्षणी, म्हणजे कोणतेही वापरकर्ता सत्र अस्तित्वात येण्यापूर्वी उपकरणाने डोमेन पडताळणीपर्यंत पोहोचले पाहिजे. डेस्कटॉप दिसल्यानंतरच सुरू होणारा VPN क्लायंट नवीन साइन-इनला कधीही न येणाऱ्या मार्गाची वाट पाहायला लावतो. अवलंबित्व यंत्राचे आहे, अजून लॉग इन न केलेल्या वापरकर्त्याचे नाही.

एंडपॉइंट आणि ओळख मालकांशी सहमत समर्थित पूर्व-लॉगिन व्यवस्था वापरा. संगणक प्रमाणपत्राने प्रमाणित Always On VPN उपकरण टनेल तेव्हा योग्य ठरते जेव्हा व्यवस्थापित उपकरण त्या तैनातीच्या पूर्वअटी पूर्ण करते. विक्रेत्याचे समर्थित साइन-इन स्क्रीन एकत्रीकरण हा दुसरा पर्याय आहे. स्वयंचलित ट्रिगर असलेले सामान्य वापरकर्ता प्रोफाइल यापैकी कोणतेही नाही, क्लायंट इंटरफेसमध्ये कितीही सारखे दिसले तरी.

त्या मार्गाला डोमेनसाठी नाव निराकरण, पोहोचण्यायोग्य डोमेन नियंत्रक आणि खाते वापरू शकते ते प्रमाणीकरण प्रोटोकॉल लागतात, आणि «जोडलेले» हा निर्देशक यापैकी काहीही देत नाही. त्याचे मार्ग आणि गाळण्या ओळख सेवा वाहून नेणे आवश्यक आहे आणि गरजेचे नसलेले इतर काहीही नाही, कारण ती उपसर्ग यादी हीच ती पृष्ठभाग आहे जी चोरलेल्या लॅपटॉपला कोणी लॉग इन करण्यापूर्वी मिळते. वापरकर्ता टनेलसाठी घेतलेले विभाजित टनेलचे निर्णय उपकरण टनेलला लागू होत नाहीत, म्हणून दोन्ही स्वतंत्रपणे तपासा.

पोहोचणे म्हणजे प्रमाणीकरण सुसंगतता नाही

टनेल पॅकेट अगदी व्यवस्थित वाहू शकते पण डोमेन प्रमाणीकरण अयशस्वी होऊ शकते, कारण प्रयत्न केला जाणारा यंत्रणा हा खाते वापरू शकत नाही असा आहे. गटाच्या निर्बंधांची अंमलबजावणी करणाऱ्या डोमेनमध्ये सदस्यांना NTLM उपलब्ध नाही आणि Kerberos ला AES-सुसंगत खाते व संरचना लागते. पॅकेटचा मार्ग यापैकी काहीही दुरुस्त करू शकत नाही. म्हणूनच डोमेन नियंत्रकाला स्वच्छ ping हा साइन-इन चालेल याचा पुरावा नाही.

दोन क्रेडेन्शियल प्रणालीही कार्यरत असू शकतात. VPN ओळख पुरवठादारासमोर प्रमाणित होऊ शकते आणि Windows ला स्वतंत्रपणे डोमेन लॉगऑन लागते, आणि पहिल्याचा स्वीकार दुसऱ्याबद्दल काहीही सांगत नाही. «VPN जोडले» आणि «वापरकर्ता साइन इन झाला» या स्वतंत्र निरीक्षणे आहेत, आणि एक दुरुस्त केल्याने दुसरे सिद्ध होत नाही.

प्रमाणीकरणाचे पुरावे वाचा

एकाच प्रयत्नासाठी क्लायंटकडून आणि डोमेन नियंत्रकाकडून घटना गोळा करा, केवळ एका बाजूने नाही. Protected Users चे लॉग Applications and Services Logs\Microsoft\Windows\Authentication खाली आहेत, आणि काहीही नोंदवण्यापूर्वी प्रशासकाला लॉग सुरू करावा लागू शकतो. वेळेच्या ठशांची टनेलच्या स्वतःच्या जोडणी लॉगशी जुळवणी करा, कारण क्रमातील चूक दोन्ही बाजूंनी क्रेडेन्शियल दोषासारखी दिसते.

खालील पहिला आदेश उपकरण जे प्रत्येक प्रमाणीकरण लॉग उघड करते त्याची यादी करतो, म्हणून ब्लॉग पोस्टने नाव दिलेला नाही तर अस्तित्वात असलेला लॉग तुम्ही वाचता. दुसरा नाव माहीत झाल्यावर अलीकडील नोंदी वाचतो. प्रमाणीकरण पॅकेज, खाते आणि अयशस्वी होण्याची अट पहा, कारण गहाळ नेटवर्क मार्ग आणि नाकारलेली यंत्रणा वेगवेगळे पुरावे सोडतात आणि त्यापैकी फक्त एकच VPN समस्या आहे. प्रयत्नानंतर टनेल वर आले असेल, तर त्या नोंदी काहीही म्हणोत, क्रम चुकीचा होता.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

थंड बूटपासून सीमा सिद्ध करा

चाचणी साइन आउट किंवा नुकत्याच बूट झालेल्या स्थितीतून मर्यादित खात्यासह चालवा, आणि विशेषाधिकारित वापरकर्त्यांसाठी काहीही बदलण्यापूर्वी मंजूर पुनर्प्राप्ती मार्ग उघडा ठेवा. आधीच चालू असलेल्या डेस्कटॉपवरील चाचणी महत्त्वाच्या कोड मार्गाचा कोणताही भाग वापरत नाही, आणि यामुळेच पुढील रीबूटपर्यंत टिकलेल्या दुरुस्तीबद्दलचे बहुतेक अहवाल स्पष्ट होतात. नंतर चार पायऱ्या याच क्रमाने पूर्ण करा.

1. कोणीही साइन इन करण्यापूर्वी उपकरण डोमेन नियंत्रक शोधू शकते याची nltest /dsgetdc:corp.example.com ने खात्री करा.
2. डोमेन साइन-इनचा प्रयत्न करा, नंतर klist ने विचारा की तिकीट मिळालेच का.
3. उपकरण जो प्रमाणीकरण लॉग नोंदवतो तो वरील दोन आदेशांनी वाचा, आणि पॅकेज व अयशस्वी होण्याची अट नोंदवा.
4. मंजूर पुनर्प्राप्ती क्रेडेन्शियल अजूनही साइन-इन स्क्रीनवरून चालते याची खात्री करा, कारण सीमा चाचणी अयशस्वी झाल्यास परत जाण्याचा तोच एकमेव मार्ग आहे.

दिलेल्या क्रेडेन्शियलसह फाइल शेअर उघडणेही ऑफलाइन संवादात्मक लॉगऑन तयार करत नाही, म्हणून ते वरील कोणत्याही पायरीचा पर्याय नाही. संस्थेला खरोखर जोडणीविना साइन-इन हवे असेल, तर उत्तर म्हणजे जाणीवपूर्वक निवडलेली सुसंगत खाते व एंडपॉइंट रचना. खाते गटातून बाहेर काढणे, किंवा प्रत्येक लॅपटॉपवर एक अमर्यादित आपत्कालीन लॉगिन ठेवणे, हा ओळख धोरणाचा निर्णय आहे जो VPN बदल तुमच्यावतीने घेऊ शकत नाही.

Protected Users ची माहितीपत्रके पडताळणीकारकाचे वर्तन आणि ही रचना ज्या डोमेन निर्बंधांवर अवलंबून आहे त्या दोन्हींचे वर्णन करतात. कोणी प्रवास करण्यापूर्वी पुनर्प्राप्ती प्रक्रियेचे नियोजन करा, कारण थंड-बूट चाचणी हीच ती एकमेव जागा आहे जिथे त्याचा सराव होतो.