locked
Network Policy Server - RADIUS issues RRS feed

  • Question

  • Hi,

    I'm trying to configure an NPS as a RADIUS server for a customer, I've never set one up before and after a week of troubleshooting from where I am to where the customer is (Across the country) we are finally getting rejected instead of no response from the server at all (yay).

    The issue I have now is event ID 4401 Domain controller for "domain" DIR is not responsive. NPS switches to another DC.

    Then I get event ID 4400 There is an LDAP connection for domain controller "domain" is established. Each time it hops between different domain controllers. This is a large domain with many DC's...

    The NPS server is a member of the RAS and IAS group in activate directory and is on the domain...

    Any ideas?

    EDIT:

    I would also like to add that I am getting access-request and access-challenge and access-reject while watching wireshark when someone tries to connect. The users are added to the security group that is added to the network policy conditions.

    • Edited by Sbakor Tuesday, June 21, 2016 8:07 PM
    Tuesday, June 21, 2016 8:01 PM

Answers

  • Just as an update, came in the next day and changed nothing and it started working... Just gonna chalk it up to network load...
    • Marked as answer by Sbakor Wednesday, June 22, 2016 3:59 PM
    Wednesday, June 22, 2016 3:59 PM

All replies

  • Hi ,

    NPS doesn't choose the DC. NPS calls the DC Locator Service to locate the DC.

    It should be a question about how client locates the DC.

    The picture below shows the process of how clients locates the DC,

    For detailed information, please refer to the blog below, Ace has explained the process in detail.

    The DC Locator Process, The Logon Process, Controlling Which DC Responds in an AD Site, and SRV Records

    http://blogs.msmvps.com/acefekay/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records/

    If you still have the question about how client locates the DC, to get better help, please post the question on the AD forum below,

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverDS

    ________________________________________
    Best Regards,
    Cartman
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, June 22, 2016 3:05 AM
  • Thanks for the response Cartman,

    I thought with RADIUS, the client attempts to connect to the SSID broadcasted from the WLC (Cisco 5508) in this case. The WLC sends the request to NPS server and the NPS server, can then either authenticate it itself or act as a proxy to another RADIUS server (It is not forwarding in this case, i have it configured to authenticate on the NPS server). From what I can tell the client isn't trying to contact the DC at all, on wireshark, I see an Access-request from the WLC, to the NPS server, the NPS server then sends an access-challenge and shortly after I see the NPS server send an LDAP packet to whichever DC it has connected too. It's like it can't stick with 1 DC long enough to authenticate a user.

    The event viewer logs show the ID's mentioned above.

    event ID 4401 "Domain controller for "domain" DIR is not responsive. NPS switches to another DC."

    event ID 4400 "There is an LDAP connection for domain controller "domain" is established."

    The NPS and WLC in question are also on a satellite link so latency between the NPS and the AD environment is high, so i'm starting to think that may be an issue as well.

    I will look into the DC locator service a bit more and see if I can come up with anything. When I figure out the solution I will be sure to post it here in case anyone else has similar problems. Until then, still open to any ideas! thank you.

    I found this article...steps 5 and 6 I think is where I'm getting confused, this article claims NPS is authenticating with a global catalog, and the article you linked claims the client contacts a DC.

    https://technet.microsoft.com/en-us/library/dd197428%28v=ws.10%29.aspx

    • Edited by Sbakor Wednesday, June 22, 2016 1:02 PM
    Wednesday, June 22, 2016 12:24 PM
  • Just as an update, came in the next day and changed nothing and it started working... Just gonna chalk it up to network load...
    • Marked as answer by Sbakor Wednesday, June 22, 2016 3:59 PM
    Wednesday, June 22, 2016 3:59 PM