I don't think so... The webchanges won't be saved based on the privileges of Apache, It might have been changed depending on the user you used to edit the file manually. So, you problem was that the search dn was wrong? Now it looks to me that you are confusing one thing, If you are using customer auth module, you shouldn't get the errors for Agent, since customer's won't syncronize. Or if you are trying to configure this for user agents, then you shouldn't use CustomerAuth Module. Regards On Mon, Apr 2, 2012 at 10:58 AM, Eddie wrote:

On Mon, Apr 2, 2012 at 12:08 PM, Alvaro Cordero wrote:

...

Hello Eddie,

Have you specified which fields are being sincronized into de local database. If the autentication suceds, the next step is to create a local copy of the agent, If that does not happen you will always get that

Check if you are missing the UseSync area. For more info Check Manual on Chapter 11.

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

Thanks, but that section looks the same here. One thing I noticed is that if I tried to change Customer::AuthModule::LDAP::UID using the SysConfig web interface the change wouldnt save. I had it set to sAMAccountName and was trying to change it to userPrincipalName so users can specify their domains but after saving it would revert back to sAMAccountName. Went to Config.pm and search/replaced all instances of sAMAccountName with userPrincipalName. Maybe it changed something it shouldnt. Im going to revert this virtual machine to a snapshot I took just before the changes to LDAP. Does it mean anything when the web interface wont save a change but wont give any error?

--------------------------------------------------------------------- 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

-- ___________________________ Alvaro Cordero Retana Consultor de Tecnologias Gridshield Monitoreo de Redes e Infraestructura. 2258-5757 ext 123 alvaro@gridshield.net www.gridshield.net

How about "just" adding yet another customer authentication (and data) backend pointing at the child domain? http://doc.otrs.org/3.1/en/html/auth-backends.html#customer-auth-backends http://doc.otrs.org/3.1/en/html/customer-user-backend.html#multiple-customer... -- /Sune T. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Eddie Sent: 3. april 2012 03:13 To: User questions and discussions about OTRS. Subject: Re: [otrs] child domain auth (multiple baseDN) On Mon, Apr 2, 2012 at 4:31 PM, Alvaro Cordero mailto:alvaro@gridshield.net> wrote: I don't think so... The webchanges won't be saved based on the privileges of Apache, It might have been changed depending on the user you used to edit the file manually. Weird as changes made to other fields on that page were saving correctly but the UID field kept reverting back So, you problem was that the search dn was wrong? Now it looks to me that you are confusing one thing, If you are using customer auth module, you shouldn't get the errors for Agent, since customer's won't syncronize. Or if you are trying to configure this for user agents, then you shouldn't use CustomerAuth Module. The problem Im trying to solve is to have customers from a child domain being able to log in trough the web interface and manage their tickets. Closest I can get is by changing the LDAP port to 3268 so it "sees" accounts on the child domain but OTRS is not able to use them with the error: Authentication succeeded, but no customer record is found in the customer backend. Please contact your administrator. For Agents its working for accounts on the parent domain without any problems. Maybe Im using the wrong approach for getting a child domain working but all I could find while searching was other people asking for something similar with child domains but no real answers on how to accomplish it. I'll be very grateful for any links to documentation or some pointers on how to accomplish this I guess as a plan B I can have users from the child domain opening tickets via email if nothing else works

