locked
NPS Policy failing - Reason Code 65 between two way trust domains RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have NPS (win server 2008 ) in DOMAIN1  configured(working)  .1x policy for assigning VLAN for user, I have working 2way trust to DOMAIN2. Users loged to their PC with DOMAIN2 accounts can't be authenticate. They match proper NPS policy (matching user Group from DOMAIN2) Access Permission  : allow but NPS still reject them with code 65 details below:

    User: 
    Security ID: DOMAIN2\TEST1
    Account Name: DOMAIN2\TEST1 
    Account Domain: DOMAIN2
    Fully Qualified Account Name: ....... 

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

    NAS: 
    NAS IPv4 Address: x.x.x.x
    NAS IPv6 Address: - 
    NAS Identifier: - 
    NAS Port-Type: Ethernet 
    NAS Port: 50634 

    RADIUS Client: 
    Client Friendly Name: ***** 
    Client IP Address: x.x.x.x 

    Authentication Details: 
    Connection Request Policy Name: NAP 802.1X (Wired) 
    Network Policy Name: correct group 
    Authentication Provider: Windows 
    Authentication Server: ****** 
    Authentication Type: PEAP 
    EAP Type: Microsoft: Secured password (EAP-MSCHAP v2) 
    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.

    Pls  any idea?

    Wednesday, April 30, 2014 9:24 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Do these domains belong to the same forest? Two way trust is not required to configure if they are in the same forest, otherwise, please check whether your two-way trust works properly to find if there is any error about two-way trust in the event viewer.

    Authentication always occurs in the domain which users belong to. This is done by the involved DCs, where the users get the token information that allow to access the other domains resource.

    Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. An SPN can be one of the following:

    • Domain Name System (DNS) name of a host
    • DNS name of a domain
    • Distinguished name of a service connection point object

    When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and follows the referral chain until it gets to the domain where the resource is located.

    For more detailed information, view the link below,

    Accessing resources across forests
    http://technet.microsoft.com/en-us/library/cc772808(v=ws.10).aspx

    Steven Lee

    TechNet Community Support

    Monday, May 5, 2014 5:51 AM