Customer Users: Can we keep all data in OTRS database, but still authenticate against LDAP?
We’re evaluating OTRS at present, and are looking to get LDAP authentication working. We’ve succeeded in getting Users (agents) authenticating against our LDAP server (eDir) but haven’t yet got Customer authentication working against this directory – we want our Customers to be able to login to the Customer web page with their eDir uids and passwords. Before we get too deeply into the mysteries of configuring this setup, can I just check one fundamental point - In our case, in order to provision each Customer record, we will need to be getting the fields from a number of different sources – our own MySQL tables, queries on a different LDAP server etc. It is probably going to be easier for us to assemble this data for each customer, and directly update the OTRS database ‘customer_user’ table, than it is for us to write the fields into our eDir schema and then synchronise this with OTRS’s tables. Given that we have a full Customer record in the customer_user table, is it possible for OTRS just to use LDAP for the purpose of customer authentication only, without us having to modify our eDir entries at all? This isn’t clear to me from the documentation. Also, if we have Customer data in ‘customer_user’ and are just using LDAP for Customer (and User/Agent) authentication, will we be able to edit individual users via the OTRS web interface? I assume there would be no reason why we couldn’t also edit the ‘customer_user’ table directly if we preferred. This SEEMS to be the way things are working with our User/Agent LDAP authentication - I can see and edit agent details in the OTRS web interface, but any changes to password I put in there are ignored, and agents are correctly authenticated against my eDir login. Is this how it should work for customer users too, once we’ve sorted out the LDAP setup? I’d be grateful for any clarification on this point. Regards Phil Stanford
Hello Phil,
It is probably going to be easier for us to assemble this data for each customer, and directly update the OTRS database ‘customer_user’ table, than it is for us to write the fields into our eDir schema and then synchronise this with OTRS’s tables.
Actually you don't need to snychronize your LDAP to your OTRS database. OTRS is able to retrieve the customer data directly from the LDAP (and may cache this data to increase performance if you like). However, since LDAP can be used in far more applications than OTRS, I'd recommend using the LDAP for storing customer data. At least you have only one data source which needs to be updated.
Given that we have a full Customer record in the customer_user table, is it possible for OTRS just to use LDAP for the purpose of customer authentication only, without us having to modify our eDir entries at all?
Yes, OTRS differentiate between customer data backend and customer authentication backend. Thus, you can use your LDAP for authentication and retrieve the customers data from your OTRS- or any other accessible database.
Also, if we have Customer data in ‘customer_user’ and are just using LDAP for Customer (and User/Agent) authentication, will we be able to edit individual users via the OTRS web interface? I assume there would be no reason why we couldn’t also edit the ‘customer_user’ table directly if we preferred.
Also an agreement on this point. If you have the corresponding permissions, you may update a customer users data in die OTRS-database. If you are using a writable LDAP-backend (currently not available in default OTRS installations but possible) you may also update your customer users data directly in the LDAP. kind regards, Torsten Thau -- ** Besuchen Sie uns auf dem LinuxTag in Berlin ** ** vom 9. - 12. Juni, Stand 110 in Halle 7.2A** Torsten Thau, Dipl. Inform. c.a.p.e. IT Labs GbR - Annaberger Str. 240 - D-09125 Chemnitz phone: +49 371 5347 623 cell: +49 176 66 680 680 personal pgp-key: 0x93E0A174 fax: +49 371 5347 625 http://www.cape-it.de
Many thanks for those comments Torsten.
Yes, I can see the merits of keeping everything accessible via LDAP - we'll
consider that option. However in the future we might need to use AD
elsewhere in the organisation, where we don't have much control over
content, hence there are some benefits in keeping most things in the
database.
It's good to know that OTRS can probably be as flexible as we need it to be
anyway.
Regards
Phil
On 30/05/2010 09:33, "Torsten Thau"
Hello Phil,
It is probably going to be easier for us to assemble this data for each customer, and directly update the OTRS database Œcustomer_user¹ table, than it is for us to write the fields into our eDir schema and then synchronise this with OTRS¹s tables.
Actually you don't need to snychronize your LDAP to your OTRS database. OTRS is able to retrieve the customer data directly from the LDAP (and may cache this data to increase performance if you like). However, since LDAP can be used in far more applications than OTRS, I'd recommend using the LDAP for storing customer data. At least you have only one data source which needs to be updated.
Given that we have a full Customer record in the customer_user table, is it possible for OTRS just to use LDAP for the purpose of customer authentication only, without us having to modify our eDir entries at all?
Yes, OTRS differentiate between customer data backend and customer authentication backend. Thus, you can use your LDAP for authentication and retrieve the customers data from your OTRS- or any other accessible database.
Also, if we have Customer data in Œcustomer_user¹ and are just using LDAP for Customer (and User/Agent) authentication, will we be able to edit individual users via the OTRS web interface? I assume there would be no reason why we couldn¹t also edit the Œcustomer_user¹ table directly if we preferred.
Also an agreement on this point. If you have the corresponding permissions, you may update a customer users data in die OTRS-database. If you are using a writable LDAP-backend (currently not available in default OTRS installations but possible) you may also update your customer users data directly in the LDAP.
kind regards, Torsten Thau
participants (2)
-
Stanford P. -
Torsten Thau