Univention Bugzilla – Bug 33399
'Waiting for DRS replication' failed on a school slave
Last modified: 2016-02-04 13:58:47 CET
From the join.lg of a school slave with samba4: Waiting for DRS replication: ................................................................................. ........................................................................................................................................................................................................................... failed This happens with UCS 3.1 and UCS 3.2. I think the new password is not synced to the S4 of the master: root@slave2032:~# ldbsearch -H ldap://master203 -U slave2032\$%$(</etc/machine.secret) SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INVALID_PARAMETER Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <SASL:[GSS-SPNEGO]: NT_STATUS_LOGON_FAILURE> <> Failed to connect to 'ldap://master203' with backend 'ldap': (null) Failed to connect to ldap://master203 - (null) root@slave2032:~#
Ok, as discussed offline, some more info about this: This check was introduced for Bug 32257, but in the case of a UCS@school DC Slave it doesn't work, isn't required and adds an inefficient timeout delay, so it should be be avoided in this case. In case Bug 33388 gets fixed, this check may even be removed completely.
Created attachment 5883 [details] consider_only_S4_connector_hosts_with_DRS_connection.patch This patch improves detection of the S4 Connector host in the univention-samba4 joinscript. It introduces a test if the DC advertising univentionService="S4 Connector" is available for DRS replication. This should fix three unnecessary timeout situations of 'Waiting for DRS replication': 1) The problem of this bug, where a UCS@school slave PDC waits for DRS replication of its own machine account. 2) In UCS@school domains with more than one S4 Connector the current joinscript will find all of them and try to connect e.g. against "master slave1 slave2", which is not a valid hostname. 3) In UCS@school domains with one Samba4 school DC Slave, installation of a second Samba4 School will make the current joinscript wait for the first Samba4 school DC Slave to replicate the machine account of the school DC on the second school.
Customer experienced this with a non-edu school slave (4.0-2 errata 263) The attached patch worked (at least the joinscripts finished with EXITCODE=0 and superficial tests were okay).
Another customer experienced this problem (2015110521000117)
Once more during UCS@school Workshop ... UCS 4.1-0 errata 29, UCS@school Edu Slave
Since it has to be fixed in the Samba 4 package, I'll move it to the Samba 4 component.
Hit me again on one of my test systems during re-join: UCS 4.0-4 Errata 377 ucsschool_20151201
Noticed by a customer, mentioned on summit. I don't know why the join script sometimes fails at that point and sometimes doesn't. Nevertheless, even if it doesn't fail, the "Waiting for DRS replication"-part slows down the join process and should be removed.
Adjusted: * The joinscript * check_essential_samba4_dns_records Advisory: univention-samba4.yaml
ucs@school OK - no DRS REPL IN JOIN on first school slave OK - no DRS REPL IN JOIN on second school slave OK - no DRS REPL IN JOIN on first school slave during rejoin OK - no DRS REPL IN JOIN on second school slave during rejoin ucs OK - DRS REPL IN JOIN second s4 server OK - DRS REPL IN JOIN third s4 server OK - DRS REPL IN JOIN second s4 server during rejoin OK - DRS REPL IN JOIN third s4 server during rejoin OK - continue if server object can not be found in scripts/check_essential_samba4_dns_records.sh
<http://errata.software-univention.de/ucs/4.1/95.html>