On 9/2/06, Rob Church <robchur(a)gmail.com> wrote: what can I do with a vanilla 1.7.1 release using Apache? mod_krb? mod_auth_pam? authenticating against a Windows 2003 domain from within a linux Apache might be possible. any configuration howtos? it's just a whish of that one coworker, no policy or anything.

On 9/2/06, Stephen Warren <swarren(a)wwwdotorg.org> wrote: 50% of the password issue is that if you require passwords for editing articles by anyone then you should also put it behind https:// and this would require a properly signed certificate. *sigh* now I remember why I just said let everyone edit damnit. the point is if I do remote password checking than these passwords will be for real user accounts in LDAP/Active Directory and these should not be transferred as is. thanks for the help, I'll have to think about it...

contribute issues Just because you trust your users doesn't mean you should EVER pass username/password combos in the clear. You should always assume there is a hostile on your network waiting for someone with domain admin privileges to pass a username/password in the clear. Using HTTPS is so simple that there is never a reason not to use it to protect credentials. If the user doesn't want to pay for a real cert, he can create his own internal CA, and push out the CA cert to his clients to trust. To be a little more on topic though... Doesn't apache have an NTLM authentication module? I usually shy away from NTLM since I have a diverse network, but if all of the people authenticating will be coming from the same domain (and all of them are windows clients), it would probably be a good idea, and might not require https. V/r, Ryan Lane

We had this discussion where I work and the idea of not being able to trace back the edit to a contact was deemed to be a bad thing since you could not track down who made the edit in order to discuss what they meant by that edit. Talk pages are limited in this respect since not everyone uses them. In our setup we require logins to edit (but anyone can read), allow anyone to setup a login account and require email verification for the account to be established. We were not particularly interested in detering spamming or disgruntled employees. We simply wanted to know which user made an edit so anyone could contact them about the edit using the "Email this user" link in the toolbox. Since we use our wiki for collaboration the idea of an anonymous editor makes little sense since it is difficult to collaborate with those you cannot contact and do not know. We were worried about the effort people would go through to create an account but we found no one was detered. It's a one-time effort and we found that if people really wanted to contribute, the effort was not an obstacle. Hope this experience helps... -Jim -----Original Message----- From: Andy Roberts [mailto:aroberts@gmail.com] Sent: Wednesday, September 06, 2006 9:22 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] to require login or not On 02/09/06, gmu 2k6 <gmu2006(a)gmail.com> wrote: _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

I forgot to mention our web services are firewalled so no one outside the organization can see the content. So we allow "everyone" to read, meaning everyone at our organization. You are right that if we were open to the world reading would be a different matter and probably require login or other authentication. Wikis are scary things and if you don't think there can be security problems on an open system just visit the George W. Bush page on Wikipedia. Our firewall shrinks our world to just the right size and logins-to-edit makes the content even more secure. -Jim -----Original Message----- From: David Pace [mailto:gps.david.pace@gmail.com] Sent: Wednesday, September 06, 2006 3:20 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] to require login or not In the environment I use Mediawiki in, security is a very important concern, so naturally we require login to edit or even view wiki pages. I'm not sure what your particular business entails no what the exact purpose of your depolyment is, but if you have proprietary corporate data on there you should at the very least be requiring logins to edit if not view the content. If you are a public corporation, I would urge this even more strongly. Liability for the loss or leaking of proprietary corporate information is a serious matter and one which shareholders should take very seriously. In order to best mitigate the risk and protect the company and yourself from potential shareholder legal action, you shoudl take every security measure you can and document it all. I understand you want to ensure there are few barriers to entry, but there are options like LDAP authentication available and frankly requiring users to sign up isn't that big a deal. Get managment behind it and give the users a reason to use the wiki and they will, period. Regards, Dave Pace On 9/6/06, Sullivan, James (NIH/CIT) [C] <sullivan(a)mail.nih.gov> wrote: _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

One additional security step I've taken is to limit access to our dept. Wiki to only computers in our department thru the httpd.conf file for Apache. That gives you the option of leaving pages readable w/o passwords and still limiting who will be able to see them. The section in httpd.conf looks like this: # Controls who can get stuff from this server. # Order Allow,Deny Allow from ComputerName1.domain.com Allow from ComputerName2.domain.com Allow from ComputerName3.domain.com Allow from ComputerName4.domain.com Computers not explicitly allowed get a Access Denied message. It works well for small departments, with # of computers < 20. I'm sure there are other ways to limit access as well, such as firewalling and only allowing a certain subnet range.. BTW, I too prefer logging in to edit for tracking and to have a contact to talk to if there's incorrect data/info etc... Good luck, Joe S. -----Original Message----- From: David Pace [mailto:gps.david.pace@gmail.com] Sent: Wednesday, September 06, 2006 4:58 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] to require login or not My corporate wiki is constrained to the corporate intranet as well and regardless we require login. external threat (depending upon the integrity of your intranet), but internal threats are not only possible they are likely. Do not underestimate the threat from someone inside your organization. Again, I don't know what it is you do or how your company is set up, but competitive intelligence is big business. There is also the potential of disgruntled or simply foolhardy employees causing damage to the integrity of your data and the consequences can be disasterous. I understand there are rollback functions and whatnot and certainly that is an excellent way to maintain data, however this can be compromised with intent or through circumstance. Also be sure to never overestimate the integrity of your intranet. I would suggest the threat from that axis is very low, but it it remains something you need to consider when conducting risk analyses. Giving everyone the ability to read everything sounds great, but there are pitfalls and many of them lead to serious issues of legal liability. I'm not sure what industry you are in, but if you are at all regulated, you need to take every measure to mitigate risk and secure your data. If you are incorporated, you also risk exposure to "due dilligence" litigation from your shareholders if they perceive undue risk or if proprietary data is leaked (regardless of how it was leaked). Running a wiki in a corporate environment is a very different animal and the free and open philosophy of wiki's does not lend itself well to a regulated business application. There are steps you can take to reasonably mitigate yoru risk and my advice is that you take as many as you feel you can without totally compromising the benefit of the application or the user experience. It's a bit of a tightrope walk I guess. Regards, Dave Pace On 9/6/06, Sullivan, James (NIH/CIT) [C] &lt;sullivan(a)mail.nih.gov&gt; wrote: This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you.