Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 1 subscriber
  • Views 6370 views
  • Users 0 members are here
Options
Suggested
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

ASG 7.505 Remote Access based on AD Membership

paule
Hi,

because of my search in the knowledge base lead not to a solution so far I'm posting here in the hope for help.

I try to configure Remote Access for Users based on Active Directory Group Membership.
That means I want to give all members of the AD group remote-users the right to grab the VPN Client from the user portal and to connect afterwards to the ressources of the internal network.

The authentication server tests work all fine. The group membership of the user is detected correctly.

I created a group with backend membership, backend "active directory", checked "limit to backend groups membership" and selected a group. Neither the selection from the AD browser nor simply typing a group name worked afterwards.

A legal member of the group, which was proofen by the server test, could not even log into the user portal so far.

Portal use for local users works fine.

When such a AD backend login is tried aua logs like:
2010:06:16-12:29:41 mail aua[7130]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.XX.129 (adirectory)"
2010:06:16-12:29:42 mail aua[7130]: id="3006" severity="info" sys="System" sub="auth" name="could not set object for testuser: OBJECT_NAMESPACE"
2010:06:16-12:29:42 mail aua[7130]: id="3006" severity="info" sys="System" sub="auth" name="failed to set object"
2010:06:16-12:29:43 mail aua[7130]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="*********" user="testuser" caller="portal" reason="DENIED" 

( I tried to anonymize these log records, so the IP adresses look scrambled)

So can somebody give any advice in this, please?
Is it possible, what I want to configure?
What goes wrong?

Best regards

Gerold


This thread was automatically locked due to age.
Parents
  • 0
    final status: resolved

    by getting in touch with the astaro folks it turned out that:
    - using backend authentication will create local users for every
      successfully backend-authenticated user
    - these backend authenticated users merge among locally created ones 
      (we created them originally to be able to track who modified the configs,
       long before thinking about authentication against backend)
    - all local users must have a unique email address
      and this condition is of course violated if one person exists as "true" local user and
      with the same mail address as backend authenticated user
    - so the solution was: delete the "real" local account, let the person login to user
      portal, this will create the needed account for the person. And this account can
      now be added to additional groups and permission sets.

    Hth anybody else
Reply
  • 0
    final status: resolved

    by getting in touch with the astaro folks it turned out that:
    - using backend authentication will create local users for every
      successfully backend-authenticated user
    - these backend authenticated users merge among locally created ones 
      (we created them originally to be able to track who modified the configs,
       long before thinking about authentication against backend)
    - all local users must have a unique email address
      and this condition is of course violated if one person exists as "true" local user and
      with the same mail address as backend authenticated user
    - so the solution was: delete the "real" local account, let the person login to user
      portal, this will create the needed account for the person. And this account can
      now be added to additional groups and permission sets.

    Hth anybody else
Children
No Data