Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 9569 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

Automatic User Creation - not working

lelandv
ASG Firmware Version: 7.305

We have successfully setup LDAP binding and the test server and test authentication works fine.

We have turned on the option to "Create Users Automatically", and set the options for it to create user objects for End-User Portal and SSL VPN, but for LDAP this does not appear to be working at all.  It DOES work for Tacacs+, however.
(looking at the logs, it doesn't appear to be even querying the LDAP when the "unknown" user tries to login to user portal).

Oddly enough when we first installed the system, it worked for ONE and ONLY ONE test user, but hasn't worked for any other user since.

Is there a known bug here, or are we missing something?

In the back-end authentication preference order, we have LDAP first and Tacacs+ farther down the list.  (Not all users are in Tacacs...)

If we create the user manually, and set it to synchronise with a backend authentication method, the user can login to the portal, but since this authentication is fixed to remote, they cannot change their ASG password, and cannot use PPTP or L2TP/IPsec VPNs as they require local authentication for PPPD.

Ideally, we want the user creation to intially be from "unknown" user authenticated by LDAP which then creates the local user objects.  The next time the user logs into the portal, he then has the ability to change his LOCAL password. (This was the case with the first test user, and worked fine.. but no further users can be added this way).

Any assistance would be appreciated.

Thanks,

L.


This thread was automatically locked due to age.
Parents
  • 0
    Lelandy, if you are using a Windows server for your LDAP, then this should work without a problem.  I've see some comments here indicating that there's not good communication with some other LDAP servers.
  • 0 in reply to BAlfson
    Unfortunately most of the people in our environment are adamantly anti-microsoft (though I personally use a mix of Linux, Windows, and Solaris in my own personal network).  As a result, we're using a collaboration platform built upon open source standards.

    I don't require two-way synchronisation on LDAP though -- only from the main collaboration platform to the ASG.  It's weird that the first test user was automatically created, but no further ones were.

    I saw in another thread that it's possible to create the user and set them to "remotely authenticated" which, while it does allow them to login, it does not allow them to use L2TP/IPSec or PPTP since the PPPD/XL2TPD requires local authentication.  Ideally, therefore, I really need the automatic unknown user creation to work properly. [:(]

    Leland
  • 0 in reply to lelandv
    My guess is that you have a problem with the definition of the authentication.  I suspect that your 'Base DN' is too specific.  Try removing the leading 'OU=orgunit,' entry, and make sure there's no "." at the end.

    The problem also could be a misspelled 'Attribute' or specified 'Value' in the Group definition.

    Cheers - Bob
    Tu peux me contacter par email en cliquant sur mon nom.
  • 0 in reply to BAlfson
    I don't think that's the issue.  The function to "test" the LDAP functionality works fine, so I know we're using the right attributes and base DN (same as we're using for the rest of our itegrated systems...)

    It's just simply that the function to create the user tokens from LDAP into Astaro if the user is "unknown" to Astaro isn't working... 

    L.
  • 0 in reply to lelandv
    In the definition of the 'Backend Group' authenticated by LDAP, are you checking an Attribute?

    If you are not using Microsoft LDAP, you might need to wait until the release of V7.4 to get the functionality you want.  If you are using Microsoft, it should work well.

    Cheers - Bob
  • 0 in reply to BAlfson
    Nope.. not using Microsoft LDAP... 

    It's actually a scaled down "version" of OpenLDAP (OmLDAP) used by Scalix.

    Oddly enough, the automatic creation into Astaro worked for the very first "test" user and hasn't worked for any users since.

    However, once they've been created, I can then set the authentication method back from Local to LDAP and that works fine.  It's just the creation in the first place which is flakey.

    L.
  • 0 in reply to lelandv
    The support for OpenLDAP (and Domino) is supposed to be "fixed" in V7.4.  At present, an auto-created user won't have the email name field, and if you enter it manually, the next check by the Astaro will erase the field in the Astaro.  So, if you have a work-around for existing users, within a month, you'll be able to count on LDAP.

    Cheers - Bob
  • 0 in reply to BAlfson
    The support for OpenLDAP (and Domino) is supposed to be "fixed" in V7.4.  At present, an auto-created user won't have the email name field, and if you enter it manually, the next check by the Astaro will erase the field in the Astaro.  So, if you have a work-around for existing users, within a month, you'll be able to count on LDAP.

    Cheers - Bob


    Cool.. looking forward to it !

    rgds, 

    Leland
  • 0 in reply to BAlfson
    The support for OpenLDAP (and Domino) is supposed to be "fixed" in V7.4.  At present, an auto-created user won't have the email name field, and if you enter it manually, the next check by the Astaro will erase the field in the Astaro.  So, if you have a work-around for existing users, within a month, you'll be able to count on LDAP.

    Cheers - Bob



    Hi Bob,

    Can you tell me the correct settings for using Domino LDAP Settings ?
    Here, as you know, I'm useing the 7.390 Beta Relase

    Regards John
  • 0 in reply to willemsej
    I haven't been able to participate in the beta, so I haven't seen that yet.  You might try searching here on ldap domino to see whom you might message to get a suggestion.

    I have a document that explains the steps with a Windows server.  Here's the section about setting up LDAP:

    Select the ‘LDAP’ tab and click on ‘Enable’.  

    For ‘Server’, click on the file folder and drag ‘Our Server’ into the box.  It is likely that you will want to leave the ‘SSL’ box unchecked and the ‘Port’ unchanged at 389.

    Leave the ‘User Attribute’ set on ‘CN’ (Common Name).

    The ‘Bind User DN’ is the string we captured in the first step above (in our example):

    CN=bob2,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Ourdomain,DC=local



    The ‘Base DN’ is (in our example):

    OU=MyBusiness,DC=Ourdomain,DC=local



    Hit ‘Apply’.  You should get a message that the LDAP settings were saved successfully.

    Cheers - Bob
  • 0 in reply to BAlfson
    In General:

    •  Users authenticating against a backend do not store their password on the ASG. Therefore, it is not possible to change the password for those users (unless you change the authentication method to local)

    •  Changes on the ASG are not synced back to the directory. The idea is that the ASG asks the directory for authentication, but does not otherwise fiddle with it.


    Authentication:
    The authentication process works as follows:

    •  There must be a user in the directory (e.g. cn=foo,cn=users,dc=mydomain)
    •  The ASG must be configured to authenticate against the LDAP backend. 'CN' must be set as attribute to match the username.
      A group must be created for an LDAP backend. This group needs to be entered into the 'allowed users' field of the requested service.
      Note that even if you check 'enable all users' in the user portal, you still need an LDAP group.
    • Automatic user creation must be enabled in general, and for the facility in question (i.e. portal, ssl, ...)
    •  When a user tries to authenticate with username 'foo' the ASG tries to bind to the directory with this username (i.e. cn=foo) and the configured base DN (cn=users,dc=mydomain) ( -- see bottom -- )
    •  If this bind succeeds AND the user falls into the LDAP group AND automatic user creation is enabled for this service, a user object will be created.


    Here is how you would setup authentication against an LDAP backend with automatic user creation for ssl and portal:

    [list=1]
    • goto Users->Authentication->LDAP

      •  enter your server, ssl, port
      •  test if this server is available
      •  check which attribute you want to check (on OpenLDAP, CN should be fine
      • Enter bind DN and bind password
      • Enter Base DN
      • Test you setup with an example user to see, if the entered values are correct.


    •  goto Users->Groups

      • create a new group
      • set group type to 'backend membership'
      • select 'LDAP' as backend
      • optionally you may check an LDAP attribute. I recommend either leaving this out, or at least try without, until it works, and add this later.
      • save the group


      • goto Management->User Portal

        •  enable it, if not already enabled
        •  set the allowed networks (again I recommend to specify 'any' at first, and be more specific later, if things work, and if needed)
        •  check either 'Allow all users' or 'Allow only specific users' and drag the newly created LDAP group into the 'Allowed users' field.
        •  do not forget to 'Apply' [:)]


      •  goto Remote Access -> SSL

        •  enable it, if not already enabled
        •  add the LDAP group to the 'Users and Groups' box
        •  add your local networks
        •  'Apply'

        [/list]

        EDIT:
        I just found that the description of the ldapsearch was a bit sloppy and could be misunderstood. To clear this up:

        The ASG searches the tree below and including the base_dn for a user with cn=foo and tries to bind to this user with the provided password.
      • 0 in reply to rleibl
        In General:

        •  Users authenticating against a backend do not store their password on the ASG. Therefore, it is not possible to change the password for those users (unless you change the authentication method to local)

        •  Changes on the ASG are not synced back to the directory. The idea is that the ASG asks the directory for authentication, but does not otherwise fiddle with it.


        Authentication:
        The authentication process works as follows:

        •  There must be a user in the directory (e.g. cn=foo,cn=users,dc=mydomain)
        •  The ASG must be configured to authenticate against the LDAP backend. 'CN' must be set as attribute to match the username.
          A group must be created for an LDAP backend. This group needs to be entered into the 'allowed users' field of the requested service.
          Note that even if you check 'enable all users' in the user portal, you still need an LDAP group.
        • Automatic user creation must be enabled in general, and for the facility in question (i.e. portal, ssl, ...)
        •  When a user tries to authenticate with username 'foo' the ASG tries to bind to the directory with this username (i.e. cn=foo) and the configured base DN (cn=users,dc=mydomain)
        •  If this bind succeeds AND the user falls into the LDAP group AND automatic user creation is enabled for this service, a user object will be created.


        Here is how you would setup authentication against an LDAP backend with automatic user creation for ssl and portal:

        [list=1]
        • goto Users->Authentication->LDAP

          •  enter your server, ssl, port
          •  test if this server is available
          •  check which attribute you want to check (on OpenLDAP, CN should be fine
          • Enter bind DN and bind password
          • Enter Base DN
          • Test you setup with an example user to see, if the entered values are correct.


        •  goto Users->Groups

        • create a new group
        • set group type to 'backend membership'
        • select 'LDAP' as backend
        • optionally you may check an LDAP attribute. I recommend either leaving this out, or at least try without, until it works, and add this later.
        • save the group


        • goto Management->User Portal

          •  enable it, if not already enabled
          •  set the allowed networks (again I recommend to specify 'any' at first, and be more specific later, if things work, and if needed)
          •  check either 'Allow all users' or 'Allow only specific users' and drag the newly created LDAP group into the 'Allowed users' field.
          •  do not forget to 'Apply' [:)]


        •  goto Remote Access -> SSL

        •  enable it, if not already enabled
        •  add the LDAP group to the 'Users and Groups' box
        •  add your local networks
        •  'Apply'

        [/list]



        Thanks I will test this !! Thanks !
      Reply
      • 0 in reply to rleibl
        In General:

        •  Users authenticating against a backend do not store their password on the ASG. Therefore, it is not possible to change the password for those users (unless you change the authentication method to local)

        •  Changes on the ASG are not synced back to the directory. The idea is that the ASG asks the directory for authentication, but does not otherwise fiddle with it.


        Authentication:
        The authentication process works as follows:

        •  There must be a user in the directory (e.g. cn=foo,cn=users,dc=mydomain)
        •  The ASG must be configured to authenticate against the LDAP backend. 'CN' must be set as attribute to match the username.
          A group must be created for an LDAP backend. This group needs to be entered into the 'allowed users' field of the requested service.
          Note that even if you check 'enable all users' in the user portal, you still need an LDAP group.
        • Automatic user creation must be enabled in general, and for the facility in question (i.e. portal, ssl, ...)
        •  When a user tries to authenticate with username 'foo' the ASG tries to bind to the directory with this username (i.e. cn=foo) and the configured base DN (cn=users,dc=mydomain)
        •  If this bind succeeds AND the user falls into the LDAP group AND automatic user creation is enabled for this service, a user object will be created.


        Here is how you would setup authentication against an LDAP backend with automatic user creation for ssl and portal:

        [list=1]
        • goto Users->Authentication->LDAP

          •  enter your server, ssl, port
          •  test if this server is available
          •  check which attribute you want to check (on OpenLDAP, CN should be fine
          • Enter bind DN and bind password
          • Enter Base DN
          • Test you setup with an example user to see, if the entered values are correct.


        •  goto Users->Groups

        • create a new group
        • set group type to 'backend membership'
        • select 'LDAP' as backend
        • optionally you may check an LDAP attribute. I recommend either leaving this out, or at least try without, until it works, and add this later.
        • save the group


        • goto Management->User Portal

          •  enable it, if not already enabled
          •  set the allowed networks (again I recommend to specify 'any' at first, and be more specific later, if things work, and if needed)
          •  check either 'Allow all users' or 'Allow only specific users' and drag the newly created LDAP group into the 'Allowed users' field.
          •  do not forget to 'Apply' [:)]


        •  goto Remote Access -> SSL

        •  enable it, if not already enabled
        •  add the LDAP group to the 'Users and Groups' box
        •  add your local networks
        •  'Apply'

        [/list]



        Thanks I will test this !! Thanks !
      Children
      No Data