તમે client-connect સ્ક્રિપ્ટ ઉમેરો છો જે એવા કોઈપણ કનેક્શનને નકારે છે જ્યાં common_name username થી અલગ હોય, અને તે પ્રમાણપત્ર અને ખાતા વચ્ચેની જોડાણ જેવું લાગે છે. username-as-common-name ચાલતા સર્વર પર, સ્ક્રિપ્ટ ચાલે તે પહેલાં જ તે તુલનાએ તેનો અર્થ ગુમાવી દીધો છે. બંને મૂલ્યો એક જ શબ્દમાળા છે, તેથી પરીક્ષણ સંપૂર્ણપણે બીજા કોઈને જારી કરેલા પ્રમાણપત્ર માટે પાસ થાય છે.

તપાસ ખોટી નથી કારણ કે સ્ક્રિપ્ટ ખરાબ રીતે લખાયેલી છે. તે ખોટી છે કારણ કે તે જે મૂલ્ય વાંચે છે તે અગાઉ એ જ કનેક્શનમાં બદલાઈ ગયું હતું.

તુલના શું સાબિત કરતી હોય તેવું લાગે છે

પ્રમાણપત્ર પ્રમાણીકરણ અને પાસવર્ડ પ્રમાણીકરણ અલગ પુરાવા છે, અને સર્વર બંને માંગી શકે છે તે માંગ્યા વિના કે તે એક જ વ્યક્તિના છે. આંતર સાચો છે: માન્ય ઉપકરણ પ્રમાણપત્ર વત્તા કોઈપણ માન્ય ખાતું એ તે ઉપકરણ પ્રમાણપત્ર વત્તા એક નામિત ખાતા કરતાં અલગ દાવો છે. common_name ની username સાથે તુલના કરતી સ્ક્રિપ્ટ બંને વચ્ચેની ખૂટતી કડી જેવી વંચાય છે. તે એવી હોત, જો common_name હજી પણ પ્રમાણપત્ર કહે તેનો અર્થ ધરાવતું હોત.

તે એવું છે કે નહીં તે એક સર્વર વિકલ્પ પર આધાર રાખે છે, અને તે વિકલ્પ સામાન્ય રીતે અસંબંધિત કારણોસર ચાલુ કરવામાં આવે છે, જેમ કે વપરાશકર્તા દીઠ રૂપરેખા ફાઇલોને નામ આપવાનું સરળ બનાવવું.

username-as-common-name નામ સાથે શું કરે છે

username-as-common-name ચાલુ હોય ત્યારે, OpenVPN પાસવર્ડ અને વપરાશકર્તાનામની ચકાસણી થયા પછી પ્રમાણપત્રના સામાન્ય નામને બદલે પ્રમાણીત વપરાશકર્તાનામ મૂકે છે. તે ચકાસણી દરમિયાન ચાલતો ચકાસણી હૂક હજી પણ પ્રમાણપત્રનું સામાન્ય નામ મેળવે છે, કારણ કે બદલી હજી થઈ નથી. તે પછીનું બધું, client-connect સહિત, વપરાશકર્તાનામ જુએ છે. તેથી પછીનો કૉલબેક એક જ ઓળખ બે વાર મેળવે છે અને રજૂ કરેલા પ્રમાણપત્ર સાથે તેની તુલના કરી શકતો નથી.

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

એક ઉદાહરણ કનેક્શનને અનુસરો: bob-device માટે જારી કરેલું પ્રમાણપત્ર, alice તરીકે સફળ ડિરેક્ટરી લૉગિન, અને વિકલ્પ ચાલુ. ચકાસણી તબક્કો હજી પણ બે અલગ શબ્દમાળાઓ જોઈ શકે છે. કનેક્શન તબક્કો alice અને alice જુએ છે.

તે ઉદાહરણ દર્શાવે છે કે તુલના ખાલી કેમ છે. તે દર્શાવતું નથી કે કનેક્શન અન્યથા સ્વીકારાયું હોત, કારણ કે પ્રમાણપત્ર માન્યતા અને પાસવર્ડ ચકાસણી હજી પણ સ્વતંત્ર રીતે ચાલે છે.

