We switched from using the token to MFA last year and users who need VPN access needs to be assigned with a specific group on the GlobalAD level. This group has about 3200+ users and users have been reporting they are getting error 1329 intermittenly, which is not a good user experience.
Following is our configuration:
Base DN: DC=GlobalAD,DC=local
Member Attribute: member
Query Atibute: <blank>
Nested Group Level: 0 (since we dont use it)
Nested Group Search: Nested groups in SERVER CATALOG
Our service provider helped us to run the packet capture on users who had this issue (which is not easy as it does not happen all the time and not to a specific user), they pointed out it is failing on the group membership lookup.
One change we just made is to increase the Search time out from 60 to 180, which I believe has helped another member on this board to resolve his/her issue. However, here are my questions:
- Currently we put everyone who need the VPN access to ONE group and it is at the Global AD level (we tried at the domain level and it didn't work). Since we have users across regions and we have 4 domains one per region, would it be better to create 4 VPN groups so the number of users in each group would not be a lot? Will it help to make the search faster?
- We did not check the option "Reverse group search" so the search starts from the group instead of the member, would it make any imiprovement if we start the search on the user level?
Any suggestion is greatly appreciated.
Thank you very much for your response!
We recently changed our Search Timeout to 180 and it seemed to help addressing this issue 1329. However, we would still like to look into using the 'reverse group search' to see if it will help on the performance. May I know how it actually works, does it look for the user first and then search if this VPN group is assigned to him/her, or does it have to look through ALL groups that is assigned to this user?
I will work with my team on the TCP dump.