New Host not found in DNS

Yes, VMANAGE is the only problematic host. I have deleted it and recreated as well and it still wont resolve

I still have the same issue where SYNOLOGY is an “IP Managed Host” which does not have an option for primary group.

The problem with SYNOLOGY is most likely an incorrect errorhandling, I would leave that be for the moment. Apart from SYNOLOGY we still do not know why VMANAGE gets possibly rejected.

It would be very strange if you create a host, have it in DNS but this same DNS server that has the host-record on file would be unable to resolve this record. We may be missing crucial information about this host.

I have just been looking around again and I still see the same issues. I DO see that there is an error with SYNOLOGY not having a primary group, however, as I mentioned, its an IP Managed Host (not windows host) so there is no option for primary group. That host is only a member of one group.

So where are we at? I don’t know where to look. Should I delete the SYNOLOGY host and recreate or something?

after deleting and recreating some hosts…and then resyncing, I see the following in connector-s4.log:

20.04.2017 20:56:55,483 LDAP (PROCESS): sync from ucs: [windowscomputer] [ add] cn=vmanage,cn=computers,DC=drager,DC=local
20.04.2017 20:56:56,534 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=vmanage,cn=computers,dc=drager,dc=local
20.04.2017 20:56:56,579 LDAP (WARNING): password_sync_ucs_s4_to_ucs: Failed to get Password-Hash from S4
20.04.2017 20:57:28,906 MAIN (------ ): DEBUG_INIT

is the password hash error significant?

Sorry that I took so long to answer. Can you have a look if the DNS object of VMANAGE is synced to the S4?

univention-s4search dc=vmanage --cross-ncs

Sorry for bringing up this old thread again. But, I have a similar problem decided not to start a new thread as the topic would be the same.
I have recently added a new memberserver (“telefonanlage”) to my UCS Domain for which I’ve added a DNS record beforehand. The record and the server-object appered on both domain controllers (ucs-3600 and ucs-3700) However, this record does not resolve to an address. Following this thread, I figured out there was a problem with two directory entries:

10.12.2020 14:10:51.347 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=dns-ucs-3700,CN=Users,DC=beaplas,DC=intranet
10.12.2020 14:10:51.358 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] u'uid=dns-ucs-3700,cn=users,dc=beaplas,dc=intranet'
10.12.2020 14:10:51.622 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
10.12.2020 14:10:51.622 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1555, in sync_to_ucs
    result = self.modify_in_ucs(property_type, object, module, position)
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1299, in modify_in_ucs
    res = ucs_object.modify(serverctrls=serverctrls, response=response)
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/users/user.py", line 1438, in modify
    return super(object, self).modify(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 650, in modify
    dn = self._modify(modify_childs, ignore_license=ignore_license, response=response)
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 1313, in _modify
    self.call_udm_property_hook('hook_ldap_pre_modify', self)
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 1054, in call_udm_property_hook
    func(module)
  File "/usr/lib/pymodules/python2.7/univention/admin/hooks.d/kopano4ucsRole.py", line 122, in hook_ldap_pre_modify
    raise univention.admin.uexceptions.valueError, _("Kopano users must have a primary e-mail address specified.")
valueError: Kopano users must have a primary e-mail address specified.

I have installed Kopano on ucs-3700 and apperently the setup has added the Kopano user-role to all objects inside the users container. Removing the role from both entries “dns-ucs-3700” and “dns-ucs-3600” resolved the sync-issue:

# univention-s4connector-list-rejected                                                                                      
UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 4615

Unfortunately this did not solve the DNS problem. Bind uses samba as it’s backend:

# ucr search --brief dns/backend
dns/backend: samba4

And the search for the DNS-entry creates no result:

# univention-s4search dc=telefonanlage --cross-ncs
# returned 0 records
# 0 entries
# 0 referrals

Digging around a bit more lead me to “listener.log” which has an error telling me that it failed to connect to a notifier

11.12.20 09:42:47.910  LISTENER    ( WARN    ) : Notifier/LDAP server is ucs-3600.beaplas.intranet:7389
11.12.20 09:42:47.910  LDAP        ( PROCESS ) : connecting to ldap://ucs-3600.beaplas.intranet:7389
11.12.20 09:42:47.915  LISTENER    ( ERROR   ) : failed to connect to any notifier
11.12.20 09:42:47.916  LISTENER    ( WARN    ) : can not connect any server, retrying in 30 seconds

Doing an ldapsearch on the CLI returns an error:

# ldapsearch -h ucs-3600.beaplas.intranet -p 7389 -s base -b "cn=users,dc=beaplas,dc=intranet" "objectclass=*"
SASL/GSS-SPNEGO authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate)

