: 4582 | 108646 | 12353

Give Groups in the Domino Directory their own ACL's 
Use this IdeaSpace to post ideas about Domino Administrator.

: 67
: 75
: 8
: Domino Administrator / Directory
: acl, nab, group, directory
: John Roling579 27 Dec 2007
: / Email
I would like to see a simple ACL placed on group documents in the NAB.  You put who can use those groups in the ACL and then only THOSE people can send to the groups in question.  Also, those people are the only ones that could actually see them in the Send To: dialog.
Right now too many people send email to the All Company email lists and there should be an easy way to limit that.

1) Joe Puglisi632 (27 Dec 2007)
I like the idea of restricting access to groups. Maybe the default could be * or everyone but then you are able to explicitly allow or deny like a server document. Not sure about an actual ACL but a few extra fields on the group document itself would be nice.
2) Chris Whisonant2445 (27 Dec 2007)
This can already be accomplished. And it works with any document. Open the document properties, then go to the Security tab (it's the key). Uncheck "All Readers and Above" and then select from the list who can see it and/or add people/groups from the address book.

This will effectively prevent people from seeing the groups to be able to email to them. And if they do figure out the right name, the email will bounce back because they don't have access to it.

ps - make sure that the server(s) and admins are listed to have access to it.
3) John Roling579 (27 Dec 2007)
@Chris, I know that this can be done but it's not exactly user friendly. I really think there should be a tab or a couple of fields outlining this in a far simpler fashion.

Maybe even allow a certain role in the NAB the ability to make these changes...

Having to go to Doc Properties to do this is more of a pain and not at all obvious to new administrators.
4) Bruce Elgort8298 (27 Dec 2007)
Promoted - great Idea JR.
5) Dan Sickles1710 (28 Dec 2007)
I like the idea of surfacing this as a feature. In my experience, the standard doc level ACL has caused all kinds of problems, even if it is occasionally a good solution for something.
6) Chris Whisonant2445 (28 Dec 2007)
@John - "user friendly"? Who lets users modify groups? ;)

Until IBM does something about this, you could also throw a readers field on the document. That would be more user friendly than "having to go to [ACL Window] to do this".

And when I was a new administrator, this was one of the first things I did.

@4 - I didn't say it was a bad idea - just that it's already possible.
7) Bruce Elgort8298 (28 Dec 2007)
@Chris - don't be so defensive as you are my Domino Idol. Really...
8) Chris Whisonant2445 (28 Dec 2007)
@Bruce, not being defensive at all. Hope I'm not taken that way by anyone. :)
9) Tom McArthur1022 (28 Dec 2007)
Editing the document-level ACL isn't a complete solution. Although users can't see the restricted group in the address dialog, they can still use it via type-ahead, and they can still reply to the group. An R5 server will even deliver the message, but an R6 (or higher) server generates a poorly-worded delivery failure.

Because of the above limitations of document-level ACLs, I had to implement those restrictions by customizing our mail templates.

It would be nice to be able to "properly" restrict groups using built-in functions. It would also be nice if the send attempt was stopped immediately with a pop-up that says something about "group XYZ has been restricted by the admins".

10) Peter Presnell26659 (29 Dec 2007)
I agree with Chris. Existing reader and author fields should be more than enough and would probably be just as "User Friendly" as trying to impose some form of ACL on the group.
11) John Roling579 (29 Dec 2007)
Okay, I don't think you guys are quite getting what I mean.

Right now, there is no way in a group document to lock it down to not be seen or sent to unless you A. Go into the document properties and set readers or B. Customize the NAB to add reader fields.

I'm proposing adding the ability inherent into a Group document so you can restrict who can see and/or send to a group. And maybe even (as some have suggested) add nice error messages for people trying to send to a group that aren't authorized to do so.

I called this an "ACL" in the sense that we are controlling access to the group. Not that it would look exactly like a database ACL.


12) Luis Guirigay262 (29 Dec 2007)
A user can create a Group and add everybody in the Domino Directory using the Personal Address Book.

Now, if behind this idea is that you don't want mass emails, just go an create a Server Rule:

No messages to more than 50 recipients. Allowed just if you are HR User.

This is a basic example.

13) Ron kamstra21 (04 Jan 2008)
I agree with this idea and want to extend this to a acl for folders and maybe views.
14) Stephen Bailey1819 (08 Jan 2008)
Sorry to extol the virtues of Exchange in this Forum but... it has been possible to enforce who can email a group since Exchange 97, maybe before! Surely this can't be such a complicated request.

It should be clearly visible in the group document: "Senders to this group", with users, a group, or an OU set there. A simple idea, but how to do it?

Using document properties is not an option to me to resolve this question. Users should be able to clearly see who can email a group.

Agreed with the points above about type-ahead, and a server rule can cause false positives, and give us admins more headaches.

Sorry to be posing comments and not answers, but I just wanted to say something - this feature is one of the common user complaints from Exchange users who join a Notes house!
15) John Tincher10 (22 Jan 2008)
Making the existing features more visible would be great. This is especially true for an inherited environment. The new admin may not know which groups are hidden from all users but visible to the servers and select users.
16) Tripp Black622 (26 Jan 2008)
What we've done since R5 was add to the $PersonSchema and $GroupSchema subforms (which supposedly will be arround "forever" for LDAP schema extension) an additional readers field (and authors so on same tab instead of adding to admin tab).
It works VERY well and we simply upgrade from version to version of Domino without having to add anything. I literally is a 15 minute thing to customize your subform in you Directory and then write an agent to populate all groups and person docs with whatever is the "most case".
One other thing, once you use this, you may want to set the INI for the router to still deliver mail if typed blind.
17) Steve Whitehouse46 (28 Feb 2008)
@Stephen - Absolutely correct... Amazing how as a Notes admin my team have been getting "beaten up" by our new Notes users (former Outlook/Exchange users). Seems to me that a directory "object" should have ACLs assignable in a straight forward manner out of the box.
18) Stephen Bailey1819 (12 Feb 2009)
@Steve - thanks for your comment.

@Chris - what you propose simply doesn't work. When a user performs an address lookup, the server's access to the Domino Directory is used, NOT the user's.

Consequently, if the user knows the first few characters of the name of the group, they will be able to send mail to it.

Try to demo your proposal to a half-experienced CIO who gets bugged by complaints about people sending rubbish to all users via email, and you will end up feeling rather embarrassed.

This is a real requirement by real users, rather than many of the other ideas on this site which are "nice to haves" in my humble opinion. C'mon guys, get promoting!
19) Christopher Boote6132 (11 Aug 2009)
This can be achieved with Reader fields - albeit in a rather clunky fashion - so, sorry, I'm demoting it
20) Vincent Pihouee433 (29 Mar 2010)
Document Readers properties can be a solution, but if you are using a dircat and synch groups. The hiding group will show in the dircat. Users using the dircat will be able to use the group (Group will be expand), Same for Webmail users.


Welcome to IdeaJam™

You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>

IdeaJam developed by

Elguji Software Logo