Rory wrote:

I had some confusion with this recently too. As I understand it, you can have either DB or LDAP authentication for agents, not both.

Oh lovely. I guess that explains why I cannot login even as the root/localhost user.

The way OTRS authenticates is by checking the user against its own database. Once the user exists in its database it will authenticate the user against the LDAP directory.

So, otrs is only using ldap to check the passwords? Is the access/ownership info (i.e. who belongs to which group and can do what kind of harm) stored in the local DB then? I guess it has to since the documentation states otrs only does read only access to ldap.

In order for the local DB to have the same user details in the otrs DB as in the LDAP directory. To do this you need to configure OTRS to sync its data from the LDAP directory. The data is sync'd the first time the user logs in. Have a look through the following doc for the sync config settings;

http://doc.otrs.org/2.4/en/html/x1890.html

After reading it, I began to wonder if it meant that once it gathers the data it will use the local DB entirely instead of ldap. If that is the case, wouldn't it mean that it should be able to lookup user info on both local db and ldap at the same time?

The "first bind failed" TLS error you are getting means that your LDAP server needs to have a TLS secured connection. Make sure you have the correct Perl package for TLS installed on your system. You may or may not need to do somthing like this;

$Self->{'AuthModule::LDAP::Host'} = 'ldaps://ldap-pserver.internal.domain.com';

I hope that helps,

Rory

Support my 365 Challenge in aid of the Irish Cancer Society

www.365challenge.ie

2009/8/5 Mauricio Tavares :

...

I am trying to have otrs to have some of my agents defined in ldap. So, I set /etc/otrs/Kernel/Config.pm as follows:

# Authenticate agents against LDAP backend $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'ldap-pserver.internal.domain.com'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=domain,dc=com'; $Self->{'AuthModule::LDAP::UID'} = 'uid'; $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=users,ou=Groups,dc=domain,dc=com'; $Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid'; $Self->{'AuthModule::LDAP::UserAttr'} = 'UID'; $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, verify => 'require', cafile => '/etc/ssl/certs/root.pem', # async => 0, version => 3, };

When I try to login, either as a previously defined (in its database, and that includes root) otrs user or as one of the ldap users, it seems to be looking for them in ldap:

ERROR: OTRS-CGI-10 Perl: 5.10.0 OS: linux Time: Wed Aug 5 12:09:54 2009

Message: First bind failed! TLS confidentiality required

Traceback (32329): Module: Kernel::System::Auth::LDAP::Auth (v1.46) Line: 191 Module: Kernel::System::Auth::Auth (v1.29) Line: 121 Module: Kernel::System::Web::InterfaceAgent::Run (v1.34) Line: 192 Module: /usr/share/otrs/bin/cgi-bin/index.pl (v1.87) Line: 47

What should I tell otrs to look for users in its own database there and then for ldap users, well, in ldap? And, what would this "TLS confidentiality required" error be trying to tell me? --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

Rory wrote:

2009/8/5 Mauricio Tavares :

...

So, otrs is only using ldap to check the passwords? Is the access/ownership info (i.e. who belongs to which group and can do what kind of harm) stored in the local DB then? I guess it has to since the documentation states otrs only does read only access to ldap.

Effectively yes, its just checking the passwords. I'm not too sure about groups, I havn't gone so far as to mess with that yet but I have seen some config entries that relate to groups. I think you can pull a users group info from ldap but you cannot make changes to the ldap groups from otrs.

I have no problems if otrs cannot edit ldap. What I would like is to be able to define which group someone belongs to in ldap and then otrs will see the groups memberships and then grant the said user rights according to the memberships.

I don't think otrs is as strict when it comes to using the DB or ldap for groups tho.

Hope so.

...

After reading it, I began to wonder if it meant that once it gathers the data it will use the local DB entirely instead of ldap. If that is the case, wouldn't it mean that it should be able to lookup user info on both local db and ldap at the same time?

This line from the doc makes me believe its still checking the ldap directory to authenticate even tho it has all the details in the DB;

"Allthough the data can be synched into the local OTRS database the LDAP directory is the last instance for the authentification, so a inactive user in the LDAP tree can't authenticate to OTRS even when the account data are allready stored in the OTRS database."

So as I understand it, the sync will pull user details from ldap if a user tries to login who is not in the local db but is in the ldap directory. Once it has sync'd to the local db it will then verify only the users password against the ldap directory and not the entire user data, so less ldap queries.

