Hallo,

seit wenigen Tagen kann ich keine Domain Joins mehr auf einem unserer UCS Server durchführen.
Die installierte UCS Version ist 4.1-4 errata353.
Die Fehlermeldung von Windows 7 lautet “Der DNS-Name ist nicht vorhanden.” (Abfrage: _ldap._tcp.dc._msdcs.archiv.local).

Dies lässt sich auch mit nslookup bestätigen:
C:Usersffischer>nslookup -type=SRV _ldap._tcp.dc._msdcs.archiv.local
Server: logon.archiv.local
Address: 10.1.1.100

*** _ldap._tcp.dc._msdcs.archiv.local wurde von logon.archiv.local nicht gefunden: Non-existent domain.

In der UCS Management Oberfläche ist dieser Eintrag aber vorhanden und sieht auch korrekt aus.
Ich habe im Forum bisher keinen passenden Fall gefunden.
Wo könnte hier noch das Problem liegen?

Vielen Dank,
Florian Fischer

Da müsste ich jetzt doch nochmal nachfragen:
Mit Domain Joins meinen Sie Windows Clients, die nicht gejoint werden können? Können Sie die Umgebung etwas genauer schildern?

Was sagen die Logfiles: “/var/log/syslog”, “/var/log/daemon.log”, “var/log/samba/log.samba” (und ggf. auch log.smbd), “/var/log/univention/listener.log”, /var/log/univention/connector-status.log?

Was gibt die Ausgabe der folgenden Befehle auf dem Server:

[code]# univention-check-join-status

univention-ldapsearch uid=administrator dn

univention-s4search cn=administrator dn[/code]

Auf den Clients:

[code]# nslookup

nslookup

ipconfig /all[/code]

Können Server und Clients alle Ressourcen ausserhalb sich selbst per Ping, etc. erreichen (google, andere Clients, Server, etc.) auch per Name?

Gerne kann ich die Umgebung noch etwas genauer beschreiben.
Es handelt sich um einen UCS Domain Controller Master (Version 4.1), der durch ein AD Takeover entstanden ist.
Seitdem haben wir schon mehrere Windows Clients (7 und 10) erfolgreich gejoint, aber seit dieser Woche funktioniert es nicht mehr.
Die Logfiles sind soweit unauffällig, bis auf die /var/log/univention/connector-s4.log
Hier finden sich haufenweise Fehler ähnlich wie der folgende:

[code]NO_SUCH_ATTRIBUTE: {‘info’: “0000200A: replmd_delete: Failed to modify object cn=discoverysearchmailbox {d919ba05-46a6-415f-80ad-7e09334bb852},cn=users,DC=archiv,DC=local in delete - attribute ‘authOrig’: no such attribute for delete on ‘cn=discoverysearchmailbox {d919ba05-46a6-415f-80ad-7e09334bb852}\0ADEL:c1ae9aa0-a3e8-4226-a501-6087b955aaaf,CN=Deleted Objects,DC=archiv,DC=local’”, ‘desc’: ‘No such attribute’}

