Some users cannot login to new NPS based VPN server

Our environment previous used a Windows 2003 Server running RAS to offer our employees VPN. This server went away for multiple reasons and we built a brand new 2012 R2 server running NPS and RAS.

Since switching over we’ve had a few employees unable to login to the new VPN server. They keep getting “Invalid Username/Password”. Strangely these users had access to a different account that would work from their personal device. This eliminated client side issues as being the culprit.

Checking the Event Logs on the VPN server we found this event:

Log Name:      System
Source:        RemoteAccess
Date:          8/23/2017 10:03:12 AM
Event ID:      20271
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <SERVER FQDN>
Description:
CoId={NA}: The user <DOMAIN>\<USERNAME> connected from xxx.xxx.xxx.xxx but failed an authentication attempt due to the following reason: The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.

We had the user login to Webmail to verify their username and password. Everything was fine.

That led us into the text based logs. We found these:

10.x.x.x,<DOMAIN>\<USERNAME>,08/23/2017,09:58:49,RAS,<SERVERNAME>,44,1634,32,<SERVERNAME>,4,10.x.x.x,7,1,5,6,61,5,64,3,65,1,30,104.x.x.x,67,104.x.x.x,31,207.x.x.x,66,207.x.x.x,4108,10.x.x.x,4128,<SERVERNAME>,8132,2,4147,311,4148,MSRASV5.20,4160,MSRASV5.20,4159,MSRAS-0-DESKTOP-DG5CEKG,8158,{552971A4-83C8-4208-A1F7-54834C94498F},4154,Microsoft Routing and Remote Access Service Policy,4155,1,4129,<DOMAIN>\<USERNAME>,25,311 1 104.x.x.x 08/09/2017 14:23:47 1633,4127,4,4130,<DOMAIN FQDN>/User Accounts/<OU>/<OU>/<USERNAME>,4149,ORG VPN Access,8136,1,4136,1,4142,0

10.x.x.x,<DOMAIN>\<USERNAME>,08/23/2017,09:58:49,RAS,<SERVERNAME>,44,1634,25,311 1 104.x.x.x 08/09/2017 14:23:47 1633,8153,0,8111,0,6,2,4130,<DOMAIN FQDN>/User Accounts/<OU>/<OU>/<USERNAME>,4294967206,12,4294967207,2,4294967209,120,4294967210,50,28,3600,7,1,8136,1,4149,ORG VPN Access,4154,Microsoft Routing and Remote Access Service Policy,4155,1,4129,<DOMAIN>\<USERNAME>,4127,4,4120,0x00564955,4136,2,4142,0

10.x.x.x,<DOMAIN>\<USERNAME>,08/23/2017,09:58:49,RAS,<SERVERNAME>,32,<SERVERNAME>,4,10.x.x.x,6,2,7,1,5,6,61,5,64,3,65,1,30,104.x.x.x,67,104.x.x.x,31,207.x.x.x,66,207.x.x.x,25,311 1 104.x.x.x 08/09/2017 14:23:47 1633,44,1634,8,10.x.x.x2,12,1400,28,3600,50,2045,51,1,55,1503507529,45,3,40,1,4108,10.x.x.x,4128,<SERVERNAME>,4147,311,4148,MSRASV5.20,4160,MSRASV5.20,4159,MSRAS-0-DESKTOP-DG5CEKG,8158,{552971A4-83C8-4208-A1F7-54834C94498F},8132,2,4120,0x00564955,4294967206,4,4154,Microsoft Routing and Remote Access Service Policy,4155,1,4136,4,4142,0

10.x.x.x,<DOMAIN>\<USERNAME>,08/23/2017,09:58:51,RAS,<SERVERNAME>,32,<SERVERNAME>,4,10.x.x.x,6,2,7,1,5,6,61,5,64,3,65,1,30,104.x.x.x,67,104.x.x.x,31,207.x.x.x,66,207.x.x.x,25,311 1 104.x.x.x 08/09/2017 14:23:47 1633,44,1634,8,10.x.x.x2,12,1400,28,3600,50,2045,51,1,55,1503507529,45,3,46,0,43,1068,42,1185,48,19,47,26,49,1,40,2,4108,10.x.x.x,4128,<SERVERNAME>,4147,311,4148,MSRASV5.20,4160,MSRASV5.20,4159,MSRAS-0-DESKTOP-DG5CEKG,8158,{552971A4-83C8-4208-A1F7-54834C94498F},8132,2,4120,0x00564955,4294967206,4,4154,Microsoft Routing and Remote Access Service Policy,4155,1,4136,4,4142,0

The tip-off here was “Microsoft Routing and Remote Access Service Policy”. That was not the name of our VPN access policy. In fact that policy is located on a completely separate tab in NPS.

Turns out the issue was a AD account setting:

After some digging I found out that this AD attribute is called ‘msnpallowdialin’ and can have the following values:

Knowing this I wrote a quick PowerShell script to tell me how many accounts we had configured incorrectly:

$usersTrue = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $TRUE}
$usersFalse = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $FALSE}
$usersUnset = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $NULL}

Write-Output "TRUE = $($usersTrue.Count)"
Write-Output "FALSE = $($usersFalse.Count)"
Write-Output "BLANK = $($usersUnset.Count)"

Turns out we had 142 accounts that were incorrect and 1783 accounts that were. All of the accounts that were incorrect have been around a LONG time.

To change this property on all accounts that were set to TRUE or FALSE we used the following script:

$usersTrue = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $TRUE}

foreach ($user in $usersTrue) {

    Set-ADUser $user -clear msnpallowdialin -Server <DC FQDN>

}

$usersFalse = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $FALSE}

foreach ($user in $usersFalse) {

    Set-ADUser $user -clear msnpallowdialin -Server <DC FQDN>

}

$usersTrue = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $TRUE}
$usersFalse = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $FALSE}
$usersUnset = Get-ADUser -SearchBase "OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN" -Filter * -Properties msnpallowdialin -Server <DC FQDN> |Where-Object {$_.msnpallowdialin -eq $NULL}

Write-Output "TRUE = $($usersTrue.Count)"
Write-Output "FALSE = $($usersFalse.Count)"
Write-Output "BLANK = $($usersUnset.Count)"

I didn’t bother making variables of the repeating values. You can just search/replace these scripts. You need to change “OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN” to be the OU of where your users are and “<DC FQDN>” to the FQDN of one of your Domain Controllers.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.