- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-31-2021 05:32 PM - edited 10-31-2021 05:40 PM
Hi Everyone,
I firstly want to thank to whomever takes their time to read this post, and provide me with some further insight.
To get into it.
I am attempting to configure RADIUS for Admins on my VM running 10.0.7, in which is pointing towards a Windows 2016 AD in a DMZ.
I have configured a service route to point RADIUS down this route.
I also have LDAP which works fine with User-ID.
I have followed these two videos, and the KB for RADIUS (going down the respective routes for config):
https://www.youtube.com/watch?v=1J9ZfwckUbE
https://www.youtube.com/watch?v=qloRn0ObQ0I
However, for some strange reason every time I try to access with my RADIUS account. I am receiving the following error in the system logs
What I can confirm is that the shared secret password is the same both sides, I have input this about three times. this also includes the tested admin user.
I have conducted a PCAP which appears to shows my PA sending the Radius request on port 1812 to the Server (telling me the config for PA is fine). However, it comes back with the 'Radius-Reject' response. Which would tell me there is something occurring in my AD.
I am hoping someone can point me in the right direction to look at what potential config I have missed on the AD. I really really hope it is not something soo obvious.
To add, I am only testing with PAP until I can this up and running, in which I will then increase the security of the exchange.
Please see images below with my configuration:
Service route
RADIUS Server Details
RADIUS Auth Profile
RADIUS Admin Test Prof
Auth Settings Under MGT Settings
Windows 2016 AD Details (I have registered the NPS to my see my AD users - which I see RAS - IAS Servers in the AD domain group for users)
RADIUS Client Settings
RADIUS Policy Part 1
RADIUS Policy Part 2
Vendor Attributes (Using VSA 1)
User 'Radius'
Dial In Properties for user 'Radius'
Also I have run the less mp-log authd.log:
Troubleshooting:
- I've tried to remove the User from all other domain groups and use one domain group for that user.
- Tried reinstalling server details in PA.
- For my authentication profile, I have tried to associate to the specific domains the user is a member of, rather than 'all'. Including adding the domain name for my AD to the profile details.
- Tried to use MGT interface rather than a Service route, in which I also amended on the NPS RADIUS settings for the IP.
- I have tried adding VSA (1 and 2) for the vendor attributes.
- I attempted to add the user in the RAS-IAS sec group.
- I finally created a brand new user (just to make sure that I did not input the generic password which I use incorrectly).
Is there any further logs, that I can investigate on the AD.
Thank you once again.
Callum
10-31-2021 08:08 PM
Hi @Callum_Bisley ,
An Access-Reject message means that RADIUS is working fine. The user was rejected by NPS policy. Also, the system log "invalid username/password" also indicates the PA is talking to NPS fine. You are correct to say, "there is something occurring in my AD." The best place to look for the reason NPS is rejecting the request is under the Windows Event Viewer in the Security logs.
Your other config looks fine at 1st glance. It looks like you have followed this document -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClIxCAK.
You can also test RADIUS without the VSAs by creating a local admin under Administrators and selecting RADIUS_ADMIN as the authentication profile. You can even assign your CorpAdmin role there. Of course, that doesn't scale well, but it allows you to eliminate some variables in your testing.
Thanks,
Tom
10-31-2021 08:08 PM
Hi @Callum_Bisley ,
An Access-Reject message means that RADIUS is working fine. The user was rejected by NPS policy. Also, the system log "invalid username/password" also indicates the PA is talking to NPS fine. You are correct to say, "there is something occurring in my AD." The best place to look for the reason NPS is rejecting the request is under the Windows Event Viewer in the Security logs.
Your other config looks fine at 1st glance. It looks like you have followed this document -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClIxCAK.
You can also test RADIUS without the VSAs by creating a local admin under Administrators and selecting RADIUS_ADMIN as the authentication profile. You can even assign your CorpAdmin role there. Of course, that doesn't scale well, but it allows you to eliminate some variables in your testing.
Thanks,
Tom
10-31-2021 08:25 PM
Hi Tom,
Thanks for the message, and the tips.
I hope I am not being too daft, but I am assuming the local admin will use the shared secret password instead? If I am creating a local admin which is not an AD member.
If that is the case, I am seeing the same error message as with my previous admin. Which would point me in the direction of the NPS policies.
If I am able to find the solution, I will mention on here.
Thanks
Callum
10-31-2021 08:28 PM
Hi @Callum_Bisley ,
Great questions. The local admin has to match an AD username exactly (case sensitive). The password will be the AD password. The shared secret is only for secure communication between the PA and NPS.
Thanks,
Tom
10-31-2021 08:37 PM
Hi Tom,
That's great, I am just testing this right now. The security logs have provided something interesting:
What it looks like to me (I am going to double check the NPS Polices) is that it appears to be hitting the wrong Network Policy. As I do know both sides for the configured policy should be using PAP.
If I can hopefully drill this down, I will update here.
Thanks for the message again.
Callum
10-31-2021 09:13 PM
Hi, @TomYoung
Also hello to everyone else whom may come across this issue themselves with regards to 2016 ADs
Ok, so with Toms' great advice (regards the PA config) and some research. It appeared to be hitting a completely different policy (a default RADIUS deny policy as stated in on my above image). So as a test, I allowed the policy and left the constraints with only the default time constraint, adding in the respective VSA for PA. In which has now worked, and I able to access with RADIUS as an Admin onto my PA.
However, when I added other constraints in such as 'Authentication', 'Windows Groups', and 'Client IP'. It would fail, on the PA side I would get generic invalid username/password error. I would get an error in the event security logs, actually not pointing towards any error at all simply stating 'No match to NPS policies'.
So for my configured VSA rule, I simply removed the constraints, added the time constraint, and it appears to be working.
I have to conduct some further tests. I.E removing adding constraints, removing local admin profile etc.
10-31-2021 09:27 PM
Hi Everyone,
Finally to add to this post.
My apologies I meant 'Conditions' not 'Constraints'.
@TomYoung I finally removed the Local Admin Profile from my PA, and I am able to successfully (externally) authenticate to my NPS server.
After some testing, it was very weird, I retraced my steps and steadily added all the 'Conditions' that were failing previously. I have no idea why but it appears to be working.
If you come across this issue (a bit buggy) enable the denied policy (you see in the system logs>security on Windows event viewer) test, then disable and reenable your configured NPS policy.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!