I cannot give you an authoritative answer, but I agree that Kerberos-authenticated DNS updates will likely only work with the samba_dlz backend for Bind. Reading the manual doesn’t provide a concluding answer either, but one can read into it that only the Samba backend provides direct updates. In your domain you will likely see your Windows clients not being able to update their own DNS entries either, correct?
What’s the reason for using the LDAP backend in the first place if I may ask?
well the patch for the bug you are refferring to is already relased in March '18. Indeed there was an issue when executed on a system without Samba installed. This is fixed.
The test can not provide meaningful results without Samba being installed as it test the functionality of Samba DNS updates.
Background:
When a client receives it’s IP-address through DHCP it starts an update for it’s name to DNS. In our case to bind9 (the DNS server on UCS systems). Bind9 then updates to its backend Samba through the samba_dlz module about the new entry. Afterwards the new entry is registered as well as in Samba-DNS as ind bind9. Perfect so far but you need the Kerberos stuff working mentioned in the bug.
If the backend is set to ldap nearly the same happens- until bind9 tries to update its backend. But unlikely with samba_dlz bind9 does not have any write permissions to the ldap database and therefore is not permitted to write any entries. And so no client updates could be performed.
This is not a case of not having Samba installed. Samba is installed. The thing is that Bind’s DNS backend is not set to samba4 but to ldap.
Unfortunately that’s something that a server executing the diagnostics has no knowledge of as the setting isn’t done on the server running the diagnostics but the server running Bind. I don’t see an easy way to fix this safe for ssh’ing into the server running Bind and querying the UCR variable dns/backend.