NetExtender લૉગ ઇન થાય છે પણ પ્રવેશ નથી: SonicWall સ્થાનિક + LDAP
NetExtender જોડાય છે પણ કંઈ જવાબ આપતું નથી: SonicWall પ્રમાણીકરણ, SSL VPN સેવાની સભ્યપદ અને સ્થાનિક તથા LDAP વપરાશકર્તાઓ માટે VPN પ્રવેશ પરવાનગીઓ અલગ તપાસો.
લૉગ ઇન સફળ થાય છે, ટનલ ઊભી થાય છે અને ફાયરવૉલ પાછળ કંઈ જવાબ આપતું નથી. SonicWall SSL VPN પર આ પેટર્ન સામાન્ય રીતે દર્શાવે છે કે ખાતું પ્રમાણીકરણ પસાર કરી ગયું અને પછીની બે પરવાનગીઓમાંથી એક પર અટક્યું: SSL VPN સેવામાં સ્વીકૃતિ, અથવા કોઈ સંસાધન સુધી પહોંચવાની પરવાનગી. સ્થાનિક અને LDAP ખાતાં મિશ્ર હોય તો સ્થિતિ બગડે છે, કારણ કે બંને ભંડાર આ પરવાનગીઓ સુધી અલગ માર્ગે પહોંચે છે. ક્લાયન્ટ તરફથી લક્ષણ એકસરખું હોય છે, તેથી સ્તરો જાણી જોઈને અલગ કરવા પડે છે.
લક્ષણ અને તેની પાછળની ત્રણ પરવાનગીઓ
વપરાશકર્તાનામ અને પહોંચી શકાય તેવા સર્વર વચ્ચે ત્રણ સ્વતંત્ર નિર્ણયો હોય છે. પ્રમાણીકરણની પદ્ધતિ નક્કી કરે છે કે ઓળખપત્ર સ્વીકારાય છે કે નહીં અને કયો ભંડાર તેને સ્વીકારે છે. SSL VPN સેવાની સભ્યપદ નક્કી કરે છે કે આ ઓળખ SSL VPN વાપરી શકે છે કે નહીં. VPN પ્રવેશ યાદી નક્કી કરે છે કે સત્ર કયા ખાનગી લક્ષ્યો સુધી પહોંચી શકે છે. એક પસાર કરવાથી આગલા બે વિશે કંઈ કહેવાય નહીં.
જે વપરાશકર્તા પ્રમાણિત થાય છે પણ SSL VPN સેવા જૂથમાં નથી, તેને એવું જોડાણ દેખાય છે જે બને છે અને પછી કંઈ વહન કરતું નથી, અને ફાયરવૉલ લૉગ નિષ્ફળતાને બદલે સ્વીકૃત લૉગઇન દર્શાવે છે. આ જ એવી સ્થિતિ છે જે ઝડપથી ઓળખવી જોઈએ, કારણ કે ઉપાય જૂથની સભ્યપદ છે, પાસવર્ડ રીસેટ નહીં.
જે વપરાશકર્તા સ્વીકારાય છે પણ તેની પાસે સંસાધનો નથી, તેને એવું સત્ર દેખાય છે જે જોડાય છે અને ક્યાંય ઉપયોગી જગ્યાએ જતું નથી. હેલ્પ ડેસ્કની નજરમાં બંને તૂટેલી ટનલ જેવા દેખાય છે, અને બંને કનેક્ટિવિટી નહીં, રૂપરેખાંકનની સમસ્યા છે.
ડોમેન બૉક્સ ડિરેક્ટરી નથી
NetExtender ડોમેન માંગે છે, અને તે ક્ષેત્ર Active Directory માટે શોધ આધાર નથી. ડિફૉલ્ટ ગોઠવણીમાં ક્ષેત્ર તે SSL VPN વપરાશકર્તા ડોમેનની બરાબર હોવું જોઈએ જે ફાયરવૉલે રૂપરેખાંકિત કર્યું છે, અને તેના માટે દસ્તાવેજી ડિફૉલ્ટ મૂલ્ય છે LocalDomain. તુલના કેસ-સંવેદનશીલ છે, તેથી અલગ મોટા-નાના અક્ષરોમાં લખાયેલું મૂલ્ય ખાતું સાચું હોવા છતાં નિષ્ફળ જાય છે.
જ્યારે પ્રમાણીકરણ વિભાજન રૂપરેખાંકિત હોય, ત્યારે વિભાજનના નામ બાહ્ય પ્રમાણીકરણ સંદર્ભ પસંદ કરે છે, અને રૂપરેખાંકિત ડિફૉલ્ટ પોતાની ભૂમિકા રાખે છે. બંને ગોઠવણીમાં ક્લાયન્ટ બાજુનું ડોમેન લેબલ વપરાશકર્તાનામના ભાગ રૂપે LDAP કે RADIUS ને મોકલાતું નથી, તેથી તે ડિરેક્ટરી શોધનું નિર્દેશન કરી શકતું નથી.
ત્રણેય સ્ટ્રિંગ તમારી નોંધમાં અલગ રાખો: કંપનીનો DNS પ્રત્યય, LDAP શોધ આધાર અને NetExtender ડોમેન લેબલ. આ એકસરખા દેખાય છે અને એક પણ બીજાની જગ્યા લેતું નથી. આ ઇન્સ્ટૉલેશન માટે ઑપરેટરનું મૂલ્ય કૉપી કરો, બીજી ફર્મવેર આવૃત્તિ વિશેના ફોરમ પોસ્ટનું મૂલ્ય નહીં.
સ્વીકૃતિ અને સંસાધન પ્રવેશ અલગ પરવાનગીઓ છે
સ્થાનિક ખાતાંને સેવા સ્વીકારે તે પહેલાં SSL VPN સેવા જૂથની સભ્યપદ જરૂરી છે. ડિરેક્ટરી ખાતાં તે જ જૂથ સુધી સમર્થિત જૂથ મૅપિંગ વર્કફ્લો દ્વારા પહોંચે છે, એટલે LDAP જૂથ સંબંધ રૂપરેખાંકિત કરવો પડે અને પછી ડિરેક્ટરી બાજુથી ધારી લેવાને બદલે અસરકારક સભ્યપદ તરીકે ચકાસવો પડે.
સંસાધન પ્રવેશ ત્યાર બાદ આવે છે, વપરાશકર્તા કે જૂથ પર VPN પ્રવેશ હેઠળ. ભૂમિકાને જરૂરી હોય તેવા ચોક્કસ સબનેટ અને સેવાઓ આપો, અને એક એપ્લિકેશનની જરૂર પડે તેથી આખું LAN આપવાના શૉર્ટકટ ટાળો. સત્રના રૂટ, પ્રવેશ નિયમો અને લક્ષ્ય સેવાની પરવાનગીઓ બધા આ વ્યાપ સાથે મેળ ખાવા જોઈએ.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
ક્લાયન્ટ પરનો રૂટ લક્ષ્યને પસંદ કરી શકાય તેવું બનાવે છે અને તેને પરવાનગી આપતો નથી. SSL VPN જૂથની સભ્યપદ ખાતાને ફાયરવૉલ વ્યવસ્થાપક પણ બનાવતી નથી, અને તેને સામાન્ય વિશેષાધિકાર આપવા તરીકે ગણવી ન જોઈએ.
બે ઓળખ, દરેકની ચાર ચકાસણી
એક સ્થાનિક ખાતા અને એક ડિરેક્ટરી ખાતા સાથે પરીક્ષણ કરો, બંનેને મર્યાદિત પરવાનગી આપો અને બંનેને પરીક્ષણ ખાતા તરીકે નોંધો. દરેક માટે જે પ્રમાણીકરણ સ્રોતે લૉગઇન સ્વીકાર્યું, અસરકારક જૂથો, ફાળવેલ સંસાધન પ્રવેશ અને એક મંજૂર એપ્લિકેશન ક્રિયા લખો. ચાર ચકાસણી, બે ભંડાર અને દરેક સંયોજન માટે લેખિત પરિણામ.
પછી નકારાત્મક સ્થિતિઓ ચકાસો: જે સંસાધન સુધી ખાતું પહોંચવું ન જોઈએ, અને જે ખાતું તરત જ નકારવું જોઈએ. ફક્ત સકારાત્મક માર્ગ સાબિત કરતી રચના ઘણી વાર બીજું પ્રવેશદ્વાર ખુલ્લું છોડે છે, ખાસ કરીને જ્યારે એ જ ટૂંકું વપરાશકર્તાનામ બંને ભંડારમાં હોય. ડિરેક્ટરી ખાતું બંધ કરો અને ખાતરી કરો કે સ્થાનિક ખાતું ચૂપચાપ કામ ચાલુ રાખતું નથી.
પુનરાવર્તિત નામોની સમીક્ષા તૈનાતીના ભાગ રૂપે કરો, ઘટના પછી નહીં. એક જ વ્યક્તિ બે ભંડારમાં હોવું એકસાથે સહાયની સુવિધા અને ઑડિટની સમસ્યા છે, અને ફાયરવૉલ તમે રૂપરેખાંકિત કરેલા ખાતાને જ ખુશીથી પ્રમાણિત કરશે.
પુનઃપ્રાપ્તિ માર્ગ સાંકડો રાખો
સ્થાનિક ખાતાંને મુક્તિ આપવાને બદલે દરેક ખાતા વર્ગ માટે MFA નીતિ જાળવો. જો સ્થાનિક ખાતાં ડિરેક્ટરી અવરોધ માટે મંજૂર પુનઃપ્રાપ્તિ માર્ગ આપે છે, તો તે માર્ગ નામાંકિત વ્યવસ્થાપકો સુધી મર્યાદિત રાખો અને જાણી જોઈને ચલાવો, કારણ કે દરેક કર્મચારી માટે સ્થાનિક કટોકટી ખાતું નબળી દેખરેખવાળી બીજી પ્રમાણીકરણ પ્રણાલી છે.
ક્લાયન્ટ ડોમેન, પ્રમાણીકરણ સ્રોત અને અસરકારક પ્રવેશ એક જ રેકોર્ડમાં લખો. પછીનો વ્યવસ્થાપક કામ કરતી મિશ્ર ખાતા રચના ફરી બનાવી શકશે, લૉગઇન સફળ થાય ત્યાં સુધી ડોમેન સ્ટ્રિંગ અજમાવવાને બદલે.