_ldap._tcp.<domain>.<tld>: Port 389 statt 7389

ich habe hier eine schon länger existierende UCS Domäne mit einem reinen UCS master, UCS backup und einem Slave als S4 Server. Dabei ist mir aufgefallen, dass ein ‘host -t SRV _ldap_tcp..’ alle drei DCs mit Port 389 als Antwort zurückgibt.

Ich denke dabei, dass das auf den ersten Blick Problematisch ist, weil beim S4 Server auf Port 389 Samba 4 läuft und entsprechend andere Attribute zurückgibt (sAMAccountName statt uid etc.). AD/S4 benutzt ja andere SRV records wie _ldap._tcp.dc._msdcs..

Jetzt die Fragen:

  • Wäre es nicht besser die Records auf Port 7389 anzupassen?
  • Muss ich damit rechnen, dass Probleme auftauchen, wenn man die Einträge ändert?
  • Warum ist das noch so? (allenfalls ien Fehler in UCS beim joinen?

Im Konkreten Fall habe ich eine Software, die so schlau wäre, diese SRV records abzufragen, wodurch eine explizite Konfiguration der LDAP Server entfallen würde (damit auch wenn ein LDAP-Server den Hostnamen wechselt etc.)

Besten Dank im voraus!

Da mich dieses Thema interessiert, habe ich mal kurz recherchiert.

Laut https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc961719(v=technet.10) ist _ldap._tcp.DnsDomainName. schon ein von Microsoft für AD verwendetes Vehikel. Neuere Dokumentationen, wie z.B. https://blogs.msdn.microsoft.com/servergeeks/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory/ nehmen darauf aber keinen Bezug mehr.

Port 7389 wird seit UCS 3.2 (http://forge.univention.org/bugzilla/show_bug.cgi?id=30890) nicht mehr gesetzt.

Besten Dank, interessanter Link zum Bug. Etwas gemein ist, dass _ldap._tcp SRV records in RFC2782 (“A DNS RR for specifying the location of services (DNS SRV)”), spezifiziert sind.

RFC2782 habe ich in etwas älteren MS-Dokumentation durchaus auch erwähnt gefunden. Es ist also kein reines AD-Konstrukt. In einem reinen OpenLDAP UCS könnte man das sogar so belassen, aber in meinem Fall ist S4 auf einem Teil der UCS DCs installiert.

In meinem Fall schliesse ich daraus, dass ich besser die _ldap._tcp SRV records der reinen UCS OpenLDAP DCs aus dem DNS entferne. Und ja, soweit erkennbar dürfte die UCS Domäne mit einer frühen 3er Version oder 2.4 initial gestartet haben, also definitiv vor dem 3.2 resp. bevor Univention Bug 30890 geschlossen wurde.

Was aber ich dabei im verlinkten Bug unschön finde, ist dass bestehende SRV-Records nie durch Upgradescripte oder geprüft und allenfalls min. auf Vorschlag hin entfernt wurden. Denn eigentlich - und soweit ich den Bug verstehe - dürften der AD-Kompatibilität nur S4 DCs in diesen SRV-Records auftauchen. Richtig?

Huhu,

Der _ldap._tcp mit Port 389 ist nicht falsch. S4 ist auch ein LDAP, dessen Inhalt zu einem Großteil mit dem OpenLDAP-Inhalt übereinstimmt. Es hängt sogar sehr von der Anwendung ab, ob diese besser mit einem OpenLDAP- oder mit einem ActiveDirectory-LDAP-Schema zurecht kommt. Meiner Erfahrung nach ist die Anzahl der Anwendungen, die mit AD-LDAP-Schema gut zurecht kommen, sogar höher als die der Anwendungen, die mit OpenLDAP-Schema zurecht kommen.

Gruß
mosu

1 Like
Mastodon