AD Connector - stop syncing after upgrade 4.2 --> 4.3

I recently updated a UCS system consisting of 2 servers, members of existing AD domain, from version 4.2 to 4.3 (as systems reported the version is “out of maintenance”).
The UCS DC Master has the AD Connector installed and running.
It is/was all running “normally” until after a few days I noticed the UCS systems don’t get/reflect any changes made in AD (no new groups, memberships, users…)
The servers seems working “normally”, you can authenticate, use resources… just no “updates/changes” coming from AD…

The connector-status.log reports:

 --- connect failed, failure was: ---
Traceback (most recent call last):
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 303, in main
    connect()
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 191, in connect
    baseConfig['%s/ad/listener/dir' % CONFIGBASENAME]
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 837, in __init__
    self.open_ad()
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 1038, in open_ad
    self.lo_ad.lo.sasl_interactive_bind_s("", auth)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 962, in sasl_interactive_bind_s
    res = self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 931, in _apply_method_s
    return func(self,*args,**kwargs)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 244, in sasl_interactive_bind_s
    return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
    result = func(*args,**kwargs)
LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)', 'desc': 'Local error'}


the same error is reported by univention-adsearch

but, net ads testjoin reports all ok

kinit/klist seems working OK

net ads info works ok

LDAP server: 172.16.0.180
LDAP server name: DC01.sih.net
Realm: SIH.NET
Bind Path: dc=SIH,dc=NET
LDAP port: 389
Server time: Sat, 20 Oct 2018 12:49:18 CEST
KDC server: 172.16.0.180
Server time offset: 0
Last machine account password change: Sat, 20 Oct 2018 01:49:06 CEST

net ads status fails

root@ucs-master:~# net ads status
gse_get_client_auth_token: gss_init_sec_context failed with [ Miscellaneous failure (see text): KDC has no support for encryption type](2529638926)
Enter root's password:
ads_connect: No logon servers are currently available to service the logon request.
kerberos_kinit_password root@SIH.NET failed: Client not found in Kerberos database
ads_connect: No logon servers are currently available to service the logon request.

Did the net ads status after kinit Administrator and entered the password.

The “KDC has no support for encryption type](2529638926)” seems suspicious… but I do not know what changed?? Which KDC does not support which encryption? (local? AD?)

The current AD is still a Windows 2003 domain and the “primary” AD DC is still a Windows 2003 server… if that could be the reason…

I tried to deinstall the AD Conenctor and reinstall it again - hoping the “config wizard” will re-join/re-configure the AD connection but “nothing happened” - all the “config” was already there and I had no chance to reconfigure anything.

What can be done?! How to (manually) re-join/reconfigure the AD connector and hopefully resolve the issue?

Regards,
M.Culibrk

It seems I managed to solve the problem(s)…

First, as found on another forum, the similar issue with “no support for encryption” https://serverfault.com/questions/441662/kdc-has-no-support-for-encryption-type-when-setting-up-cross-realm-trust-betwe

I addedd the rc4-hmac encryption type to krb5.conf

After that I started getting another error - “Server not found in Kerberos database”

Digging around I find a nice “warning/emphasis” saying just "DNS! DNS! DNS! end more precisely r-dns

And yes… trying to do a dig -x AD_Master returned “nothing”… so I tried adding manual entries and eventually ended with setting rdns=false in kerberos config (with ucr set kerberos/defaults/rdns=false)

And finally… (afer a reboot) the connector started working again!

So… it’s somehow working (the diagnostic tells nothing about this DNS “issues”…)
It’s all a little “touchy” if I may say… somehow fragile and “cryptic” if you do not know all the “hidden inner workings” of UCS…

Regards