Well, what I have found so far (I might be wrong) is that the user has to be in the local db; the password can be kept in ldap but you have to create an user in otrs. What I did was after setting ldap up, I tried to login as one of the users from the ldap group (cn=users) I gave otrs as the GroupDN. It cheerfully ignored that user. THen I created an user with the same username inside otrs but did not give a password. I was able to login as the said user.

My ideas on this are all open to questioning tho as I don't know this for fact.

Do you think I do? =) I am still figuring this program out.

Rory --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

Hi Rory and Mauricio, Let me first state that if you have configured the AuthSyncModule the OTRS will sync agent data every time a user logs in to OTRS. If you'd change the user properties in active directory; they would be updated in OTRS as soon as the agent logs in. And of course, if the account is disabled in the AD, the user will not be able to log in to OTRS. the UserSyncInitialGroups can be used to define a standard group for every user from a certain source. For instance, you could define it so that every LDAP user is automatically put in the groups Users and FAQ. If you would like to manage your OTRS groups from your LDAP source, that is also possible. Please look into the Defaults.pm file, under UserSyncGroupsDefinition: modify, unquote and put into your Custom.pm Regards, Michiel # AuthSyncModule::LDAP::UserSyncGroupsDefinition # (If "LDAP" was selected for AuthModule and you want to sync LDAP # groups to otrs groups, define the following.) # $Self->{'AuthSyncModule::LDAP::UserSyncGroupsDefinition'} = { # # ldap group # 'cn=agent,o=otrs' => { # # otrs group # 'admin' => { # # permission # rw => 1, # ro => 1, # }, # 'faq' => { # rw => 0, # ro => 1, # }, # }, # 'cn=agent2,o=otrs' => { # 'users' => { # rw => 1, # ro => 1, # }, # } # }; # AuthSyncModule::LDAP::UserSyncRolesDefinition # (If "LDAP" was selected for AuthModule and you want to sync LDAP # groups to otrs roles, define the following.) # $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = { # # ldap group # 'cn=agent,o=otrs' => { # # otrs role # 'role1' => 1, # 'role2' => 0, # }, # 'cn=agent2,o=otrs' => { # 'role3' => 1, # } # }; -- Michiel Beijen Software Consultant +31 6 - 457 42 418 Bee Free IT + http://beefreeit.nl On Thu, Aug 6, 2009 at 16:08, Rory wrote:

2009/8/6 Mauricio Tavares :

...

       I have no problems if otrs cannot edit ldap. What I would like is to be able to define which group someone belongs to in ldap and then otrs will see the groups memberships and then grant the said user rights according to the memberships.

I'm kinda guessing here but you may be able to find more with a quick google; I think the following piece of config will add any user, who logs in for the first time, to the specified group in OTRS

   # AuthSyncModule::LDAP::UserSyncInitialGroups    # (sync following group with rw permission after initial create of first agent    # login)    $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [        'users',    ];

But that could be syncing groups from ldap to the DB. I know I've seen more about this in the docs or on this list but I havn't found it yet.

...

       Well, what I have found so far (I might be wrong) is that the user has to be in the local db; the password can be kept in ldap but you have to create an user in otrs. What I did was after setting ldap up, I tried to login as one of the users from the ldap group (cn=users) I gave otrs as the GroupDN. It cheerfully ignored that user. THen I created an user with the same username inside otrs but did not give a password. I was able to login as the said user.

That's fits with how I understand this to work. If you don't have the sync config added it doesn't know to pull the user from ldap so it can't find them in the DB and fails. Once you create them in the DB you're golden. The sync has the benefit that you can pull across some extra info into the DB e.g.;

   $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {        # DB -> LDAP        UserFirstname => 'givenName',        UserLastname  => 'sn',        UserEmail     => 'mail',    };

I wonder if that can be used to pull across the group info too?

...

...

My ideas on this are all open to questioning tho as I don't know this for fact.

       Do you think I do? =) I am still figuring this program out.

I was kinda hoping somebody was gonna come along and tell that I was right :)

Rory --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

Nuts, hit send too early. So I've added the following to the config; # Sync LDAP group to role in OTRS # AuthSyncModule::LDAP::UserSyncRolesDefinition $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = { # ldap group 'CN=IT,OU=Groups,OU=IT,OU=Departments' => { # otrs role 'r_IT' => 1, }, }; I prefix all my roles in otrs with r_ to try to keep things clear (group with g_ too) Does the ldap group use the baseDN specified in the Agent LDAP Auth config Do I need to use the attributes specified for group syncs when syncing roles? i.e. # Attributes needed for group syncs # (attribute name for group value key) # $Self->{'AuthSyncModule::LDAP::AccessAttr'} = 'memberUid'; # (attribute for type of group content UID/DN for full ldap name) # $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'UID'; # $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'DN'; Rory Support my 365 Challenge in aid of the Irish Cancer Society www.365challenge.ie 2009/8/7 Rory :

