0

I've created a new NPS network policy with the following settings:

Overview
- Policy Enabled
- Grant access
- Type: Remote Access Server (VPN-Dial up)

Conditions
- Machine Group: Domain Computers

Constraints
- Authentication: EAP-MSCHAPv2, user can change password
- NAS port type: VPN

Authentication is handled locally and not passed to RADIUS.

When I attempt to connect to the VPN my connection doesn't match the policy. I've tried using both "Machine Group" and "Windows Group" conditions. I've tried various other authentication methods. It seems to me that there is some additional step that I'm missing but cannot find any documentation on using Machine Group conditions.

This is the most helpful unhelpful article from Microsoft on the topic, and it only states "If the NAP enforcement method is 802.1X or VPN enforcement, members of the security group can be users or computers." Under "Settings" I've checked "NAP Enforcement" and there are no options to select different enforcement methods; we have no health policies created and are not using NAP at this time.

I must be missing something, but I don't know what. I've thought about setting up a CA and doing certificate authentication, but I don't think that should be necessary just to filter by computer security group membership.

:Edit:
So I gave this some more extensive troubleshooting on the 26th when I had a few more hours to devote to it, but I've been so busy I haven't been able to update this question. I enabled auditing and reviewed the detailed NPS logs which helped tremendously, in conjunction with this explanatory article from Microsoft.

  1. Using a server type of "VPN" I was getting reason code 48, "IAS_NO_POLICY_MATCH". I discovered after copying our wireless policy (which uses machine group filter only and works) I found that the server type has to be set to "unspecified".

  2. I then saw reason code 66 which translates to "IAS_INVALID_AUTH_TYPE", and found that I had mismatched authentication settings between the client and the server (doh). (This is most likely because I gave up testing with a copy of our regular VPN policy which uses MS-CHAPv2 and copied our wireless policy which uses PEAP and didn't update the client accordingly.)

  3. I saw reason code 65 which translates to "IAS_DIALIN_DISABLED". This is where things get weird.

    a. If I add a second, "AND", condition for user group membership (using user group conditions or windows group conditions) I get nowhere, same error code. (Using a single Windows Group condition for "Domain Computers" OR "VPN Users" allows VPN users in from any computer, but not any user from Domain Computers.)

    b. If I set the policy to "Ignore user account dial-in properties", I get nowhere, same error code.

    c. If I go to the user's AD object properties in ADUC and change the Dial-in properties from "Control access through NPS Network Policy" to "Allow access" everything works.

At this point I'm convinced there's some sort of bug or design flaw in NPS that is keeping this from working. I haven't had any success so far in finding any KB from MS with a hotfix or update to download, but the fact that other people seem to have this working tells me that something is broken in our environment. If anyone has any ideas what that might be, please let me know!

1

I would suggest changing the "Type of network access server" to "Unspecified". Then add the condition "NAS Port Type:VPN"

I am using the condition "Windows Groups" successfully for machine accounts.

|improve this answer|||||
  • Thanks for the response. The day before you answered I was able to make a lot of progress on my troubleshooting, updating the question with my findings. – Thomas Oct 31 '17 at 15:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.