Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 11 replies
  • Subscribers 0 subscribers
  • Views 2574 views
  • Users 0 members are here
Options
Suggested

[v7.360] Problems authenticating with OpenLDAP Server

b2bweb
Hi All,

I've got an OpenLDAP server running on SUSE Enterprise Linux 10 server which I'd like to authenticate against.

I've got into Users -> Authentication -> LDAP, and filled in all the correct details for my server, and using the Test button, I get the response "Authentication test passed. No groups found for this user". (Do there need to be any groups associated with the user to ASG's purposes?)

I've got automatic user creation turned on for everything under the global settings for Authentication.  Yet when I try to use the same login details that I did with the testing button above to login to the user portal, I'm refused with the generic message "Invalid username/password, or access denied by a policy".

Looking at the Authentication Daemon logs, there's not enough info to give me any clues:

[SIZE="1"][FONT="Courier New"]2008:12:08-21:48:40 (none) aua[15080]: id="3006" severity="info" sys="System" sub="auth" name="checking if benh is enabled"
2008:12:08-21:48:40 (none) aua[15080]: id="3006" severity="info" sys="System" sub="auth" name="user is enabled. Calling do_auth()"
2008:12:08-21:48:40 (none) aua[15080]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="10.0.10.20" user="benh" caller="portal" reason="DENIED"
[/FONT][/SIZE]

I turned on heavy logging on the LDAP server side as well and this is what I found:

2 attachments - one is the LDAP server logs when the "Test Login" button is used successfully on the LDAP Settings screen, the other are the server logs generated when a portal login is attempted with the same user account - both BIND successfully!  I'm at a loss why portal is coming back with a login result of "DENIED".

There's no local user with clashing email or login details.

Does anything jump out to you guys as to why the same results from the LDAP server (successful search and BIND) would give a positive test result, but fail to create an automatic user for the User Portal web pages? Or is there extra places I can be looking for clues as to why LDAP authentication is failing? (tried with multiple LDAP users)....

Cheers,

Ben
Parents
  • 0 in reply to poero
    >>> "Authentication test passed. No groups found for this user".

    This warning is thrown as a reminder for users who either want to use automatic user creation or want to allow a specific group for a facility, e.g. User Portal.

    For both cases it's necessary to create a group with a backend membership, which in this case would be the LDAP backend.

    For the  groups members automatic user creation must be enabled  in 
    Authentication->Global Settings.

    If follow this steps Authentication should be possible. 
    I checked this against a 7.360.

    Should anyhow issues with authentication occur you may enable debugging
    by sending a signal via console to the authentication process. The debug logs also
    are written to aua.log.
    $ killall -SIGUSR2 aua.bin
Reply
  • 0 in reply to poero
    >>> "Authentication test passed. No groups found for this user".

    This warning is thrown as a reminder for users who either want to use automatic user creation or want to allow a specific group for a facility, e.g. User Portal.

    For both cases it's necessary to create a group with a backend membership, which in this case would be the LDAP backend.

    For the  groups members automatic user creation must be enabled  in 
    Authentication->Global Settings.

    If follow this steps Authentication should be possible. 
    I checked this against a 7.360.

    Should anyhow issues with authentication occur you may enable debugging
    by sending a signal via console to the authentication process. The debug logs also
    are written to aua.log.
    $ killall -SIGUSR2 aua.bin
