જૂની હેશનો પુનઃઉપયોગ કર્યા વિના VPN પ્રમાણીકરણ બેકએન્ડનું સ્થળાંતર
VPN ઓળખોને ખસેડવી એ કટઓવર છે, નકલ નહીં: પ્રમાણીકરણની સાંકળનો નકશો બનાવો, એક પાયલોટ જૂથ ખસેડો, ક્રેડેન્શિયલ ફેરફારો ચકાસો અને એવી પુનઃપ્રાપ્તિનું આયોજન કરો જે રીસેટ ભૂંસી ન શકે.
વપરાશકર્તાનામો નવી ડિરેક્ટરીમાં દેખાય છે, સ્થળાંતર પૂર્ણ જાહેર કરાય છે, અને લોગિન તો પણ નિષ્ફળ જાય છે. ગેટવેને હજી પણ સમર્થિત પ્રમાણીકરણ માર્ગ અને સાચું અધિકૃતતા પરિણામ જોઈએ છે, અને બંન્નેમાંથી કંઈ પણ હવે ખાતાં ધરાવતી ડિરેક્ટરીમાંથી આવતું નથી. બેકએન્ડ ખસેડવું એ જીવનચક્ર સાથેનું કટઓવર છે, નકલનું કામ નહીં. નીચેનું લક્ષણ તે જ છે જે સામાન્ય રીતે ફરક ઉજાગર કરે છે.
લક્ષણ: ખાતાં છે, સત્રો નથી
નવી ડિરેક્ટરીમાં દરેક વપરાશકર્તાનામ છે, પરીક્ષણ બાઇન્ડ સફળ થાય છે, અને VPN ક્લાયન્ટ તો પણ પ્રમાણીકરણ નિષ્ફળતા પરત કરે છે. આ સંયોજન કહે છે કે ઓળખ અસ્તિત્વમાં છે, પણ ગેટવે જે ચકાસણી માર્ગ વાપરે છે તે ત્યાં પહોંચતો નથી, અથવા એવી પદ્ધતિથી પહોંચે છે જે તે પૂરી કરી શકતું નથી. બંને રૂપરેખાંકન છે, અને આ જુદી સમસ્યાઓ છે.
પહેલું વાયરિંગ છે: ગેટવે એવા બેકએન્ડ તરફ ઈશારો કરે છે જે જવાબ આપતું નથી, બીજી બાજુ અપેક્ષા ન હોય એવું સહિયારું રહસ્ય વાપરે છે, અથવા નવી સેવા પરત ન કરે એવો ગુણ માંગે છે. બીજું ક્રિપ્ટોગ્રાફિક છે: પદ્ધતિ મૂળ રહસ્ય માંગે છે, અને નવું ભંડાર ફક્ત તેનો હેશ રાખે છે. ભૂલનું લખાણ બંને સ્થિતિમાં સરખું દેખાય છે, એટલે બંનેને એક સમસ્યા ગણવામાં આવે છે.
ખાતાંને સ્પર્શ કરતા પહેલાં આ બંનેને અલગ કરવાથી એક અઠવાડિયું બચે છે. એક રાઉટિંગ અને વિશ્વાસનો પ્રશ્ન છે, બીજું ક્રેડેન્શિયલ રીસેટ કરવાનો નિર્ણય, અને તેમને ભેગા કરવાથી એવા ફેરફારો થાય છે જેને કોઈ જવાબદાર ઠેરવી શકતું નથી.
કોઈને ખસેડતા પહેલાં સાંકળનો નકશો બનાવો
દરેક ક્લાયન્ટ પ્રોફાઇલ માટે છ બાબતો લખો: બાહ્ય પ્રમાણીકરણ પદ્ધતિ, હોય તો આંતરિક પદ્ધતિ, ક્લાયન્ટ જે સર્વર ઓળખની અપેક્ષા રાખે છે, ગેટવે અને બેકએન્ડ વચ્ચેનું ઇન્ટરફેસ, ગેટવે જે ગુણને જૂથ સભ્યપદ પર મેપ કરે છે, અને તેમાંથી નીકળતી સંસાધન નીતિ. તેમને ક્રમમાં વાંચવાથી દેખાય છે કે કઈ કડીનો માલિક કોઈ નથી. દરેક વસ્તુનો જવાબદાર હોય છે, અને કટઓવર ત્યાં જ નિષ્ફળ જાય છે જે કોઈએ ચકાસ્યું નથી.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
સાધારણ ડિરેક્ટરી લોગિન એ સાંકળમાંથી લગભગ કંઈ પસાર કરતું નથી. તે સાબિત કરે છે કે ખાતું છે અને પાસવર્ડ ચાલે છે, એટલે કે તે જ ભાગ જેના પર કદી શંકા નહોતી.
હેશ પદ્ધતિઓ વચ્ચે મુસાફરી કરતા નથી
ક્રેડેન્શિયલની સુસંગતતા એક વાર ચકાસવી જોઈએ, કોઈ પણ જૂથ ખસે તે પહેલાં. FreeRADIUS વિભાજન સ્પષ્ટ રીતે દસ્તાવેજ કરે છે: સર્વર પોતે કરે એવી CHAP ચકાસણીને ખરો પાસવર્ડ જોઈએ છે, અને MS-CHAP તે પાસવર્ડ કે યોગ્ય NT સામગ્રી સ્વીકારે છે. બીજા હેતુ માટે બનાવેલો હેશ બંનેમાંથી કોઈ સ્થિતિમાં બંધ બેસતો નથી, તે ગમે તેટલો મજબૂત હોય.
ફરક એમાં છે કે પુરાવો કોણ ગણે છે. જે પદ્ધતિ ડિરેક્ટરી સાથે જોડાઈને ચકાસે છે તે ડિરેક્ટરીને જે ચકાસી શકે તે ચકાસવા દે છે. જે પદ્ધતિ પડકાર પ્રતિસાદ ફરી ગણીને ચકાસે છે તેને પોતે રહસ્ય જોઈએ છે, કારણ કે સર્વરે પણ એ જ ગણતરી કરવી પડે છે.
જ્યાં સામગ્રી નથી, ત્યાં પ્રામાણિક વિકલ્પો સમર્થિત રીસેટ, પુનઃ નોંધણી, બાહ્ય ચકાસણી સેવા કે પદ્ધતિ બદલાવ છે. પુનઃપ્રાપ્ત કરી શકાય તેવા પાસવર્ડની કામચલાઉ નિકાસ એ યાદીમાં નથી. તે પ્રોજેક્ટના સૌથી ગૂંચવણભર્યા અઠવાડિયામાં સાદા લખાણનું ક્રેડેન્શિયલ ભંડાર બનાવે છે, અને સામાન્ય રીતે સ્થળાંતર પછી પણ ટકે છે.
પાયલોટ જૂથ, પછી જીવનચક્ર ફેરફારો
મંજૂર ઓળખોનું નાનું જૂથ ખરા ક્લાયન્ટ સાથે ખસેડો, અને ચાર બાબતો ચકાસો: તાજું લોગિન, જાણી જોઈને ખોટું ક્રેડેન્શિયલ, જે સંસાધનો સુધી સત્ર પહોંચી શકે તે, અને જે સંસાધનો સુધી પહોંચવું ન જોઈએ તે. ક્લાયન્ટે સ્વીકારેલી સર્વર ઓળખ પણ ચકાસો, કારણ કે પ્રમાણપત્ર નામની અસંગતિ ત્યાં સુધી અદૃશ્ય રહે છે જ્યાં સુધી કોઈ ક્લાયન્ટ લોગ ન વાંચે.
પછી એ ફેરફારો ચકાસો જેના પર તૈનાતી ખરેખર આધાર રાખે છે. પાસવર્ડ બદલો, પ્રમાણપત્ર નવીકરણ કે પુનઃ નોંધણી કરો, અને એક પાયલોટ ખાતામાંથી પ્રવેશ દૂર કરો. દરેક પછી પુષ્ટિ કરો કે કયા ચકાસનારે પ્રયાસ સંભાળ્યો, કારણ કે કટઓવર પહેલાં બનેલું સત્ર ચાલુ રહી શકે છે અને આગલા લોગિન વિશે કંઈ સાબિત કરતું નથી.
પ્રોફાઇલ વિતરણને ઓળખ પરિવર્તનથી અલગ રાખો. દરેક જૂથને તેની ઇચ્છિત પ્રોફાઇલ, તેની ક્રેડેન્શિયલ કે નોંધણીની સ્થિતિ, વાપરવાની પ્રમાણીકરણ સેવા અને સહાય સંપર્ક જોઈએ છે, અને આમાંની કોઈ નોંધમાં રહસ્ય ન હોવું જોઈએ.
જૂનો અને નવો માર્ગ સાથે હોય તો તેમને અંતિમ તારીખથી મર્યાદિત કરો. સ્વયં પુનરાગમન નવા માલિકે પ્રવેશ દૂર કર્યા પછી ખાતાને જૂના ક્રેડેન્શિયલથી અંદર લઈ શકે છે, અને આ ઉપલબ્ધતાના વેશમાં સુરક્ષા પ્રતિગમન છે.
પુનરાગમન ક્રેડેન્શિયલ પુનઃસ્થાપિત કરી શકતું નથી
કટઓવર ઉલટાવવાથી ડિરેક્ટરી બરાબર અત્યારની સ્થિતિમાં રહે છે. રીસેટ કરેલો પાસવર્ડ રીસેટ જ રહે છે, રદ કરેલું પ્રમાણપત્ર રદ જ રહે છે, અને બદલેલું ક્રેડેન્શિયલ સ્વરૂપ બદલેલું જ રહે છે. આ ડિરેક્ટરીમાંની ઘટનાઓ છે, અને ગેટવે કદી તેમનો સ્રોત નહોતું. પુનઃપ્રાપ્તિ દરેક ઘટના માટે નક્કી કરવી પડે છે, અને આમાંથી કંઈ પણ અસંગત હેશમાંથી રહસ્ય પુનર્નિર્માણ પર આધારિત હોઈ શકતું નથી.
એવો વહીવટી માર્ગ રાખો જે સ્થળાંતરિત થતું જોડાણ વાપરતો નથી. જ્યારે નવું પ્રમાણીકરણ નિષ્ફળ જાય, જૂથ થોભાવો અને તેનો દસ્તાવેજીકૃત પુનઃપ્રાપ્તિ માર્ગ વાપરો, સમયમર્યાદા પાળવા સૌ માટે પ્રમાણીકરણ નબળું પાડવાને બદલે.
જૂથો ઢાંક્યા પછી જૂનાં બેકએન્ડ ક્રેડેન્શિયલ, પ્રોફાઇલ અને વિશ્વાસ સંબંધો તેમના માલિકો મારફતે પાછા ખેંચો. પુષ્ટિ કરો કે જૂનો માર્ગ હવે વપરાશકર્તાઓને અંદર લેતો નથી, અને સહાયને હજી જરૂરી એવું રહસ્યવિહીન ઓળખ-થી-નીતિ મેપિંગ રાખો. સ્થળાંતર ત્યારે પૂર્ણ થાય છે જ્યારે નવું જીવનચક્ર ચાલે છે અને કોઈ જૂના માર્ગેથી અંદર આવી શકતું નથી, ત્યારે નહીં જ્યારે ખાતાંની યાદી પૂર્ણ દેખાય છે.