locked
MS-CHAPV2 NAP Policy failing - Reason Code 65 RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a Sonicwall TZ100 using Radius that is connecting to a new install of Server 2012 with NPS configured. I've followed exactly what I've done on 2008 in the past and I'm getting errors when I try to connect. The error message is:

    Radius Client Authentication Failed (MSCHAP error: E=649 R=0 V=3)

    On the server, I have found that NPS authentication is failing with the following message:

    Reason Code: 65
    Reason: The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.

    I've found that if I edit the user profile in Active Directory and under a user's Dial-in tab select Allow Access, the error goes away and radius authenticates properly. For some reason the NPS policy isn't granting access properly. Where do I need to go to troubleshoot further why the NPS policy isn't working properly?

    • Moved by Aiden_Cao Wednesday, November 28, 2012 3:06 AM more appropriate (From:Network Infrastructure Servers)
    Tuesday, November 27, 2012 6:01 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Thanks for your post.

    Please change the User Dial-in AD properties Network Access Permission to Control access through NPS Network Policy. After that, verify if the user authenticate by Network Policy. In addition, you can also check the box Ignore user account dial-in properties in Network policy.

    Access Permission

    http://technet.microsoft.com/en-us/library/cc772123(v=ws.10).aspx

    Configure NPS to Ignore User Account Dial-in Properties

    http://technet.microsoft.com/en-us/library/cc732252(v=ws.10).aspx

    Best Regards,

    Aiden

    If you have any feedback on our support, please click here

    Aiden Cao
    TechNet Community Support

    Wednesday, November 28, 2012 4:51 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sorry if I didn't explain this clearly but I've already done both of those things.

    The users were set at the default setting of Control Access through NPS Network Policy. Under this default, Radius authentication fails. Changing this to Allow Access for testing purposes allows the user to authenticate via radius.

    I've tried setting the NPS policy using Ignore user account dial-in properties. When I do this, authentication still fails.

    I've configured this just like I've done in 2008 R2 many times and something in 2012 seems to be preventing the usual setup from working correctly. Where is the next place to look?

    Thursday, November 29, 2012 10:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Just checking in on this. I really need to find some resolution, but don't know where to start in 2012 to troubleshoot an issue that historically hasn't been one. Any thoughts as to where to start with this?
    Monday, December 3, 2012 10:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Sorry for the delay.

    This means that the network policy was not grant access to the authentication requests. Please verify that the connection request meet all conditions of the Network Policy which can get access. Ensure the properties was set to Control Access through NPS Network Policy, to see if the authentication still failed. Check the event logs record in NPS server. Detailed NPS event logs will logged under Event Viewer\Custom Views\Server Roles\Network Policy and Access Services.

     

    Best Regards,

    Aiden

    If you have any feedback on our support, please click here

    Aiden Cao
    TechNet Community Support

    Tuesday, December 4, 2012 2:08 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Aiden,

    The only condition listed in the NPS policy is that the user be a part of the Domain users group.

    The error message NPS event logs is:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/4/2012 12:22:20 PM
    Event ID:      6273
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      MPSDC.mps.local
    Description:
    Network Policy Server denied access to a user.

    Contact the Network Policy Server administrator for more information.

    User:
    Security ID: MPS\test
    Account Name: Test
    Account Domain: MPS
    Fully Qualified Account Name: mps.local/Company/Users/Test

    Client Machine:
    Security ID: NULL SID
    Account Name: -
    Fully Qualified Account Name: -
    OS-Version: -
    Called Station Identifier: -
    Calling Station Identifier: -

    NAS:
    NAS IPv4 Address: 10.10.0.1
    NAS IPv6 Address: -
    NAS Identifier: -
    NAS Port-Type: -
    NAS Port: 0

    RADIUS Client:
    Client Friendly Name: Sonicwall
    Client IP Address: 10.10.0.1

    Authentication Details:
    Connection Request Policy Name: Use Windows authentication for all users
    Network Policy Name: Connections to other access servers
    Authentication Provider: Windows
    Authentication Server: MPSDC.mps.local
    Authentication Type: MS-CHAPv2
    EAP Type: -
    Account Session Identifier: -
    Logging Results: Accounting information was written to the local log file.
    Reason Code: 65
    Reason: The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.

    As it turns out, I believe I've figured out the issue. I need to create a Connection Policy. In doing that I need a CA. All of these things are done on SBS by default and this is my first configuration of this on a non-SBS platform. I've got some more work to do but wanted to share this with others who may experience this at some point.

    Tuesday, December 4, 2012 8:49 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I'm getting the same issue.  Why would you need a CA?  Not needed for a Connection Policy.   I have a COnnection Policy created.  Plus there's one created by default.

    I get denied unless I changed the account to Allow Access under the Dial-in Tab.  Selecting Control through NPS denies me access.

    Friday, April 25, 2014 11:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    If NPS is not a member of the same domain or a trusted domain, it cannot read user settings from Active Directory. This might be a reason you are having trouble.

    You don't need a certification authority to authenticate unless you are using certificate based authentication (TLS). However, you do need a server certificate on NPS to authenticate with PEAP unless you clear this requirement ( which is not recommended for security purposes).

    -Greg

    Thursday, May 1, 2014 10:37 PM