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:
Do I need a PTR for each computer on the lan? If you had ddns working then it would be done 'auto-magically'.
Yes. I have ddns working. The forward zone is updated by Samba4 when new machines are allocated IP's, join the domain etc. I just didn't have a reverse lookup zone.
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.
I suppose the
test would be to remove the 127.0.1.1 hostname.fqdn hostname entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test. See later ....
There are two ways to can get their reverse addresses to work. The first is to use 'dynamic dns' where the DHCP server tells the DNS server that it has assigned an address and supplies the details which the DNS server can now had out in response to queries.
I think that is what is happening because you can see the KDC receive requests from IP's which have been allocated via DHCP _and_ correctly lookup their Kerberos machine$/fqdn key correctly for authentication.
KDC = Kerberos Domain Controller ? 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.
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.
I do know the code I've seen has kerberos calling "krb_mk_req()" to get a ticket and that needs the FQDN as a parameter.
... and it needs other parameters but I forget, ....
Kerberos needs not only to authenticate the user but also the machines on the lan. When I logon, both I and my computer have to authenticate. If I request a file then both I and the fileserver have to authenticate. This is why the dns is crucial with Kerberos.
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.
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. Since its supplying both IP address and name, the DNS server should be able to slot RRs in for both forward and backward zones. 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.
Yes, but unless it contains the crypto key shared by DHCP and DNS then DDNS won't work. This should have been generated by YAST. Its one of the options, like deleting IPv6, that you should have set. In my case, the ddns is handled elsewhere so no problem.
Yes, but it seems only for the Windows clients. With the linux clients up you should be able to do a reverse lookup for each of them.
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? 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. -- Plunderers of the world, after they, laying everything waste, run out of land, they probe even the sea: if their enemy has wealth, they have greed; if the enemy be poor, they are ambitious; neither East nor West has sated them; alone of mankind they covet poverty with the same passion as wealth. Robbery, butchery, rape they misname Empire: they make a wasteland and call it peace. - Tacitus, Agricola 80 The speech of Calgacus the Caledonian at the battle of Mons Graupius -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org