I am a newbie to wildfire server, started work on this since one week. I have installed Wildfire server 2.6.2 and integrated with LDAP in my testing environment.
However the issue is that for actual deployment, my organisation security policy does not allow me to specify the password of admin(for that matter any user) in a flat file.
Is there a workaround for not specifying admin password in the wildfire.xml file and still integrate with LDAP? Unfortunately if this cannot be achieved I would be forced not to use such a robust server. (pity me??)
Please let me know what are the possible solutions if any?
I dunno if this is the solution you are looking for, however it is trivial to configure Wildfire to use an LDAP user instead of the default admin user for administrative purposes.
In the wildfire.xml file, you can specify which users (this includes LDAP users) are admins.
Here is a sanitized snippit of my wildfire.xml file, with the relevant section bolded:
In my deployment user “Admin” does not exist. Instead, by changing the value to a valid LDAP user ID, that ID can log in and serve as admin.
I understand that I can add an LDAP user instead of and additional to the default admin user for administrative purposes. But my inhand issue is with the below part in the wildfire xml file:
your “bigadmin” just need rights to read LDAP, Wildfire does not modify anything also the tags are called adminDN and adminPassword.
How do other applications connect to LDAP?
Do you enter the password manually while starting them?
You may tell us how you are doing this right now and what could be considered a usable workaround.
I could think of storing the password encrypted in the wildfire.xml file or in the database - but making the wildfire.xml file only accessable by Wildfire is the easiest solution.
hi guys, sorry I was away for a while, got stuck in design stuff.
LG, I think in my org till now there is no CRUD kind of implementation available for the directory server. So the information from LDAP in other applications is retreived based on the user data from the request context. (user id and password of the log in user)… am not too sure here, but this is what I think is happening…
One solution that I can think of right now, is that we could store the admin(user with read only access) details in the wildfire database using some encryption algorithm (preferably a one way hash using some key value), and the adminDN and password information is then read from the database while attempting to login.