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

flatspin · October 20, 2020, 1:51pm

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

Andy_Wismer · October 20, 2020, 4:27pm

@flatspin

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…

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
Andy

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

flatspin · October 21, 2020, 6:39am

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.
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!

Andy_Wismer · October 21, 2020, 10:39am

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
Andy

giacomo · October 22, 2020, 10:02am

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?

flatspin · October 22, 2020, 11:58am

Hi giacomo,

I did a quick test: when I change the config of accountprovider from default:
grafik
to this:
grafik
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.

giacomo · October 22, 2020, 12:00pm

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

mrmarkuz · October 22, 2020, 12:52pm

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…

robb · October 22, 2020, 1:56pm

When I look at https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html 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?

flatspin · October 22, 2020, 2:14pm

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.

davidep · October 23, 2020, 6:52am

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.

flatspin · October 23, 2020, 11:38am

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.

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.

mrmarkuz · October 24, 2020, 11:22am

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

github.com

NethServer/nethserver-nextcloud/blob/master/root/etc/e-smith/events/actions/nethserver-nextcloud-occ-conf#L187


    OCC "ldap:set-config s01 ldapLoginFilterMode 0";
    OCC "ldap:set-config s01 ldapLoginFilterUsername 1";
    OCC "ldap:set-config s01 ldapUserDisplayName displayName";
    OCC "ldap:set-config s01 ldapUserDisplayName2 sAMAccountName";
    OCC "ldap:set-config s01 ldapUserFilter '(&(|(objectclass=person)))'";
    OCC "ldap:set-config s01 ldapUserFilterObjectclass person";
    OCC "ldap:set-config s01 ldapEmailAttribute userPrincipalname";
    OCC "ldap:set-config s01 turnOffCertCheck 1";
    OCC "ldap:set-config s01 useMemberOfToDetectMembership 1"; # expand all groups
    OCC "ldap:set-config s01 ldapConfigurationActive 1";
    OCC "ldap:set-config s01 ldapTLS 0"; # always disable starttls, AD does not support it
} else {
    # SSSD provider not configured, nothing to do
    exit 0;
}

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.

EDIT:

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…

dnutan · October 24, 2020, 11:04pm

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.

Source

davidep · October 28, 2020, 6:04pm

Git blames me

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

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

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

do not change LDAP setup with NC admin UI!

As workaround I’d do the following:

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

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

flatspin · October 29, 2020, 7:13am

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

flatspin · October 29, 2020, 10:24am

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

giacomo · October 30, 2020, 12:35pm

The idea is to fix for new installations on 7.9

davidep · November 2, 2020, 11:41am

Full story here

davidep · November 2, 2020, 4:03pm

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