Samba-Problem auf DC-Backup


#1

Moin Moin,

derzeit schlage ich mich wieder einmal mit einem DC-Backup herum, der nicht als Fallback-Anmeldeserver funktionieren will.
Bei irgendeinem Update muss es wohl Samba uf dem DC-BU zerschossen haben und er taucht nicht unter Netzwerk bei den Win7-Clients auf.
Über den Browser und über SSH ist er ansprechbar. /var/log/samba/ ist leer.
Parallel dazu gibt Nagios folgende Warnung für den DC-Master aus:

UNIVENTION_S4CONNECTOR
WARNING	2018-09-24 12:40:22	145d 17h 40m 3s	10/10	S4CONNECTOR WARNING: Found 1 reject(s)! Please check output of univention-s4connector-list-rejected.

Dort steht:

UCS rejected

    1:   UCS DN: uid=krbtgt,cn=users,dc=hipsy,dc=intranet
          S4 DN: cn=krbtgt,cn=users,DC=hipsy,DC=intranet
         Filename: /var/lib/univention-connector/s4/1524079606.261122


S4 rejected


        last synced USN: 38876

Gibt es einen Zusammenhang zwischen diesem Fehler und dem Veschwinden von Samba auf dem DC-BU (kenne die Funktion von krbtgt nicht)?

Das connector-s4.log sagt:

24.09.2018 19:24:00,558 LDAP        (PROCESS): sync from ucs:   Resync rejected file: /var/lib/univention-connector/s4/1524079606.261122
24.09.2018 19:24:00,563 LDAP        (PROCESS): sync from ucs: [          user] [    delete] cn=krbtgt,cn=users,DC=hipsy,DC=intranet
24.09.2018 19:24:00,632 LDAP        (WARNING): sync failed, saved as rejected
	/var/lib/univention-connector/s4/1524079606.261122
24.09.2018 19:24:00,632 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 898, in __sync_file_from_ucs
    if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new))):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2754, in sync_from_ucs
    self.delete_in_s4(object, property_type)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2783, in delete_in_s4
    self.lo_s4.lo.delete_s(compatible_modstring(object['dn']))
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 333, in delete_s
    return self.delete_ext_s(dn,None,None)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 326, in delete_ext_s
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 514, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 521, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
    result = func(*args,**kwargs)
OTHER: {'info': 'error in module samldb: Other during LDB_DELETE (80)', 'desc': 'Other (e.g., implementation specific) error'}

Soviel zum Master-DC.
Auf dem Backup ergibt die Eingabe von samba-tool drs showrepl Folgendes:

root@hipsctrl-3:~# samba-tool drs showrepl
ldb: unable to stat module /usr/lib/x86_64-linux-gnu/samba/ldb : No such file or directory
ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to hipsctrl-3. failed - drsException: DRS connection to hipsctrl-3. failed: (-1073741772, 'The object name is not found.')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/drs.py", line 44, in drsuapi_connect
    (ctx.drsuapi, ctx.drsuapi_handle, ctx.bind_supported_extensions) = drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds)
  File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 56, in drsuapi_connect
    raise drsException("DRS connection to %s failed: %s" % (server, e))

Da meine Analyse- und Reparatur-Fähigkeiten begrenzt sind, erwog ich, den DC-BU komplett aus der Domäne zu entfernen und einen neuen aufzusetzen. Ist das sinnvoll, oder erzeuge ich damit eher neue Probleme? Besser stattdessen Samba auf dem BakupDC neu installieren?
Diese Anleitung zum Entfernen

https://docs.software-univention.de/windows-4.1.html#ext-win-s4-uninstall

habe ich gefunden.
Das klingt, als müsse lediglich das besagte Skript auf dem DC-BU aufgerufen und hinterher noch das 97univention-s4-connector Script auf dem Master ausgeführt werden. Hat denn das S4-purge-Skript, wenn es auf dem DC-BU ausgeführt wird, Auswirkungen auf den Master?
Kann ich danach einfach den DC-BU aus dem Rechner-Container bzw. dem LDAP-Verzeichnis löschen und ihn abschalten?
Fragen über Fragen …