જોડાણ ત્યાં મૂકો જ્યાં બંને ઓળખ હજી અસ્તિત્વમાં છે

નિયમ એવા તબક્કે લાગુ કરવો પડે જે પ્રમાણપત્રની ઓળખ અને ખાતું એકસાથે જુએ, જેનો વ્યવહારમાં અર્થ વપરાશકર્તાનામ અને પાસવર્ડ ચકાસણી હૂક અથવા ત્યાં લોડ થયેલ પ્લગઇન છે. સપોર્ટેડ પ્લગઇન જે પહેલેથી પાસવર્ડ ચકાસણી કરે છે તે સામાન્ય રીતે જોડી નિયમ ઉમેરવાની યોગ્ય જગ્યા છે, કારણ કે તેને નામની તુલનાથી બદલવાથી પાસવર્ડ ચકાસણી સંપૂર્ણપણે નીકળી જશે.

કોડ લખતા પહેલાં મેપિંગ વ્યાખ્યાયિત કરો, કારણ કે સમાનતા ભાગ્યે જ વાસ્તવિક નીતિ હોય છે. પ્રમાણપત્ર ઘણી વાર ઉપકરણને ઓળખે છે જ્યારે લૉગિન વ્યક્તિને ઓળખે છે, અને એક ઉપકરણ કાયદેસર રીતે અનેક લોકોની સેવા કરી શકે છે. સંબંધને એવા સ્વરૂપમાં સંગ્રહો જેની જારી કરવાનું નિયંત્રણ તમારી પાસે હોય, અને નક્કી કરો કે નામ બદલતી વખતે, ફરી જારી કરતી વખતે અને ડોમેન-યોગ્ય નામોમાં શું થાય. ડિરેક્ટરી સમજ્યા વિના લોઅરકેસ કરવું અથવા ડોમેન પ્રીફિક્સ દૂર કરવું બે ખાતાંને જોડી શકે છે જે અલગ રહેવા માટે હતાં.

યાદ રાખો કે વિકલ્પ એ પણ બદલે છે કે કઈ ક્લાયન્ટ દીઠ રૂપરેખા લાગુ પડે છે, કારણ કે client-config-dir સામાન્ય નામ દ્વારા કી થયેલું છે.

બે માન્ય ઓળખપત્રો સાથે જોડીની કસોટી કરો

તમારી નીતિ જે જોડીને મંજૂરી આપે તેનાથી શરૂ કરો અને ખાતરી કરો કે તે કનેક્ટ થાય છે. પછી એ જ માન્ય પ્રમાણપત્ર અલગ પરંતુ બીજી રીતે માન્ય ખાતા સાથે રજૂ કરો: તે પ્રયાસ નિષ્ફળ થવો જોઈએ, અને તે જોડી નિયમના કારણે નિષ્ફળ થવો જોઈએ, ખોટા ટાઇપ કરેલા પાસવર્ડના કારણે નહીં. ખોટો પાસવર્ડ સાબિત કરે છે કે પાસવર્ડ ચકાસણી કામ કરે છે અને પ્રમાણપત્ર-થી-ખાતા નિયમ વિશે કંઈ કહેતો નથી.

ગુમ થયેલા પ્રમાણપત્ર અને અમાન્ય પ્રમાણપત્રના માર્ગો પણ ચકાસો, અને ખાતરી કરો કે સર્વર ક્લાયન્ટ દીઠ સેટિંગ્સ માટે કઈ ઓળખ વાપરે છે. જો તુલના કામ કરે તેનો એકમાત્ર રસ્તો username-as-common-name બંધ કરવો હોય, તો પહેલાં તે ફેરફારનો ખર્ચ ગણો, કારણ કે તે દરેક ક્લાયન્ટની રૂપરેખા શોધને પાછી પ્રમાણપત્રના નામ પર લઈ જાય છે.

સંબંધિત લેખો