Kopano failing ldap bind to MS Server 2016 AD [Solved]

Apps & App Center
#1

I have just setup an MS Server 2016 AD & installed the Kopano AD extension. I then installed a UCS 4.2 instance as a member of the AD domain & installed both Kopano Core & Kopano Webapp.
The UCS instance shows all the AD users & Kopano properties as expected. However, attempting to login to Webapp is met with:-

Logon failed. Please verify your credentials and try again.

Corresponding to the login attempt in the /var/log/kopano/server.log file I see:-

Tue Jun  5 09:04:30 2018: [error  ] LDAP search error: Can't contact LDAP server. Will unbind, reconnect and retry.
Tue Jun  5 09:04:30 2018: [warning] Authentication by plugin failed for user "username_here": Trying to authenticate failed: username_here not found in LDAP;

But if I use ldapsearch from the UCS command line to query the AD, I can do so without issue. So it seems that kopano server isn’t binding to the AD somehow. Lifting the loglevel in server.cfg doesn’t really provide any more useful info. So just looking for a little guidance as to where I can look next to further troubleshoot the issue.

#2

Before anyone wastes any time on this it looks as though this may be a case of brain fade on my part. The UCS instance is showing server role as “domaincontroller_master”. So likely an incorrect choice of server role at install is the root cause of my issues.

#3

Ok, so I understand now that the first UCS host in a MS AD will have the server role of “domaincontroller_master” while having the samba role of “memberserver”.

Looks like my issues relate to the following server.log entries:-

Tue Jun  5 14:35:57 2018: [error  ] KDatabase::Connect(): database access error Unknown error code (0x80000007), mysql error: Access denied for user 'root'@'localhost' (using password: NO)
Tue Jun  5 14:35:57 2018: [crit   ] Unable to connect to database: MYSQL not initialized

I have read this post relating to kopano failure after upgrade to 4.2

https://help.univention.com/t/kopano-wont-start-after-upgrade-to-4-2/6097/19

Have followed the advice to increase the time that mysql waits to initialize from 30 to 60 seconds & I’m no longer getting the mysql errors in server.log but the ldap errors remain on attempts to authenticate to webapp.

#4

These errors are actually normal and can be ignored, since the services start once during installation before they are properly configured.

I must say I doubt that its necessary to install our ad schema on the windows side. The way I see the Univention AD integration it is designed to fetch users from an ad, but all additional administration (especially when talking about the Kopano UCS integration) are then performed on the ucs side of things.

Are these users then locally available on the univention host (e.g. listed when querying with univention-ldapsearch)? Kopano indeed connects to the local univention (open)ldap and not to any external ldap source (by default).

#5

Hi Felix,

These errors are actually normal and can be ignored, since the services start once during installation before they are properly configured.

Ok, thanks. That’s good to know.

I must say I doubt that its necessary to install our ad schema on the windows side. The way I see the Univention AD integration it is designed to fetch users from an ad, but all additional administration (especially when talking about the Kopano UCS integration) are then performed on the ucs side of things.

Yes, I see that now. I was initially confused thinking that the UCS host could be a simple member server & authenticate directly with the MS AD server.

Are these users then locally available on the univention host (e.g. listed when querying with univention-ldapsearch)? Kopano indeed connects to the local univention (open)ldap and not to any external ldap source (by default).

Yep, ok that follows and makes sense. Yes, univention-ldapsearch displays the AD users.

#6

ok, next step. are these listed users also known to kopano (are they matched by our search filter)?:

univention-ldapsearch $(ucr get kopano/cfg/ldap/ldap_user_search_filter)

#7

Thanks Felix. The answer is apparently not:-

root@kopano4ucs:~# univention-ldapsearch $(ucr get kopano/cfg/ldap/ldap_user_search_filter)
# extended LDIF
#
# LDAPv3
# base <dc=domain,dc=lan> (default) with scope subtree
# filter: (kopanoAccount=1)
# requesting: ALL
#

