Error after setting nsslapd-allow-anonymous-access:rootdse

[Patrick Landry]

This is a fresh install on RHEL 7. 

389-adminutil-1.1.21-2.el7.x86_64 
389-admin-console-doc-1.1.12-1.el7.noarch 
389-admin-console-1.1.12-1.el7.noarch 
389-ds-base-libs-1.3.6.1-16.el7.x86_64 
389-ds-console-1.2.16-1.el7.noarch 
389-ds-1.2.2-6.el7.noarch 
389-ds-base-1.3.6.1-16.el7.x86_64 
389-ds-console-doc-1.2.16-1.el7.noarch 
389-admin-1.1.46-1.el7.x86_64 
389-console-1.1.18-1.el7.noarch 
389-dsgw-1.1.11-5.el7.x86_64 

Installation went fine and I was able to secure the directory server and 
admin server with certificates and restrict access to secure connections 
only. 

But after I changed nsslapd-allow-anonymous-access:rootdse to prevent 
anonymous binds the admin server now complains at startup: 

[Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389
Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for
LDAPConnection [SERVER:636] 

I am still able to use the console and the error doesn't seem to affect operation. 

If I set nsslapd-allow-anonymous-access:on the error goes away. 

If I set nsslapd-allow-anonymous-access:off I get additional errors (which would be
expected): 

[Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024] Could not bind
as []: ldap error 48: Inappropriate authentication 
[Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024] Unable to bind as
LocalAdmin to populate LocalAdmin tasks into cache. 


I did find an old issue in Pagure 

https://pagure.io/389-ds-base/issue/47850 

which was for a different issue related to setting nsslapd-allow-anonymous-access:rootdse

In that issue Mark mentions adding a separate user entry to be used to search
o=netscaperoot 
but I can't find any other references to this solution (and don't know if it would
solve this issue). 

-- 


	

Patrick Landry 
Director, UCSS 
University of Louisiana at Lafayette 
pml(a)louisiana.edu

[Patrick Landry]

OK. I guess no one has run into this one. 

Can anyone tell me what the impact of the admin server not being able to search the
specified DIT is? 
Is this something to worry about or something which can be ignored? 

[Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389
Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for
LDAPConnection [SERVER:636] 

----- Original Message -----

>  From: "Patrick Landry"
> <patrick.landry(a)louisiana.edu&gt;
>  To: 389-users(a)lists.fedoraproject.org
>  Sent: Saturday, September 2, 2017 4:40:27 PM
>  Subject: [389-users] Error after setting
>  nsslapd-allow-anonymous-access:rootdse 
>  This is a fresh install on RHEL 7. 
>  389-adminutil-1.1.21-2.el7.x86_64
>  389-admin-console-doc-1.1.12-1.el7.noarch
>  389-admin-console-1.1.12-1.el7.noarch
>  389-ds-base-libs-1.3.6.1-16.el7.x86_64
>  389-ds-console-1.2.16-1.el7.noarch
>  389-ds-1.2.2-6.el7.noarch
>  389-ds-base-1.3.6.1-16.el7.x86_64
>  389-ds-console-doc-1.2.16-1.el7.noarch
>  389-admin-1.1.46-1.el7.x86_64
>  389-console-1.1.18-1.el7.noarch
>  389-dsgw-1.1.11-5.el7.x86_64 
>  Installation went fine and I was able to secure the directory server
> and
>  admin server with certificates and restrict access to secure connections
>  only. 
>  But after I changed nsslapd-allow-anonymous-access:rootdse to
> prevent
>  anonymous binds the admin server now complains at startup: 
>  [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid
> 139788241741952]
>  populate_tasks_from_server(): Unable to search
>  [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
>  Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636] 
>  I am still able to use the console and the error doesn't seem to
> affect
>  operation. 
>  If I set nsslapd-allow-anonymous-access:on the error goes away.
>  If I set nsslapd-allow-anonymous-access:off I get additional errors
> (which
>  would be expected): 
>  [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid
> 139706415569024]
>  Could not bind as []: ldap error 48: Inappropriate authentication
>  [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024]
>  Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache. 
>  I did find an old issue in Pagure 
>  https://pagure.io/389-ds-base/issue/47850 
>  which was for a different issue related to setting
>  nsslapd-allow-anonymous-access:rootdse
>  In that issue Mark mentions adding a separate user entry to be used to search
>  o=netscaperoot
>  but I can't find any other references to this solution (and don't know if it
>  would solve this issue). 
>  -- 
>   
>  Patrick Landry
>  Director, UCSS
>  University of Louisiana at Lafayette
>  pml(a)louisiana.edu 
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 
-- 

	

Patrick Landry 
Director, UCSS 
University of Louisiana at Lafayette 
pml(a)louisiana.edu

[William Brown]

