Samba4 AD => kein DNS update

Hallo zusammen,

ich habe einen UCS als Domain Controller aufgesetzt. Hat auch soweit alles gut funktioniert. Der Server stellt zur Zeit folgende Dienste bereit:

-> Mail
-> Proxy
-> AD
-> DNS

Problem ist jetzt das bind9 wohl keine DNS updates mehr macht. Für den Domain Controller sind zwei IP Adressen hinterlegt. Eine davon ist falsch. Diese habe ich den Einstellungen gelöscht. Trotzdem liefert

host -t A dc.domain.local dc.domain.local has address 192.168.95.1 dc.domain.local has address 192.168.178.2
192.168.95.1 ist die korrekte IP adresse. Die andere ist das zweite Interface, welches die Verbindung ins Internet bereit stellt.

Wenn ich versuche die Datenbank manuel zu updaten bekomme ich:

samba_dnsupdate --all-names --verbose .... tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Matching credential not found. Failed nsupdate: 1 Failed update of 27 entries

Kann mir jemand helfen wo genau ich den fehler suchen soll?

Vielen Dank

Hallo,

hier sollte es reichen, die UCR-Variablen “samba/interfaces” und “samba/interfaces/bindonly” passend zu definieren.

Hintergrund: [bug]28016[/bug]

Viele Grüße,
Dirk Ahrnke

Hallo,

die entsprechendne Optionen sind bereits gesetzt. Ich habe den Server auch neu gestartet.

Was mir noch aufgefallen ist:

Ich kann IPs von Systeme abfragen, die nicht an sind. Ich habe das Gefühl das der DNS Speicher nicht geupdatet wird.

Viele Grüße,

Bastian Weißbach

Wo in den Einstellungen genau haben Sie denn die falsche IP-Adresse gelöscht?

Weiterhin: schauen Sie bitte in der Ausgabe des Befehls »udm computers/domaincontroller_master list« nach, ob die IP-Adresse auch wirklich nicht mehr angezeigt wird (ich gehe davon aus, dass Sie dem DC Master die zwei Adressen gegeben hatten). Pasten Sie die Ausgabe hier am besten. Ebenfalls nachschauen sollten Sie in der Ausgabe des folgenden Befehls:

udm  dns/host_record list --superordinate zoneName=mbu-test.intranet,cn=dns,dc=mbu-test,dc=intranet --filter relativeDomainName=master

Hier ist »dc=mbu-test,dc=intranet« durch Ihre LDAP-Base-DN, »mbu-test.intranet« durch Ihren Domänen-DNS-Suffix und »master« durch den Hostnamen des DC-Master-Servers zu ersetzen.

Hallo,

hier die gewünschten Infos:

[code]udm computers/domaincontroller_master list

DN: cn=dc,cn=dc,cn=computers,dc=ibb-tga,dc=local
ARG: None
domain: ibb-tga.local
ip: 192.168.95.1
ip: 192.168.95.5
nagiosServices: cn=UNIVENTION_PING,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_DISK_ROOT,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_DNS,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_SWAP,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_LDAP_AUTH,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_NTP,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_SMTP2,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_SSL,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_LOAD,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_REPLICATION,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_NSCD,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_JOINSTATUS,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_CUPS,cn=nagios,dc=ibb-tga,dc=local
nagiosServices: cn=UNIVENTION_SQUID,cn=nagios,dc=ibb-tga,dc=local
network: cn=default,cn=networks,dc=ibb-tga,dc=local
service: LDAP
service: DHCP
service: SMTP
service: Print
service: IMAP
service: NFS
service: DNS
service: Fetchmail
service: Samba 4
service: S4 Connector
service: Horde
service: PROXY
reinstalloption: None
unixhome: /dev/null
dnsEntryZoneForward: zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local 192.168.95.1
dnsEntryZoneForward: zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local 192.168.95.5
instprofile: None
dnsEntryZoneAlias: ibb-tga.local zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local 7c6baca8-0611-48f7-8caf-93105c1e808f._msdcs
dnsEntryZoneAlias: ibb-tga.local zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local proxy
shell: /bin/sh
description: None
objectFlag: None
mac: e6:db:02:cf:87:f4
mac: 3a:10:48:14:f6:af
groups: cn=DC Backup Hosts,cn=groups,dc=ibb-tga,dc=local
groups: cn=Enterprise Domain Controllers,cn=groups,dc=ibb-tga,dc=local
groups: cn=Domain Controllers,cn=groups,dc=ibb-tga,dc=local
primaryGroup: cn=DC Backup Hosts,cn=groups,dc=ibb-tga,dc=local
password: …
reinstall: None
serverRole: master
dnsAlias: 7c6baca8-0611-48f7-8caf-93105c1e808f._msdcs
dnsAlias: proxy
name: dc
fqdn: dc.ibb-tga.local[/code]

