[389-users] General LDAP security

[John A. Sullivan III]

On Tue, 2009-06-16 at 20:13 +0100, Chris Phillips wrote:
> http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html
> 
> On Tue, Jun 16, 2009 at 7:29 PM, John A. Sullivan III
> <jsullivan at opensourcedevel.com> wrote:
>         In briefest summary, we create a separate user who has rights
>         to see but
>         not change the commonly needed fields for as much of the DIT
>         as is
>         needed for the various servers, e.g., some may need to see the
>         entire
>         tree whereas other may only need a small subset.  The ACI's
>         are in that
>         large post.  We then use this user as the binddn in
>         ldap.conf.  We never
>         use cn=Directory Manager and always remove anonymous
>         browsing.  In fact,
>         we also change the cn for both Directory Manager and the admin
>         user just
>         to further obscure the setup.  Hope this helps - John
> 
> John, (and anyone else of course...)
> 
> I read your mail that you referred to...
> http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html
> and don't really see an answer to the question, or more honestly, the
> very similar question I was about to ask before I saw this. 
> 
> That was how to have a full administrative user that is not Directory
> Manager. I'm working in a very high profile confidential project and
> to our shame are still using this account for pretty much everything
> of note (despite my protestations from day 1, I assure you!!)
> including the IDM console which is our main tool for managing data in
> it. I've tried to work out the most formal and effective way to make
> my own normal user account able to do whatever Directory Manager can
> do with the console but without luck. I expect it's an awful lot
> simpler than I think it is. In line with doing it "right" there's a
> Directory Administrators (or nearly that) group which I tried adding
> users to but no change was seen, and I'd think there's a difference
> between the access within the main directory and the Admin server
> config in o=NetscapeRoot. Is there an ACI that already exists and
> such?
> 
> Also looking at your notes, it seems there may be better ways to
> manage a single directory (2 multimasters and 6 replicas) like
> bypassing the initial Admin section and going straight to the
> directory itself?
> 
> Also if I do make my user account able to log in, would I then be
> faced with putting in the entire DN every single time? can I alias it
> etc..? Ideally I'd not want a dedicated account, unless there's some
> real logic in not using the account - something I can imagine...
> 
> Any pointers, especially those which are simple, elegant and
> non-invasive, would be *very* much appreciated.
<snip>
Hi, Chris.  I suppose the first thing I should point out is that I am by
no means any kind of expert whatsoever in any way shape or form (not
sure if I can say that more emphatically:-)  ).  Someone like Rich
Megginson will know much more than I.  I've only learned enough to do
what I have to do on my project which is still awaiting funding to hire
an LDAP engineer.  Before this, I hadn't touched Directory Services
since NetWare 4.x!

There are a couple of options.  I've not explored the difference between
Directory Manager and
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot (or
whatever the uid is, we've changed ours from the default proposed during
installation).  Even so, we do not use this user either for most of our
functions (although our administrators are still logging in using
Directory Manager in idm-console for administration).

The magic, as you intimate, is the ACI.  We created our own since we are
a multi-tenant environment.  Our admins do use Directory Manager
(renamed) to oversee the entire tree but each of our clients have their
own designated administrator for their part of the tree.  We also break
our tree into Internal and External sections (because of uniqueness
requirements, e.g., all uids and cn must be unique across the clients in
our environment but not for their address books of their external
clients).  I believe the ACIs we use to do this are:

(targetattr = "*") (target = "ldap:///($dn),o=internal,dc=mycompany,
dc=com") (version 3.0;acl "Client Administrators Internal";allow
(all)(groupdn =
"ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");)

(targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany,
dc=com") (version 3.0;acl "Client Administrators External";allow
(all)(groupdn =
"ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");)

We are having a problem in the last line.  It does not look like DS
likes wildcards in groupdn definitions (although I think they are OK in
userdn) which we need because of our uniqueness constraints.  We haven't
had time to fix this but have been testing with something like this
where we use the same named group in different contexts in a section of
the tree which is not uniqueness constrained:

(targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany,
dc=com") (version 3.0;acl "Test Client Administrators External";allow
(all)(groupdn =
"ldap:///cn=ldapadmins,[$dn],o=SysAccounts,dc=mycompany,dc=com");)

I would think it would be trivial to adapt this to have a user oversee
then entire tree.  The trick for us was the variables to have one ACI
(or two) for hopefully hundreds of clients.

I may be missing your point as I'm honestly flying through this email on
my way to building our PBX (until we hire our PBX engineer - ah the
grief of delayed funding!) but hope this helps - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society