Dear list. I'm almost there. The problem I hit at full speed is I can't import private key for my otrs email address into S/MIME section of Admin area. Every time I try to add a private key (PEM formatted file) I get the following error:
[image: Info] : Need Certificate of Private Key first -Error reading password from BIOError getting passwords)! The certificate corresponding to the key is imported already. The key I'm trying to import has no password. If it needs a password, what encryption I should use? Please share you experience. Anton. 2008/11/12 Anton Gubar'kov <[EMAIL PROTECTED]> > 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
