કોણ ડાયલ ઇન કરી શકે? VPN ઍક્સેસ પહેલાં msNPAllowDialin નું ઑડિટ

પાસવર્ડ સાચો છે, એકાઉન્ટ VPN જૂથમાં છે, અને છતાં કનેક્શન એવા સંદેશ સાથે નકારાય છે જેમાં કોઈ નીતિનો ઉલ્લેખ જ નથી. જ્યારે આ Windows રિમોટ-ઍક્સેસ સર્વર પર થાય, ત્યારે હું સૌપ્રથમ જે જોઉં છું તે NPS નિયમ નથી, પણ Active Directory નું એક લક્ષણ છે જે કોઈ ખોલતું નથી: msNPAllowDialin, એટલે Dial-in ટૅબ પાછળનું મૂલ્ય. તેને ત્રણ સ્થિતિઓ છે, અને ત્રીજી શાંતિથી નિર્ણય બીજે ક્યાંક સોંપી દે છે. મોટા ભાગે કોઈએ તેને જાણી જોઈને બદલ્યું નથી: એકાઉન્ટ કોઈ ટેમ્પલેટમાંથી ક્લોન કરાયું હતું, અથવા એવી સ્ક્રિપ્ટ દ્વારા બનાવાયું હતું જેણે વર્ષો પહેલાં સ્પષ્ટ નકાર લખ્યો હતો અને ફરી ક્યારેય સમીક્ષા થઈ ન હતી.

નીતિ વંચાય તે પહેલાં જ નકાર થઈ શકે છે

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

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

ત્રણ સ્થિતિઓ, અને ત્રીજી અદૃશ્ય છે

TRUE ડાયલ-ઇનની પરવાનગી આપે છે, FALSE તેને નકારે છે, અને NULL મૂલ્યનો અર્થ છે કે એકાઉન્ટ તેનો જવાબ રિમોટ ઍક્સેસ નીતિ અથવા NPS ઑથરાઇઝેશનમાંથી વારસામાં લે છે. GUI તે ત્રીજી સ્થિતિને "Control access through NPS Network Policy" તરીકે દર્શાવે છે, અને તે નિર્ણયના બદલે ન ચિહ્નિત થયેલી ચેકબોક્સ જેવી વંચાય છે.

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

વારસાગત એકાઉન્ટ ગુમાવ્યા વિના ફ્લેગ્સ નિકાસ કરો

નિકાસ ડોમેન કંટ્રોલર પરથી, અથવા Active Directory મોડ્યુલ ધરાવતા વર્કસ્ટેશન પરથી ચલાવો, અને સારાંશ ફરી ટાઇપ કરવાને બદલે કાચી ફાઇલ પુરાવા તરીકે રાખો:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

એક જ LDAP ફિલ્ટર ફેરફાર રેકોર્ડમાં પેસ્ટ કરવું સરળ છે. આ ફક્ત સ્પષ્ટ પરવાનગીઓ પરત કરે છે:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

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

ફ્લેગને જૂથ ઍક્સેસ અને એકાઉન્ટની સ્થિતિથી અલગ કરો

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

તમે જેના પર કાર્ય કરો છો તે સંયોજનો છે. નિષ્ક્રિય એકાઉન્ટ TRUE સાથે ફક્ત ઘોંઘાટ છે. સક્ષમ એકાઉન્ટ TRUE સાથે એક વર્ષ લૉગિન ન કર્યું હોય તો તે દૂર કરવાનો ઉમેદવાર છે. પણ VPN જૂથમાંનું વારસાગત એકાઉન્ટ જેની કોઈ સમજૂતી આપી શકતું નથી તે જ ખરેખર મહત્ત્વની શોધ છે, કારણ કે કોઈ એક પણ સેટિંગ નોંધતું નથી કે તે કેમ આપવામાં આવ્યું.

તે એ ડોમેન કંટ્રોલર પરથી વાંચો જેની સામે VPN સર્વર ખરેખર પ્રમાણીકરણ કરે છે. રેપ્લિકેશન વિલંબ એવું મૂલ્ય દર્શાવી શકે છે જે સર્વરે પહેલેથી બદલી નાખ્યું છે, અને જૂનું DC મૂલ્ય ટાંકતું ઑડિટ જે ક્ષણે કોઈ ફરી ચકાસશે તે ક્ષણે પડકારાયું જશે.

એક એકાઉન્ટ બદલો અને સાબિત કરો કે ફેરફાર પહોંચ્યો છે

ઍક્સેસ દૂર કરવા માટે લક્ષણને FALSE પર સેટ કરો, તેને સાફ કરવાને બદલે. સાફ કરવાથી એકાઉન્ટ નીતિ-વારસામાં પાછું જાય છે, જે આગલા કનેક્શન પર ફરી પરવાનગી આપી શકે છે, અને ફેરફાર સુધારા જેવો લાગે છે જ્યારે વાસ્તવમાં તે અલગ નિર્ણય છે:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

બીજી લાઇન વારસાનું રીસેટ છે, જાણી જોઈને અલગ રાખવામાં આવી છે જેથી કોઈ બે ક્રિયાઓ ભેગી ન કરે. પછી બીજા સત્રમાંથી ખાતરી કરો, લક્ષણ ફરી વાંચો, અને કન્સોલના રિફ્રેશ પર ભરોસો કરવાને બદલે નકાર માટે NPS હિસાબી ઘટનાઓ તપાસો.

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

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