VPN વપરાશકર્તાની નોંધણી: પહેલા ઓળખનો માલિક શોધો

કોઈ VPN ઍક્સેસ માંગે છે, અને પહેલી વૃત્તિ સર્વર પર adduser ચલાવવાની હોય છે. એ વૃત્તિ ફક્ત થોડા ગણતરીના ડિપ્લોયમેન્ટમાં જ સાચી છે. કંઈ પણ બનાવતા પહેલા, સર્વરની ગોઠવણી ખોલો અને શોધો કે ત્યાં કયું ઉત્પાદન ચાલે છે અને તે ઓળખપત્રો ક્યાં ચકાસે છે, કારણ કે ખાતું ઉત્પાદનના ડેટાબેઝમાં, ઓળખ પ્રદાતા પાસે અથવા હોસ્ટની પોતાની પ્રમાણીકરણ સ્ટેકમાં રહી શકે છે. ખોટા પ્રકારનું ખાતું બનાવવાથી વ્યક્તિ પાસે ચાલતું લૉગિન રહે છે અને ટનલ નથી.

જે ક્લાયન્ટ પ્રોફાઇલ OpenVPN કહે છે તે પ્રોટોકોલનું વર્ણન કરે છે, તેની પાછળની ઓળખ પ્રણાલીનું નહીં.

adduser થી નહીં, સર્વરથી શરૂ કરો

પહેલા ઉત્પાદન ઓળખો. Community OpenVPN એ ડીમન અને તમે તેમાં જોડેલું કોઈપણ પ્રમાણીકરણ છે, જ્યારે Access Server પોતાનું વપરાશકર્તા સ્તર ધરાવતું ઉત્પાદન છે. ગોઠવણી, યુનિટનું નામ અને પેકેજ યાદી માંગો, અને વપરાશકર્તા સંચાલન માટે વેબ ઇન્ટરફેસ છે કે નહીં તે તપાસો. પછી જુઓ કે ડિપ્લોય કરેલી પ્રોફાઇલ ક્લાયન્ટ્સ પાસેથી કેવી રીતે પોતાની ઓળખ સાબિત કરવાની અપેક્ષા રાખે છે: પ્રમાણપત્ર, વપરાશકર્તાનામ અને પાસવર્ડ, અથવા બંને. એ જવાબ ખાતાનો માલિક ધરાવતી પ્રણાલીનું નામ આપે છે.

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

ચાર બેકએન્ડ, ખાતું બનાવવાના ચાર સ્થળો

Access Server નું સ્થાનિક પ્રમાણીકરણ ખાતાં તેના પોતાના ડેટાબેઝમાં રાખે છે, તેથી તે બનાવવાનું ઇન્ટરફેસ હોસ્ટનું નહીં, ઉત્પાદનનું છે. PAM ચકાસણીનો હવાલો ઓપરેટિંગ સિસ્ટમની સ્ટેકને સોંપે છે, અને તેથી જ સેવાએ તે જ સ્ટેક પસંદ કર્યો હોય ત્યારે સ્થાનિક Unix ખાતું નોંધણીનો ભાગ બની શકે છે. LDAP, RADIUS અને SAML ચકાસણીને બાહ્ય સેવામાં ખસેડે છે, જ્યાં પ્રોવિઝનિંગ, પાસવર્ડ નીતિ અને MFA રહે છે. Access Server ચારેય કિસ્સામાં વપરાશકર્તા દીઠ પ્રમાણપત્રો અને પરવાનગીઓ રાખી શકે છે, અને એ જ વિભાજનને ગૂંચવણભર્યું બનાવે છે.

આ ચોક્કસ વપરાશકર્તા માટે અમલમાં રહેલી પદ્ધતિ તપાસો, વૈશ્વિક ડિફૉલ્ટ નહીં. Access Server 2.10 અને પછીના સંસ્કરણો જૂથ અથવા વપરાશકર્તા દીઠ જુદી જુદી પ્રમાણીકરણ પદ્ધતિઓ લાગુ કરી શકે છે, તેથી ડિફૉલ્ટ સ્થાનિક હોવું એ સાબિત કરતું નથી કે તમારી સામેનું ખાતું સ્થાનિક રીતે ચકાસાય છે.

હક એ અલગ નિર્ણય છે

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

ક્લાયન્ટ સામગ્રી પણ મહત્વની છે. ઑટો-લૉગિન પ્રોફાઇલ અને ઇન્ટરેક્ટિવ વપરાશકર્તા લૉગિન જુદા જુદા પ્રમાણીકરણ સંબંધો દર્શાવે છે, અને એકને બીજા સાથે બદલવાથી સર્વર ખરેખર શું ચકાસે છે તે બદલાય છે.

ઍક્સેસ પાછી ખેંચવી નોંધણીનો ભાગ છે

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

પછી નોંધણીને હુમલાખોર કરે તે રીતે ચકાસો: નવી ઓળખ સાથે એક વાર જોડાઓ, ઇચ્છિત સંસાધનની ઍક્સેસની પુષ્ટિ કરો અને અસંબંધિત સંસાધન હજી નકારે છે તેની પુષ્ટિ કરો. કામ કરતું પહેલું જોડાણ અને નકારાત્મક પરીક્ષણ મળીને પૂર્ણ નોંધણી છે.

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