SMB 2240 sa VPN: suriin ang listahan ng logon workstation

Ang pagbukas ng share sa tunnel ay nagbabalik ng error 2240, at ang unang reaksyon ay tingnan ang routing. Mas tiyak ang numero kaysa doon. Iniulat ng Windows na maaaring hindi makapag-logon ang account mula sa workstation na ito, na isang pahayag ng patakaran tungkol sa isang account at hindi pahayag tungkol sa maabot.

Itago ang numero ng error sa ticket. Pinapakipot nito ang imbestigasyon sa isang attribute at isang pangyayari.

Ano talaga ang tinutukoy ng 2240

Tinutukoy ng listahan ng error sa pamamahala ng network ang 2240 bilang NERR_InvalidWorkstation, isang pangalang dapat basahin nang literal. Ang account ay limitado sa isang set ng pinapayagang logon computer, at ang makina na nagpapakita ng mga kredensyal ay wala sa mga iyon. Wala sa kahulugang iyon ang tumutukoy sa tunnel, share ng file o password. Ang attribute ay nasa account at sinusuri kapag sinubukan ang pag-logon.

Ang ibang numero sa parehong pamilya ay may ibang kahulugan. Ang paglabag sa pinapayagang oras ng pag-logon ay ibang code, gayundin ang maling password. Ang pag-uulat sa lahat ng ito bilang problema sa access ay nagsasayang ng partikularidad na kabibigay lang ng operating system.

Ang paghihigpit ay naninirahan sa account, kaya sinusundan nito ang pagkakakilanlan saan man ito ma-authenticate. Ang user na nagtatrabaho sa opisina araw-araw at nagdadala ng laptop pauwi ay nakakatagpo nito lamang kapag nagbago ang pangalan ng makina, at iyon ang dahilan kung bakit ang pagkabigo ay maaaring magmukhang problema sa VPN nang ilang buwan bago may makakilala sa pattern.

Dalawang kaugnay na katotohanan ang hindi nagpapaliwanag nito. Ang NAT device ay maaaring magbago ng naobserbahang source address nang hindi hinahawakan ang attribute ng account, at ang pagbabago ng DNS suffix ay maaaring mag-ayos ng maikling pangalan habang iniiwan ang paghihigpit sa pag-logon kung saan ito naroon. Pareho itong dapat ibukod, at wala alinman ang pumapalit sa pagbasa ng attribute.

Basahin muna ang rekord ng bigong pag-logon

Alamin kung aling pagkakakilanlan ang in-authenticate ng file server, at aling makina ang nagpakita nito. Ang domain account, lokal na account na may katulad na maikling pangalan at hiwalay na VPN account ay hindi mapapalitan, at ang error ay may saysay lamang kapag alam ang eksaktong isa.

Itinatala ng security log ang pagtatangka kasama ang account at pangalan ng tumatawag na workstation, at iyon ang pares na sinusuri laban sa paghihigpit:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

Ipinapakita ng unang command ang pagkabigo at ang workstation string na natanggap ng server, at ng pangalawa ang pinapayagang listahan sa account. Ihambing ang dalawa sa halip na ipagpalagay na ang sariling pangalan ng computer ng client ang naitala ng server. Ang pangalang mukhang mali sa log ay karaniwang kapaki-pakinabang na natuklasan, dahil pinangalanan nito ang makinang pinaniniwalaang talagang kausap ng server. Iyon ang paniniwalang sinusuri ng paghihigpit.

Huwag idagdag ang pangalan ng VPN gateway dahil dumadaan dito ang trapiko. Ang gateway ay hindi ang authenticated na tumatawag, at ang pagdaragdag nito sa listahan ay walang binabago habang pinapahirap ang pagsusuri ng account.

Itama ang paghihigpit sa pinakamaliit na saklaw

Kung dapat payagan ang makina, idagdag ang eksaktong entry na iyon sa listahan ng workstation ng account at iwan ang lahat ng iba. Kung hindi, ang tamang sagot ay inaprubahang makina sa halip na alisin ang paghihigpit, dahil ang paghihigpit ay umiiral upang limitahan kung saan magagamit ang mga kredensyal na iyon.

Ang maramihang pag-edit ay karaniwan dito at kadalasang mali. Ang account na may mahabang listahan ng pinapayagang makina ay account na ang paghihigpit ay tumigil nang mangahulugan ng anuman.

Nakakatulong ding malaman kung ibinabahagi ang pagkakakilanlan. Kapag maraming tao ang gumagamit ng isang service account mula sa maraming laptop, lumalaki ang listahan ng workstation hanggang maging walang saysay ang patakaran, na problema sa disenyo at hindi sa pangangasiwa.

Basahin ang susunod na resulta, hindi ang kawalan nito

Pagkatapos ng inaprubahang pagbabago, gumawa ng bagong kahilingan gamit ang sinadyang account at itala ang nangyari. Ang ibang error ay pag-unlad, dahil pinangalanan nito ang susunod na yugto sa halip na ulitin ang nauna.

Ang DFS path ay maaaring magdala ng maraming server at maraming desisyon sa access. Ang paglilinis ng isang attribute ng account ay nag-aayos ng isa sa kanila. Ang mga target ng referral ay kailangan pa ring maabot, at ang mga pahintulot sa share at filesystem sa bawat isa sa kanila ay kailangan pa ring tanggapin ang account. Dumaan sa susunod na error sa parehong paraan sa halip na ipagpalagay na ang unang pag-ayos ay sumakop sa lahat.

Walang dahilan upang muling buuin ang VPN profile o i-reset ang password habang nag-uulat ang Windows ng paghihigpit sa workstation. Ang listahan ng mga error sa network ng Microsoft ay dapat itago nang bukas sa eksaktong dahilang ito: sinasabi ng code kung aling attribute ang susuriin bago ka humawak ng anuman.