Dear colleagues, thank you for positive feedback. I'll try to set up S/MIME on my system and see if it can help. If I'm able to encrypt external emails with customer's public keys the security issue should be closed.
Anton. 2008/11/12 Michiel Beijen <[EMAIL PROTECTED]> > Jack, > in that case, user test2 can't read test1's tickets at all! That was > not the point, right? The requirement was that only passwords were > hidden, if I understood correctly? > I guess the only technical solution if you want to solve it in OTRS is > to create a new kind of email communication which is 'secret' and > hidden for other customer users. This would involve quite a lot of > hacking and I would advise against it; see my earlier mail for my > proposed solutions. > > Regards, > -- > Michiel Beijen > Software Consultant > +31 6 - 457 42 418 > Bee Free IT + http://beefreeit.nl > > > 2008/11/12 Jie(Jack) Zhu <[EMAIL PROTECTED]>: > > Hi Anton, > > > > > > > > Based on your case, I built up the following settings: > > > > > > > > 1. Be understood the "User" in OTRS is actually Agent not Customer. > > > > 2. Went to Sysconfig -> Frontend::Customer , enable > > "CustomerGroupSupport" and Delete the default value (Users, Info) from > the > > "CustomerGroupAlwaysGroups". This way the customers are not longer in the > > same group unless you set up another common group for them. > > > > 3. Created test1, test2 as 2 customers with same customer ID, > created > > CustomerSubmit1, CustomerSubmit2 as 2 Queues. Created TestGroup1, > TestGroup2 > > as 2 test groups. > > > > 4. Assigned test1 to TestGroup1 and has read and write rights, > > assigned test1 to TestGroup2 and has read rights only. Assigned test2 to > > TestGroup2 and has rights to read and write. > > > > 5. Assigned test1 to queue CustomerSubmit1, assigned test2 to queue > > CustomerSubmit2. > > > > 6. Now, user test2 can not read user test1's tickets, despite they > are > > under the same CustomerID. > > > > > > > > Jack > > > > > > > > ________________________________ > > > > From: Anton Gubar'kov [mailto:[EMAIL PROTECTED] > > Sent: 2008年11月11日 11:36 AM > > To: User questions and discussions about OTRS. > > Subject: Re: [otrs] company tickets access control > > > > > > > > Colleagues, I'm sorry for putting so much confusion into the case. > > > > I'm an IT service provider for company Acme. I support Acme's ERP > system. > > My agents are trustworthy. > > Acme has users Ann and Mallory. Ann is a financial controller. Mallory > is > > salesman. > > Mallory wants to hijack Ann's privilege to release credit blocked orders > in > > Acme's ERP to satisfy his customer with credit block.. > > Mallory tries to login 5 times using Ann's user id and causes it to > lock. > > Mallory starts to watch Company tickets waiting for Ann to raise a > password > > reset request with me. > > Ann raises a password reset request. > > Mallory continues watching waiting for the new password to appear on > Ann's > > ticket. > > Before Ann has a chance to change her new password, Mallory logs in as > Ann > > and releases the blocked order. > > > > I want to control an access to tickets from my customer's users. Can you > > suggest a way to resolve this case? > > > > 2008/11/11 Jie(Jack) Zhu <[EMAIL PROTECTED]> > > > > Sorry Anton, I do not quite understand what the point is. > > > > > > > > Suppose you have the rights to reset a password for a user. Don't you > have > > the rights to do the search on this user and relatives? > > > > This is the problem you trust your agent or not. > > > > > > > > I think the access control is quite advanced in OTRS. You have Role and > > Group. You can create a role and put groups in it. Then add the role to > the > > users. > > > > > > > > If you want, you can put different companies into different groups and > only > > set the agent on the groups they are responsible to. This way could > narrow > > down the risk? > > > > In this way, you even can set each user in each group. :) > > > > > > > > Regards, > > > > Jack > > > > > > > > ________________________________ > > > > From: Anton Gubar'kov [mailto:[EMAIL PROTECTED] > > Sent: 2008年11月10日 14:41 PM > > To: User questions and discussions about OTRS. > > Subject: [otrs] company tickets access control > > > > > > > > Hello, list. > > > > I've come across a problem I can't overcome. > > Suppose I have a request to reset a password on some account for a user > due > > to account locked or password forgotten. I thought I could communicate > the > > new password to a user using external-email or external-note article. But > it > > is really too dangerous to do that! > > > > The whole company tickets collection is searchable! I could find no way > > control access to the tickets in one CustomerID except one using queues. > The > > queues are used for different purpose usually. > > The alternative is to quit using CustomerID and treat every user as > > individual customer. This is not convenient either as some bosses at > > customers want to watch the requests of their subordinates. > > > > This is the simplest example that comes to mind. There is a lot more > > sensitive information circulating in the process of IT Service Delivery > that > > should not be shared across entire customer. > > > > I would be grateful for suggestions to solve this security issue. > > > > Regards, > > Anton Gubarkov. > > > > _______________________________________________ > > 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 >
_______________________________________________ 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
