NC fails, when installed on a seperate instance which is joined to Remote-AD

Main AD: 7.8-2003 fully updated with subscription
installed Machine: 7.8-2003 fully updated no subscription - fresh install from scartch with iso.
Module: NC 19.0.3

I hit the following problem, which is possibly a bug.

I installed a “colabrativ server” as a seperate instance (proxmox-vm), which I joined to the main-AD.
When I installed NC on this instance siganl-event nethserver-nextclout-update failed.
More precise the S30nethserver-nextcloud-occ-conf command failed.
When trying to login, I got an internal server error.
This behaviour I encountered unless I installed NC bevor or after I joined the machine to the AD.
Tried it twice, but bothtimes same error, as soon the machine is joined.

I had to install NC without selecting an accountprovider and than do the LDAP-config manually in NC over ladps on port 636. Then I got the users from the Main-LDAP.

Can anyone confirm this?

TIA Ralf


Hi Ralf

Actually I’m not surprised this fails.

A lot of people think NextCloud in NethServer “can do” AD authentification, so it must react like a Windows App installed on a “Member Server” - All Users and Groups are visible. NO !!!

This thinking may be valid for a lot of stuff, but not NextCloud…

NextCloud uses it’s own connection to AD, this fails in NethServer as - this bit I’m assuming (I’m not a NethServer developer and haven’t checked the specs) - I think it checks: Is there an account provider, and if yes, uses localhost or something similiar. This is not correct, but the behaviour is understandable.

NethServer wasn’t designed for a Multi-Server environment. Even though it works well, there are a few caveats and “gotchas”…

I’m NOT saying this behaviour can’t be improved, I’m just saying this behaviour is almost expected, but not BAD per se… :slight_smile:

I do admit being a NethServer fan, but if I need something special from it, I’m willing to do manual tweaks to get there!

My 2 cents

PS: Yes, I do think NethServer can improve this… :slight_smile:

Hi Andy,

thanks for your reply.

Yes, this behaviour isn’t bad per se. To do manual work is o.k. But in this case, the docs should provide info.
NC is a module which is installable in softwarecenter and as this, I assumed it to work out of the box.
As it didn’t, I read the docs twice but coudn’t get it to work. If there was an info about difficulties with AD and to bind it manually, I would have saved a lot of time.
The funny thing is, I found every info I needed in the file “S30nethserver-nextcloud-occ-conf” exept of the ldaps-hint on port 636. :smiley:
I think I’ll write a “how to bind NC to a reomte NS-AD” the next days.

Stay healthy and have a good time!


Hi Ralf

Driving down from Main-Spessart to Switzerland is a 3.5 hour drive, depending on road conditions…

A how-to for that would be good, the past couple of weeks a few people here ran into that problem with NC and AD on different servers…

My 2 cents

The configuration of nextcloud should be same both for local or remote AD.
I didn’t receive any report on such bug.

@lucag @nrauso do you have any evidence this is a common issue?

Hi giacomo,

I did a quick test: when I change the config of accountprovider from default:
to this:
authentication from remote-AD in NC works.

Maybe a compatibility problem from older version? My AD is an upgraded NS 6.x since beginning of 2016 or so.


I don’t remember if there were any changes on AD TLS policy.
Let’s ask @davidep if he remember something about it.

I think Nethserver just defaults to ldap:// but for remote AD with NC ldaps:// is needed. Maybe it’s the Nextcloud LDAP/AD implementation that does not support STARTTLS…

When I look at it looks like LDAP:// should be possible.
What happens if you put in the IP address of the NSDC server?

@flatspin points it does work with LDAPS… if that works, I would say that should be default. Any catches to not default to LDAPS?

Internal servererror

EDIT: this is when using ldap://IP-of-ADserver and STARTTLS checked
When using ldaps://IP-of-ADserver and STARTTLS uncheck it works again.
Seems that STARTTLS is the problem resp. not supported by NC.

1 Like

AFAIK NextCloud LDAP client is based on PHP/OpenLDAP libraries, that support STARTTLS for sure.

AFAIR NextCloud used to support remote account providers, whatever their configuration is. I might be wrong, of course but time and commits has passed and there can be something new in between, so it requires further information and analysis.

Can you see any additional detail in /var/lib/nethserver/nextcloud/*.log?

Please check the NC LDAP config with

occ ldap:show-config

If you changed the LDAP config from the NC admin page, it’s possible that you have a misalignment between NS configuration and what is applied to NC.

Hi Davide, sorry for delayed reply.

No. There is only nextcloud.log. But no entry is made about internal server error.

In the meantime, I did a complete new install. NC-ladp config is untouched. It only works out of the box when ldaps is used.

Can’t find anything strange, but I’ve to admin that I’m not expert on this.

Just something I noticed:
When I change the ldap config in NC manually:

I get a green config o.k. at first, but when clicking on “continue” I get this

And in Logging I find

Error PHP ldap_unbind(): supplied resource is not a valid ldap link resource at /usr/share/nextcloud/apps/user_ldap/lib/LDAP.php#341

Don’t know if this helps. :blush:

EDIT: I found in that LADP.php a function about startTLS:

So I assume you’re right, that NC should support startTLS.
But in my installation it doesn’t. :thinking:

1 Like

We disabled STARTTLS for AD but I don’t know why, maybe there are issues with remote M$ AD?

I am going to test it with Windows Server asap…

If you enable it on command line with occ, the Nextcloud login to remote Neth/Samba AD with STARTTLS works:

sudo -u apache scl enable rh-php73 -- php -dmemory_limit=512M /usr/share/nextcloud/occ ldap:set-config s01 ldapTLS 1

I changed the thread to bug category.


OK, STARTTLS does not work with M$ AD, at least not without additional configuration on the Windows Server but I didn’t test further.

I think Nextcloud should use the same values as configured in Nethserver instead of hardcoded disabling of STARTTLS.
This way it will work with remote Neth/Samba AD and MS AD out of the box…


STARTTLS changes might relate to Rc2 QA/testing campaign and issue #5161 / #5396.

Is this relevant to the issue?

The final step is to actually reconfigure the clients to use one of the following connection methods:

  • Simple Bind LDAP using SSL / TLS (usually on port 636) or StartTLS (usually on port 389). or
  • Simple Authentication and Security Layer (SASL) LDAP with digital signing requests.



Git blames me :sweat_smile:

I don’t remember why… The comment says # always disable starttls, AD does not support it …but that’s not true now. I know @nrauso has a procedure that enables ldaps:// and ldap://+StartTLS on Windows AD Server 2008. Am I right Nicola?

I agree NC has to honor the system-wide configuration. Furthermore, forcibly disabling StartTLS is dangerous because it exposes passwords in clear text :frowning:

However enabling it on existing systems is dangerous too, because it forces a new configuration - never touch a running system :grimacing:

If we decide to fix, we must preserve existing setups, as usual…

:warning: do not change LDAP setup with NC admin UI!

As workaround I’d do the following:

  1. go to the System > Users & Groups > Edit provider dialog as root user,
  2. disable StartTLS
  3. set protocol ldaps://

If AD is configured with a TLS certificate, the new settings are saved and applied to NC too!


@davidep yes, that what I did in the end. :wink:

1 Like

If it’s a “won’t fix”, I suggest to update the docs at least.

The idea is to fix for new installations on 7.9


Full story here


I got a similar error message during the development. It was fixed by specifying the Bind credentials in the Accounts Provider configuration