On Thu, 2017-09-07 at 11:28 -0500, Patrick Landry wrote:
>  OK. I guess no one has run into this one. 
>  
>  Can anyone tell me what the impact of the admin server not being able to search the
> specified DIT is? 
>  Is this something to worry about or something which can be ignored? 
>  
>  [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
> populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389
> Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for
> LDAPConnection [SERVER:636] 
>   
I would think that you just can't edit entries in that DIT if you can't
access it. 

TBH I would advise against using the admin server anyway, but that's
just me.


>  ----- Original Message -----
>  
>  > From: "Patrick Landry" <patrick.landry(a)louisiana.edu&gt;
>  > To: 389-users(a)lists.fedoraproject.org
>  > Sent: Saturday, September 2, 2017 4:40:27 PM
>  > Subject: [389-users] Error after setting
>  > nsslapd-allow-anonymous-access:rootdse
>  
>  > This is a fresh install on RHEL 7.
>  
>  > 389-adminutil-1.1.21-2.el7.x86_64
>  > 389-admin-console-doc-1.1.12-1.el7.noarch
>  > 389-admin-console-1.1.12-1.el7.noarch
>  > 389-ds-base-libs-1.3.6.1-16.el7.x86_64
>  > 389-ds-console-1.2.16-1.el7.noarch
>  > 389-ds-1.2.2-6.el7.noarch
>  > 389-ds-base-1.3.6.1-16.el7.x86_64
>  > 389-ds-console-doc-1.2.16-1.el7.noarch
>  > 389-admin-1.1.46-1.el7.x86_64
>  > 389-console-1.1.18-1.el7.noarch
>  > 389-dsgw-1.1.11-5.el7.x86_64
>  
>  > Installation went fine and I was able to secure the directory server and
>  > admin server with certificates and restrict access to secure connections
>  > only.
>  
>  > But after I changed nsslapd-allow-anonymous-access:rootdse to prevent
>  > anonymous binds the admin server now complains at startup:
>  
>  > [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
>  > populate_tasks_from_server(): Unable to search
>  > [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
>  > Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636]
>  
>  > I am still able to use the console and the error doesn't seem to affect
>  > operation.
>  
>  > If I set nsslapd-allow-anonymous-access:on the error goes away.
>  
>  > If I set nsslapd-allow-anonymous-access:off I get additional errors (which
>  > would be expected):
>  
>  > [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024]
>  > Could not bind as []: ldap error 48: Inappropriate authentication
>  > [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024]
>  > Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache.
>  
>  > I did find an old issue in Pagure
>  
>  > https://pagure.io/389-ds-base/issue/47850
>  
>  > which was for a different issue related to setting
>  > nsslapd-allow-anonymous-access:rootdse
>  > In that issue Mark mentions adding a separate user entry to be used to search
>  > o=netscaperoot
>  > but I can't find any other references to this solution (and don't know if
> it
>  > would solve this issue).
>  
>  > --
>  
>  > 
>  
>  > Patrick Landry
>  > Director, UCSS
>  > University of Louisiana at Lafayette
>  > pml(a)louisiana.edu
>  
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Morgan Jones]

Patrick,

I have no experience using the admin console for access control or your particular problem
but I can share what we did that I think accomplishes your goal as we similarly decided to
block anonymous access.  To oversimplify we modified the stock acis with an explicit list
of what users could see/do to themselves and defined a series of groups that could
read/write to various attributes.  Here’s a stripped down example.  I’m happy to discuss
further or share more details if this doesn’t make sense.

Disclaimer: we developed this years ago on a much older version of centos (redhat)
directory but I imagine it will work in the latest 389.  We’re working on upgrading now.

dn: dc=domain,dc=org
changetype: modify
replace: aci
#
aci: (target = "ldap:///ou=employees,dc=domain,dc=org")
 (targetattr = "userpassword")
 (version 3.0; acl "limited user self write";
 allow (write) userdn = "ldap:///self";)
