2008/11/11 Anton Gubar'kov :

I'm an IT service provider for company Acme. I support Acme's ERP system. My agents are trustworthy.

Hi Anton, This is the problem; you can not guarantee that your agents are trustworthy... Anyone with access to the tickets will have access to these passwords. This is in my opinion NOT a technical issue. You should eliminate the problem by choosing one of the following: * Alter the function that resets the password so that it will send the new password automatically to the user * Let the service desk agent send the password directly to the customer from his own account, NOT using OTRS. In both cases the agent should just put a note in OTRS, something like 'new password sent to user', and close the ticket. That way people with access to the ticket, either internal or external, can see what actions have been taken and when (the new password was send to the user) but there is no security risk because there are no passwords in clear text in accessible fields in OTRS. Regards, -- Michiel Beijen Software Consultant +31 6 - 457 42 418 Bee Free IT + http://beefreeit.nl 2008/11/11 Anton Gubar'kov :

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

...

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:anton.gubarkov@gmail.com] 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.

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 :

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:anton.gubarkov@gmail.com] 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

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:anton.gubarkov@gmail.com] 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

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

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

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 :

...

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:anton.gubarkov@gmail.com] 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

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:anton.gubarkov@gmail.com] 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

Hi Michiel, I think that was the point. 2 customers in 2 different departments should have a way to block them to see each other's ticket in case of the confidential reason. However, the big boss of the company should be able to see all his employee's tickets. My way was definitely not the best solution. Through this test I found the way to treat customer side rights in OTRS needs to be improved. You have to create too many Groups and Queues in the system. The other problem I found is that if you move a ticket from the queue to another queue the ticket will not be traceable by the customer who issued it. This is not reasonable. Regards, Jack -----Original Message----- From: Michiel Beijen [mailto:michiel@beefreeit.nl] Sent: 2008年11月12日 08:00 AM To: j.zhu@impactek.com; User questions and discussions about OTRS. Subject: Re: [otrs] company tickets access control 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 :

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:anton.gubarkov@gmail.com] 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

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:anton.gubarkov@gmail.com] 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