Val Polyakov wrote, On 9/15/10 3:51 PM:
Plaintext.

But that doesnt matter - because its a RT db, with nothing else on it.
Security has no problem with it.

They only have a problem with storing the domain account credentials in
plaintext.

I'm not sure that it will satisfy the people you are trying to satisfy, but we stay as safe as possible by using an LDAP account that has restricted read and search access and no write permissions. That account is only used to do an initial bind, search for a user by the attributes in attr_match_list, and read the attributes in attr_map. It needs no other rights in LDAP. After that, actual user authentication is done with a bind attempt using the found account DN and the password provided by the user.

The way your question is worded makes it seem like you are trying to use some sort of unique high-privilege account, which would be an unnecessary and unsafe approach. The limited-account approach works for us because the attributes it can search and read are significantly less than what any of our human users can search and read. The added risk of that account password being in the clear in a file that can only be read by 'root' and 'www' on a system that has only admins as human users is insignificant. But of course, that is our environment, and yours may be a lot different.


--Val

   On 09/15/2010 12:52 PM, Val Polyakov wrote:
Hello,

what are our options as far as securing RT_SiteConfig.pm goes?

My company has pretty strict security requirements, and our security
team
will simply not allow us to store the ldap username/password in a plain
text file on the RT server (and I can fully understand their concerns).

What are some options here? Again, keeping in mind that the requirement
is
for the password (at least the password, that is) to NOT be plaintext in
RT_SiteConfig.pm

Solutions like "well make the file only readable by root" aren't going
to
be accepted (not by me, but by our security team). Needs to be a hashed
password, may be, or something.. I don't know.. soliciting ideas.

--Val
How are you storing the database userid and password in that case?

Jeff

RT Training in Washington DC, USA on Oct 25&  26 2010
Last one this year -- Learn how to get the most out of RT!




RT Training in Washington DC, USA on Oct 25&  26 2010
Last one this year -- Learn how to get the most out of RT!


RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year -- Learn how to get the most out of RT!

Reply via email to