Children
  • 0 in reply to ee-tra
    I actually have the OpenLDAP user groups created to match the groups created locally in ASG and the test users above are members of multiple groups (which the test user reports as false)..... So I guess the question is, what branch of the LDAP directory, or what property of the LDAP user is ASG looking at to ascertain whether there are group membership...

    On another topic, I didn't see anywhere that I had to add a user to a particular group before they could access the user portal... I thought the user portal was accessible to all validly authenticated users, but the options and content available to them within the portal was controlled by the access they'd been granted to various facilities... (ie: remote access, email quarantine, etc etc)...

    Would welcome your wisdom if I'm barking up the wrong tree, because I'd love to see this working...

    I'll try the debugging option and see if it gives any clues....

    Does anyone else have any experience with LDAP (either OpenLDAP, which I'm using, or a proprietary LDAP directory system...?)...

    Cheers,

    Ben
  • 0 in reply to b2bweb
    PS:

    Users -> Authentication -> Global Settings:

     
    [Y]   Automatic user creation 


    Create users automatically:

    When this option is activated, the system will automatically create user objects whenever an unknown user successfully authenticates to a backend mechanism.
     
     
        Apply  

    Automatic user creation for facilities 



    [Y]   HTTP Proxy

    [Y]   End-User Portal

    [Y]   SMTP Proxy

    [Y]   SSL VPN

    [Y]   WebAdmin

    -------------

    So I'd suggest that the "auto user creation" setting isnt the problem.... I think it might be a legitimate bug though if the LDAP server logs show a success authentication and bind, which works in the [Test User] button but fails elsewhere (where the LDAP server still shows success)... Something is getting jumbled along the way.....

    Cheers,

    Ben
  • 0 in reply to b2bweb
    >>> I think it might be a legitimate bug though if the LDAP server logs show a success authentication and bind

    Please add the aua.log with debugging enabled, thanks.

    >> On another topic, I didn't see anywhere that I had to add a user to a particular 
    >> group before they could access the user portal... I thought the user portal was 
    >> accessible to all validly authenticated users, but the options and content available 
    >> to them within the portal was controlled by the access they'd been granted to 
    >> various facilities... (ie: remote access, email quarantine, etc etc)...

    The group is mandatory for the first login to create the user object -> automatic user creation. Once the object is available, the user is able login in the User Portal when all users are allowed without the need for a group.
  • 0 in reply to ee-tra
    Hi there, using the SUSE LDAP Adminstration system (a gui for OpenLDAP), LDAP groups identically named to local groups established on the ASG machine have been linked to the test user below (I believe they would reside under ou=Groups,dc=mel,dc=domain_censored,dc=com,dc=au).  

    Obviously the log file has had a search and replace performed routinely on the actual passwords and full LDAP contexts (the tail end only of the LDAP contexts) to preserve security. 

    The procedure that has generated this log file is:

    1)  Login to WebAdmin using local Admin account.  
    2)  Enter the LDAP section under Users -> Authorisation and enter the "testuser" credentials result:  User authenticated, No groups found.
    3)  Attempt to login from the user portal using the "testuser" credentials - authentication failed.

    It would seem that ASG is either not seeking the groups associated with the LDAP user, or not looking for them in the location typical for an OpenLDAP installation (to my understanding, the SUSE implementation has adhered to the conventions of the OpenLDAP standard for object placement (ie: ou=People........, ou=Groups.......)....

    I can't find anywhere in the ASG WebAdmin a place where a specific group needs to be associated users before they can gain access to the User Portal -  which confuses me.  

    I have enabled the generic access to User Portal for users authenticated by backend systems, so even if ASG isn't looking for or finding the groups associated with the LDAP user, I can't understand why the user is not allowed into the Portal (even if the only option available to them in the Portal is to change their password or logout)...

    Hope this is of some help to you - it still baffles me! :-)

    Cheers,

    Ben
    au_log.zip
  • 0 in reply to b2bweb
    OK, to help the developers, I've created a completely new LDAP Sever implementation on an OpenSuse 11.0 system and attached a dump of the LDAP database to understand where objects are being kept.

    By default, it places all users under an ou=people under the base, and all groups under ou=group under the base.  One of the properties of each group entry is a "member" field that contains the full DN of each user that has membership of this group...

    The groups I've setup match three local groups in ASG - one is the SuperAdmins (which you'll note testuser is a member of, so technically should be able to login to WebAdmin), and two other groups that I've defined to grant VPN and HTTP proxy access (RemoteAccess and WebAccess respectively)..

    Hope this helps understand what aua.bin isn't finding.

    I understand that other than adding a few platform specific additional fields to the normal schema, that the OpenLDAP server implementations I've got here don't stray too far from the norm.

    Does anyone else have OpenLDAP running on another platform that can compare/confirm this? (I used "slapcat -v" to obtain this dump from the attached database).

    Cheers,

    Ben
  • 0 in reply to b2bweb
    PS: Confirmed the problem is exactly the same in 7.380 firmware...

    PPS:  I believe the other common alternative entry to "member" is "uniquemember" used in some implementations- ASG should probably be checking for both to establish user group membership.

    Cheers,

    Ben
  • 0 in reply to b2bweb
    I hadn't seen any comments from developers on this in sometime.  Is this a problem that we can hope to see in BETA4 ?

    I've noticed identical problems after building up a FreeRadius evironment to test RADIUS authentication - no problems clicking the [Test] button on the settings page, but no jo in real life. (Of course I'll be posting a full thread with all the logs etc in the next 24 hours.  Does this have to do with "Automatically generating local users"?  In LDAP's case, Astaro didn't appear to be looking in the right place for group memberships. In RADIUS, there are no group memberships - the user is authentcated on a combination of NAS-Identifier and User-Name, yet when testing a user on the RADIUS settings screen, it authenticates fine but reports no group memberships.  It then fails to use the Authenticate-Accept response to allow access.

    I'll get the detailed RADiUS test info into the forums urgently for the developers, but just wanted to check if work was being done to look at the authentication logic of these external authentication sources as I hadn't seen any comments from the Astaro guys since posting all the debug stuff on LDAP a few weeks back.

    Can't wait to see what BETA4 brings!

    Cheers,

    Ben
  • 0 in reply to b2bweb
    The authentication mechanism on the ASG is twofold:

    1. Authentication (against the backend)
    2. Authorization (against the ASG)

    ad 1. The ASG authenticates the user against the backend. I.e. it is checked, if the backend knows the user, and if the password is correct.

    ad 2. The ASG checks the authorization of the user for the requested facility (i.e. service). In order to do this, the user must be known to the ASG either by a user object, or by membership to a group.

    In your case (LDAP or Radius), you would need to create a group with backend match of LDAP or Radius. A user successfully authenticating against the backend will fall into the corresponding group. The ASG then checks, if the service the user requested is available to this group. 
    This is neccessary, even if you have 'allow all users' enabled in the Portal.

    Also note that there is a difference between groups on the LDAP server and groups on the ASG.