Vem får ringa in? Revision av msNPAllowDialin före VPN-åtkomst

Lösenordet är rätt, kontot finns i VPN-gruppen, och anslutningen avvisas ändå med ett meddelande som inte nämner någon princip alls. När det händer på en Windows-server för fjärråtkomst är det första stället jag tittar inte NPS-regeln utan ett Active Directory-attribut som ingen öppnar: msNPAllowDialin, värdet bakom fliken Dial-in. Det har tre tillstånd, och det tredje överlämnar beslutet tyst till någon annanstans. Oftast har ingen ändrat det med avsikt: kontot klonades från en mall eller skapades av ett skript som skrev en uttrycklig nekning för år sedan och aldrig granskades igen.

Avvisningen kan ske innan principen läses

Windows kontrollerar kontots inringningsbehörighet medan det bygger auktoriseringsbeslutet, så en uttrycklig nekning avslutar samtalet tidigt. Det du ser på klienten är ett allmänt autentiseringsfel, ibland efter att certifikatutbytet slutförts, och därför ägnar folk en eftermiddag åt att testa inloggningsuppgifter som aldrig var problemet.

Det omvända fallet är lika förvirrande. Ett konto där flaggan aldrig satts kan ansluta framgångsrikt eftersom principen tillät det, och sedan slutar samma konto att ansluta när någon redigerar NPS-regeln av en orelaterad anledning. Ingen av de två händelserna ser utifrån ut som en ändring av inringningsbehörigheten.

Tre tillstånd, och det tredje är osynligt

TRUE tillåter inringning, FALSE nekar det, och ett NULL innebär att kontot ärver sitt svar från principen för fjärråtkomst eller NPS-auktorisering. GUI visar det tredje tillståndet som "Control access through NPS Network Policy", och det läses som en omarkerad kryssruta snarare än ett beslut.

Därför säger det nästan ingenting att räkna tillåtna användare från konsolen. Ett ärvt konto kan vara tillåtet i dag och nekat i morgon utan att kontot rörs, och ett FALSE konto kan fortfarande ansluta på en server vars princip är inställd att ignorera användarens inringningsegenskaper. Läs attributet och principen tillsammans, annars granskar du halva beslutet.

Exportera flaggorna utan att tappa de ärvda kontona

Kör exporten från en domänkontrollant, eller från en arbetsstation med Active Directory-modulen, och behåll råfilen som bevis i stället för att skriva om en sammanfattning:

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

Ett enda LDAP-filter är lättare att klistra in i en ändringsregistrering. Det här returnerar bara de uttryckliga tillstånden:

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

Fråga sedan igen utan inringningsklausulen och leta efter konton där värdet saknas. Det är de ärvda, oftast den största gruppen i domänen, och hoppar du över dem blir en revision en lista över de få personer som någon kom ihåg att konfigurera för hand.

Skilj flaggan från gruppåtkomst och kontots hälsa

Attributet svarar på en fråga: får det här kontot ringa in. Det säger ingenting om personen fortfarande arbetar här, om kontot är aktiverat eller om ett delat lösenord ligger i en anteckning från supporten. Para ihop exporten med aktiveringsstatus, datum för senaste inloggning och det gruppmedlemskap som ger åtkomst till servern.

Kombinationerna är det du agerar på. Ett inaktiverat konto med TRUE är bara brus. Ett aktiverat konto med TRUE som inte loggat in på ett år är en kandidat för borttagning. Ett ärvt konto i VPN-gruppen som ingen kan förklara är fyndet som betyder något, eftersom ingen enskild inställning registrerar varför det beviljades.

Läs det från den domänkontrollant som VPN-servern faktiskt autentiserar mot. Replikeringsfördröjning kan visa ett värde som servern redan har ersatt, och en revision som citerar ett inaktuellt DC-värde kommer att ifrågasättas i samma stund någon kontrollerar igen.

Ändra ett konto och bevisa att ändringen kom fram

För att ta bort åtkomst, sätt attributet till FALSE i stället för att rensa det. Rensning återför kontot till principärvning, som kan tillåta det igen vid nästa anslutning, och ändringen ser ut som en rättelse medan den i själva verket är ett annat beslut:

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

Den andra raden är återställningen av ärvning, medvetet hållen separat så att ingen blandar ihop de två operationerna. Bekräfta sedan från en andra session, läs attributet igen och kontrollera NPS-redovisningshändelserna för avvisningen i stället för att lita på konsolens uppdatering.

Skriv slutligen ned vilken mekanism som äger beslutet för varje fjärråtkomsttjänst. Om principen ignorerar användarens inringningsegenskaper är gruppvillkoret avgörande och attributet bara rådgivande för den tjänsten. Två tjänster i samma domän kan legitimt svara olika, och granskningsanteckningen bör säga det på en rad per tjänst.

Det resultat som överlever en revision är kort: vem som får ansluta, enligt vilken mekanism, granskat när, av vem. Inringningsflaggan ger de två första svaren; bara principgranskningen ger resten.