El 01/04/12 15:21, Anton Aylward escribió:
lynn said the following on 04/01/2012 03:06 AM:
El 31/03/12 20:57, Anton Aylward escribió:
lynn said the following on 03/31/2012 01:54 PM:
On 03/31/2012 06:59 PM, Anton Aylward wrote:
lynn said the following on 03/31/2012 11:36 AM:
Then you don't have ddns working _completely_. Sorry if I seem picky, but we are definitely in a realm where accuracy and completeness matters.
No, be as picky as necessary. I need it.
KDC = Kerberos Domain Controller ?
Yes.
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. The forward zone is created when I start bind. 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.
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.
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.
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. The KDC is supplied by Samba so Samba must be up before any ddns takes place. 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.
How come the windows clients work OK. What do they have that we don't?
I don't know. I'm not very Windows-savvy.
Actually we are *assuming* things here. Did you do the dump of the DNS tables? How do I do a dump?
If we see in that dump that the Windows clients have both forward and reverse entries we know they are doing something the Linux clients are not. Then and only then can we say they are working OK in this sense of OK.
Will post it as soon as I know how. Meanwhile am running with the mysterious 127.0.1.1:-( Thanks again for your time, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org