And with debug level set to 9:

# ldapsearch -h ucs-3600.beaplas.intranet -p 7389 -s base -b "cn=users,dc=beaplas,dc=intranet" "objectclass=*" -d 9
ldap_create
ldap_url_parse_ext(ldap://ucs-3600.beaplas.intranet:7389)
ldap_pvt_sasl_getmech
ldap_search
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ucs-3600.beaplas.intranet:7389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.200.0.200:7389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 64 bytes to sd 3
ldap_result ld 0x55ce7bc6d630 msgid 1
wait4msg ld 0x55ce7bc6d630 msgid 1 (infinite timeout)
wait4msg continue ld 0x55ce7bc6d630 msgid 1 all 1
** ld 0x55ce7bc6d630 Connections:
* host: ucs-3600.beaplas.intranet  port: 7389  (default)
  refcnt: 2  status: Connected
  last used: Fri Dec 11 10:19:11 2020


** ld 0x55ce7bc6d630 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x55ce7bc6d630 request count 1 (abandoned 0)
** ld 0x55ce7bc6d630 Response Queue:
   Empty
  ld 0x55ce7bc6d630 response count 0
ldap_chkResponseList ld 0x55ce7bc6d630 msgid 1 all 1
ldap_chkResponseList returns ld 0x55ce7bc6d630 NULL
ldap_int_select
read1msg: ld 0x55ce7bc6d630 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 86 contents:
read1msg: ld 0x55ce7bc6d630 msgid 1 message type search-entry
wait4msg continue ld 0x55ce7bc6d630 msgid 1 all 1
** ld 0x55ce7bc6d630 Connections:
* host: ucs-3600.beaplas.intranet  port: 7389  (default)
  refcnt: 2  status: Connected
  last used: Fri Dec 11 10:19:11 2020


** ld 0x55ce7bc6d630 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x55ce7bc6d630 request count 1 (abandoned 0)
** ld 0x55ce7bc6d630 Response Queue:
 * msgid 1,  type 100
  ld 0x55ce7bc6d630 response count 1
ldap_chkResponseList ld 0x55ce7bc6d630 msgid 1 all 1
ldap_chkResponseList returns ld 0x55ce7bc6d630 NULL
ldap_int_select
read1msg: ld 0x55ce7bc6d630 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x55ce7bc6d630 msgid 1 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x55ce7bc6d630 0 new referrals
read1msg:  mark request completed, ld 0x55ce7bc6d630 msgid 1
request done: ld 0x55ce7bc6d630 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
adding response ld 0x55ce7bc6d630 msgid 1 type 101:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt ([v]) ber:
ldap_msgfree
ldap_sasl_interactive_bind: server supports: GSS-SPNEGO GSSAPI DIGEST-MD5 CRAM-MD5 NTLM
ldap_int_sasl_bind: GSS-SPNEGO GSSAPI DIGEST-MD5 CRAM-MD5 NTLM
ldap_int_sasl_open: host=ucs-3600.beaplas.intranet
SASL/GSS-SPNEGO authentication started
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate)
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

May this be the cause of the DNS problem, e.g. there is simply no change detected because the listener is not connected?
What can I do to resolve the error reported in “listener.log”?

Best regards,
Martin.

Mastodon