I just sat in on the excellent "Securing Domino Web Server" open-mic hosted by IBM. Go watch the replay when it is available, easily worth 60 minutes of your life. This showed how to "harden" a Domino web server and they think handled all the points well, with one exception (and I don't think is the fault of the presenters, but more a serious Domino issue). The user side of the equation. The people with the shitty passwords like "1234" and "password".

It is no secret the users and their organizations wish to rid themselves of the Notes ID. Hell, even IBM are developing everything these days on Websphere. For some organizations this means utilizing Domino as web server, as Traveler server or as an LDAP repository for authentication to WAS based or other applications. These all have a common thread, they use the Internet Password from a Domino Person Document. So my final question on the open-mic revolves around an organization that either does not use Notes ID files (let's say for iNotes, Quickr or Connections access) or a customer using Notes Shared Login (new in 8.0 or 8.5 I don't recall). These two types of organizations have two things in common......

Their users never change the Notes ID password. Ever. Never. Never, never, never.

So, if I don't have nor have ever changed my Notes ID password how can I force them to change their HTTP passwords (yes, I can do this via a policy if they change their Notes ID password, but this is not that scenario). The same HTTP password that is used to access Traveler, iNotes, Quickr, Connections, basically everything ICS makes these days? Bottom line, you can't. This is a pretty serious issue that I have brought up several times now only to be told you can do it by policies (with an ID file and not using NSL, yes you can, otherwise you cannot) or use certificates (how does that work well unless I only ever use one PC all the time?). So here is the policy setting document screen shot:

Image:Want to know the Achillies Heel of Domino Security? It’s internet passwords and the lack admin control over them

This seems to indicate that you need a Notes ID. Swing and a miss for just forcing an Internet Password change and that, in my opinion is a really bad design flaw in Domino. I just can't, in any practicable manner, force an Internet password change policy and/or an Internet password complexity policy without tying it back to an actual ID file that forces a user to enter a password.

Why not? This is not 1994 folks. Or am I missing something? And this exists already? I'm looking forward to eating crow on this post. So what am I missing?
Darren Duke   |   April 10 2013 11:10:07 AM   |    domino    |  
  |   Next Document   |   Previous Document

Discussion for this entry is now closed.

Comments (4)

Gravatar Image
1 - David Schaffer    http://about.me/davidschaffer    04/10/2013 12:18:47 PM

We've also found that the security setting "Update Internet Password when Notes Client Password Changes" is usually ignored if the password change is made from a Mac client; works from the Windows client.

Gravatar Image
2 - Chris Whisonant    http://cwhisonant.blogspot.com    04/10/2013 12:39:53 PM

If you set that value to Internet only, then it WILL force you to change your http password and it will honor the settings for quality, etc... However, that doesn't extend over into other ICS software such as Connections.

Although if you use Domino LDAP and would like this security option to work for your solutions, you could do a little engineering to send logins through a Domino Web Server frontend that would enforce this.

Gravatar Image
3 - Gregg Eldred    http://geldred.com/    04/10/2013 12:49:58 PM

Well, you could look at a 3rd party solution, like PistolStar:

{ http://pistolstar.com/password-plugin-products/password-power-8.html }

I believe that most/all of their developers came over from Lotus and Iris, which is pretty funny considering that they plug holes in the internet password issues of native Domino.

Gravatar Image
4 - Mark       04/10/2013 1:17:58 PM

On the web application side of things where Policies and Notes IDs are irrelavant, we hoped to write our own application security and use @PasswordQuality... only to find that it doesn't work through HTTP (and does say it should work) :-( I think the PMR was recycled into toilet paper long ago. There were further issues with Policies anyway so it would have been pointless attempting them. Time for a different platform we've decided.