# search result
search: 3
result: 0 Success

# numResponses: 1

So despite the users being listed as “Kopano User” in the kopano section of the UMC Users module, this is not reflected in the LDAP ? So to answer my own question, I go into the UMC and set one users “Kopano Role” from “Kopano User” back to “None” and save. Then I change the Kopano Role from “None” back to “Kopano User” and save again.

BAM. Your search query returns that users details and I can login to webapp as that user. So to confirm I do another user. Same same. So it looks as though (on fresh install) for some reason the Kopano Role setting for each user is a “false positive”. Such a simple thing that I probably should have tried earlier but there you go.

Thanks again Felix. Everytime you have helped me with Kopano & UCS issues in these forums I have picked up a little extra snippet of insight that will hopefully mean I’ll have to bother you less often in the future. :slight_smile:

1 Like
#8

Hey,

This is due to how the UMC and the Kopano attributes work. If the underlying LDAP attribute (in this case: kopano-role) is unset, the drop-down box will have its default value selected. The default value is “Kopano user”.

Now one would think that this change in value (from unset to “Kopano user”) should be saved when you hit the “save” button, but until recently there was a bug in the UMC regarding default values for attributes. This bug has been fixed in UCS 4.3 errata 88 and 89.

What happens when you do the “change, save, change back, save again” dance is:

  1. Initially the LDAP attribute is unset, the drop-down box shows the default value instead of the current value (unset).
  2. You change the value to a non-default and save. With this you circumvent the aforementioned UMC bug. The UMC recognizes a change in attribute value and sets the kopano-role attribute to “none”.
  3. You change the value from “none” to “Kopano user”. As the LDAP attribute is set, the UMC bug is again not triggered. The UMC recognizes the change from “none” to “Kopano user” upon saving and sets the LDAP attribute accordingly.

The same issue was a topic in this thread, too (in German). There are some more details there.

Kind regards,
mosu

#9

Thanks for the explanation Moritz & it’s good to hear that the issue is addressed in UCS 4.3. I missed the German thread (even though I quite often “google translate” many of the German threads).

While we’re talking Kopano & UCS 4.3, is there any indication of a Kopano4UCS release in the 4.3 train that you or Felix (if you’re listening) know of?

#10

There is currently an update waiting in the test appcenter to resolve some of the php5 issues of Ucs 4.3. But if you want to stay up to date with Kopano releases I recommend to use https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server.

#11

Thanks Felix. I usually wait for the Kopano4UCS packages but I upgraded to UCS 4.3 in one of my environments before I realized there were a few Kopano issues on 4.3

Good to know it’s coming soon. Thanks again.

#12

If you have a subscription, then there is no reason not to use https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server to keep updated.

#13

If you have a subscription, then there is no reason not to use https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server to keep updated.

Oh ok. Then I’m learning more again. Yes I do have a subscription. I always thought I was better off waiting for the Kopano4UCS packages to ensure there was no integration issues that the “Kopano Download Server” packages were not designed/prepared for.

I read that opting to update direct from the Kopano package server “disables” the UCS4Kopano (ie UCS App Centre) upgrade path. Would you mind just confirming if that is correct please? (then I promise I’ll stop hounding you on this :slight_smile:

#14

No, that is not really correct. The only thing that this impacts is that whenever there is a new app update, most probably only the kopano4ucs packages will be updated on your system. The only “downside” is that upgrading from one Univention release to another is impacted by that (so 4.2 to 4.3, not the errata updates), since at the time of the upgrade not all kopano dependencies can be resolved. But there are ways around this.

#15

Ok, thanks for that. It’s much clearer to me now what the pro’s and cons are.

My use of Kopano (nowadays) is almost exclusively within a UCS environment, and I think from that point of view, I’m inclined still to stay in the Kopano4UCS upgrade train. But it’s great to know about other options/pros/cons are.

Mastodon