This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote Access Tab in Portal - Not Configured for User

I'm using Astaro ASG V7.202

Here is my setup:
1. We have a Windows 2003 R2 Server running Active Directory on the LAN interface of our Astaro ASG V7.202 box.

2. I have a group set up in AD called "IPSec VPN Users" with user accounts I want to allow IPSec Remote Access to.

3. I have a group set up on the ASG box (under Users->Groups) called"IPSec Remote Access Users" with a backend membership of Active Directory; I also have "Limit to backend group/s membership" enabled with a group object called "IPSec VPN Users" in the "Active Directory Groups" list.

4. Under Remote Access->IPSec I have a rule created with the Allowed Users set to include "IPSec Remote Access Users" (which has a backend membership set to the IPSec VPN Users group in AD as explained in point 3 above).

5. AD user accounts can successfully authenticate and log into the ASG user portal.

My problem: When I log into the user portal with an AD user account belonging to the AD group "IPSec VPN Users" I cannot see the download links for the Astaro Secure Client software or the configuration files. I just get a message saying "Unfortunately this remote access method is not configured for you. Please contact your system administrator for more information on that."

Can anybody help me to figure out how I should get the user portal to recognize that the user logging in is a member of the "IPSec VPN Users" group on the AD server and therefore should have IPSec VPN Remote Access enabled for them?

Thank you for any comments. [H]


This thread was automatically locked due to age.
  • Hi

    For technical reasons it is not possible to use backend groups with IPSec.

    In newer versions (7.300) it will not be possible to drag backend groups into the allowed users field.
    This will prevent the situation you are in. Your setup is, in general, correct, except that it does not work. 

    Documentation will be updated in 7.300.

    FYI:
    Backend groups can be used with "CA DN Match" and "preshared key" connections.
  • Hi

    For technical reasons it is not possible to use backend groups with IPSec.

    In newer versions (7.300) it will not be possible to drag backend groups into the allowed users field.
    This will prevent the situation you are in. Your setup is, in general, correct, except that it does not work. 

    Documentation will be updated in 7.300.

    FYI:
    Backend groups can be used with "CA DN Match" and "preshared key" connections.


    Hi Robert_L,
    Thanks for posting. I am truly curious to know what technical reasons you feel exist for IPSec to not use AD backend authentication.

    I received feedback from Astaro support saying that this feature will be resolved in 7.3 but as it is not officially released yet I'll have to wait for the official release if I wanted to have formal support under our support agreement for the product.

    I have the Beta running at my home at the moment and will be doing some further testing in the coming few days to see if I can confirm that the AD auth works with IPSec on the Beta version. I'll provide some feedback on this here when I have been able to confirm whether V7.3 really does allow the AD backend authentication or not.

  • Thanks for posting. I am truly curious to know what technical reasons you feel exist for IPSec to not use AD backend authentication.


    First I want to make clear that we are talking about x509 (Certificate) authentication only.

    With backend authentication, we do not know the user until she logs in. In the case of IPSec when a user logs in we would have to write an Astaro-side configuration for that user and restart/reload pluto. We experience extremely high load and interruptions of the IPSec service, if several users log in at the same time.

    We are doing research on the subject, so this might change in the future.
  • Thank you for posting more information Robert_L.
    [:)]