Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Probleme mit Samba, NFS, FTP und Co.
Antworten
Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 20.03.2018 22:13:09

Hallo zusammen,

ich habe mir unter Debian9 mit Samba (4.7.5) und Bind9 (9.11.3) einen AD-Controller eingerichtet. Soweit läuft alles einwandrei, bis auf ein kleines Problem: Wenn ich unter Windows mit RSAT im DNS einen Hosteintrag erstelle, wird kein PTR-Eintrag erzeugt (der Haken, dass ein PTR erzeugt werden soll, ist natürlich gesetzt). Die Reverse-Lookup Zone ist eingerichtet, manuell erzeugte PTR-Einträge funktionieren auch. Lediglich das automatische erzeugen der PTR-Einträge bei manuell hinzugefügten Hosts funktioniert nicht. DHCP ist nicht eingerichtet, das System ist für mich zu Hause zum testen und üben.
Ich habe dieses Problem bereits in den Tickets von Samba gesehen, der letzte Eintrag dort ist jedoch von 2014 - daher "dachte" ich mir eigentlich, dass das Thema schon lange gelöst sein sollte - ich bekomm es aber leider nicht zum laufen.
Kennt sich da vielleicht jemand aus und könnte mir einen Lösungsansatz geben?


Danke,

Lauri

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von eggy » 21.03.2018 08:03:31

Willkommen im Forum.

Ohne die Bind/Samba configs wird Dir wahrscheinlich niemand was genaues sagen können. Links im Menü gibts "NoPaste", da kannst Du sie hochladen (und dann hier entsprechend verlinken), falls Du Teile anonymisieren willst: denke bitte daran das an den jeweiligen Stellen deutlich zu machen. Wenn Du die entsprechenden Sambatickets verlinkst, ersparst Du möglichen Helfern das Suchen. Mal nen Link anklicken machen sicherlich einige, selbst ne halbe Stunde in Recherche versenken, für ein Problem, das sie selbst nicht haben, wohl eher wenige

Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 21.03.2018 17:58:48

Hallo zusammen,

hier wie gewünscht der Inhalt der config-Dateien. Sind natürlich ein paar mehr, aber ich kann durchaus nachvollziehen, dass ohne diese Files eine Analyse des Problems schwer möglich ist.

Configfiles Bind9:

named.conf

Code: Alles auswählen

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/usr/local/bind9/etc/named.conf.options";
include "/usr/local/bind9/etc/named.conf.local";
include "/usr/local/bind9/etc/named.conf.default-zones";
include "/usr/local/samba/private/named.conf";
named.conf.options

Code: Alles auswählen

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                192.168.0.254;
                8.8.8.8;
        };
        notify no;

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation no;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { no; };
};
named.conf.local

Code: Alles auswählen

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
named.conf.default-zones

Code: Alles auswählen

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};
Configfiles KRB5 (Kerberos):

krb5.conf

Code: Alles auswählen

[libdefaults]
        default_realm = TEST.HOME

# The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
        fcc-mit-ticketflags = true

[realms]
        TEST.HOME = {
                kdc = VERLEIHNIX
                admin_server = VERLEIHNIX
        }
        ATHENA.MIT.EDU = {
                kdc = kerberos.mit.edu
                kdc = kerberos-1.mit.edu
                kdc = kerberos-2.mit.edu:88
                admin_server = kerberos.mit.edu
                default_domain = mit.edu
        }
        ZONE.MIT.EDU = {
                kdc = casio.mit.edu
                kdc = seiko.mit.edu
                admin_server = casio.mit.edu
        }
        CSAIL.MIT.EDU = {
                admin_server = kerberos.csail.mit.edu
                default_domain = csail.mit.edu
        }
        IHTFP.ORG = {
                kdc = kerberos.ihtfp.org
                admin_server = kerberos.ihtfp.org
        }
        1TS.ORG = {
                kdc = kerberos.1ts.org
                admin_server = kerberos.1ts.org
        }
        ANDREW.CMU.EDU = {
                admin_server = kerberos.andrew.cmu.edu
                default_domain = andrew.cmu.edu
        }
        CS.CMU.EDU = {
                kdc = kerberos-1.srv.cs.cmu.edu
                kdc = kerberos-2.srv.cs.cmu.edu
                kdc = kerberos-3.srv.cs.cmu.edu
                admin_server = kerberos.cs.cmu.edu
        }
        DEMENTIA.ORG = {
                kdc = kerberos.dementix.org
                kdc = kerberos2.dementix.org
                admin_server = kerberos.dementix.org
        }
        stanford.edu = {
                kdc = krb5auth1.stanford.edu
                kdc = krb5auth2.stanford.edu
                kdc = krb5auth3.stanford.edu
                master_kdc = krb5auth1.stanford.edu
                admin_server = krb5-admin.stanford.edu
                default_domain = stanford.edu
        }
        UTORONTO.CA = {
                kdc = kerberos1.utoronto.ca
                kdc = kerberos2.utoronto.ca
                kdc = kerberos3.utoronto.ca
                admin_server = kerberos1.utoronto.ca
                default_domain = utoronto.ca
        }

