Sorry, I mistook you. I thought you meant create policies matching AD user, not SG. I understand the user-id process now. I'm still stuck on RADIUS to AD. We have RADIUS to our MFA provider working, but I am still working out certificate issues connecting to AD, I think. I do still have some conceptual areas that are unclear. Reading about authentication sequence, the documentation states that the first authentication method to succeed causes the sequence to complete with a success. No further authentication profiles are used. So if I want to use Kerberos for user ID and then RADIUS to return group membership, that doesn't seem like it works that way. If Kerberos works, the rest of the authentication sequence is not processed. RADIUS alone seems like it would work correctly to authenticate the user and match security group. So the only usefulness of Kerberos with Palo Alto then seems to be for SSO? But this implies that if you did use SSO (requiring Kerberos) you can't then create further policies matching the AD security group instead of the user account. That seems like a needless limitation, if true. Another area that I don't quite understand is that it seems like RADIUS security group matching occurs on the RADIUS server end / AD ? In other words, it seems like one makes NSP policies that match the security group and allow login or not allow and this is what is returned to Palo Alto, not the security group membership? That can't be the case but I don't see how RADIUS passes back the SG membership nor how Palo Alto identifies it and uses it. Maps SG group to Role is what I am assuming. This would be a whole lot easier and more powerful if PanOS could join the domain as a member workstation and directly integrate with AD.
... View more