Sino ang Maaaring Mag-dial In? Pag-audit ng msNPAllowDialin Bago ang VPN Access

Tama ang password, nasa VPN group ang account, at tinatanggihan pa rin ang koneksyon gamit ang mensaheng hindi man lang nagbabanggit ng anumang patakaran. Kapag nangyari ito sa isang Windows remote-access server, ang unang titingnan ko ay hindi ang NPS rule kundi isang attribute ng Active Directory na walang nagbubukas: msNPAllowDialin, ang value sa likod ng Dial-in tab. May tatlong estado ito, at ang pangatlo ay tahimik na nagbibigay ng desisyon sa ibang lugar. Kadalasan, walang sinasadyang nagbago nito: ang account ay kinopya mula sa isang template, o ginawa ng isang script na nagsulat ng tahasang pagtanggi maraming taon na ang nakalipas at hindi na muling nirepaso.

Maaaring mangyari ang pagtanggi bago pa mabasa ang patakaran

Sinusuri ng Windows ang pahintulot sa pag-dial ng account habang binubuo ang desisyon sa awtorisasyon, kaya't maagang tinatapos ng tahasang pagtanggi ang usapan. Ang nakikita sa client ay isang pangkalahatang pagkabigo sa pagpapatunay, kung minsan pagkatapos mabuo ang pagpapalitan ng sertipiko, at iyon ang dahilan kung bakit nag-aaksaya ang mga tao ng isang hapon sa pagsubok ng mga kredensyal na hindi naman kailanman naging problema.

Ang kabaligtarang kaso ay kasingnakakalito. Ang account na hindi kailanman nalagyan ng flag ay maaaring matagumpay na kumonekta dahil pinahintulutan ito ng patakaran, at pagkatapos ay hihinto ang parehong account sa pagkonekta kapag may nag-edit ng NPS rule dahil sa isang walang kaugnayang dahilan. Wala sa dalawang pangyayaring iyon ang mukhang pagbabago sa pahintulot sa pag-dial mula sa labas.

Tatlong estado, at ang pangatlo ay hindi nakikita

TRUE pinapayagan ang pag-dial in, FALSE tinatanggihan ito, at ang NULL ay nangangahulugang ang account ay nagmamana ng sagot mula sa patakaran ng remote access o sa awtorisasyon ng NPS. Ipinapakita ng GUI ang pangatlong estadong iyon bilang "Control access through NPS Network Policy", at binabasa ito na parang hindi naka-check na kahon sa halip na desisyon.

Kaya't ang pagbilang ng mga pinapayagang user mula sa console ay halos walang sinasabi. Ang namana na account ay maaaring pinapayagan ngayon at tatanggihan bukas nang hindi hinahawakan ang account, at ang FALSE account ay maaari pa ring kumonekta sa isang server na ang patakaran ay nakatakdang balewalain ang mga katangian ng pag-dial ng user. Basahin ang attribute at ang patakaran nang sabay, o kalahati lang ng desisyon ang inaaudit mo.

I-export ang mga flag nang hindi nawawala ang mga namana na account

Patakbuhin ang pag-export mula sa isang domain controller, o mula sa isang workstation na may Active Directory module, at itago ang raw na file bilang ebidensya sa halip na i-type muli ang buod:

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

Mas madaling i-paste sa isang talaan ng pagbabago ang isang LDAP filter. Ibinabalik lamang nito ang mga tahasang pahintulot:

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

Pagkatapos, mag-query muli nang walang sugnay sa pag-dial at hanapin ang mga account na wala ang value. Iyon ang mga namana, kadalasan ang pinakamalaking grupo sa domain, at ang paglaktaw sa kanila ay ginagawang listahan ng ilang taong naalala ng isang tao na i-configure nang manu-mano ang isang audit.

Ihiwalay ang flag mula sa access ng grupo at sa kalusugan ng account

Sinasagot ng attribute ang isang tanong: maaari bang mag-dial in ang account na ito. Wala itong sinasabi tungkol sa kung nagtatrabaho pa rin dito ang tao, kung naka-enable ang account, o kung may nakalagay na shared password sa isang nota ng help desk. Ipares ang export sa estado ng pag-enable, petsa ng huling pag-log on, at pagiging miyembro ng grupong nagbibigay ng access sa server.

Ang mga kombinasyon ang pinagkikilosan mo. Ang naka-disable na account na may TRUE ay ingay lamang. Ang naka-enable na account na may TRUE na hindi nag-log on nang isang taon ay kandidato para alisin. Ang namana na account sa VPN group na walang makapagpaliwanag ay iyon ang tunay na mahalagang natuklasan, dahil walang iisang setting na nagtatala kung bakit ito ibinigay.

Basahin ito mula sa domain controller na aktuwal na pinagpapatunayan ng VPN server. Maaaring magpakita ng value ang pagkaantala ng replication na napalitan na ng server, at ang audit na sumipi ng lumang DC value ay kukwestiyunin sa sandaling may mag-verify muli.

Baguhin ang isang account at patunayang nakarating ang pagbabago

Upang alisin ang access, itakda ang attribute sa FALSE sa halip na i-clear ito. Ibinabalik ng pag-clear ang account sa mana ng patakaran, na maaaring muling magpahintulot dito sa susunod na koneksyon, at ang pagbabago ay mukhang pagwawasto habang talagang ibang desisyon ito:

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

Ang pangalawang linya ay ang pag-reset ng mana, sadyang hiwalay na itinago upang walang makalito sa dalawang operasyon. Pagkatapos, kumpirmahin mula sa pangalawang session, basahin muli ang attribute, at suriin ang mga event ng accounting ng NPS para sa pagtanggi sa halip na magtiwala sa refresh ng console.

Sa huli, itala kung aling mekanismo ang nagmamay-ari ng desisyon para sa bawat serbisyo ng remote access. Kung binabalewala ng patakaran ang mga katangian ng pag-dial ng user, ang kundisyon ng grupo ang may awtoridad at ang attribute ay payo lamang para sa serbisyong iyon. Maaaring lehitimong magkaiba ang sagot ng dalawang serbisyo sa iisang domain, at dapat itong sabihin ng talaan ng pagsusuri sa isang linya bawat serbisyo.

Ang output na nakakaligtas sa isang audit ay maikli: sino ang maaaring kumonekta, sa ilalim ng aling mekanismo, kailan nirepaso, at kanino. Ang flag ng pag-dial ay nagbibigay ng unang dalawang sagot; ang natitira ay ang pagsusuri ng patakaran lamang ang nagbibigay.