Hi Rory,
One thing that you need to take into account is caching. By default,
OTRS caches all queries to the Customer database for a couple of
minutes. This means, that if you search for "John Doe", change a bit
in your customer data source configuration, then do the same search
for "John Doe" again, it generally does not show you new results; it
shows you the old results. If you want to make sure you get new
results, you should empty the cache (by running otrs.DeleteCache.pl)
or run a search for which you are sure you did not use it before :D
--
Mike
On Fri, May 13, 2011 at 6:12 PM, Rory <rcler...@gmail.com> wrote:
> Well this is annoying ... I've added each extra line one by one from the old
> config to new one and after I inserted a new line I tested it to see if it
> broke the ldap lookup.
>
> My config is now back to its original state as I listed in my first mail ...
> every line is in the same place, every variable is the same, I've even added
> the extra elements into the user map. It works.
> I thought may it was because I was using a user who was now populated in the
> database so I used a whole new user and it still worked.
>
> The only thing I can think of is that there must be some kind of variable
> cache somewhere, in OTRS or the PERL module maybe, and this cache must be
> cleared or updated which I did by using the stripped down config which Shawn
> sent i.e. the variables I now was not using were reset to zero or blanked.
> I've checked th ZZZAuto.pm file and it hasn't changed.
> That's only speculation but it's all I can think of which makes sense.
>
> Oh, and I can confirm that you don't need to restart the webserver for the
> changes to Config.pm to take effect. You just need to call the Customer.pl
> or index.pl file again which will then complie the Config.pm on the fly.
>
> I hope this helps sombody in the future because it has me baffled.
>
> Kind regards,
> Rory Clerkin
>
> On 13 May 2011 16:40, Rory <rcler...@gmail.com> wrote:
>>
>> Thanks Shawn!
>>
>> I've implemented your config and it works.
>> I'm going to go through the different items that I have extra in my own
>> config to see what breaks it.
>> I do want to have features such as the user is required to be in a group.
>> This is great though, I'm delighted to have some progress on this.
>>
>> I'll update this thread with the items I find that break the LDAP login,
>> it may be useful to somebody else in the future.
>>
>> Thanks again,
>> Rory Clerkin
>>
>> On 13 May 2011 15:56, Gadow, Shawn <sga...@ocusd.net> wrote:
>>>
>>> Just out of curiosity use mine and see what happens (obviously change
>>> what you need to change) but you seem to have some extra un-needed stuff in
>>> there.. worth a try anyway
>>>
>>>
>>>
>>> $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
>>>
>>> $Self->{'AuthModule::LDAP::Host'} =
>>> 'ODDC-01.ocusd.local';
>>>
>>> $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=ocusd,dc=local';
>>>
>>> $Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
>>>
>>>
>>>
>>> $Self->{'AuthModule::LDAP::SearchUserDN'} =
>>> 'cn=testuser,cn=Users,dc=ocusd,dc=local';
>>>
>>> $Self->{'AuthModule::LDAP::SearchUserPw'} = 'test123';
>>>
>>>
>>>
>>> $Self->{'Customer::AuthModule'} =
>>> 'Kernel::System::CustomerAuth::LDAP';
>>>
>>> $Self->{'Customer::AuthModule::LDAP::Host'} =
>>> 'ODDC-01.ocusd.local';
>>>
>>> $Self->{'Customer::AuthModule::LDAP::BaseDN'} =
>>> 'dc=ocusd,dc=local';
>>>
>>> $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
>>>
>>>
>>>
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'cn=
>>> testuser,cn=Users,dc=ocusd,dc=local';
>>>
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'test123';
>>>
>>>
>>>
>>> $Self->{CustomerUser} = {
>>>
>>> Module => 'Kernel::System::CustomerUser::LDAP',
>>>
>>> Params => {
>>>
>>> Host => 'ODDC-N1.ocusd.local',
>>>
>>> BaseDN => 'dc=ocusd,dc=local',
>>>
>>> SSCOPE => 'sub',
>>>
>>> UserDN => 'cn= testuser,cn=Users,dc=ocusd,dc=local',
>>>
>>> UserPw => 'test123',
>>>
>>> },
>>>
>>> CustomerKey => 'sAMAccountName',
>>>
>>> CustomerID => 'sAMAccountName',
>>>
>>> CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
>>>
>>> CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
>>>
>>> CustomerUserPostMasterSearchFields => ['mail'],
>>>
>>> CustomerUserNameFields => ['givenname', 'sn'],
>>>
>>> Map => [
>>>
>>> # note: Login, Email and CustomerID needed!
>>>
>>> # var, frontend, storage, shown, required, storage-type
>>>
>>> # [ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
>>>
>>> [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
>>>
>>> [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
>>>
>>> [ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
>>>
>>> [ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
>>>
>>> [ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
>>>
>>> [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
>>>
>>> # [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
>>>
>>> [ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
>>>
>>> ],
>>>
>>> };
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Shawn Gadow
>>>
>>> Network Administrator
>>>
>>> Oregon CUSD 220
>>>
>>>
>>>
>>> “Security is when everything is settled. When nothing can happen to you.
>>> Security is the denial of life.” – Germaine Greer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
>>> Rory
>>> Sent: Friday, May 13, 2011 9:49 AM
>>>
>>> To: User questions and discussions about OTRS.
>>> Subject: Re: [otrs] Customer LDAP Auth Issue - not anonymous
>>>
>>>
>>>
>>> Hi Shawn,
>>>
>>> Yes, I restarted the httpd service (I'm using CentOs 5.5 btw with OTRS
>>> built from the tar.gz download, latest stable apache webserver, latest
>>> stable mysql database, perl installed via Yum, some per module installed via
>>> Yum and some through CPAN, Windows Server 2008 R2 Active Directory as the
>>> LDAP server)
>>>
>>> Commenting out the settings in the ZZZA* files made no difference. I've
>>> also reinstated the customer Authentication into the Config.pm file.
>>>
>>> I'm still getting OTRS trying to bind to LDAP using the user <ROOT>
>>> (Which I'm assuming is an anonymous user).
>>>
>>> Kind regards,
>>> Rory Clerkin
>>>
>>> On 13 May 2011 15:33, Gadow, Shawn <sga...@ocusd.net> wrote:
>>>
>>> Did you restart the services after you made the config change? I wouldn’t
>>> think you would have to but it’s worth a shot if you didn’t
>>>
>>>
>>>
>>>
>>>
>>> Shawn Gadow
>>>
>>> Network Administrator
>>>
>>> Oregon CUSD 220
>>>
>>>
>>>
>>> “Security is when everything is settled. When nothing can happen to you.
>>> Security is the denial of life.” – Germaine Greer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
>>> Rory
>>> Sent: Friday, May 13, 2011 9:32 AM
>>> To: User questions and discussions about OTRS.
>>> Subject: Re: [otrs] Customer LDAP Auth Issue - not anonymous
>>>
>>>
>>>
>>> I'm seeing some strange behaviour now.
>>> After changing the SearchUserDN to the Users container I noticed that it
>>> was still using the previous setting.
>>> This reminded me to check the SysConfig options under System
>>> Administration in the Admin panel. In the Frontend::CustomerAuth module it
>>> was still showing the old Customer Auth LDAP settings. (it must have pulled
>>> them in from somewhere as I didn't set them)
>>> I cleared all the checkboxes and set the other options to their defaults.
>>>
>>> This put lines of the following format in the ZZZAuto.pm and ZZZAAuto.pm
>>> files for all the settings I un-ticked;
>>>
>>> delete $Self->{'Customer::AuthModule::LDAP::SearchUserDN'};
>>>
>>>
>>> When the Customer.pl script authenticates now it doesn't use any user
>>> details, just "<ROOT>".
>>>
>>> Can anybody tell me which settings take precedence?
>>>
>>> I'm going to try commenting out the lines from the ZZZAuto.pm and
>>> ZZZAAuto.pm files (even tho I probably shouldn't)
>>>
>>> Any more help, ideas or opinions would be greatly appreciated.
>>> Kind regards,
>>> Rory Clerkin
>>>
>>> On 13 May 2011 14:52, Rory <rcler...@gmail.com> wrote:
>>>
>>> Hi Shawn,
>>>
>>> Thanks for your reply, I'll see how it works out in the container
>>> instead.
>>>
>>> Kind regards,
>>> Rory Clerkin
>>>
>>> On 13 May 2011 14:25, Gadow, Shawn <sga...@ocusd.net> wrote:
>>>
>>> Ok I could be wrong because I don’t know your AD structure but take a
>>> look here..
>>>
>>>
>>>
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=LDAP
>>> Lookup,OU=Service Accounts,OU=Users,OU=Dept,DC=mydomain,DC=local';
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'mypw123';
>>>
>>> Mine looks like this
>>>
>>>
>>>
>>>
>>>
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} =
>>> 'cn=testaccount,cn=Users,dc=ocusd,dc=local';
>>>
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'test123';
>>>
>>>
>>>
>>> What I have is the user account test witch which is located in the users
>>> directly under the base DN.. the folder it’s located in needs to be a
>>> container not an OU I believe this is where your issue lies once again I
>>> could be wrong however
>>>
>>>
>>>
>>> Same applies with
>>>
>>>
>>>
>>> UserDN => 'CN=LDAP Lookup,OU=Service
>>> Accounts,OU=Users,OU=Dept,DC=mydomain,DC=local',
>>> UserPW => 'mypw123',
>>>
>>>
>>>
>>>
>>>
>>> Shawn Gadow
>>>
>>> Network Administrator
>>>
>>> Oregon CUSD 220
>>>
>>>
>>>
>>> “Security is when everything is settled. When nothing can happen to you.
>>> Security is the denial of life.” – Germaine Greer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
>>> Rory
>>> Sent: Friday, May 13, 2011 8:00 AM
>>> To: otrs@otrs.org
>>> Subject: [otrs] Customer LDAP Auth Issue - not anonymous
>>>
>>>
>>>
>>> Hi All,
>>>
>>> I'm having an issue while authenticating a Customer user against our
>>> windows Active Directory tree and I hope somebody can help me.
>>>
>>> I've been watching the network traffic on the AD server with Wireshark to
>>> see exactly what's happening. Here's the steps:
>>>
>>> 1. OTRS requests to bind to LDAP using a specified user "CN=LDAP
>>> Lookup,OU=Service Accounts,OU=Users,OU=EFC,DC=mydomain,DC=local".
>>> 2. LDAP server accepts the bind.
>>> 3. OTRS searches for the username.
>>> 4. LDAP server returns the correct user
>>> 5. OTRS searches for the group with the condition that the user is in the
>>> group
>>> 6. LDAP server returns the correct group
>>> 7. OTRS unbinds from LDAP
>>> 8. OTRS requests to bind to LDAP using the login user that was returned
>>> in step 4.
>>> 9. LDAP server accepts the bind
>>> 10. OTRS unbinds from LDAP server
>>>
>>> So far this is good and shows that the initial authentication succeeds.
>>> The next few steps are where OTRS tries to retrieve the customer attributes
>>> from LDAP
>>>
>>> 11. OTRS requests to bind to LDAP using "<root>".
>>> 12. LDAP server accepts the bind
>>> 13. OTRS searches the specified OU's subtree for the attributes listed in
>>> the map
>>> 14. LDAP server gives an error "000004DC: LdapErr: DSID-0C0906E8,
>>> comment: In order to perform this operation a successful bind must be
>>> completed on the connection., data 0, v1db1"
>>>
>>> The problem seems to be that OTRS tries to access the LDAP tree as an
>>> anonymous user in order to retrieve the customer attributes. Everything I've
>>> tried has not made any change to this part of the process.
>>>
>>> Here are some of the things I've tried;
>>>
>>> * The customer config format, in the manual, at the following link which
>>> authenticates but doesn't have details to map customer data
>>> http://doc.otrs.org/3.0/en/html/auth-backends.html
>>>
>>> * The customer config format, in the manual, at the following link which
>>> authenticates but fails to map customer data
>>> http://doc.otrs.org/3.0/en/html/customer-user-backend.html
>>>
>>> * Using both the above config formats at the same time.
>>>
>>> * Copying the Customer Config details into the Default.pm file which
>>> seemed to work for another user.
>>>
>>> * Using different attributes of the LDAP user to search and authenticate
>>> with e.g. sAMAccountName and userPrincipleName.
>>>
>>> * Using the domain suffix as part of the search and authenticate
>>> settings.
>>>
>>>
>>> I've included my customer config below which isn't working (and is
>>> currently written in the Default.pm file).
>>> I've sanitised the domain and password details but otherwise the config
>>> is exactly as on my server.
>>>
>>> ############################
>>> # Start Customer LDAP config copied over from Config.pm
>>> ############################
>>>
>>>
>>> $Self->{'Customer::AuthModule'} =
>>> 'Kernel::System::CustomerAuth::LDAP';
>>> $Self->{'Customer::AuthModule::LDAP::Host'} =
>>> 'svr004.mydomain.local';
>>> $Self->{'Customer::AuthModule::LDAP::BaseDN'} =
>>> 'ou=dept,dc=mydomain,dc=local';
>>> $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
>>>
>>> # Check if the user is allowed to auth in a posixGroup
>>> # (e. g. user needs to be in a group xyz to use otrs)
>>> $Self->{'Customer::AuthModule::LDAP::GroupDN'} =
>>> 'CN=OTRS_Customers,OU=Security,OU=Groups,OU=Dept,DC=mydomain,DC=local';
>>> $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'member';
>>> # for ldap posixGroups objectclass (just uid)
>>> # $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';
>>> # for non ldap posixGroups objectclass (full user dn)
>>> $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
>>>
>>> # The following is valid but would only be necessary if the
>>> # anonymous user does NOT have permission to read from the LDAP
>>> tree
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=LDAP
>>> Lookup,OU=Service Accounts,OU=Users,OU=Dept,DC=mydomain,DC=local';
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'mypw123';
>>>
>>> # in case you want to add always one filter to each ldap query,
>>> use
>>> # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter
>>> => '(objectclass=user)'
>>> $Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} =
>>> '(objectclass=user)';
>>>
>>> # in case you want to add a suffix to each customer login name,
>>> then
>>> # you can use this option. e. g. user just want to use user but
>>> # in your ldap directory exists user@domain.
>>> # $Self->{'Customer::AuthModule::LDAP::UserSuffix'} =
>>> '@mydomain.local';
>>>
>>> # Net::LDAP new params (if needed - for more info see perldoc
>>> Net::LDAP)
>>> $Self->{'Customer::AuthModule::LDAP::Params'} = {
>>> port => 389,
>>> timeout => 120,
>>> async => 0,
>>> version => 3,
>>> };
>>>
>>>
>>> $Self->{CustomerUser} = {
>>> Name => 'LDAP Datasource',
>>> Module => 'Kernel::System::CustomerUser::LDAP',
>>> Params => {
>>> Host => 'svr004.efc.local',
>>> BaseDN => 'ou=EFC,dc=mydomain,dc=local',
>>> SSCOPE => 'sub',
>>> UserDN => 'CN=LDAP Lookup,OU=Service
>>> Accounts,OU=Users,OU=Dept,DC=mydomain,DC=local',
>>> UserPW => 'mypw123',
>>> AlwaysFilter => '(objectclass=user)',
>>> Params => {
>>> port => 389,
>>> timeout => 120,
>>> async => 0,
>>> version => 3,
>>> },
>>> },
>>> CustomerKey => 'sAMAccountName',
>>> CustomerID => 'mail',
>>> CustomerUserListFields => ['sAMAccountName', 'sn', 'cn',
>>> 'mail'],
>>> CustomerUserSearchFields => ['sAMAccountName', 'cn', 'sn',
>>> 'mail'],
>>> CustomerUserSearchPrefix => '',
>>> CustomerUserSearchSuffix => '*',
>>> CustomerUserSearchListLimit => 250,
>>> CustomerUserPostMasterSearchFields => ['mail'],
>>> CustomerUserNameFields => ['givenname', 'sn'],
>>> CustomerUserExcludePrimaryCustomerID => 0,
>>> AdminSetPreferences => 0,
>>> Map => [
>>> [ 'UserSalutation', 'Title',
>>> 'title', 1, 0, 'var', '', 0 ],
>>> [ 'UserFirstname', 'Firstname',
>>> 'cn', 1, 1, 'var', '', 0 ],
>>> [ 'UserLastname', 'Lastname',
>>> 'sn', 1, 1, 'var', '', 0 ],
>>> [ 'UserLogin', 'Username',
>>> 'sAMAccountName', 1, 1, 'var', '', 0 ],
>>> [ 'UserEmail', 'Email',
>>> 'mail', 1, 1, 'var', '', 0 ],
>>> [ 'UserCustomerID', 'CustomerID',
>>> 'mail', 0, 1, 'var', '', 0 ],
>>> [ 'UserPhone', 'Phone',
>>> 'telephoneNumber', 1, 0, 'var', '', 0 ],
>>> [ 'UserAddress', 'Address',
>>> 'postaladdress', 1, 0, 'var', '', 0 ],
>>> [ 'UserComment', 'Comment',
>>> 'description', 1, 0, 'var', '', 0 ],
>>> ],
>>> };
>>>
>>>
>>> ############################
>>> # End Customer LDAP config copied over from Config.pm
>>> ############################
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
