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