Re: [otrs] Restricting the self-registration feature

You could write some other web app that allows users to create a user account/record in a separate database/table/ldap and then point OTRS at that data source for customer information. That would allow you to easily customise the logic behind account creation. Or hack the OTRS code to add in some email address checking to the user registration component (remember to diff your changes so you can reapply on an update). Steve On 28 August 2012 20:40, brianmortonb2b-atwork@yahoo.dk wrote:

Hmm, I think you are missing the point. Our customers (the organisations) are very well-known to us. The individual users within those organisations are not. We are contractually committed to give support to ANY user from within our customer's organisations. For some of our customers there are literally hundreds of users that we serve within a single customer organisation. We would kill ourselves if we were to set up customer users on a person-by-person basis. And it would probably infuriate our customers to wait for us to do so every time.

There's no way that our customers would hand out anything that looks like a user registry, e.g LDAP or similar. These are well-guarded secrets that cannot even be offered to the government unless required to by law. Corporations treat even the usernames that they use internally as well-guarded secrets that are not to leave the doorstep of the organisation. (the idea is that knowing internal user names within a corporation moves a potential hacker one step closer to his target).

This may all sound as if I cannot use your answer. Far from it. I can use the CAPTCHA idea and will look into it.

Thank you.

Brian

________________________________ From: Gerald Young To: "brianmortonb2b-atwork@yahoo.dk" ; User questions and discussions about OTRS. Sent: Tuesday, August 28, 2012 5:57 PM Subject: Re: [otrs] Restricting the self-registration feature

http://forums.otterhub.org/viewtopic.php?f=60&t=5941 (reCAPTCHA) http://forums.otterhub.org/viewtopic.php?f=60&t=6586 (Accept customer only emails as tickets)

or, ddt (don't do that). "our customers should be able to self serve as much as possible." "our customers" and "self serve" are contradictory in this sense. If they're your customers, you should already know who they are and have them as customers (link to or import from existing data source). They shouldn't have to register themselves if they're known to you. (Personal opinion). Now, in the case of (large multinational corporation) this may be a bit difficult to obtain and sync all the customers who will be able to create tickets with your company, but on the other hand, if you're that intimate, you may ask to get an ldap connection for Customer queries. That will be helpful in this case: 1) add/remove users is not up to you 2) password management is customer-side (ldap) 3) customer knows her password is the same as office 4) no registration 5) zero administrative communication when users change 6) list is always uptodate 7) you don't burden your customers with registration

On Tue, Aug 28, 2012 at 11:33 AM, brianmortonb2b-atwork@yahoo.dk wrote:

Maybe I'm thick but I cannot figure this one out:

I really like the self-registration feature. The idea is that our customers should be able to self serve as much as possible. However at the moment anyone can register and I fear that when we go live there will be lots of self-registration attempts by spammers.

In the company I work for the customer organizations are well-known (a dozen or so). The users within them are not (several hundreds).

What I would like is that only users (customers) who register with e-mail domains that are known to the OTRS system are allowed to self-register on the portal. Example : We would allow john.doe@ikea.com to self-register because IKEA is a customer of ours and thus "@ikea.com" is a well-known e-mail domain. Conversely if joe.hacker@harmful.com tries to register he should be rejected. (IKEA is not really a customer of ours in real world :-))

Having the above functionality would of course require that OTRS would store a list of known e-mail domains for each customer organization.

But, but. There may be other ways to prevent misuse of the self-registration feature. Perhaps some functionality that already exist? Any ideas ?

Thx.

Brian

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