Thu Jul 24 2014 11:13:05 EDTfrom harryc @ Uncensored Subject: re: 8.25Thu Jul 24 2014 03:47:28 EDTfrom dothebart @ Uncensored Subject: re: 8.25"ok - now that you say it, this makes a lot more sense.
however, if you are to set this string, isn't that rather going to happen during setup?"
You've spotted a little quirk in citadel that I struggle with as well. Notice that using the command line interface or using sendcommand, all the possible ldap items are there available to be set: basedn, binddn, and with my little patch also the search string. So I thought adding the search string setup to the exact same spot as the other ldap items was in keeping with the sentiment of the main authors. But in webcit one can only choose 'authentication mode' and if that happens to be one of the ldap choices there is no way to set that up other than using the command line or sendcommand. I wondered perhaps it was the plan of the authors to remove the authentication matter entirely from webcit and that's why they didn't add the ldap setup details? Or was it the ldap setup details were on the list to be added to webcit? Anyhow it was beyond my available minutes to puzzle that one through so I just continued in the direction I thought I saw there.
switching authentication modes isn't supported - since you will loose access to the accounts you've created in the other authentication means.
However, loading the contact data probably isn't as permissive.
One idea - sendcommand IGAB should probably do the ldap polling too if used with an ldap enabled setup.. Spidering the ldap for all accounts (and creating them if not there) then would probably also be a good thing to do.
"so at the place where you choose LDAP/AD you would need another mask, defaulted with the two strings?
And, what about editing it? should webcit expose this to the user?"
I suppose if it is the intention of the authors to make webcit able to do everything authentication related the command line / sendcommand is capable of doing, you'd want the current "access" tab on webcit to allow gui entry of the basedn, binddn, and a drop-down box offering the current choices with an added one "LDAP (custom search)". When the "custom search" is chosen then a text box that is not user editable beneath the access item would become user editable. For security I'd advise forcing the response to be A-Za-z0-9 and having webcit paste it in (XXXX=%s). Somehow allowing even power-users access to the whole % thing strikes me as an invitation to trouble. I suppose in a perfect world webcit would create a dropdown on the fly composed of all the items in the ldap schema it finds with format compatible with being a user id and not allow the user to have to know in advance but just choose from a list."
yes, you're shurely right. theres no fun to be made with %s.
"On other topics, git master has the draft code for ldaps binding - maybe you could give it a try?"
What a welcome change that would have been for me a year ago. So I needed security as well, and was trying to decide whether to patch citadel to do ldaps or try some other approach. In the end, with storage being so cheap and the content of the ldap database changing so slowly (hence the reason for ldap to exist separately from databases) I decided to set up the citadel system as an ldap replication slave using secure communications between the ldap replication slave and the master ldap systems. In that fashion, a hacker would not be able to tell based on ldap traffic between the mail systems and the ldap servers what's going on on the email system or be able to interfere. Only when there's a change on the ldap server would there be ldap traffic between the ldap systems and the email systems, and that happens so infrequently it's much easier to detect security shenanigans than lookups every email transit. Meanwhile all the ldap lookups for email purposes would be local socket calls, never hitting the net.
In direct answer to your question, perhaps a bit shame-facedly, so... err... I really have never pulled a development system fresh from the source, compiled and ran it. I've always used the 'apt-get source' and dpkg-build... tools to keep the systems tidy. Using debian/ubuntu what's the best practice to keep systems from colliding to get and compile and 'psuedo-real-world install' these sandbox ideas? Set up a VM I suppose then... well, I need a clue.
Harry
You can ./bootstrap and then use dpkg-buildpackage from git too, see http://www.citadel.org/dokuphp/installation:debian for details.
LDAPS/Certificates - yes.
A feature complete ssl client would be able to do like that; a first start would however be to have a working encryption at all.