Vielen Dank schon mal

Bernhard


#2

Hey,

(Wir versuchen, Englisch als Forensprache zu etablieren, um internationale User einzubeziehen. Daher antworte ich in Englisch. Falls Sie kein Englisch sprechen, antworte ich auch gerne noch mal auf Deutsch.)

You seem to have several problems (1. the S4 connector reject and 2. Samba not working on your DC Backup) that aren’t necessarily related. I’ll start with the state of your DC Backup.

What you’ve shown from your DC Backup looks like Samba isn’t running, or maybe not even installed properly. This line in particular leaves me to think it isn’t installed:

ldb: unable to stat module /usr/lib/x86_64-linux-gnu/samba/ldb : No such file or directory

That directory belongs to the package samba-dsdb-modules which should really be installed.

Can you please show the output of the following commands:

lsof -PniTCP:445,139
univention-app domain
dpkg -l | grep samba

The first shows whether or not Samba is running while the latter two can shed light on the installation status.

I wouldn’t remove and reinstall the server. It might suffice to reinstall Samba and to rejoin the server into the domain.

About your S4 connector reject on the master: the user krbtgt is a system user required to exist for Kerberos to work correctly. Please show the output of the following commands (to be executed on your DC Master) which determine where the user account still exists:

univention-ldapsearch -LLL -b uid=krbtgt,cn=users,$(ucr get ldap/base) -s base dn
univention-s4search -b cn=krbtgt,cn=users,$(ucr get ldap/base) -s base dn | grep -v '^#'

Kind regards
mosu


#3

Hello Mr. Mosu,

thank you very much for your reply!

lsof -PniTCP:445,139

did not generate any answer from the machine (the DC-Backup):

root@hipsctrl-3:~# lsof -PniTCP:445,139
root@hipsctrl-3:~# univention-app domain
hipsctrl-1.hipsy.intranet:
UCS: 4.3-1 errata218
Installed: dhcp-server=12.0 kde=5.8 nagios=4.3 pkgdb=11.0 samba4=4.7 uvmm=7.0
Upgradable:

hipsctrl-3.hipsy.intranet:
UCS: 4.3-1 errata218
Installed: kde=5.8
Upgradable:

None:
Failed to get info
ssh: Could not resolve hostname none: Name or service not known

vpn.hipsy.intranet:
UCS: 4.3-1 errata218
Installed: kde=5.8 openvpn4ucs=1.1.14 radius=5.0
Upgradable:
root@hipsctrl-3:~# dpkg -l | grep samba
ii python-samba 2:4.7.8-1A~4.3.0.201808081836 amd64 Python bindings for Samba
ii samba-common 2:4.7.8-1A~4.3.0.201808081836 all common files used by both the Samba server and client
ii samba-common-bin 2:4.7.8-1A~4.3.0.201808081836 amd64 Samba common files used by both the server and the client
ii samba-libs:amd64 2:4.7.8-1A~4.3.0.201808081836 amd64 Samba core libraries
ii univention-newsid 9.0.0-1A~4.3.0.201712120245 amd64 UCS - generate a new samba sid
root@hipsctrl-3:~#

And here is the output of the DC-Master:

root@hipsctrl-1:~# univention-ldapsearch -LLL -b uid=krbtgt,cn=users,$(ucr get ldap/base) -s base dn
No such object (32)
Matched DN: cn=users,dc=hipsy,dc=intranet
root@hipsctrl-1:~# univention-s4search -b cn=krbtgt,cn=users,$(ucr get ldap/base) -s base dn | grep -v ‘^#’
dn: CN=krbtgt,CN=Users,DC=hipsy,DC=intranet

Does that mean, krbtgt does not exist in the ldap-directory? I didn’t realize any authentication-problems yet.
I’m curious about your conclusions from the lines above …