[domain_realm]
        .mit.edu = ATHENA.MIT.EDU
        mit.edu = ATHENA.MIT.EDU
        .media.mit.edu = MEDIA-LAB.MIT.EDU
        media.mit.edu = MEDIA-LAB.MIT.EDU
        .csail.mit.edu = CSAIL.MIT.EDU
        csail.mit.edu = CSAIL.MIT.EDU
        .whoi.edu = ATHENA.MIT.EDU
        whoi.edu = ATHENA.MIT.EDU
        .stanford.edu = stanford.edu
        .slac.stanford.edu = SLAC.STANFORD.EDU
        .toronto.edu = UTORONTO.CA
        .utoronto.ca = UTORONTO.CA
Configfiles Samba:

smb.conf

Code: Alles auswählen

# Global parameters
[global]
        netbios name = VERLEIHNIX
        realm = TEST.HOME
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
        workgroup = TEST
        spoolss: architecture = Windows x64
        wins support = yes
        name resolve order = wins lmhosts hosts bcast
        dns proxy = yes

[netlogon]
        path = /usr/local/samba/var/locks/sysvol/test.home/scripts
        read only = No

[sysvol]
        path = /usr/local/samba/var/locks/sysvol
        read only = No

named.conf

Code: Alles auswählen

# This DNS configuration is for BIND 9.8.0 or later with dlz_dlopen support.
#
# This file should be included in your main BIND configuration file
#
# For example with
# include "/usr/local/samba/private/named.conf";

#
# This configures dynamically loadable zones (DLZ) from AD schema
# Uncomment only single database line, depending on your BIND version
#
dlz "AD DNS Zone" {
    # For BIND 9.8.x
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";

    # For BIND 9.9.x
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";

    # For BIND 9.10.x
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";

    # For BIND 9.11.x
    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so";
};
named.conf.update

Code: Alles auswählen

/* this file is auto-generated - do not edit */
update-policy {
        grant TEST.HOME ms-self * A AAAA;
        grant Administrator@TEST.HOME wildcard * A AAAA SRV CNAME;
        grant VERLEIHNIX$@test.home wildcard * A AAAA SRV CNAME;
};
Ich hoffe, das waren alle Files die ihr für die Analyse braucht, ansonsten bitte einfach bescheid geben - ich gebe alles an, was für die Analyse notwendig ist oder sein könnte.
Den Link zum Ticket habe ich noch nicht wieder gefunden, sonst hätte ich den auch bereits gepostet.


Vielen Dank,

Lauri

Benutzeravatar
pangu
Beiträge: 1400
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von pangu » 21.03.2018 20:07:21

Hey Lauri,

das ist was bekanntes bei Samba4 und dem ADUC tool. Aber probier erstmal über CLI ob du den PTR-Eintrag erzeugen kannst, damit man erst mal weiß ob deine DNS config soweit i.O. ist

Code: Alles auswählen

samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 55 PTR demo.samdom.example.com
Ich denke aber schlichtweg dass diese Funktion nicht geht wenn du mit dem RSAT tool arbeitest. (ist bei einer Installation von mir ebenfalls der Fall, aber ältere Version von samba4 und noch auf Jessie.)

Ansonsten frag mal im channel #samba oder #samba-technical nach (IRC). Abartlet wird dir sicherlich gleich sagen können ob das mittlerweile funzt oder nicht ;)
Viel Erfolg.
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 21.03.2018 23:22:23

Hallo,

