Using an Existing non-Updatable LDAP Database
I submitted a couple questions to this group yesterday about using two DB's simultaneously -- using LDAP to pull up new user data to pre-populate the add user/update user form, then a local database for storeage. Then I realized that the add/change screen might be the only place in OTRS that the user database info is changed. If this is the case, I could use the corporate read-only LDAP database and simply reprogram the update user info button to direct the user to the official, corporate LDAP maintenance web page. When we try to log in with the OTRS backend set to LDAP, though, we can authenticate but receive a message that there is no user data. It seems that there's more going on behind the scenes than there appears to be at first glance. I figure very few companies give new OTRS admins write access to valuable LDAP employee directories. I suspect my situation is not unique. How has anyone else confronted with this situation solved this problem? (I mean, besides disregarding LDAP altogether and entering user data manually to a local SQL database.) TIA, Richard Petty Austin, Texas
From what I have seen, if you are using LDAP, it is only read only. I am not able to update any data in LDAP via OTRS.
I get this error, but I have not looked into it because I do not want to
edit the LDAP data via OTRS.
ref:
ERROR: OTRS-CGI-10 Perl: 5.8.5 OS: linux Time: Thu Dec 1 16:27:26 2005
Message: Not supported for this module!
Traceback (20882):
Module: Kernel::System::CustomerUser::LDAP::CustomerUserUpdate (v1.24)
Line: 370
Module: Kernel::System::CustomerUser::CustomerUserUpdate (v1.21) Line:
189
Module: Kernel::Modules::AdminCustomerUser::Run (v1.37 ) Line: 191
Module: Kernel::System::Web::InterfaceAgent::Run (v1.8) Line: 651
Module:
ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler
(v) Line: 48
Module: (eval) (v1.80) Line: 202
Module: ModPerl::RegistryCooker::run (v1.80) Line: 202
Module: ModPerl::RegistryCooker::default_handler (v1.80) Line: 168
Module: ModPerl::Registry::handler (v1.99) Line: 30
If it is supposed to write back to LDAP, mine may not be working because of
the extra info I am pullig:
ref:
Firstname:
Lastname:
Login:
Title:
Department:
Email:
CustomerID:
Phone:
Mobile:
Nextel:
Company:
Building:
LoginScript:
Address:
--
--
Steven
May you have the peace and freedom that come from abandoning all hope of
having a better past.
--- - --- - - - - - - - -- - - - --- - ------ -
- --- - - -- - - - -- - - -
"Richard Petty"
I submitted a couple questions to this group yesterday about using two DB's simultaneously -- using LDAP to pull up new user data to pre-populate the add user/update user form, then a local database for storeage.
Then I realized that the add/change screen might be the only place in OTRS that the user database info is changed. If this is the case, I could use the corporate read-only LDAP database and simply reprogram the update user info button to direct the user to the official, corporate LDAP maintenance web page.
When we try to log in with the OTRS backend set to LDAP, though, we can authenticate but receive a message that there is no user data. It seems that there's more going on behind the scenes than there appears to be at first glance.
I figure very few companies give new OTRS admins write access to valuable LDAP employee directories. I suspect my situation is not unique.
How has anyone else confronted with this situation solved this problem? (I mean, besides disregarding LDAP altogether and entering user data manually to a local SQL database.)
TIA,
Richard Petty
Austin, Texas _______________________________________________ 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 Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
participants (2)
-
Richard Petty -
Steven