Best regards

Bernhard


#4

As @Moritz_Bunkus already thought, your Samba is not installed on the hipsctrl-3. Just the KDE app, not more.
The packages with “samba” in the name are common files used for several functions, but do not offer Samba services at all.

So I would suggest to install it. Best through WEb-Frontend (UMC). Install the “AD compatible domain controller” not just on you master server. Otherwise, use univention-install univention-samba4.

Let us know if you have issues doing this.

/CV


#5

allright, I have been following your advice and installed the AD compatible domain controller on the DC-Backup. Although the join scripts had been marked as successfull nagios showed some warnings.
I rejoined the DC-BU but the warnings are still there:

nach%20rejoin2

Any Idea?

B


#6

Hi,

please do not mixed every issue into a single thread! Configuring Nagios is a different thing- please consider to open a new thread for this issue!

What was the output of the Join command? Everything ok?
Well, then you should check if your initial issue is solved now. Do you see the server in your Windows network environment now? Could the server now be used as %LOGONSERVER%? Is there still a traceback when starting smaba-tool drs showrepl?

/CV


#7

Hello,

sorry, I did not intend to ask for Help with Nagios. Just wanted to show you these warnings concerning Samba which I’ve not seen before.
But: The DC-Backup works as logon-server perfectly now.
Actually an easy-to-fix-problem but I did not expect at all Samba to be completely missing on a machine that was installed as Backup-DC.

Her is the output of samba-tool drs showrepl:

root@hipsctrl-1:~# samba-tool drs showrepl
Default-First-Site-Name\HIPSCTRL-1
DSA Options: 0x00000001
DSA object GUID: b613ad3f-245f-4c88-8160-f7176bc4babd
DSA invocationId: 5518c7ea-5fb8-44fb-8c79-767d595d54b1

==== INBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ Wed Oct 10 18:19:26 2018 CEST was successful
0 consecutive failure(s).
Last success @ Wed Oct 10 18:19:26 2018 CEST

DC=DomainDnsZones,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ Wed Oct 10 18:22:05 2018 CEST was successful
0 consecutive failure(s).
Last success @ Wed Oct 10 18:22:05 2018 CEST

DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ Wed Oct 10 18:19:27 2018 CEST was successful
0 consecutive failure(s).
Last success @ Wed Oct 10 18:19:27 2018 CEST

CN=Schema,CN=Configuration,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ Wed Oct 10 18:19:27 2018 CEST was successful
0 consecutive failure(s).
Last success @ Wed Oct 10 18:19:27 2018 CEST

CN=Configuration,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ Wed Oct 10 18:19:27 2018 CEST was successful
0 consecutive failure(s).
Last success @ Wed Oct 10 18:19:27 2018 CEST

==== OUTBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=DomainDnsZones,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

CN=Configuration,DC=hipsy,DC=intranet
Default-First-Site-Name\HIPSCTRL-3 via RPC
DSA object GUID: b0ad4799-a74a-4e7e-a82e-a47b5592af2c
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection –
Connection name: f18505a1-2a78-4708-b19b-e39583005484
Enabled : TRUE
Server DNS name : hipsctrl-3.hipsy.intranet
Server DN name : CN=NTDS Settings,CN=HIPSCTRL-3,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=hipsy,DC=intranet
TransportType: RPC
options: 0x00000001
Warning: No NC replicated for Connection!
root@hipsctrl-1:~#

I Don’t know how to interprete the last warning.
Do you see any more issues to deal with?

Thank you

Regards

Bernhard


#8

Moin,

well all looks good from the drs showrepl. And as there are no more issues in functionality your issue regarding Samba is solved.

Yes, it might be confusing samba not being installed automatically on a backupDC, but imagine environments where Samba is not needed- so the master does not have Samba installed- why should the backup it then install automatically?

/CV


#9

Auch wieder wahr.

Well, we live and learn … .