erst mal lieben Dank für Deine Hilfe. Manuelles anlegen von PTR-Einträgen funktioniert einwandfrei, sowohl über die CLI als auch über RSAT. Deshalb hat es mich ja so gewundert, dass das "automatische" erzeugen von PTR-Einträgen bei manuell angelegten Hosts nicht funktioniert. Seis drum, wenn das Problem bekannt ist, dann kann ich damit durchaus leben - ich wollte lediglich verhindern, dass irgendwas noch nicht einwandfrei funktioniert und ich nachher (wenn ich mal ein Problem bekomme) an der falschen Stelle suche. Denn wenn die Grundinstallation nicht sauber läuft, kann im nachhinein ja alles mögliche schieflaufen und ich werde immer an Stellen suchen die schuldlos sind.
Von daher kann das Thema denke ich als "solved" geschlossen werden - mit der Info dass es auch bei Dir nicht funktioniert bin ich soweit erst mal zufrieden und kann aufhören, einen Fehler bei mir zu suchen ;)


Gruß,

Lauri

Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 22.03.2018 18:29:58

Ok,

ich habe wohl doch noch ein grösseres Problem.
Zum einen wird der Samba-Server nicht zum Master Browser - egal welches OS-Level ich einstelle - selbst mit 255 erhält immer einer der PCs aus der Domäne den Master Browser. Zum anderen wird der Server nicht in der Netzwerkliste angezeigt - es ist keinerlei Router, Firewall oder ähnliches dazwischen - ich habe hier jetzt 2 Testmaschinen, 1 mit Windows 7, 1 mit Windows 10. Auf beiden sind sämtliche Firewallfunktionalitäten deaktiviert, trotzdem ist der Samba-Server nicht zu sehen. Wenn ich manuell auf den Server zugreife funktioniert natürlich alles, inkl. Benutzerrechten, Drucker etc. - alles so wie man es sich wünscht. Aber die Probleme häufen sich leider grade:

- kein automatischer PTR-Eintrag im DNS bei manuell hinzugefügten Hosts
- der Server ist weder unter Windows7 noch unter Windows 10 sichtbar
- der Server wird, trotz Einstellung und OS Level 255 nicht Master Browser


Kann sich da jemand einen Reim drauf machen?


Danke,

Lauri

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von eggy » 23.03.2018 05:47:31

Fehlende/falsche WINS Einträge (brauchen WIN7/10 sowas überhaupt noch?) bzw ServiceRecords im DNS vielleicht?
Was sagt denn die Namensauflösung im Detail? Mal manuell versucht? Stimmen die Uhren der Rechner überein?

Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 23.03.2018 08:57:57

Hy,

der Server stellt WINS zur Verfügung und ist auch als WINS auf den PCs eingetragen. DNS-Einträge stimmen an und für sich soweit, wie gesagtg, der AD als solches läuft ja. NTP ist auf dem Server installiert und der Server als NTP-Quelle auf den Maschinen eingetragen - auch das funktioniert, die Maschinen sowie der Server differieren zeitlich nicht.
Es sind "komische" Fehler, irgendwas scheint im Netbios-Bereich nicht zu passen. Deshalb ist der Server nicht sichtbar, aber erreichbar (auf den Windowskisten mit \\[Servername]) und er wird partout nicht Master Browser.
Das Problem ist, dass ich mich mit Linux einfach viel zu wenig auskenne um wirklich selbst analysieren zu können, was da jetzt genau im Netbios-Bereich schief läuft.



Gruß,

Lauri

Lauri
Beiträge: 6
Registriert: 20.03.2018 22:06:12

Re: Samba und Bind9 - kein PTR-Eintrag bei manuell eingetragenen Hosts

Beitrag von Lauri » 23.03.2018 13:17:15

Hallo,

ich habe dazu jetzt (endlich) auch mal eine Aussage seitens dem Samba-Team gefunden, damit klärt sich natürlich so ziemlich alles:
https://lists.samba.org/archive/samba/2 ... 95978.html

kurzer Auszug:
[...]
Browsing is turned off for the DC by design, and this will not change.
Use member servers to implement browsing.
[...]
Klar, wenn Browsing auf dem DC seitens der Software deaktiviert ist, kann ich suchen bis ich schwarz werde, wieso der Server im Netz nicht auftaucht und nicht zum Master Browser wird.

Gruß,

Lauri

Antworten