OpenVPN LDAP Extended Query Authentication Fails without Domain Admin Permission
-
Hello, I am hoping someone can help me with a problem I am running into for one of our clients running 2.3.2-p1. I use extended LDAP queries with OpenVPN to restrict VPN access to users in specific groups in Microsoft Active Directory.
This works for all of our clients except for one. We have triple checked to make sure their settings match everyone else’s and have found no discrepancies. For this particular client only users who are domain admins, or who have been domain admins in the past pass the authentication check to access the VPN.
I have confirmed the same behavior in real world testing and using the pfsense diagnostic for testing authentication. I was able to confirm the problem several times by creating test accounts and testing if they could pass the extended query. No matter how long I waited after adding them to the security group they could not use the VPN. I would then make them domain admins and they would continue to fail. However, 30-60 minutes after being made a domain admin they would start passing the authentication test and could access the VPN. Just for reference our typical AD changes replicate much faster than that. For Example removing a user from a security group or an OU seems to change their permissions almost immediately. Once the user had VPN access I would remove their domain admin permissions and they would continue to have access as long as they are in the VPN security group.
As expected accounts that have domain admin but aren’t in the VPN Security group cannot access the VPN. I have seen these same results from all accounts I’ve tested, and from the accounts that already existed in Active Directory. I have noticed that all of the accounts (at least to my knowledge) that are able to access the VPN have the “Admin Count” AD attribute set to 1. This seems to persist on accounts even after they have been removed from the domain admin group, where as users that have never been domain admins are <not set="">by default. I tried manually changing this attribute but it did not seem to have any impact during my testing.
I have not found anything so far that explains why only admin / previous admin accounts can pass the authentication. Any help would be appreciated.</not>
-
I was able to figure this out. The problem was caused by "Authenticated Users" no longer being included in the Pre-Windows 2000 Compatible access built in security group. This group normally provides read rights to all AD Objects.
Previous and existing domain admins were automatically being assigned some of these read permissions. Fixed by giving the pfsense LDAP Active Directory account read access to all users.