Samba4-DNS-Zone Unterschiede zu Standard Univention-DNS-Zone

german

#1

Guten Tag

Wir haben hier eine Samba4 Installation mit UCS3.1-1. Samba4 ist auf dem DC-Backup installiert und der DC-Master hat keine Samba4 Installation. Nun hatten wir Probleme mit dem Kerberos siehe https://forge.univention.org/bugzilla/show_bug.cgi?id=30973. Deswegen ist diese Frage aufgetaucht. Wir haben die selbe DNS-Zone mittels dig AXFR auf dem DC-Master ausgegeben und auf dem DC-Backup. Uns war ganz klar bewusst dass beim Bind-Backend einmal Univention-LDAP und einmal Samba4 verwendet wird. Deshalb sollte die dig AXFR Ausgabe auch Unterschiedlich ausfallen. Warum sind aber z.B. die SRV Records von Kerberos unterschiedlich oder gar nicht mehr vorhanden?
Wie funktioniert die pseudo Replikation dieser DNS-Server? Weil doch jeder DNS Server seine Daten aus dem LDAP bezieht, aber einmal ist es der Univention-Openldap und bei Samba4 ist der eigens mitgelieferte LDAP Server. Der Samba4-LDAP wird mittels S4-Connector gesynct.

Der S4-Connector Mappings konnten wir keine expliziten Ausschlüsse finden. Wie könnte man den"RESYNC" der LDAP-Zonen auf dem Samba4 Server anstossen?

Leider findet man nirgends Hinweis was alles angepasst wird, wenn man Samba4 installiert. Das macht das Debugging doch einiges schwieriger.

Freundliche Grüsse
RolandB


#2

Hallo,

ich bin nicht sicher ob ich Sie richtig verstehe. In einem standard UCS Samba4 Setup werden die Service-Records auch in das AD synchronisiert und sind damit im Samba4-DNS Backend verfügbar. Eine beispielhafte Antwort eines Samba4 DCs sieht wie folgt aus:; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 s4lish.qa -t AXFR ; (1 server found) ;; global options: +cmd s4lish.qa. 10800 IN SOA master.s4lish.qa. root.s4lish.qa. 38 28800 7200 604800 0 s4lish.qa. 900 IN NS master.s4lish.qa. s4lish.qa. 900 IN A 10.200.6.100 member.s4lish.qa. 900 IN A 10.200.6.101 master.s4lish.qa. 900 IN A 10.200.6.100 win7pro.s4lish.qa. 1200 IN A 10.200.6.103 winxpsp3.s4lish.qa. 1200 IN A 10.200.6.102 _gc._tcp.s4lish.qa. 900 IN SRV 0 100 3268 master.s4lish.qa. gc._msdcs.s4lish.qa. 900 IN A 10.200.6.100 thinclient.s4lish.qa. 900 IN A 10.200.6.199 _ldap._tcp.s4lish.qa. 900 IN SRV 0 100 7389 master.s4lish.qa. _ldap._tcp.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. _kpasswd._udp.s4lish.qa. 900 IN SRV 0 100 464 master.s4lish.qa. _kpasswd._tcp.s4lish.qa. 900 IN SRV 0 100 464 master.s4lish.qa. _kerberos._udp.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _kerberos._tcp.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _kerberos-adm._tcp.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _ldap._tcp.gc._msdcs.s4lish.qa. 900 IN SRV 0 100 3268 master.s4lish.qa. _ldap._tcp.dc._msdcs.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. _ldap._tcp.pdc._msdcs.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. _kerberos._tcp.dc._msdcs.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _domaincontroller_master._tcp.s4lish.qa. 900 IN SRV 0 0 0 master.s4lish.qa. _gc._tcp.Default-First-Site-Name._sites.s4lish.qa. 900 IN SRV 0 100 3268 master.s4lish.qa. _ldap._tcp.Default-First-Site-Name._sites.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. 28425896-4db1-4f8e-89ef-c65af51470c4._msdcs.s4lish.qa. 3600 IN CNAME master.s4lish.qa. _kerberos._tcp.Default-First-Site-Name._sites.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.s4lish.qa. 900 IN SRV 0 100 3268 master.s4lish.qa. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.s4lish.qa. 900 IN SRV 0 100 88 master.s4lish.qa. _ldap._tcp.ebe968ee-68b9-4cf9-8c00-f0c2bef6bafe.domains._msdcs.s4lish.qa. 900 IN SRV 0 100 389 master.s4lish.qa. s4lish.qa. 10800 IN SOA master.s4lish.qa. root.s4lish.qa. 38 28800 7200 604800 0 ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Apr 12 16:30:37 2013 ;; XFR size: 31 records (messages 1, bytes 1406)

Welche Service-Records fehlen in Ihrer Umgebung? Gibt es evtl. Probleme mit der S4-Connector Synchronisation? univention-s4connector-list-rejected bzw. die Logdateien /var/log/univention/connector-s4* sollten hier weitere Hinweise liefern.