Die zweite IP habe ich zum testen gesetzt, aber diese wird bei einer DNS Abfrage auch nicht angezeigt.

[code]udm dns/host_record list --superordinate zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local --filter relativeDomainName=dc

relativeDomainName=dc
DN: relativeDomainName=dc,zoneName=ibb-tga.local,cn=dns,dc=ibb-tga,dc=local
ARG: None
a: 192.168.95.1
a: 192.168.95.5
name: dc
zonettl: 80600 seconds[/code]

In den Rechner Einstelungen in der Web Oberfläche habe ich die beiden IP Adressen gesetzt. Dort sind auch Forward und Reverse Zone eingetragen.

Der DC hat zwei Netzwerkkarten. Eine nach extern (192.168.178.X) und eine nach Intern (192.168.95.1 und .5). Ein host -t A dc.ibb-tga.local liefert allerdings 192.168.178.X und 192.168.95.1

Schon mal vielen Dank für die Hilfe.

Viele Grüße,

Bastian Weißbach

Danke für die Informationen.

Schauen Sie bitte weiterhin nach, welches DNS-Backend aktiv ist (»ucr get dns/backend«). Hier gibt es zwei, entweder, der Bind holt sich die Infos aus dem LDAP, oder vom Samba-4-Prozess.

Weiterhin bitte einmal prüfen, ob es Konflikte bei der Synchronisation zu Samba 4 gab (»univention-s4connector-list-rejected«).

Hallo,

die Meldungen erstaunen mich selbst:

ucr get dns/backend --> samba4

univention-s4connector-list-rejected
Traceback (most recent call last):
File “/usr/sbin/univention-s4connector-list-rejected”, line 159, in main()
File “/usr/sbin/univention-s4connector-list-rejected”, line 122, in main False)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/init.py”, line 760, in __init__timeout=-1, sizelimit=0)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 552, in search_ext_smsgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 548, in search_ext timeout,sizelimit,
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 106, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {‘desc’: “Can’t contact LDAP server”}

So weit ich das überblicke sollte Samba allerdings laufen.

Viele Grüße,

Bastian Weißbach

Ha, damit hat man doch Anhaltspunkte

Der s4connector versucht, sich über einen Hostnamen mit dem Samba-LDAP zu verbinden. Dafür wird der Hostname genommen, der in der UCR-Variablen »connector/s4/ldap/host« steht. Meine Vermutung ist, dass dort nun der Hostname Ihres Master-Servers drinsteht und dieser Hostname weiterhin auf die alte Adresse auflöst, und daher der s4connector den Host nicht kontaktieren kann.

Ein Durchsuchen mit »univention-s4search« könnte so momentan ebenfalls nicht funktionieren.

Das könnte momentan auch generell ein Problem sein.

Was Sie versuchen können, ist die Variable »connector/s4/ldap/host« mal auf einen Hostnamen zu setzen, der definitiv auf den lokalen Master auflöst und auf keinen Fall auf eine nicht mehr existente Adresse. »localhost« könnte so ein Kandidat sein. Danach den s4connector einmal neu starten (»service univention-s4-connector restart«) und schauen, ob die Einträge nun wieder synchronisiert werden, auch mit dem bereits erwähnten »univention-connectors4-list-rejected« nachträglich prüfen.

Alternativ könnten Sie schauen, auf welche Adresse(n) der Hostname in »connector/s4/ldap/host« momentan noch auflöst und diese Adressen kurz manuell (nicht über die UMC!) auf das Interface konfigurieren (»ip add 192.168.x.y/24 dev eth0«), die ganze Geschichte synchronisieren lassen, damit die DNS-Einträge nun wieder stimmen, danach die IP-Adresse(n) wieder entfernen (oder halt rebooten).

Hallo,

ich habe das ganze Versucht, leider ohne Ergebnis.

