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 l**ife*.” – 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
