lynn said the following on 04/01/2012 04:41 PM:
To correctly look up FQDN from only a IP requires treat DNS properly implements reverse lookup. We've established you don't have complete and accurate reverse tables.
Could you please elucidate.
I do not have reverse lookup.
Then I can't see how you can expect this to work properly. And no, spoofing Kerberos by fiddling with /etc/hosts 127.0.0.1 entry is not "working properly". Carlos is quite right, that is localhost.localdomain and cannot be anything else without breaking other fundamentals. Changing it to the fqdn to get around the absence of reverse lookup is subverting Kerberos.
The forward zone is created when I start bind.
Picky: No, when you start bind it reads the config file and builds its internal map so that it can respond to queries about the forward zone. You need to have that zone defined and all the static devices in it (servers, firewalls, routers) as defined resource records (RRs) DHCP will add and remove more RRs - if you have the thing set up properly and DHCP knows about the shared cypto key needed for secure communications.
It get updated when a new client (Linux or windows) boots or joins the domain. For ddns it has a tsig which is a Kerberos keytab. The keytab was produced when the AD was first provisioned. I posted he named.conf a few posts ago. I also have a static reverse zone. The only thing that prevents it too from being included in the ddns is that I don't know how to generate a keytab for it. This is where the Samba guys have changed the bind innards.
Try reading http://www.oceanwave.com/technical-resources/unix-admin/nsupdate.html You recall that bind complained about a file and you created it (empty) with 'touch'? Well guess what....
Are you running AD? You have a Microsoft domain master running AD or are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
I think we are talking at cross [purposes or I need an update. I thought SAMBA was acting as a Domain Controller and that the AD was the database, possibly (but not always) implemented by LDAP.
AD = Active Directory, a dynamically maintained database, a directory service that runs on the Domain Controller and needs DNS, Kerberos and LDAP to support it.
I thought SAMBA was more than just AD.
Samba4 is a windows domain controller. It consists of a totally Linux-ified AD. It has its own built in KDC and LDAP server.
Soon, it will have its own DNS server too. It already has its own working DNS server but ironically it only works for forward ddns at the moment.
You keep asserting that, but can you give reference please.
Kerberos needs not only to authenticate the user but also the machines on the lan. That is why *properly implemented* DNS is crucial with Kerberos.
If the code can't do a full backward-for-ward-backward verification of the IP/FQDN from the *authoritative* (and presumably secured) DNS service then the fallback to the /etc/hosts is a security hole. The user in control of the client machine can put whatever he (or she) likes into /etc/hosts and so spoof the identification.
Only root has access to /etc/hosts on our lan.
Picky: Its not meant to be accessed from the LAN, its meant to be accessed from local programs, including ones that are not running as root. It should be 0644/root:root. Carlos, others, would you care to verify that and explain to Lynn why /etc/hosts needs to be readable by everyone. Check /etc/permissions
Now the question I'm left with is this. Is the machine up and running, has it got its IP address from the DHCP server?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the DHCP server telling the DNS server.
The address is handed out after the Linux machine is booted, long before the SAMBA client comes up, so the SAMBA side of things should have nothing to do with it. All this DDNS should work regardless of the presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it running in that kind of setting.
Kerberos has to authenticate the dns server before it can do anything on the lan.
Please explain. Are you saying that before the DNS server program listening on port 53 on the server machine can respond to DNS requests from the machine some Kerberos authentication has to take lace? Of what and by what? What about the DHCP server program running on the server ... ?
The KDC is supplied by Samba so Samba must be up before any ddns takes place.
No, that doesn't make sense. Take all the Windows stuff off your LAN, disable SAMBA and run it just as a Linux server and Linux clients. (or Linux server and Solaris clients, or AIX clients or HP-UX or DG-UX). You're running DHCP and BIND, so it must still be able to work. And I know, BTDT, that DDNS works without SAMBA in that kind of setup. I'm sure there are many people on this list who are or who have clients that are running DHCP<->DDNS<->BIND. Yes, I'm sure that one-day/some-day SAMBA will have built in replacements for all this (and probably its own internal database so you can forget about LDAP, forget about everything about Linus except the kernel...) but this is now. I'm sure that SAMBA *does* deal with the Windows side of things quite well, but what we are discussion is getting Linux machines working with Kerberos. That means getting forward and reverse DNS entries working. And if these machines have addresses handed out by DHCP that means either "cheating" (as I've described) or getting DDNS working.
We can however show that the clients have an IP before doing a domain logon as they can ping the server on bot IP and fqdn (because the server is in their etc/hosts file. The missing link seems to be what the windows clients have instead of /etc/hosts.
Googling I see mention of c:\windows\system32\drivers\etc\hosts Please note: Unlike the DNS, the hosts file is under the direct control of the local computer's administrator. That's why it should be *writeable* only by root and end users should not have root access. In addition, your nsswitch should prefer DNS and only use the host file when DNS isn't available. See also http://support.microsoft.com/kb/172218
Actually we are *assuming* things here. Did you do the dump of the DNS tables?
How do I do a dump?
Send a signal to the server, as I described in the except from the man page in an earlier mail. -- If computers get too powerful, we can organize them into a committee - that will do them in. -- Bradley's Bromide -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org