Hi Michiel,

Thanks for the info. I'm trying to use the SyncRolesDefinition and I've added the following to the config;

   # Sync LDAP group to role in OTRS    # AuthSyncModule::LDAP::UserSyncRolesDefinition    $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = {

       # ldap group        'CN=IT,OU=Groups,OU=IT,OU=Departments' => {                # otrs role                'r_IT' => 1,        },

   };

I prefix  all my roles in otrs with r_ to try to keep things clear (group with g_ too)

Support my 365 Challenge in aid of the Irish Cancer Society

www.365challenge.ie

2009/8/7 Michiel Beijen :

...

Hi Rory and Mauricio,

Let me first state that if you have configured the AuthSyncModule the OTRS will sync agent data every time a user logs in to OTRS. If you'd change the user properties in active directory; they would be updated in OTRS as soon as the agent logs in. And of course, if the account is disabled in the AD, the user will not be able to log in to OTRS.

the UserSyncInitialGroups can be used to define a standard group for every user from a certain source. For instance, you could define it so that every LDAP user is automatically put in the groups Users and FAQ.

If you would like to manage your OTRS groups from your LDAP source, that is also possible. Please look into the Defaults.pm file, under UserSyncGroupsDefinition: modify, unquote and put into your Custom.pm

Regards,

Michiel

   # AuthSyncModule::LDAP::UserSyncGroupsDefinition    # (If "LDAP" was selected for AuthModule and you want to sync LDAP    # groups to otrs groups, define the following.) #    $Self->{'AuthSyncModule::LDAP::UserSyncGroupsDefinition'} = { #        # ldap group #        'cn=agent,o=otrs' => { #            # otrs group #            'admin' => { #                # permission #                rw => 1, #                ro => 1, #            }, #            'faq' => { #                rw => 0, #                ro => 1, #            }, #        }, #        'cn=agent2,o=otrs' => { #            'users' => { #                rw => 1, #                ro => 1, #            }, #        } #    };

   # AuthSyncModule::LDAP::UserSyncRolesDefinition    # (If "LDAP" was selected for AuthModule and you want to sync LDAP    # groups to otrs roles, define the following.) #    $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = { #        # ldap group #        'cn=agent,o=otrs' => { #            # otrs role #            'role1' => 1, #            'role2' => 0, #        }, #        'cn=agent2,o=otrs' => { #            'role3' => 1, #        } #    };

-- Michiel Beijen Software Consultant +31 6 - 457 42 418 Bee Free IT + http://beefreeit.nl

On Thu, Aug 6, 2009 at 16:08, Rory wrote:

...

2009/8/6 Mauricio Tavares :

...

       I have no problems if otrs cannot edit ldap. What I would like is to be able to define which group someone belongs to in ldap and then otrs will see the groups memberships and then grant the said user rights according to the memberships.

I'm kinda guessing here but you may be able to find more with a quick google; I think the following piece of config will add any user, who logs in for the first time, to the specified group in OTRS

   # AuthSyncModule::LDAP::UserSyncInitialGroups    # (sync following group with rw permission after initial create of first agent    # login)    $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [        'users',    ];

But that could be syncing groups from ldap to the DB. I know I've seen more about this in the docs or on this list but I havn't found it yet.

...

       Well, what I have found so far (I might be wrong) is that the user has to be in the local db; the password can be kept in ldap but you have to create an user in otrs. What I did was after setting ldap up, I tried to login as one of the users from the ldap group (cn=users) I gave otrs as the GroupDN. It cheerfully ignored that user. THen I created an user with the same username inside otrs but did not give a password. I was able to login as the said user.

That's fits with how I understand this to work. If you don't have the sync config added it doesn't know to pull the user from ldap so it can't find them in the DB and fails. Once you create them in the DB you're golden. The sync has the benefit that you can pull across some extra info into the DB e.g.;

   $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {        # DB -> LDAP        UserFirstname => 'givenName',        UserLastname  => 'sn',        UserEmail     => 'mail',    };

I wonder if that can be used to pull across the group info too?

...

...

My ideas on this are all open to questioning tho as I don't know this for fact.

       Do you think I do? =) I am still figuring this program out.

I was kinda hoping somebody was gonna come along and tell that I was right :)

Rory --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/