locked
Deny Access based on RADIUS client and group RRS feed

  • Question

  • I'm having issues blocking internal users accessing a SSID (eduroam) -the same users are allowed access when not on campus. 

    I've two Network Policies enabled and in processing order they are as follows:

    The first Network Policy is set to deny access. Its conditions are "User Groups = [domain]\default staff group OR [domain]\default student group" and Client IPv4 Address with all the 9 Wifi controllers (Ruckus Zone Directors) IP's (as per RADIUS clients)

    I have also tried using Client Friendly Name, and changing the "User Groups" to equal "[domain]\Domain Users" only but these changes had no affect (I restarted the NPS service after each change).

    The second Network Policy grants access with condition of "User Groups = [domain]\default staff group OR [domain]\default student group"

    For both policies Constraints and Settings are identical.

    This setup initially worked to block internal users but some time in the last few months has stopped.

    Viewing logs I can see that internal users are accessing the SSID with the NP Policy name in the log being the second policy i.e. the conditions of the first policy are not being met. Yet the Client IP Address / Client Friendly Name are the ones in the first policy meant to disable access.

    Any ideas?

    Wednesday, April 27, 2016 9:41 PM

Answers

  • Solved:

    I realised that when the system was being set up I had only tested with one campus RADIUS client in the deny policy and the deny policy worked. Going live I added the 8 other campus Zone Directors as clients (separate "Client Friendly Names") in the same policy.

    This means the request would have to be marked as coming from all RADIUS clients so of course the conditions will never be met.

    Separating out the RADIUS clients into separate deny policies works for denying access so will either workout the correct Client Friendly Name (or a Client IPv4 Address) pattern matching syntax (so i don't need a separate policy per campus RADIUS client)

    :)


    • Marked as answer by SteveHB Thursday, April 28, 2016 11:14 PM
    • Edited by SteveHB Thursday, April 28, 2016 11:15 PM
    Thursday, April 28, 2016 11:14 PM

All replies

  • Hi SteveHB,

    According your description,you have already add Wireless access point as RADIUS clients.Then,please Use the 802.1x Wizard to Configure Network Policies:

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

    After you finished that,you got 2 policies created:

    • One connection request policy
    • One network policy

    In the network policy,you have 2 conditions:

    Then set this policy to Deny Access.

    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.

    Thursday, April 28, 2016 6:36 AM
  • Hi Cartman,

    Unfortunately this will not work as it will then block the external (allowed) users on our campuses from Eduroam WiFi as they also will have the same NAS Port type, plus it will also block our users located externally for the same reason.

    I should have more fully explained what eduroam is so FYI: (from https://www.eduroam.us/) "eduroam (education roaming) is the secure, world-wide roaming access service developed for the international research and education community.  eduroam allows students, researchers and staff from participating institutions to obtain Internet connectivity across campus and when visiting other participating institutions by simply opening their laptop"

    Basically one of our users on an external institution will connect to that institute's eduroam wifi network, that institute's RADIUS system will forward the request to the federation (national) RADIUS server and on to our RADIUS (NPS) server. The same traffic flow is true for external users on our network (i.e. we have the federation server set up in NPS as a remote RADIUS server which all external users requests get forwarded to).

    This is a live system that is working and has been for some time -just the deny of internal users is not working (I thought it had but after going through the logs this may not be the case)

    Thank you for trying though!
    Cheers

    Steve

    Thursday, April 28, 2016 10:42 PM
  • Solved:

    I realised that when the system was being set up I had only tested with one campus RADIUS client in the deny policy and the deny policy worked. Going live I added the 8 other campus Zone Directors as clients (separate "Client Friendly Names") in the same policy.

    This means the request would have to be marked as coming from all RADIUS clients so of course the conditions will never be met.

    Separating out the RADIUS clients into separate deny policies works for denying access so will either workout the correct Client Friendly Name (or a Client IPv4 Address) pattern matching syntax (so i don't need a separate policy per campus RADIUS client)

    :)


    • Marked as answer by SteveHB Thursday, April 28, 2016 11:14 PM
    • Edited by SteveHB Thursday, April 28, 2016 11:15 PM
    Thursday, April 28, 2016 11:14 PM