Tuesday, March 22, 2011

Breaking into Domino? Have ideas?

The View Admin Conference, June 22-24 Las Vegas.
What you learn in Vegas should NOT stay in Vegas. Share it!

So I have a session I am doing and given I only get about 75 minutes to present, want to focus on what you need.

The basic abstract is below:

Breaking and entering: If you can hack it, so can I
Have you ever tried to break into your own Lotus infrastructure?
Walk through different scenarios and find out how to test the limits of your
infrastructure in order to keep it running properly.
Find out how to make sure a terminated employee is not only removed from your Directory, but you know how to handle their email if it needs to continue to accept inbound mail, how to disable them from Traveler, and how to handle any Quickr sites
they might own.

So what other aspects should I cover?
Over the years of cleaning up environments the most common issues are the admin is gone but their ID is on everything.
Quickr sites/places administration.
Connections ownership?

Mostly focusing on Domino side but open to more depends on my time and how I map this session out.

So ever wonder about what to do when firing people? Or try to get into your own nab but without proper access?

This is not how to bullet proof your server for security, although some aspects will be hit on, this is more about the practicality of a day to day admins role.

Thank you in advance.


  1. Pff, the obvious ones. Make sure names.nsf and catalog.nsf aren't open, enforce acl's on all ports

  2. You wouldn't believe how many domino sites I've gained access to the NAB by appending "names.nsf" to the URL, then when challenged, entering a username of "admin" and a password of "password".

    Since I'm not "known", I always pass the info on to a prominent member of our circle so that he can inform the offending site administrator that the site has "issues".

  3. @tlbriley I do that too all the time, don't always get far but at least I secured another environment that wasn't so some admin didn't get yelled at.

    @d2k yep, the basics are important. I had a great email from someone that had good input too.
    See social media works.

  4. a couple of obvious things.
    a)make sure user ids expire within a reasonable period of time.(2 years for full time employees)
    b) always create a contractor OU and make their IDs expire on a 90 day(or less) cycle.

    2) Enable user tracking, and look at it occasionally. Make note of the users who never login or who haven't logged in a long time. Check with HR/user manager and delete those inactive accounts. (bonus: you can which user need training and have avoided using the system)

    3) Use the Domino security policy to ensure password uniqueness.

    4) use the database catalogue and look at which databases have -default- as manager.

  5. Insider threat: sniffing basic authentication and session authentication passwords on internet ports that don't force SSL connections.

  6. Version identification is one I look at. With that you can then identify possible issues to work around / exploit.

    So basic things like telnet to port 25, 80 etc. Hide the typical responses (ie. ESMTP Service (Lotus Domino Release 8.5.2FP1))

  7. Template databases (*.ntf) are also a risk. Too often you find them with a default ACL set to "Desinger". And actually if you allow your users to be "Manager" on any server-database then they can turn it into a template and name it anyway they like, even "StdR85Mail". And when the designer-task runs at night this could cause some trouble ...

  8. Send the user a button which he should click on to open a website. Add a code to the button which will change his mailfile ACL (if he has manager access) and then open the website.

    This works if there is no ECL in place ;-).