Also, perhaps take a quick look here: http://doc.otrs.org/3.1/en/html/config.html#Framework:Frontend::Customer::Au... Search for "suffix". With "Customer::AuthModule::LDAP::UserSuffix" you can append the UPN part to the username, and have them login with just that. That does not solve the duplicate usernames though, I'm not sure how it will handle that, but it may be worth a shot. -- /Sune T. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Eddie Sent: 5. april 2012 20:34 To: User questions and discussions about OTRS. Subject: Re: [otrs] child domain auth (multiple baseDN) On Tue, Apr 3, 2012 at 2:13 AM, Sune T. Tougaard mailto:stt@lyngsoesystems.com> wrote: How about "just" adding yet another customer authentication (and data) backend pointing at the child domain? http://doc.otrs.org/3.1/en/html/auth-backends.html#customer-auth-backends http://doc.otrs.org/3.1/en/html/customer-user-backend.html#multiple-customer... -- Thanks for the links. After reading those docs I had a better a idea of what I should be searching for and found this: http://faq.otrs.org/otrs/public.pl?Action=PublicFAQZoom;ItemID=219 Now I have users and agents working for parent and child domain. Only issue is that if a username is in both domains it will give me problems. Using userPrincipalName instead of sAMAccount should help with this but it seems it needs the username in the format username@domain so It might confuse users a little. Our emails are different from user@domain and the closest thing they know besides their email is the occasional domain\username. Going to try to set it to log in using the users email address as it will be more "natural" How does the sysconfig page work now that there are a "duplicate" sections ? config section: ------------------------------------------------------------ #LDAP1 START $Self->{'AuthModule1'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host1'} = '192.168.0.1'; $Self->{'AuthModule::LDAP::BaseDN1'} = 'dc=parentdomain, dc=com'; $Self->{'AuthModule::LDAP::UID1'} = 'sAMAccountName'; $Self->{'AuthModule::LDAP::SearchUserDN1'} = 'cn=bind user,ou=Users,dc=parentdomain,dc=com'; $Self->{'AuthModule::LDAP::SearchUserPw1'} = 'password'; $Self->{'Customer::AuthModule1'} = 'Kernel::System::CustomerAuth::LDAP'; $Self->{'Customer::AuthModule::LDAP::Host1'} = '192.168.0.1'; $Self->{'Customer::AuthModule::LDAP::BaseDN1'} = 'dc=parentdomain, dc=com'; $Self->{'Customer::AuthModule::LDAP::UID1'} = 'sAMAccountName'; $Self->{'Customer::AuthModule::LDAP::SearchUserDN1'} = 'cn=bind user,ou=Users,dc=parentdomain,dc=com'; $Self->{'Customer::AuthModule::LDAP::SearchUserPw1'} = 'password'; $Self->{CustomerUser1} = { Module => 'Kernel::System::CustomerUser::LDAP', Params => { Host => '192.168.0.1', BaseDN => 'dc=parentdomain, dc=com', SSCOPE => 'sub', UserDN => 'cn=bind user,ou=Users,dc=parentdomain,dc=com', UserPw => 'password', }, CustomerKey => 'sAMAccountName', CustomerID => 'mail', # CustomerID => 'o', 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' ], ], }; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group OTRS_Agents to use otrs) $Self->{'AuthModule::LDAP::GroupDN1'} = 'cn=helpdesk_agents,ou=Security Groups,ou=Groups,dc=parentdomain,dc=com'; $Self->{'AuthModule::LDAP::AccessAttr1'} = 'member'; $Self->{'AuthModule::LDAP::UserAttr1'} = 'DN'; # Now sync data with OTRS DB $Self->{'AuthSyncModule1'} = 'Kernel::System::Auth::Sync::LDAP'; $Self->{'AuthSyncModule::LDAP::Host1'} = '192.168.0.1'; $Self->{'AuthSyncModule::LDAP::BaseDN1'} = 'dc=parentdomain, dc=com'; $Self->{'AuthSyncModule::LDAP::UID1'} = 'sAMAccountName'; $Self->{'AuthSyncModule::LDAP::SearchUserDN1'} = 'cn=bind user,ou=Users,dc=parentdomain,dc=com'; $Self->{'AuthSyncModule::LDAP::SearchUserPw1'} = 'password'; $Self->{'AuthSyncModule::LDAP::UserSyncMap1'} = { # DB -> LDAP UserFirstname => 'givenName', UserLastname => 'sn', UserEmail => 'mail', }; # AuthSyncModule::LDAP::UserSyncInitialGroups # (sync following group with rw permission after initial create of first agent # login) $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups1'} = [ 'users', ]; #LDAP1 END #LDAP2 START $Self->{'AuthModule2'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host2'} = '192.168.0.2'; $Self->{'AuthModule::LDAP::BaseDN2'} = 'dc=childdomain,dc=parentdomain, dc=com'; $Self->{'AuthModule::LDAP::UID2'} = 'sAMAccountName'; $Self->{'AuthModule::LDAP::SearchUserDN2'} = 'cn=bind user,ou=Users,dc=childdomain,dc=parentdomain,dc=com'; $Self->{'AuthModule::LDAP::SearchUserPw2'} = 'password'; $Self->{'Customer::AuthModule2'} = 'Kernel::System::CustomerAuth::LDAP'; $Self->{'Customer::AuthModule::LDAP::Host2'} = '192.168.0.2'; $Self->{'Customer::AuthModule::LDAP::BaseDN2'} = 'dc=childdomain,dc=parentdomain, dc=com'; $Self->{'Customer::AuthModule::LDAP::UID2'} = 'sAMAccountName'; $Self->{'Customer::AuthModule::LDAP::SearchUserDN2'} = 'cn=bind user,ou=Users,dc=childdomain,dc=parentdomain,dc=com'; $Self->{'Customer::AuthModule::LDAP::SearchUserPw2'} = 'password'; $Self->{CustomerUser2} = { Module => 'Kernel::System::CustomerUser::LDAP', Params => { Host => '192.168.0.2', Port => '3268', BaseDN => 'dc=childdomain,dc=parentdomain, dc=com', SSCOPE => 'sub', UserDN => 'cn=bind user,ou=Users,dc=childdomain,dc=parentdomain,dc=com', UserPw => 'password', }, CustomerKey => 'sAMAccountName', CustomerID => 'mail', # CustomerID => 'o', 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' ], ], }; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group OTRS_Agents to use otrs) #$Self->{'AuthModule::LDAP::GroupDN2'} = 'cn=helpdesk_agents,ou=Security Groups,ou=FP_Groups,dc=parentdomain,dc=com'; $Self->{'AuthModule::LDAP::GroupDN2'} = 'cn=helpdesk_agents,ou=FP_Groups,dc=childdomain,dc=parentdomain,dc=com'; $Self->{'AuthModule::LDAP::AccessAttr2'} = 'member'; $Self->{'AuthModule::LDAP::UserAttr2'} = 'DN'; # Now sync data with OTRS DB $Self->{'AuthSyncModule2'} = 'Kernel::System::Auth::Sync::LDAP'; $Self->{'AuthSyncModule::LDAP::Host2'} = '192.168.0.2'; $Self->{'AuthSyncModule::LDAP::BaseDN2'} = 'dc=childdomain,dc=parentdomain, dc=com'; $Self->{'AuthSyncModule::LDAP::UID2'} = 'sAMAccountName'; $Self->{'AuthSyncModule::LDAP::SearchUserDN2'} = 'cn=bind user,ou=Users,dc=childdomain,dc=parentdomain,dc=com'; $Self->{'AuthSyncModule::LDAP::SearchUserPw2'} = 'password'; $Self->{'AuthSyncModule::LDAP::UserSyncMap2'} = { # DB -> LDAP UserFirstname => 'givenName', UserLastname => 'sn', UserEmail => 'mail', }; # AuthSyncModule::LDAP::UserSyncInitialGroups # (sync following group with rw permission after initial create of first agent # login) $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups2'} = [ 'users', ]; #LDAP2 END # 3rd backend, internal OTRS DB $Self->{'AuthModule3'} = 'Kernel::System::Auth::DB'; $Self->{'AuthModule::DB::CryptType3'} = 'crypt'; ------------------------------------------------------------

Great that you got it working. Would you mind sharing relevant config parts? :) Instead of removing, perhaps finding out how to merge the two would be great (adding the e-mail to the existing agents/customers). To preserve history and all that... -- /Sune T. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Eddie Sent: 10. april 2012 14:47 To: User questions and discussions about OTRS. Subject: Re: [otrs] child domain auth (multiple baseDN) On Tue, Apr 10, 2012 at 4:46 AM, Sune T. Tougaard mailto:stt@lyngsoesystems.com> wrote: Also, perhaps take a quick look here: http://doc.otrs.org/3.1/en/html/config.html#Framework:Frontend::Customer::Au... Search for "suffix". With "Customer::AuthModule::LDAP::UserSuffix" you can append the UPN part to the username, and have them login with just that. That does not solve the duplicate usernames though, I'm not sure how it will handle that, but it may be worth a shot. -- /Sune T. Im using the "mail" ldap attribute for UID and its working great now. The email is unique for each user and something they are very familiar with. Side effect is that any agents that logged in previously with sAMAccountName now when they logged in using their emails appear a "new" agents in the system. They have an old agent record based on the username and a new agent record based on the email. Need to figure out how to remove the old records