#
aci: (target = "ldap:///dc=domain,dc=org" )
 (targetattr = “attr1 || attr2”)
 (version 3.0; acl "self read"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self")
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org" )
 (targetfilter =
"(|(objectclass=objectclass1)(objectclass=objectclass2)(objectclass=domain)

(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))")
 (targetattr = “attr1 || attr2 || attr3")
 (version 3.0; acl "general access, replaces anonymous access"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self") or 
 (groupdn = "ldap:///cn=group1,ou=groups,dc=domain,dc=org") or
 (groupdn = "ldap:///cn=group2,ou=groups,dc=domain,dc=org")
;)

-morgan


>  On Sep 7, 2017, at 8:55 PM, William Brown <wibrown(a)redhat.com&gt;
> wrote:
>  
>  On Thu, 2017-09-07 at 11:28 -0500, Patrick Landry wrote:
> > OK. I guess no one has run into this one. 
> > 
> > Can anyone tell me what the impact of the admin server not being able to search the
> specified DIT is? 
> > Is this something to worry about or something which can be ignored? 
> > 
> > [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
> populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389
> Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for
> LDAPConnection [SERVER:636] 
> > 
>  
>  I would think that you just can't edit entries in that DIT if you can't
>  access it. 
>  
>  TBH I would advise against using the admin server anyway, but that's
>  just me.
>  
>  
> > ----- Original Message -----
> > 
> >> From: "Patrick Landry" <patrick.landry(a)louisiana.edu&gt;
> >> To: 389-users(a)lists.fedoraproject.org
> >> Sent: Saturday, September 2, 2017 4:40:27 PM
> >> Subject: [389-users] Error after setting
> >> nsslapd-allow-anonymous-access:rootdse
> > 
> >> This is a fresh install on RHEL 7.
> > 
> >> 389-adminutil-1.1.21-2.el7.x86_64
> >> 389-admin-console-doc-1.1.12-1.el7.noarch
> >> 389-admin-console-1.1.12-1.el7.noarch
> >> 389-ds-base-libs-1.3.6.1-16.el7.x86_64
> >> 389-ds-console-1.2.16-1.el7.noarch
> >> 389-ds-1.2.2-6.el7.noarch
> >> 389-ds-base-1.3.6.1-16.el7.x86_64
> >> 389-ds-console-doc-1.2.16-1.el7.noarch
> >> 389-admin-1.1.46-1.el7.x86_64
> >> 389-console-1.1.18-1.el7.noarch
> >> 389-dsgw-1.1.11-5.el7.x86_64
> > 
> >> Installation went fine and I was able to secure the directory server and
> >> admin server with certificates and restrict access to secure connections
> >> only.
> > 
> >> But after I changed nsslapd-allow-anonymous-access:rootdse to prevent
> >> anonymous binds the admin server now complains at startup:
> > 
> >> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
> >> populate_tasks_from_server(): Unable to search
> >> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
> >> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636]
> > 
> >> I am still able to use the console and the error doesn't seem to affect
> >> operation.
> > 
> >> If I set nsslapd-allow-anonymous-access:on the error goes away.
> > 
> >> If I set nsslapd-allow-anonymous-access:off I get additional errors (which
> >> would be expected):
> > 
> >> [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024]
> >> Could not bind as []: ldap error 48: Inappropriate authentication
> >> [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024]
> >> Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache.
> > 
> >> I did find an old issue in Pagure
> > 
> >> https://pagure.io/389-ds-base/issue/47850
> > 
> >> which was for a different issue related to setting
> >> nsslapd-allow-anonymous-access:rootdse
> >> In that issue Mark mentions adding a separate user entry to be used to search
> >> o=netscaperoot
> >> but I can't find any other references to this solution (and don't know if
> it
> >> would solve this issue).
> > 
> >> --
> > 
> >> 
> > 
> >> Patrick Landry
> >> Director, UCSS
> >> University of Louisiana at Lafayette
> >> pml(a)louisiana.edu
> > 
> >> _______________________________________________
> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> > 
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  
>  -- 
>  Sincerely,
>  
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Patrick Landry]

Thanks Morgan. I will take a look at those ACIs. 

----- Original Message -----

