વપરાશકર્તા VPN દ્વારા ડોમેનમાં જોડાઓ અને રીબૂટમાંથી પસાર થાઓ

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

આ તબક્કાઓને અલગ રાખવી એ જ પ્રોજેક્ટને સફળતાપૂર્વક જોડાયેલા અને વાપરી ન શકાય તેવા લેપટોપ સાથે પૂરો થવાથી રોકે છે.

કનેક્ટ કરતા પહેલાં: આવૃત્તિ, સ્થાનિક એડમિન, DNS

મશીનને ડોમેન જોડાણને સમર્થન આપતી આવૃત્તિ અને તે કરવા માટે અધિકૃત સ્થાનિક એડમિનિસ્ટ્રેટરની જરૂર છે. VPN એ જ સત્ર હેઠળ ચાલુ હોવું જોઈએ, કારણ કે જોડાણ તમે વાપરી રહ્યા છો તે સુરક્ષા સંદર્ભમાં ચાલે છે.

ક્લાયંટને સંસ્થાના ડિરેક્ટરી DNS તરફ નિર્દેશિત કરો, જાહેર રિઝોલ્વર તરફ નહીં અને hosts ફાઇલની એન્ટ્રી તરફ પણ નહીં. જોડાણને સેવા રેકોર્ડ શોધવા પડે છે અને પછી તે રેકોર્ડ નામ આપે છે તેવા હોસ્ટ સુધી પહોંચવું પડે છે. જૂનું સફિક્સ અથવા જાહેર રિઝોલ્વર શોધને સાવ બીજે જ મોકલે છે.

ઘડિયાળ પણ તપાસો. Kerberos સમયના તફાવતને સહન કરતું નથી, અને એક મહિના ઑફલાઇન રહેલું લેપટોપ મૂંઝવતી જોડાણ ભૂલોનો સામાન્ય સ્રોત છે.

ખાતરી કરો કે ડોમેન શોધી શકાય છે, ફક્ત પિંગ નહીં

જોડાણનો પ્રયાસ કરતા પહેલાં ડોમેનનો LDAP SRV રેકોર્ડ ઉકેલો. ad.corp.example નામના દૃષ્ટાંતરૂપ એક-ડોમેન વાતાવરણ માટે, ક્વેરી આ છે:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

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

દસ્તાવેજીકૃત AD નિર્ભરતાઓને મંજૂરી આપો: પ્રમાણીકરણ, SMB અને RPC ટ્રાફિક, ઉપરાંત સમય સિંક્રોનાઇઝેશન. દરેકને તમે ખરેખર ડિપ્લોય કરેલા ફાયરવોલ નિયમો સામે તપાસો. ડોમેન કંટ્રોલરના પોર્ટ ઇન્ટરનેટ પર પ્રકાશિત કરવું વિચારવા યોગ્ય શોર્ટકટ નથી.

જોડાણ ચલાવો અને ભૂલ વાંચો

સમર્થિત જોડાણ આદેશ અથવા સિસ્ટમ સંવાદનો ઉપયોગ કરો અને ચોક્કસ ભૂલ લખાણ કેપ્ચર કરો. «ઉલ્લેખિત ડોમેન કાં તો અસ્તિત્વમાં નથી અથવા તેનો સંપર્ક કરી શકાયો નથી» શોધ અથવા પહોંચ તરફ સંકેત કરે છે, ઓળખપત્રો તરફ નહીં.

જો સમાન નામનું ઑબ્જેક્ટ પહેલેથી અસ્તિત્વમાં હોય, તો પ્રતિક્રિયાવશ તેને ડિલીટ કરશો નહીં. તે પૂર્વ-તૈયાર ખાતું હોઈ શકે છે, અને netjoin કઠોરીકરણ માલિકી અને નીતિ અનુસાર કેટલાક પુનઃઉપયોગના કિસ્સાઓ મર્યાદિત કરે છે. ડિરેક્ટરી માલિકને ઑબ્જેક્ટ તપાસવા અથવા સુધારવા કહો.

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

પ્રથમ ડોમેન સાઇન-ઇનની યોજના કરો

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

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

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

સ્થાનિક પુનઃપ્રાપ્તિ ઍક્સેસ રાખો

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

તમે શું સાબિત કર્યું તે લખો: SRV રિઝોલ્યુશન, DC સુધી પહોંચ, જોડાણ ભૂલ, પ્રથમ લોગઓનની પદ્ધતિ અને પુનઃપ્રાપ્તિ ખાતું. તે રેકોર્ડ જ પુનરાવર્તનીય બિલ્ડ અને ફક્ત ઑફિસમાં કામ કરતા લેપટોપ વચ્ચેનો તફાવત છે.