The ldap.adminPassword filed under the system properties page in the administration console reveals the password for the ldap acount used.
This is a security risk.
Can this be addressed?
Regards
Riyaz Hussain
There isnt really much of a security risk by allowing the ldap admin password to be seen from the admin console. If a user has access to the admin console, they can control all aspects of OpenFire anyway. If the ldap admin you are using has more rights than read-only to your ldap database, then the security risk is allowing a service more privilege than it needs.
I agree that, but in an enterprise enviroment we force all the users to use their own accounts for accountability.
As openfire does not have delegated admin rights, we are forced to give the engineers the admin access for the console so as to manage the chat server.
The engineers now have an option to use this account for various other resaons to hide their identity.
In my prespective this falls under the security risk category.
This is scheduled to be fixed in the next release, if it ever comes out, and if it has not been bumped again. I reported this months ago with the release of 3.6.0.
If the ldap admin account only has read-only rights, what risk are you mitigating? Your chat server admins will be able to see all users on the ldap server either way. If that ldap admin account can be used for anything but read-only ldap queries, then I repeat that your security problem is that account, and not openfire.
Its important to recognize what Openfire is- it is a single service with limited opportunity for role delineation. Because there are so few tasks to be administered, adding a complex ACL and role separation would be costly (time-wise) to develop, and would make the user experience less usable overall. That means Openfire gets two types of users: Admins and Non-Admins. Anyone with admin rights can control the server, and thus could emulate any of the server functions. Looking up information in ldap is pretty minor. I would be more worried about your admins using the SSL certificates and private keys (traffic snooping, man-in-the-middle, used as a trusted client cert, etc). Your admins also have access to some database which contains user information (contact lists, openfire config, maybe even chat history). Admins here do have access to much, and trust in your admins is required to some degree.
Openfire does the best job it can at not requiring privledge above what is needed to do its task. Proper configuration of the things Openfire utilizes will prevent misuse (ie- ldap account is read-only, db account is limited to its own database). Any service that uses other service accounts (database, etc) has this same issue.
It still allows users to masquerade as another account on the network. This is a breach of security no matter how minimal. I don’t think anyone is asking for complex ACL just password masking/encryption. There is no reason to display the password in plain text. If you use the embedded database this password is easily retrievable and external SQL is only as secure as the config of that server. Plain text passwords do not pass even the most basic security audit. This product would fail a compliancy check in most business and school environments.