Dokuwiki: "ldap" authentication against other NS failed

Support
, ,
1

NethServer Version: 7.5.1804
Module: dokuwiki
Hello,

following situation: 2x NS into the same network:

  • NS1 is the “ad-master”. Users are set on it.
  • NS2 is the “ad-slave”, successfully bound to NS1. Dokuwiki runs on it and is configured “Authentication=ldap” by the “config” command.
  • users of NS1 are visible into the server-manager of NS2

The problem: the authentication of the users (from NS1) doesn’t work on Dokuwiki (NS2)

I installed dokuwik on NS1 (for tests) and I had a look into the file “etc/dokuwiki/local.protected.php” (AFAIK this is the right conf file):

  • by a dokuwiki installed on NS1:
$conf['authtype'] = 'authad';
$conf['plugin']['authad']['account_suffix']     = '@domain.tld';
$conf['plugin']['authad']['base_dn']            = 'dc=ad,dc=domain,dc=tld';
$conf['plugin']['authad']['domain_controllers'] = 'ldaps://ad.domain.tld'; //multiple can be given
  • by the dokuwiki installed on NS2:
$conf['authtype'] = 'authad';
$conf['plugin']['authad']['account_suffix']     = '@domain.tld';
$conf['plugin']['authad']['base_dn']            = 'DC=ad,DC=domain,DC=tld';
$conf['plugin']['authad']['domain_controllers'] = 'ldap://nsdc-NS1.ad.domain.tld'; //multiple can be given

I tried entering the parameters of the conf of dokuwiki-NS1 into the conf of the dokuwiki-NS2 and restart httpd but it doesn’t work too!
Questions:

  • why do the parameters of dokuwiki-NS1 not work into dokuwiki-NS2? The domain controller is the same: NS1 => ad.domain.tld via ldaps
  • BTW: why “DC=” in capital characters by NS2 and not by NS1? Other template?
  • why “ldaps” by NS1 and “ldap” by NS2? Same reason: other template?
  • and much more important: how to get it working??:thinking:

Tia
Bye
Arnaud

2

I guess something is wrong in the parameters that dokuwiki found itself by NethServer::SSSD

  • what is the output of account-provider-test dump on the NS1 and NS2
  • can you login with dokuwiki on NS1
  • if you adjust the ldaps in the parameter of the SssdConfig page of NS2, can you login in NS2 (I recall a similar issue for sogo and a remote authentication)
1 Like
3

It works! :heart_eyes:

But I don’t really understand why:

  • I tried to change ldap to ldaps into “LDAP server URI” of the account-provider of NS2 (from the server-manager) and I got an error by saving.
  • I unbound NS2 from the domain and bound it again. No problem and again ldap into “LDAP server URI”.
  • into "/etc/dokuwiki/local.protected.php” of NS2, I replace ldap through ldaps for 
    $conf[‘plugin’][‘authad’][‘domain_controllers’] =‘ldap://nsdc-NS1.ad.domain.tld’
  • restart apache
  • and it works!

I’m quite sure that I have tried to replace ldap through ldaps in this file yesterday, but without success.
Today I unbound and re-bound but the parameters are the same => it should have worked yesterday (if I didn’t do a mistake…).

=> IMHO this has just to be modified into the template.

Could somebody confirm or do you @stephdl want to make the modification only based on the info of this topic?

Thanks to have asking the right question!

Bye
Arnaud

4

this is a know bug @davidep SSSd probes first ldap and ldaps is needed

5

but but if you expand the template, do you still have ldaps ???

6

could you reproduce and check in logs (messages or httpd-admin) please

7

does it is a mandatory :-?

???

8 
[code]
# account-provider-test dump on NS1:
{
   "BindDN" : "ldapservice@AD.DOMAIN.EU",
   "LdapURI" : "ldaps://ad.domain.tld",
   "StartTls" : "",
   "port" : 636,
   "host" : "ad.domain.tld",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "dc=ad,dc=domain,dc=tld",
   "GroupDN" : "dc=ad,dc=domain,dc=tld",
   "BindPassword" : "###########",
   "BaseDN" : "dc=ad,dc=domain,dc=tld",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dtld"
}

# account-provider-test dump on NS2
{
   "BindDN" : "ldapservice@AD.DOMAIN.EU",
   "LdapURI" : "ldap://nsdc-ns1.ad.domain.tld",
   "StartTls" : "1",
   "port" : 389,
   "host" : "nsdc-ns1.ad.domain.tld",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=tld",
   "GroupDN" : "DC=ad,DC=domain,DC=tld",
   "BindPassword" : "#############",
   "BaseDN" : "DC=ad,DC=domain,DC=tld",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dtld"
} [/code]

=>LdapUri #1 is ldaps and #2 is ldap
=>LdapUriDn are ldap on both

9

yep same behaviour with sogo, sssd probed ldap and ldaps is needed to connect remotely

10

On NS2 (already bound with NS1) => accounts provider => LDAP server URI => I re-enter ldaps instead of ldap (ldaps://nsdc-ns1.ad.domain.tld) and I get an error with a red banner:

STARTTLS
        Conflicts with "ldaps://" URI scheme
    Authentication credentials for LDAP applications
        LDAP connection error

There is no corresponding entry into the logs /var/log/messages into /var/log/httpd-admin/error_log and neither into /var/log/httpd/error_log

I thought about a “stupid” template-custom where the URL is entered, without any automatic function.

11

@davidep why when you bind to a remote samba AD (nethserver) you found the ldap url instead of a ldaps url.
In the example above you can see NS1 (which is the remote samba AD) using LDAPS and NS2 with LDAP

12

Because LDAPS wasn’t standardized. So when talking to other appliances StartTLS is preferred.

Dokuwiki should honor that setting first. If that’s not possible it could try LDAPS even it isn’t know to work.

13

it is the same for sogo, do you suggest I force the ldaps by my code

something like

s/ldap/ldaps/

14

PHP can work with StartTLS as roundcube and nextcloud show us. I bet dokuwiki can do it too…

1 Like
15

@Arnaud could you add

$conf['plugin']['authad']['use_tls'] = 1;
you could add also
$conf['plugin']['authad']['ad_port'] = '389';

restart apache after and test to connect

1 Like
16

please could you test

yum install http://mirror.de-labrusse.fr/NethDev/nethserver-dokuwiki/nethserver-dokuwiki-1.2.6-1.ns7.sdl.noarch.rpm

normally we should probe tls and add

$conf['plugin']['authad']['use_tls'] = 1;