Mit freundlichen Grüßen
Janis Meybohm


#3

Guten Tag

Ich habe nachgesehen und dig AXFR @127.0.0.1 +short auf dem DC-Master mit dem DC-Backup (Samba4) verglichen. Hier fehlen diverse SRV Records (alle Kebreos SRV Records). Danach habe ich den S4-Connector nochmals neu gesynct:

http://sdb.univention.de/1151
/etc/init.d/univention-s4-connector stop
mv /etc/univention/connector/s4internal.sqlite /etc/univention/connector/s4internal.sqlite.old
univention-directory-listener-ctrl resync s4-connector
/etc/init.d/univention-s4-connector start
/etc/init.d/samba4 restart

Leider auch dies hat keine Veränderung gebracht. auch Ihr Tipp mit univention-s4connector-list-rejected hat nichts gezeigt:

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: 4517

Wie kann man sonst noch feststellen wo diese Infos verloren gehen? Ich habe auch noch folgendes verglichen:

ldapsearch -xLLL -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret) -b zoneName=sn-srv.test.com,cn=dns,$(ucr get ldap/base) -s one relativeDomainName=_kerberos* dn sRVRecord
Das hat mir gezeigt das der DC-Master und DC_Backup korrekt synchronisiert sind und die Infos beim S4-Connector irgendwie verloren gehen.

Etwas habe ich gefunden:

ucr search connector/s4/mapping/dns connector/s4/mapping/dns/ignorelist: DC=_ldap._tcp.Default-First-Site-Name._site connector/s4/mapping/dns/srv_record/_gc._tcp.default-first-site-name._sites.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_gc._tcp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos-adm._tcp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._tcp.dc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._tcp.default-first-site-name._sites.dc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._tcp.default-first-site-name._sites.gc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._tcp.default-first-site-name._sites.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._tcp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kerberos._udp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kpasswd._tcp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_kpasswd._udp.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.dc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.default-first-site-name._sites.dc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.default-first-site-name._sites.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.gc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.pdc._msdcs.sn-srv.test.com/location: ignore connector/s4/mapping/dns/srv_record/_ldap._tcp.sn-srv.test.com/location: ignore

Wann und warum werden diese vielen ignore Einträge erstellt? Kann man die entfernen?

Grüsse, Rolandb


#4

Hallo

Ich habe alle ignors entfernt, dass es nur noch so aussieht:

ucr search connector/s4/mapping/dns connector/s4/mapping/dns/ignorelist: DC=_ldap._tcp.Default-First-Site-Name._site

Danach wieder folgendes:

/etc/init.d/univention-s4-connector stop mv /etc/univention/connector/s4internal.sqlite /etc/univention/connector/s4internal.sqlite.old univention-directory-listener-ctrl resync s4-connector /etc/init.d/univention-s4-connector start /etc/init.d/samba4 restart

Und nun sind alle fehlenden SRV Redords vorhanden. Jetzt stellt sich die Frage warum und wann wurden diese UCR Variablen erstellt?

Grüsse. RolandB


#5

Hallo,

[quote=“rolandb”]Wie funktioniert die pseudo Replikation dieser DNS-Server?[/quote]die Synchronisation der DNS-Informationen erfolgt im Fall von Samba4 mit dem S4-Connector zwischen Samba4 und OpenLDAP. Die Replikation der Informationen zwischen den Servern erfolgt dann per Listener/Notifier (OpenLDAP) und DRS (Samba4).

Im UCS@school Umfeld gibt es im Bereich der Service-Records einige Besonderheiten, u.a. um die selektive Replikation mit AD zu ermöglichen. Die Trennung der Service-Records zwischen Zentrale und Schul-Servern stellt sicher dass die Anmeldung der Schul-PCs nicht gegen die Zentralen Server erfolgen kann (u.a.). Generell wird die Konfiguration wie folgt vorgenommen:

DC-Master / DC-Backup
Auf DC-Master und/oder DC-Backup werden diverse Service-Records im S4-Connector Mapping als “zu ignorieren” definiert, eine Liste ist dem Join-Script ucs-school-metapackage/62ucs-school-master.inst zu entnehmen.
Dies stellt sicher, dass die Service Records zwar per DRS zwischen den zentralen Samba4 Servern repliziert werden können, jedoch nicht zwischen OpenLDAP und AD synchronisiert werden. So wird z.B. verhindert das neu gejointe Schul-Slaves in das AD der Zentralen Samba4 Server aufgenommen werden.

DC-Slave
Auf DC-Slaves werden diverse Service-Records mit Standardwerten (pro Schule) überschrieben, welche Werte hier verwendet werden können Sie dem Join-Script ucs-school-metapackage/62ucs-school-slave.inst entnehmen.

Mit freundlichen Grüßen
Janis Meybohm