हरवलेला VPN प्रमाणक: MFA बंद न करता बदला
हरवलेला घटक हे पुनर्प्राप्तीचे काम आहे, व्यत्यय नाही। अयशस्वी मार्गाबाहेर पडताळणी करा, बदली नोंदवा, जुनी पद्धत मागे घ्या आणि नंतर लॉगिन चालते हे सिद्ध करा।
एखाद्याचा फोन हरवतो आणि तिकीट VPN बिघडले असे येते। ही चौकट दोनदा चुकीची आहे: खाते अजूनही अस्तित्वात आहे, आणि गेटवे अजूनही ओळख पुरवठादारावर विश्वास ठेवतो, त्यामुळे बिघडलेला एकमेव भाग म्हणजे व्यक्तीकडे आता नसलेला एक घटक। त्याकडे व्यत्यय नाही, पुनर्प्राप्ती म्हणून पहा: विनंतीकर्त्याची पडताळणी करा, बदली नोंदवा, हरवलेली पद्धत मागे घ्या आणि नंतर खाते चालते हे सिद्ध करा। हे सर्व असे गृहीत धरते की योजना हानीपूर्वी लिहिली होती, कारण कॉलदरम्यान ती तयार करणे हाच मार्ग MFA सर्वांसाठी बंद होण्याकडे नेतो।
पायरी 1: नोंदणीकृत घटक स्मरणातून नाही, नोंदीतून वाचा
पहिला प्रश्न कोणते उपकरण हरवले हा नाही, तर खाते आणखी काय वापरू शकते हा आहे। खात्यात पासवर्डसह पुश, वेळ-आधारित कोड, हार्डवेअर की आणि छापलेले पुनर्प्राप्ती कोड असू शकतात, आणि त्यापैकी एक हरवणे हे एकमेव हरवण्यापेक्षा पूर्णपणे वेगळी घटना आहे। वापरकर्त्याला लक्षात ठेवायला सांगण्याऐवजी ओळख प्रणालीतून पद्धतींची यादी वाचा, आणि Microsoft Entra टेनंटमध्ये क्वेरी एक ओळ आहे:
Get-MgUserAuthenticationMethod -UserId [email protected]
मग खाते अजून चालत असताना पुनर्प्राप्ती नोंद लिहा: खाते ओळखकर्ता, नोंदणीकृत घटक, पुनर्प्राप्ती कोड कुठे राहतात, कोण विनंतीकर्त्याची स्वतंत्रपणे पडताळणी करू शकतो आणि खाते कोणत्या प्रणालींपर्यंत पोहोचते। ती संघ आधीच वापरत असलेल्या संरक्षित इन्व्हेंटरीत ठेवा, कधीही सक्रिय कोड असलेल्या टिपेत ठेवू नका। ती पाच क्षेत्रे घाबरलेल्या कॉलचे चेकलिस्टमध्ये रूपांतर करतात, आणि NISTचे प्रमाणक जीवनचक्र मार्गदर्शन पुनर्प्राप्तीला क्रेडेन्शियलचा भाग मानते, त्यातील अपवाद नाही।
पडताळणी वाहिनी स्वतंत्र क्षेत्र म्हणून नोंदवा, कारण लोक हाच भाग वगळतात। खात्याशी जोडलेला फोन क्रमांक स्वतंत्र वाहिनी नाही जेव्हा मागणारी व्यक्तीच फोन नियंत्रित करते।
पायरी 2: विनंतीकर्त्याची अयशस्वी मार्गाबाहेर पडताळणी करा
ओळख तपासणी VPN, मेलबॉक्स किंवा हरवलेल्या उपकरणावर अवलंबून नसलेल्या वाहिनीतून करा। मनुष्यबळ नोंदीतील क्रमांकावर परतीचा कॉल, किंवा डिरेक्टरीत आधीच असलेल्या व्यवस्थापकासोबत प्रत्यक्ष तपासणी, दोन्ही चालतात; पुनर्प्राप्तीखालील खात्यातून पाठवलेला चॅट संदेश चालत नाही। तपासणी व्यक्तीबद्दल आहे, खात्याबद्दलच्या प्रश्नांची उत्तरे देण्याच्या क्षमतेबद्दल नाही, कारण खात्याचे तपशील गळतात। कोणी केव्हा विनंतीची पडताळणी केली ते नोंदवा, कारण पुढील पुनरावलोकनकर्त्याला दोन्ही हवे असते।
विनंती तातडीने आणि तपासणी वगळण्याच्या दबावाने आली की तोच संथ होण्याचा क्षण। पुनर्प्राप्ती फसवणूक घाईत असलेल्या मदतशील सहकाऱ्यासारखीच दिसते।
पायरी 3: बदली नोंदवा, मग जुना घटक मागे घ्या
नवीन प्रमाणक नेहमीच्या नोंदणी प्रवाहातून नोंदवा, कधीही प्रशासकीय बायपासने नाही। मग हरवलेली पद्धत स्पष्टपणे काढून टाका, कारण बदली नोंदवल्याने पूर्वीचा प्रमाणक कोणी मागे घेईपर्यंत अधिकृत राहतो। जुने उपकरण दुसऱ्याच्या हातात असू शकत असेल, तर काढणे तातडीचे माना आणि पुनर्प्राप्तीऐवजी घटना प्रक्रिया अनुसरा। त्याच फेरीत विद्यमान सत्रे रद्द करा, कारण बदलापूर्वी तयार केलेले सत्र त्याच्यापेक्षा जास्त टिकू शकते:
Revoke-MgUserSignInSession -UserId [email protected]
बाकीच्या सर्वांसाठी घटक काढणे, किंवा गेटवेच्या प्रमाणपत्र तपासण्या सैल करणे, एका व्यक्तीच्या पुनर्प्राप्तीच्या बदल्यात संपूर्ण तैनातीला लागणारा व्यत्यय घेते। बदल एकाच खात्यापुरता मर्यादित ठेवा आणि पुरावे मोठ्या तडजोडीकडे निर्देश करत असतील तर वर न्या। तिकिटात कोणता घटक मागे घेतला आणि कोणी त्याची जागा घेतली ते नोंदवा।
पायरी 4: खाते दोन्ही दिशांनी चालते हे सिद्ध करा
समर्थित क्लायंटद्वारे नवीन घटकाने एकदा लॉगिन करा, मग हानीपूर्वी पोहोचणाऱ्या संसाधनांपर्यंत खाते अजूनही पोहोचते याची खात्री करा। टनेल लागणारे एक संसाधन आणि न लागणारे एक तपासा, जेणेकरून अपयश योग्य स्तराकडे निर्देश करेल। मागे घेतलेल्या घटकाने लॉगिनचा प्रयत्न करा आणि प्रॉम्प्टऐवजी नकाराची अपेक्षा करा, जे काढणे प्रभावी झाले हे सिद्ध करते। विद्यमान नोंदणीकृत उपकरणावरून अयशस्वी होणारे आव्हान ही प्रॉम्प्टची समस्या आहे, सर्व काही पुन्हा नोंदवण्याचे कारण नाही।
मग वापरकर्त्याला तेच लॉगिन मार्गदर्शनाशिवाय पूर्ण करायला सांगा। तुमची यशस्वी चाचणी संरचना सिद्ध करते; त्यांचा प्रयत्न हस्तांतरण सिद्ध करतो।
यशस्वी लॉगिनच्या वेळमुद्रेसह आणि आता वापरल्या जाणाऱ्या घटकाच्या नावासह तिकीट बंद करा। त्याच फेरीत पुनर्प्राप्ती नोंद अद्ययावत करा, जेणेकरून पुढील हानी जुन्या नाही, अचूक इन्व्हेंटरीतून सुरू होईल।
पायरी 5: हे कष्टदायक करणारी अट काढून टाका
प्रत्येक पुनर्प्राप्ती कॉल नोंदणी संरचनेबद्दलचा पुरावा आहे। खात्यात नेमका एकच घटक असेल, तर त्या गटातील सर्वांसाठी दुसरा बंधनकारक करा। पुनर्प्राप्ती कोड हरवलेल्या लॅपटॉपवर असतील, तर ते कुठे राहतात ते बदला। पडताळणीसाठी रजेवरच्या व्यवस्थापकाची गरज असेल, तर प्रतिनिधी नेमा। प्रत्येक दुरुस्ती एक दुपार घेते आणि पुढील घटनेचा सर्वात वाईट तास काढून टाकते।
मग पायरी एकची नोंद वास्तवाच्या तुलनेत पुन्हा वाचा। ती खरोखर अस्तित्वात असलेल्या घटकांची यादी देते का, आणि पडताळणी वाहिनी अजूनही माणसापर्यंत पोहोचते का? कोणीही अद्ययावत न करणारे हस्तपुस्तिका ज्या कॉलसाठी लिहिले होते त्या कॉलदरम्यान लोक दुर्लक्ष करतात अशा दस्तऐवजात क्षीण होते।