FreeRADIUS is the most widely used RADIUS server in the world. It powers most major Internet Service Providers and Telecommunications companies world-wide and is one of the key technologies behind eduroam, the international Wi-Fi education roaming service. It is the RADIUS server used by all Cloud Identity providers and is embedded in products from network equipment vendors and token card manufacturers.
The FreeRADIUS product suite includes a server, radius client, development libraries, and numerous additional RADIUS and IP address-related utilities. It is fundamental to the working of the Internet around the world, and is responsible for authenticating hundreds of millions of users every day.
The FreeRADIUS project maintains the following components: a multi protocol policy server (radiusd) that implements RADIUS, DHCP, BFD, and ARP; a BSD licensed RADIUS client library; a RADIUS PAM library; and an Apache RADIUS module.
We provide a step-by-step guide to radiusd -X. The guide breaks down the different pieces of the debug output, and explains what they mean. Often you can just look for ERROR or WARNING to solve many problems.
I am running bigip 11.4.1 on a 3900 that is licensed for LTM and ASM with client authentication.I am able to configure user authentication to a Windows NPS radius server and have all external users all get authenticated to the windows radius and authorized to the same default external user role. (This is purely for user login access to the BIG-IP managment interface via a browser).
I would now like to create four new Windows user groups: F5-Admin, F5-resource-admin, F5-operator, F5-guest.The goal is to have the Windows NPS radius server return the F5 vendor specific attribute "F5-LTM-User-Role" with the appropriate values for the four roles I need.
I have the document: " -us/solutions/public/14000/300/sol14324.html".It is not clear to me how to add the role attributes to windows 2008 NPS such that the new role attribute will be returned to the F5 after successful authentication.It is also not clear how to configure the F5 to then take the returned role attribute for the user and over-ride (ignore) the default external role setting.
Since version 7.0 authentication against our microsoft NPS radius servers is broken. Because the firewall now always first tries CHAP instead op PAP (see this article) and microsoft NPS always replies with a ACCESS-REJECT massage (see this article -> item 9).
NPS logs give an error (19): No reversibly encrypted password is stored for the user account. This means you should enable reversible encryption on you domain controllers with the policy setting "Store password using reversible encryption for all users in the domain" which is not something we can do.
The whole CHAP implementation in 7.0 is pretty silly. The failover only works half the time for the inital logins, it causes massive issues with Multi Factor Authentication solutions using RADIUS Challenge/Response, there's no tickbox to turn it off and completely baffling that CHAP, instead of MS-CHAPv2 is supported..
Added a new CLI operational command ( set authentication radius-auth-type ) to address an incompatibility issue between PAN-OS and some RADIUS servers. With this fix, you can manually override the automatic selection mechanism introduced with Challenge-Handshake Authentication Protocol (CHAP) support in PAN-OS 7.0 to select either CHAP or Password Authentication Protocol (PAP) as needed.
We have a working Windows 2012R2 NPS server running our wireless network at the moment and I want to add the juniper devices to it. EX4200 and EX2200 mostly. I have the following config changes successfully setup:
set system authentication-order [ radius password ]
set system radius-server 10.10.10.1 secret "XXXXXXXXXXxxxxxxxxXXXXXXXXXXX"
set system radius-server 10.10.10.1 timeout 3
set system radius-server 10.10.10.1 retry 3
set system radius-server 10.10.10.1 source-address 10.3.0.1
set system radius-options password-protocol mschap-v2
set system services ssh
set system login user SU class super-user
set system login user SU full-name "Default RADUIS admin access template"
set system login user OP class operator
set system login user OP full-name "Default RADUIS operater access template"
set system login user RO class read-only
set system login user RO full-name "Default RADUIS read-only access template"
Logs in the Radius server show full-access with successful login. PIng tests between all is good and no firewall/filters anywhere in this setup. We checked and triple checked the vendor code in the Radius setup. No joy.
Basically, from what I can tell at this point, everything is working but the switch is waiting for 'something' from the Windows Server and not getting it. Or not understanding it. Does anyone have a working Windows 2012R2 setup? I would like to compare the setup if possible.
I have Accounting enabled on the Windows Server (which is now a DC running Server 2016. I had been running 2012 R2 but decided to wipe it and install 2016 afresh as though maybe RADIUS worked better!). The NPS Account log shows this when I click the Test button:
I joined this forum purely to post this reply, hopefully it helps your case. I was dealing with this problem today, and got to the point where I had the exact same issue above. My Windows 10 wifi would not authenticate, but my iPhone wifi would authenticate and work fine with the username and password once you trust a cert.
I solved this on my Windows 10 machine by connecting to the SSID, and not ticking "use my Windows user account" at the prompt, and instead I typed in my username and password without the domain prefix. A new message will appear asking you to confirm the expected domain it found, then it connects. Who knew.
Yes, I have a certificate selected in NPS > Network Policies > My Meraki Policy > Constraints > Auth Methods > Microsoft PEAP > (Edit), issued by the server I installed the CA role on. I suspect it could be failing to do with this? I think at some point I created a Group Policy to deploy that certificate to client PC's, perhaps something is amiss with that but I can't seem to get enough info from any logs.
Thanks, I did come across that thread previously (with all the Spanish screenshots!) but I think I need to get the Test button working from the Meraki dashboard > Access Control for SSID first, before I then troubleshoot client PC's, would you agree?
Okay I'll give it a go. Our clients are all Windows 10. At the moment when I try to connect to the Radius SSID it prompts me for credentials, with a tickbox to 'use my Windows user account', which if I tick fills in the boxes with my AD credentials. It check network requirements after clicking OK, but the credentials prompt just comes back again.
Interesting to read your post, i'm in pretty much the same boat. So I can sympathize with your struggles, I'm dealing with almost the same thing. One thing I wanted to mention is to be sure that your NPS Network Policy is configured per the Meraki Documentation for 802.1X authentication (in addition to having your RADIUS Clients portion configured) since I found it needed both in order to test from the Meraki Dashboard. Check the following:
So, i've gone through much of what you've already outlined and get the same interesting behavior. Macs and Apple IOS devices can successfully authenticate against AD using RADIUS, but only after they "Trust" the AD CS certificate used on our Domain.
I'm at a loss. I think this is a certificate issue on the windows end stations, but i am not sure how to fix this. I'd like to avoid having to push out a GPO to get this going. We have a large traveling workforce that doesn't always get GPO updates in a timely manner because they are off the domain most of the time.
I was able to get this resolved / working. Make sure that Wireless > Access Control > 802.11r is set to "Adaptive" (not Enabled). I think at one point we had turned this on. The tooltip description of what 802.11r made me think it only applied to old systems, not the Windows 10 computers we were having problems with.
802.11r technology reduces overhead when a client roams from one AP to another, delivering a more seamless transition. "Enabled" will activate 802.11r for devices that support it, though some legacy clients may not be able to join the network. "Adaptive" enables a custom version of 802.11r just for Apple iOS devices. Very few devices will have compatibility challenges with the "Adaptive" mode.
I was really hopeful with your suggestion on 802.11r, however I don't seem to have an 802.11r section in my dashboard! Searching for it just takes me to the Access Control page but the nearest thing to that on the page is 802.11w.
I've opened my AD user properties, navigated to the Dial-in tab, changed Network Access Permission to 'Control access through NPS Network Policy', then rebooted my laptop but no joy. I then changed it to 'Allow access' but still no joy. I made these changes on my local domain controller, but I'll try again in an hour or so in case it's referring to another DC for some reason.
With my user profile in AD set to 'Allow access' under the Dial-in tab, and the computer account having always been set to 'Control access through NPS Network Policy', I now see in Event Viewer on the NPS server:
I'm looking at your NPS logs and its definitely trying to authenticate a computer account (as opposed to a user security group), is this by design? You will need to have a matching NPS policy which allows the AD computer group(s) under NPS > Policies > Network Policies > (policy name) > Properties > "Conditions" Tab.
Note that when using conditions in NPS that all conditions have to be true. So when you want to match on Windows Groups (and assuming whatever needs access is not in both groups) you have to put both of those groups into a single condition.
If I change it to an OR condition, which I have previously tried, and set the condition to Windows Groups, when attempting to connect it just hangs on 'Verifying and connecting' on the laptop for a minute or so, then eventually ask for credentials. I tick the box for 'Use my Windows user account' and click OK, it checks for network requirements, then prompts for credentials again, and at no stage does anything get logged in the NPS event log.
c80f0f1006