>  From: "Morgan Jones" <morgan(a)morganjones.org&gt;
>  To: "General discussion list for the 389 Directory server project."
>  <389-users(a)lists.fedoraproject.org&gt;
>  Sent: Friday, September 15, 2017 3:11:02 PM
>  Subject: [389-users] Re: Error after setting
>  nsslapd-allow-anonymous-access:rootdse 
>  Patrick, 
>  I have no experience using the admin console for access control or
> your
>  particular problem but I can share what we did that I think accomplishes
>  your goal as we similarly decided to block anonymous access. To oversimplify
>  we modified the stock acis with an explicit list of what users could see/do
>  to themselves and defined a series of groups that could read/write to
>  various attributes. Here’s a stripped down example. I’m happy to discuss
>  further or share more details if this doesn’t make sense. 
>  Disclaimer: we developed this years ago on a much older version of
> centos
>  (redhat) directory but I imagine it will work in the latest 389. We’re
>  working on upgrading now. 
>  dn: dc=domain,dc=org
>  changetype: modify
>  replace: aci
>  #
>  aci: (target = "ldap:///ou=employees,dc=domain,dc=org")
>  (targetattr = "userpassword")
>  (version 3.0; acl "limited user self write";
>  allow (write) userdn = "ldap:///self";)
>  #
>  aci: (target = "ldap:///dc=domain,dc=org" )
>  (targetattr = “attr1 || attr2”)
>  (version 3.0; acl "self read";
>  allow (read, search, compare)
>  (userdn = "ldap:///self")
>  ;)
>  #
>  aci: (target = "ldap:///dc=domain,dc=org" )
>  (targetfilter =
>  "(|(objectclass=objectclass1)(objectclass=objectclass2)(objectclass=domain)
>
> (objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))")
>  (targetattr = “attr1 || attr2 || attr3")
>  (version 3.0; acl "general access, replaces anonymous access";
>  allow (read, search, compare)
>  (userdn = "ldap:///self") or
>  (groupdn = "ldap:///cn=group1,ou=groups,dc=domain,dc=org") or
>  (groupdn = "ldap:///cn=group2,ou=groups,dc=domain,dc=org")
>  ;) 
>  -morgan 
>  > On Sep 7, 2017, at 8:55 PM, William Brown
> <wibrown(a)redhat.com&gt; wrote:
>  >
>  > On Thu, 2017-09-07 at 11:28 -0500, Patrick Landry wrote:
>  >> OK. I guess no one has run into this one.
>  >>
>  >> Can anyone tell me what the impact of the admin server not being able to
>  >> search the specified DIT is?
>  >> Is this something to worry about or something which can be ignored?
>  >>
>  >> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
>  >> populate_tasks_from_server(): Unable to search
>  >> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
>  >> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636]
>  >>
>  >
>  > I would think that you just can't edit entries in that DIT if you can't
>  > access it.
>  >
>  > TBH I would advise against using the admin server anyway, but that's
>  > just me.
>  >
>  >
>  >> ----- Original Message -----
>  >>
>  >>> From: "Patrick Landry" <patrick.landry(a)louisiana.edu&gt;
>  >>> To: 389-users(a)lists.fedoraproject.org
>  >>> Sent: Saturday, September 2, 2017 4:40:27 PM
>  >>> Subject: [389-users] Error after setting
>  >>> nsslapd-allow-anonymous-access:rootdse
>  >>
>  >>> This is a fresh install on RHEL 7.
>  >>
>  >>> 389-adminutil-1.1.21-2.el7.x86_64
>  >>> 389-admin-console-doc-1.1.12-1.el7.noarch
>  >>> 389-admin-console-1.1.12-1.el7.noarch
>  >>> 389-ds-base-libs-1.3.6.1-16.el7.x86_64
>  >>> 389-ds-console-1.2.16-1.el7.noarch
>  >>> 389-ds-1.2.2-6.el7.noarch
>  >>> 389-ds-base-1.3.6.1-16.el7.x86_64
>  >>> 389-ds-console-doc-1.2.16-1.el7.noarch
>  >>> 389-admin-1.1.46-1.el7.x86_64
>  >>> 389-console-1.1.18-1.el7.noarch
>  >>> 389-dsgw-1.1.11-5.el7.x86_64
>  >>
>  >>> Installation went fine and I was able to secure the directory server and
>  >>> admin server with certificates and restrict access to secure connections
>  >>> only.
>  >>
>  >>> But after I changed nsslapd-allow-anonymous-access:rootdse to prevent
>  >>> anonymous binds the admin server now complains at startup:
>  >>
>  >>> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
>  >>> populate_tasks_from_server(): Unable to search
>  >>> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
>  >>> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636]
>  >>
>  >>> I am still able to use the console and the error doesn't seem to affect
>  >>> operation.
>  >>
>  >>> If I set nsslapd-allow-anonymous-access:on the error goes away.
>  >>
>  >>> If I set nsslapd-allow-anonymous-access:off I get additional errors
>  >>> (which
>  >>> would be expected):
>  >>
>  >>> [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024]
>  >>> Could not bind as []: ldap error 48: Inappropriate authentication
>  >>> [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024]
>  >>> Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache.
>  >>
>  >>> I did find an old issue in Pagure
>  >>
>  >>> https://pagure.io/389-ds-base/issue/47850
>  >>
>  >>> which was for a different issue related to setting
>  >>> nsslapd-allow-anonymous-access:rootdse
>  >>> In that issue Mark mentions adding a separate user entry to be used to
>  >>> search
>  >>> o=netscaperoot
>  >>> but I can't find any other references to this solution (and don't
> know if
>  >>> it
>  >>> would solve this issue).
>  >>
>  >>> --
>  >>
>  >>>
>  >>
>  >>> Patrick Landry
>  >>> Director, UCSS
>  >>> University of Louisiana at Lafayette
>  >>> pml(a)louisiana.edu
>  >>
>  >>> _______________________________________________
>  >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  >>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  >>
>  >> _______________________________________________
>  >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  >
>  > --
>  > Sincerely,
>  >
>  > William Brown
>  > Software Engineer
>  > Red Hat, Australia/Brisbane
>  >
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 
-- 

	

Patrick Landry 
Director, UCSS 
University of Louisiana at Lafayette 
pml(a)louisiana.edu