नवीन iPad संघात सामील होते, आणि सर्वात वेगवान मार्ग म्हणजे विद्यमान क्लायंट प्रमाणपत्र निर्यात करून ते टॅब्लेटवर स्थापित करणे। कोणी सोडले, उपकरण हरवले किंवा कोणते उपकरण कधी जोडले गेले हे सांगणारे ऑडिट मागितले गेले तोपर्यंत हे चालते। निर्णय प्रमाणपत्र फाइलबद्दल नाही, ओळखीबद्दल आहे: प्रत्येक उपकरण स्वतंत्रपणे अधिकृत आणि रद्द करता येईल का। खर्च आणि व्यवस्थापन श्रम उत्तर ठरवतात, आणि दोन्ही दिसतात त्यापेक्षा लहान आहेत।

सामायिक जारीकर्ता, वेगळ्या ओळखी।

प्रत्येक उपकरण एकाच प्रमाणपत्र प्राधिकरणावर विश्वास ठेवू शकते आणि एकाच गेटवेला जोडू शकते, तरीही वेगळी क्लायंट ओळख ठेवते। जारीकर्ता विश्वासाचा आधार आहे, तर ओळख ही की-जोडी आहे जिचा विषय सर्व्हर धोरणाशी जोडतो। या दोन्हींचा गोंधळच सामायिक प्रमाणपत्र निरुपद्रवी वाटण्यास कारणीभूत ठरतो। कोणत्या उपकरणाने सत्र उघडले हे कोणाला कळण्याची गरज होईपर्यंत ते निरुपद्रवी राहते।

जारीकर्ता सामायिक केल्याने संरचना कार्य वाचते आणि प्रत्येक उपकरणाच्या जबाबदारीत काहीही बदलत नाही। ओळख सामायिक केल्याने प्रत्येक उपकरण एका रद्द करण्यायोग्य घटकात मिळते: एक रद्द केल्यास सर्व रद्द होतात, आणि बदली अधिकृत केल्यास आजवर तयार झालेली कीची प्रत्येक प्रत अधिकृत होते। ही अदलाबदल शुक्रवारी दुपारी वेगवान आहे म्हणून फाइल कॉपी करण्याऐवजी स्पष्टपणे करणे योग्य आहे।

जेव्हा दुसरे प्रमाणपत्र खूप महाग पडते।

प्रत्येक उपकरणासाठी नोंदणी एक पायरी घेते: व्यवस्थापित पेलोड, SCEP विनंती किंवा एकवेळच्या पासवर्डसह मार्गदर्शित आयात। अनुक्रमांक आणि समाप्ती तारखा मागोवा घेण्यासाठी जागा देखील लागते, हा भाग बहुतेक तैनाती पहिले प्रमाणपत्र संपेपर्यंत विसरतात। दोन्ही खर्च एकवेळचे आहेत, आणि नोंदणी प्रवाह त्यांना स्वयंचलित करताच दोन्ही कमी होतात।

दोन टॅब्लेट आणि एक वापरकर्ता असलेल्या कुटुंबासाठी खर्च वास्तविक आहे, जिथे सामायिक ओळख एका वाक्यात नोंदवलेला वाजवी निर्णय आहे। परंतु प्रत्येक व्यक्ती किंवा प्रत्येक उपकरणानुसार प्रवेश मागे घ्यावा लागणाऱ्या सेवेसाठी तो वाजवी नाही, कारण रद्दीकरणाची कथा हीच पासवर्डऐवजी प्रमाणपत्रे वापरण्याचे संपूर्ण कारण आहे। तैनातीचे मूल्यमापन आज किती उपकरणे आहेत यावरून नाही, तर उपकरणे किती वेळा हात बदलतात यावरून करा।

उपकरणाची नोंदणी करा, की कॉपी करू नका।

आधुनिक प्लॅटफॉर्म खाजगी की संरक्षित भांडारात ठेवतात, आणि काही त्यांना रचनेनुसार निर्यात-अयोग्य असे चिन्हांकित करतात। हाच गुण सुरुवातीलाच कॉपी करणे अशक्य करतो, आणि लॅपटॉपवरून निर्यात केलेले बंडल कोणत्याही समर्थित पद्धतीने टॅब्लेटवर पुन्हा आयात करता येऊ नये याचे कारणही तेच आहे। तरीही प्रयत्न केल्यास स्वच्छपणे स्थापित होणारी आणि नंतर कधीही प्रमाणीकरण न करणारी प्रोफाइल तयार होते।

तैनाती आधीच समर्थन देते ती नोंदणी पद्धत वापरा: व्यवस्थापित ओळख पेलोड, SCEP सेवा किंवा उपकरणावर नवीन की देणारा खाते-आधारित प्रवाह। गहाळ ओळख सोडवण्यासाठी प्रमाणपत्र प्राधिकरणाची खाजगी की वाटणे ही दुसरी चूक आहे, जिचा प्रभाव कक्ष खूप मोठा आहे। प्राधिकरण ओळखपत्रे देते आणि कधीही अंतिम टोकापर्यंत प्रवास करू नये।

उत्तर देण्यापूर्वी रद्दीकरण तपासा।

सामायिक पर्याय निवडण्यापूर्वी, सर्वात वाईट दिवशी रद्दीकरण कसे दिसेल ते वर्णन करा। उत्तर अनेक उपकरणांवर परिणाम करणारी एक क्रिया असेल, तर रचनेने आधीच तुमच्या विरुद्ध निर्णय घेतला आहे।

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

तुमच्याकडे प्रत्यक्षात असलेली सामग्री तपासा: खाजगी की आहे का, विषय काय सांगतो आणि अनुक्रमांक स्वतंत्रपणे रद्द करता येतो का। की नसलेली प्रमाणपत्र फाइल काहीही प्रमाणित करू शकत नाही, आणि म्हणूनच काही कॉपी केलेल्या ओळखी पहिल्या कनेक्शनवर अयशस्वी होतात।

टॅब्लेटवरून ॲप हटवणे म्हणजे रद्दीकरण नाही, आणि कोणी ते निष्क्रिय करेपर्यंत सर्व्हर ओळख स्वीकारत राहतो। पहिल्या उपकरणाची नोंदणी करण्यापूर्वी ते वाक्य रनबुकमध्ये लिहा।

संबंधित लेख