Ich habe zunächst “ucr set connector/s4/ldap/host=‘localhost’” die Adresse auf localhost gesetzt. Dann den Dienst neu gestartet. Wenn ich jetzt univention-s4search aufrufe, steht da aber noch der alte ldap URL drin.

Failed to connect to ldap URL ‘ldaps://dc.ibb-tga.local’ - LDAP client internal error: NT_STATUS_CONNECTION_REFUSED

Vielen Dank schonmal

Ich meinte, dass mit der Änderung der Variablen der s4-connector danach hoffentlich wieder eine Verbindung bekommt und die Einträge richtig synct, woraufhin hoffentlich dann auch die DNS-Abfrage wieder richtig funktionieren sollte. Das univention-s4search ist davon nicht betroffen, weil das diese Variable nicht benutzt.

Haben Sie nach dem Setzen der Variablen den univention-s4-connector neu gestartet? Falls ja, was sagt die Logdatei /var/log/univention/connector-s4.log? Irgend welche Fehlermeldungen?

Und klappt jetzt der Aufruf mit univention-s4connector-list-rejected?

Hallo,

leider keine Hilfreichen Fehlermeldungen in der connector-s4.log:

tail -f /var/log/univention/connector-s4.log 17.06.2015 13:40:47,137 MAIN (------ ): DEBUG_INIT 17.06.2015 13:40:47,172 LDAP (ERROR ): Failed to lookup S4 LDAP base, using UCR value. 17.06.2015 13:40:52,184 MAIN (------ ): DEBUG_INIT 17.06.2015 13:40:52,223 LDAP (ERROR ): Failed to lookup S4 LDAP base, using UCR value. 17.06.2015 13:40:57,236 MAIN (------ ): DEBUG_INIT 17.06.2015 13:40:57,275 LDAP (ERROR ): Failed to lookup S4 LDAP base, using UCR value. 17.06.2015 13:41:02,287 MAIN (------ ): DEBUG_INIT 17.06.2015 13:41:02,326 LDAP (ERROR ): Failed to lookup S4 LDAP base, using UCR value. 17.06.2015 13:41:07,339 MAIN (------ ): DEBUG_INIT 17.06.2015 13:41:07,393 LDAP (ERROR ): Failed to lookup S4 LDAP base, using UCR value.

Entsprechend funktionieren auch die anderen tools weiterhin nicht. Samba4 läuft allerdings.

Viele Grüße,

Bastian Weißbach

Nochmal meine Nachfrage: haben Sie den univeniton-s4-connector nach der Änderung der UCR-Variable neu gestartet? Sicherheitshalber sollten Sie ihn direkt jetzt noch mal neu starten und vorher noch einmal nachschauen, was der Wert der Variablen connector/s4/ldap/host ist.

Hallo,

ich habe es nochmal probiert:

rootr# ucr set connector/s4/ldap/host='localhost'Setting connector/s4/ldap/host root# service univention-s4-connector restart [info] Stopping univention-s4-connector daemon. done. [info] Starting univention-s4-connector daemon. done. root# univention-s4connector-list-rejected Traceback (most recent call last): File "/usr/sbin/univention-s4connector-list-rejected", line 159, in <module> main() File "/usr/sbin/univention-s4connector-list-rejected", line 122, in main False) File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 760, in __init__ timeout=-1, sizelimit=0) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 552, in search_ext_s msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 548, in search_ext timeout,sizelimit, File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Ich frage mich auch ob das hilft. Der Server ist ja auch über die externe IP adresse erreichbar. Zumindest vom Server aus. Daher sollte univention-s4connector-list-rejected ja aufjeden fall funktionieren oder sehe ich das falsch? Ich habe Probeweise beim samba das bind only ausgestellt und die anderen Variablen wieder auf ihre ursprungswerte gestellt. Trotzdem bleibt das Ergebnis gleich.

Viele Grüße,

Hmm, OK, dann weiß ich da leider aus dem Stehgreif auch nicht weiter. Wie alt ist die Installation denn? Wäre ein Neuaufsetzen zu aufwändig? Ihr erster Beitrag klingt so, als wäre das noch ein ganz frischer Server.

Hallo,

frisch ja mehr oder weniger. Ich denke ich werde ihn neu aufsetzten, hätte aber gern gewusst was genau da schief gelaufen ist, damit ich nicht nochmal den gleichen Fehler machen.

Trotzdem vielen Dank für Ihre Hilfe.

Viele Grüße,

Bastian Weißbach