One of the simplest and most low-tech but most effective security features in Domino is the deny list. Deny lists are easy to create and maintain, and, in my experience, they work perfectly. Unfortunately, many organizations make poor use of this key security feature. This month's tip presents some ideas for using deny lists efficiently.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As you undoubtedly know, a deny list is a group of names of people who are no longer allowed access to the Domino server. Deny lists are different from other name groups, however, in that they appear in a different area of the Domino Administrator program. In ND6.5, the deny groups are found at People and Groups / Domino Directories / <directory name> / Deny Access Groups. In reality, deny groups are just like any other Domino name group, except the Group Type field is set to "Deny List Only."
The most important item to understand about deny groups is that creating such a group (and putting some names in it) does not block those people from using the server. You have to activate the group by listing it in the Not Access Server field found at Configuration / Server / All Server Documents / <server name> / Security. Only after a deny group is listed here are its members denied access to the specified server.
One mistake some organizations make is using a regular name group as a deny list. This mistake is a holdover from the days when Domino did not contain a special group type for deny lists. If you do this now, however, AdminP will not be able to help you maintain groups correctly. It will try to remove departing employees from any regular groups they appear in, resulting in ex-employees being removed from the deny groups you are trying to add them to! The solution to this problem is simple. If you have any standard groups that you are using as deny lists, just change the Group Type field as shown above. The group will automatically vanish from the Groups view and appear in the Deny Access view.
Vary your deny lists
Another useful tip is to set up different kinds of deny lists. Technically, they are all the same to Domino, but using some standardized conventions will make life easier for administrators. I like to create deny lists named Terminations, Nonactive_Consultants and Mail_Forward_Only. All three are added to the Not Access Server field for all servers.
- Terminations holds employees and contractors who are gone from your organization and probably are not coming back.
- Nonactive_Consultants holds consultants who work for you from time to time, but are not active right now. Typically, these consultants have a valid ID file and a mail database, and are listed in various access groups. When a consultant becomes inactive, you simply add them to this deny list, but make no other changes to their account or permissions. If the consultant returns, you remove their name from Nonactive_Consultants and they are instantly up and running.
- Mail_Forward_Only holds the names of people who are affiliated with your organization, so you want them in your NAB, but they never log onto your servers. Their names exist in the NAB only for the purpose of forwarding mail to an outside mail account. By placing their names in this deny group, mail will still flow to their forwarding address but no one can use the NAB entry to gain access to your servers.
And finally, although this is only tangentially related, I like to keep mail databases for departed employees. When you use AdminP to delete an employee (which you should do), you are given several options. The first is what to do with the user's mail database. I keep it. You can always archive and remove a mail file later. But if you delete it now, you may be throwing away information you need and cannot get back. The other option I like is to let AdminP add the user to the Terminations group. This saves you work and ensures you don't forget to do it later.
As always, I enjoy reader feedback about these tips. If I made a mistake, let me know. If there is a better way to do something, please share it. If there is a topic you want me to address, just speak up!
Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes.
I agree with your point of view -- deny lists are poorly used.
Even if I consider there's a lack on Domino usage and disagree with you on the point, "One of the…most effective security features in Domino is the deny list...They work perfectly," I also recommend usage of them for two reasons.
First of all, closing accounts (access) is AS important as opening new ones and maintaining accounts. If you are using deny lists, this means that you not only have a process when a new user arrives, but also a process when a user leaves your company. This last process does not systematically exist in the international companies I've worked for.
I mentioned a lack on Domino usage, here it is.
Up to R5 (I didn't test it on R6.x), only NRPC access is checked for deny. This means that the user/server ID could be used, but as long as the person document exists in the Directory, or if the server used an external LDAP directory, you CAN use this account for any other protocols, specially HTTP.
So I recommend usage of deny lists with a custom login form that check user is not in a top-level deny access group.
It's not a perfect solution because not all protocols are covered, but it work perfectly, adding a new security level.
-- J. Gassies
I thought I would share a slightly different approach to the "Terminations" group that I have used for deny-access lists. Each year, I create a new deny-access group, so that I will have deny-access groups like:
Because I always recertify users for two years, I do not have to maintain former users perpetually. So if John Doe/Acme left the company in December 2002, I add him to the corresponding deny-access group for 2002. Then, once 2005 comes, I know that everyone who could have possibly been recertified (for two years) in December of 2002 and terminated (including John Doe) would be safe to remove, because the longest their certification would last would be until December of 2004. In January of 2005, I delete the deny group for 2002, create a new deny group for 2005 and make the corresponding adjustments in the security section of the Domino Directory. This model could easily be used in conjunction with the "Nonactive_Consultants" and "Mail_Forward_Only" groups that you mentioned in your security tip.
I likewise keep e-mail databases for departed employees, but typically for one year. When an employee departs, I move his/her e-mail file to a folder/directory that is out of the Domino folder hierarchy. If mail is normally kept in the C:LotusDominoDatamail folder, I might move (not copy) the e-mail file to the C:Old_Mail folder. Once there, Domino doesn't have to maintain it, check it for agents to run and so forth, so server performance is increased. Daily backups are still getting the file backed up. Plus, the date stamp of the e-mail file stays dormant in the C:Old_mail folder. Once a year has passed and no one has needed the data, I delete it. I also use this approach for regular databases that do not seem to have had any use in some time. If someone complains, it is easy to move the data back into the Domino folder hierarchy.
I typically use the OS command prompt to move the databases, but I don't see why it couldn't be done through Windows Explorer or some similar file management GUI. Here are the steps:
- Verify that no one is using the file in question by issuing the "show users" command (without quotes) at the Domino server prompt or via the Administrator.
- From the Domino server's console, flush the cache by typing "dbcache flush" [Enter].
- Move the file (cut and paste) using Windows Explorer or other file manipulation means.
-- Mark B.
I enjoyed your article on the efficient use of deny lists. One thing that I have painfully discovered, though, is that merely putting someone's name in a "deny list" only stops them from accessing the Domino Server from a Notes client. My client had to terminate someone immediately, and they asked me to strip this person's access from Domino. So I put the name in the deny list. This person was still able to get to Notes mail through iNotes Web Access (which actually happened). I had put a ticket into Lotus Support for this and found out that HTTP security works a little differently than Notes security. What I had to do was strip out the person's Internet password in the user doc in the Domino Directory.
Just thought you might want the input for anyone who may had the same misperceptions I had.
-- Bill D.
Beware of depending solely on deny access lists. If the person document is not deleted then you need to clear the Internet password field or that user will still have access via a browser.
-- David H.
Tip for "Mark B" on his termination list usage: You can use nested Deny Access groups.
Have one Deny Access group called "Terminations" and refer to your other groups as members. Then you do not have to change the security settings every year, just the nested list in "Terminations."
-- Steve B
Do you have comments of your own? Let us know.