Meraki

HarleyBurton · ‎Aug 9 2020

That's my opinion around most everything Microsoft. It tends to "just work" for the most basic and cookie cutter scenarios. However, when it doesn't "just work" it's a horrible platform to work with. That being said, I'm surprised that THIS isn't something that just works. I mean, I'm trying to use a Microsoft service to authenticate against a Microsoft platform, and I'm using a built-in filter option where I'm literally selecting the group from a drop-down that is given to me from the connection to the domain. I'm not trying to do anything that I wouldn't assume is cookie cutter.

HarleyBurton · ‎Aug 9 2020

Thank you again. The events confirm that the user is part of the correct domain, and the correct fully qualified account name is being returned. However, there is no indicator of group membership in the event logs. If there should be, that may be pointing me to the problem, and, as I have suspected, it could be a problem with the way the user(s) is/are setup on the domain. These are full-fledged user groups, and not security groups or any other specialized group. It could be that my assumptions about how this works are incorrect, but the document that you linked seems to support my assumption that when a user provides his/her credentials, nps verifies them with the DC and is given the information that it needs to act on these filter options (Group Membership in this case). I also tried looking at packet captures (Running WireShark on the NPS server) and I'm not seeing anything useful. It's times like these when I miss old Unix and Linux servers so much. You had to understand them, but they always seemed to give you what you needed for troubleshooting once you knew how to tickle it out. Maybe Windows is the same and I just don't know where to tickle it.

HarleyBurton · ‎Aug 9 2020

Thanks. I did try that, and no change. I've been applying the blackbox troubleshooting method of changing different things and seeing what happens, so I've changed things like that, that make sense, as well as things that don't even make sense like putting the group-based policy last instead of first. Even tried dropping all encryption and using EAP. At this point, I suspect that it's something at the domain level, like the type of group; maybe it needs to be a security group, or some such, but I don't have access to the DC, and can't find any documentation that goes in to the domain requirements.

HarleyBurton · ‎Aug 8 2020

This question is much more a Microsoft/Windows question than a Meraki question, but I expect some of you guys have experience with NPS and may be able to help. I have RADIUS working for AD authentication using what will be my "fallback" policy in the end. The fallback policy has a single Condition (EAP OR PEAP) and is last in the processing order. I have added a second (first in processing order) policy that contains the same EAP OR PEAP Condition as well as a User Groups condition that should match for users who are part of the selected group (WKAdmins). However, when I login (802.1x) as a user from our WKAdmins group, the login is successful but it uses the fallback policy. I have confirmed that the user is part of the WKAdmins group, and that the NPS Server is able to see the group membership for that user, but I don't know what else I can look at. NPS seems to be a black box, and all there is to see is the result of a request. I can see that the NP-Policy-Name used to authenticate the user is our fallback policy, but I have no way to see why, or look deeper in to that process as far as I can see. If anyone knows of tools that would be helpful in troubleshooting, or, better yet, what I may be missing, I would greatly appreciate it.

Meraki

Community

About HarleyBurton

HarleyBurton

Community Record

Badges

Re: Troubleshooting NPS RADIUS Network Policy Matching

Re: Troubleshooting NPS RADIUS Network Policy Matching

Re: Troubleshooting NPS RADIUS Network Policy Matching

Troubleshooting NPS RADIUS Network Policy Matching

Re: Troubleshooting NPS RADIUS Network Policy Matching