09.12.2016 09:12:13,209 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=naujoks,DC=archiv.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=archiv,DC=local
09.12.2016 09:12:13,211 LDAP (PROCESS): sync to ucs: [ dns] [ modify] relativedomainname=naujoks,zonename=archiv.local,cn=dns,dc=archiv,dc=local
09.12.2016 09:12:13,216 LDAP (ERROR ): Unknown Exception during sync_to_ucs
09.12.2016 09:12:13,217 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1471, in sync_to_ucs
result = self.property[property_type].ucs_sync_function(self, property_type, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1637, in con2ucs
ucs_host_record_create(s4connector, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 978, in ucs_host_record_create
newRecord.modify()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 316, in modify
return self._modify(modify_childs, ignore_license=ignore_license)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 810, in _modify
self.lo.modify(self.dn, ml, ignore_license=ignore_license)
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 403, in modify
raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg)
ldapError: Type or value exists: aRecord: value #52 provided more than once
[/code]
Der Output der Diagnose-Befehle ist ebenfalls unauffällig:

[code]root@logon:/var/log/univention# univention-check-join-status
Joined successfully
root@logon:/var/log/univention# univention-ldapsearch uid=administrator dn

extended LDIF

LDAPv3

base <dc=archiv,dc=local> (default) with scope subtree

filter: uid=administrator

requesting: dn

Administrator, users, archiv.local

dn: uid=Administrator,cn=users,dc=archiv,dc=local

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1

root@logon:/var/log/univention# univention-s4search cn=administrator dn

record 1

dn: CN=Administrator,CN=Users,DC=archiv,DC=local

Referral

ref: ldap://archiv.local/CN=Configuration,DC=archiv,DC=local

Referral

ref: ldap://archiv.local/DC=DomainDnsZones,DC=archiv,DC=local

Referral

ref: ldap://archiv.local/DC=ForestDnsZones,DC=archiv,DC=local

returned 4 records

1 entries

3 referrals

[/code]

Was sagt die Ausgabe von:

[code]# univention-s4connector-list-rejected

univention-connector-list-rejected

[/code]

Ist seit dem es nicht mehr funktioniert irgendeine Änderung am UCS vorgenommen worden (Updates, Konfigänderungen, etc.)? “Unauffällige Logs” heisst: keine Tracebacks und keine Fehler?

Hier die Ausgabe des Befehls:

[code]root@logon:~# univention-s4connector-list-rejected

UCS rejected

1:   UCS DN: uid=SM_c263d47471df46bca,cn=users,dc=archiv,dc=local
      S4 DN: cn=discoverysearchmailbox {d919ba05-46a6-415f-80ad-7e09334bb852},cn=users,DC=archiv,DC=local
     Filename: /var/lib/univention-connector/s4/1481104862.202655

S4 rejected

1:    S4 DN: DC=naujoks,DC=archiv.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=archiv,DC=local
     UCS DN: relativedomainname=naujoks,zonename=archiv.local,cn=dns,dc=archiv,dc=local

    last synced USN: 32850

[/code]
Der Befehl univention-connector-list-rejected existiert nicht.

Ja, wir haben das Update auf 4.1-4 errata353 in der letzten Woche installiert. Es war aber nur ein Update des errata levels, da der Server regelmäßig aktualisiert wird (kann ich die alte Version irgendwo nachschauen)?

“Unauffällige Logs” heisst: keine Tracebacks und keine Fehler.

Okay, die rejects passen an sich mit den Tracebacks zusammen. Ich bin mir im Moment sehr sicher, dass diese aber nichts mit dem Problem zu tun haben, dass Sie keine Windows Clients joinen können.
Im Moment sieht es für mich so aus, als würde der UCS an sich einwandfrei laufen - daher müsste man eher schauen wie der Vorgang beim Join abläuft, etc.

Können Sie einen neuen Windows Client (oder einen bestehenden Windows Client mit neuem Namen) manuell im UCS als Computerobjekt anlegen, prüfen per

univention-ldapsearch cn=

univention-s4search cn=

ob das Objekt im S4 und Ldap angekommen ist und dann einen Join mit diesem Computernamen durchführen (wenn möglich die Schritte dokumentieren)?

Ich habe die beschriebene Prozedur mit dem Rechnernamen RSOPERATOR durchgeführt.

[code]root@logon:~# univention-ldapsearch cn=RSOPERATOR

extended LDIF

LDAPv3

base <dc=archiv,dc=local> (default) with scope subtree

filter: cn=RSOPERATOR

requesting: ALL

RSOPERATOR, computers, archiv.local

dn: cn=RSOPERATOR,cn=computers,dc=archiv,dc=local
univentionServerRole: windows_client
displayName: RSOPERATOR
cn: RSOPERATOR
krb5PrincipalName: host/RSOPERATOR.archiv.local@ARCHIV.LOCAL
(…)

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1

[/code]

[code]root@logon:~# univention-s4search cn=RSOPERATOR

record 1

dn: CN=RSOPERATOR,CN=Computers,DC=archiv,DC=local
(…)

returned 4 records

1 entries

3 referrals

[/code]

Die Fehlermeldung beim Join des Rechners RSOPERATOR bleibt allerdings dieselbe.

[code]Der folgende Fehler ist beim Abfragen von DNS über den Ressourceneintrag der Dienstidentifizierung (SRV) aufgetreten, der zur Suche eines Active Directory-Domänencontrollers für die Domäne “archiv.local” verwendet wird:

Fehler: “Der DNS-Name ist nicht vorhanden.”
(Fehlercode 0x0000232B RCODE_NAME_ERROR)

Es handelt sich um die Abfrage des Dienstidentifizierungseintrags (SRV) für _ldap._tcp.dc._msdcs.archiv.local.

Häufigste Fehlerursachen:

• Die zum Ermitteln eines Active Directory-Domänencontrollers (AD DC) erforderlichen DNS-SRV-Einträge wurden nicht in DNS registriert. (…) Dieser Computer wurde zum Verwenden von DNS-Servern mit den folgenden IP-Adressen konfiguriert:

10.1.1.100

• Mindestens eine der folgenden Zonen enthalten keine Delegierung zu dieser untergeordneten Zone:

archiv.local
local
. (die Stammzone)

[/code]

Die DNS-Einstellungen auf dem RSOPERATOR habe ich aber geprüft, und ich kann den DNS auch von dort aus erreichen.

[code]C:UsersAdministrator>nslookup logon.archiv.local
Server: logon.archiv.local
Address: 10.1.1.100

Name: logon.archiv.local
Addresses: 10.1.3.100
10.1.1.100
[/code]

was zeigt die DNS überprüfung:

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

bitte output des befehls checken

falls hier Einträge fehlen dann wende ich immer folgenden KB guide an um die SAMBA AD neu zu erstellen:

sdb.univention.de/content/6/274/ … aster.html

dies ist bei mir bei bisher allen AD-TakeOver installationen von UCS notwendig gewesen - k.a. warum das nicht reibungslos funktioniert aber die re_provisionierung von samba4 aus dem Ldap ist schnell erledigt

Danke für den Tipp.
Es fehlen alle Einträge die auf _msdcs enden.

[code]root@logon:~# /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
Host gc._msdcs not found: 3(NXDOMAIN)
_gc._tcp.archiv.local has SRV record 0 100 3268 logon.archiv.local.
Host _ldap._tcp.gc._msdcs not found: 3(NXDOMAIN)
_ldap._tcp.archiv.local has SRV record 0 100 389 logon.archiv.local.
Host _ldap._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.pdc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.ccd0e9a8-35b6-4a68-b6dc-208ecb437195.domains._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.dc._msdcs not found: 3(NXDOMAIN)
_kerberos._tcp.archiv.local has SRV record 0 100 88 logon.archiv.local.
_kerberos._udp.archiv.local has SRV record 0 100 88 logon.archiv.local.
_kpasswd._tcp.archiv.local has SRV record 0 100 464 logon.archiv.local.
_kpasswd._udp.archiv.local has SRV record 0 100 464 logon.archiv.local.
Located DC ‘logon’ in site ‘Default-First-Site-Name’
Host dcd59c15-7e7f-4a0c-a7dc-3262358e7cbc._msdcs not found: 3(NXDOMAIN)

Records for site Default-First-Site-Name:

_ldap._tcp.Default-First-Site-Name._sites.archiv.local has SRV record 0 100 389 logon.archiv.local.
Host _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs not found: 3(NXDOMAIN)
_kerberos._tcp.Default-First-Site-Name._sites.archiv.local has SRV record 0 100 88 logon.archiv.local.
Host _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs not found: 3(NXDOMAIN)

Optional GC Records for site Default-First-Site-Name:

_gc._tcp.Default-First-Site-Name._sites.archiv.local has SRV record 0 100 3268 logon.archiv.local.
Host _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs not found: 3(NXDOMAIN)
[/code]
Der Lösungsvorschlag aus der SDB scheint mir aber recht radikal zu sein. Sollten diese Einträge nicht eigentlich synchronisiert werden? Gibt es evtl. eine Möglichkeit eine Synchronisation zu forcieren?

Ja wie gesagt keine Ahnung warum das nicht richtig erstellt wird beim AD-Takeover

Aber mit dem KB eintrag den ich gepostet habe funktionert das super und schaut nur im ersten Moment radikal aus
Ich mache diese Schritte seit einem Jahr gleich nach der Fertigstellung einer AD-TakeOver installation und danach gabs nie mehr Probleme damit

LG

Christian

Leider scheint das Problem nicht im Samba-Server, sondern im Bind-Dienst zu liegen.
Abhängig davon wie ich die Einträge abfrage, tauchen sie entweder auf oder auch nicht.
Bei einer simplen DNS-Abfrage mit nslookup oder dig werden sie nicht gefunden:

[code]root@logon:~# nslookup -type=SRV _ldap._tcp.dc._msdcs.archiv.local
Server: 10.1.1.100
Address: 10.1.1.100#53

** server can’t find _ldap._tcp.dc._msdcs.archiv.local: NXDOMAIN
[/code]

Führe ich jedoch mit host einen Zone Transfer durch dann tauchen sie auf:

[code]root@logon:~# host -al -t SRV archiv.local
Trying “archiv.local”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13602
;; flags: qr aa ra; QUERY: 1, ANSWER: 225, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;
;; ANSWER SECTION:
_gc._tcp.archiv.local. 900 IN SRV 0 100 3268 logon.archiv.local.
_ldap._tcp.archiv.local. 900 IN SRV 0 100 389 logon.archiv.local.
_kpasswd._udp.archiv.local. 900 IN SRV 0 100 464 logon.archiv.local.
_kpasswd._tcp.archiv.local. 900 IN SRV 0 100 464 logon.archiv.local.
_kerberos._udp.archiv.local. 900 IN SRV 0 100 88 logon.archiv.local.
_kerberos._tcp.archiv.local. 900 IN SRV 0 100 88 logon.archiv.local.
_kerberos-adm._tcp.archiv.local. 900 IN SRV 0 100 88 logon.archiv.local.
_ldap._tcp.gc._msdcs.archiv.local. 900 IN SRV 0 100 3268 logon.archiv.local.
_ldap._tcp.dc._msdcs.archiv.local. 900 IN SRV 0 100 389 logon.archiv.local.
(…)
[/code]

Leider bin ich völlig überfragt, wie es zu einer solchen Fehlkonfiguration des bind-Dienstes kommen kann. An der hat auf jeden Fall niemand bei uns etwas geändert…

Wie ist das Backend konfiguriert?

# ucr search dns/backend dns/backend: <ldap>/<samba4> Bind can use different backends for its configuration: 'ldap' configures the use of the UCS OpenLDAP directory. 'samba4' uses the Samba 4 LDB database. When using the Samba backend, a search is performed in the LDAP for every DNS request. With the OpenLDAP backend, a search is only performed in the directory service if the DNS data has changed.

root@logon:/# ucr search dns/backend dns/backend: samba4
Das bedeutet wohl dass die Samba LDAP Datenbank verwendet wird.

Okay, zumindest warum nslookup die Informationen nicht anzeigt ist bekannt. BIND erreicht die Samba interne DB für DNS Daten nicht via dem DLZ (dynamic loading zone) Interface. Ich habe dafür keine direkte Lösung aber das würde die Ungereimtheiten erklären. Den Windows Clients dürfte das aer egal sein, die greifen auf das Samba4 zu und wenn die DNS Daten dort hinterlegt sind müsste das funktionieren. Im Moment sieht mir das aber auch nach einem Fall für: http://sdb.univention.de/content/6/274/en/re_provisioning-samba4-on-a-dc-master.html aus. Das ist radikal (es müssen die Server und Clients neu gejoint werden und wahrscheinlich auch die Passwörter neu gesetzt werden) und sollte in einer Testumgebung mind. einmal durchgetestet werden.