Dear Andreas, dear Petter, On Mi 05 Jan 2011 19:10:24 CET Petter Reinholdtsen wrote:
[Andreas B. Mundt]I tried to find the reason for these corresponding A-records,There are two aspects coming together to cause this effect. We use strict mode in powerdns, allowing shared A/PTR entries in LDAP, and the fact that SRV and MX records need to point to A records. As our design allow for scaling by moving individual services out by changing DNS entries, we need to use the service names in DNS. And thus, we end up with several PTR entries for 10.0.2.2. :/ Not quite sure how to best adjust this and still get a sensible and scalable solution.I am not an expert regarding that stuff and I don't know if there are other ways to achieve the desired. However, it looks as with the current setup we need service principals for all host aliases.That isn't too bad, is it? It can be added automatically at install time, right?
Kerberos demands a correct ReverseDNS setup. It can handle multiple A-Records for the same IP. Important is that the host principal's IP correctly reverse-resolve to the hostname used in the Kerberos host principal.
For a correctly working NFS4+Kerberos setup you need (it's quite a while ago that I set up my NFS4, so some things might be inaccurate):
o host principals for all clients and servers of the form:
host/<fully.qualified.domain.name>@<REALM>
so for tjener, this is
host/tjener.int...@intern
and for clients this is
host/dhcp001.int...@intern
...
o each host has a keytab entry stored locally that corresponds to the host
principal. This keytab hash must be distributed during client installation
(or retrieved via kadmin-server)
o each service needs a service principal of the form
<servicename>/<fully.qualified.domain.name>@<REALM>
so these might be:
ldap/tjener.int...@intern
nfs/tjener.int...@intern
etc.
o these service principals' credentials have to be distributed to all
clients' keytab files individually
on dhcp001: kadmin -q ktadd host/dhcp001.int...@intern
kadmin -q ktadd nfs/dhcp001.int...@intern
on dhcp002: kadmin -q ktadd host/dhcp002.int...@intern
kadmin -q ktadd nfs/dhcp002.int...@intern
...
o and then you need principals for each user (and pam_krb5.so to get the
tickets for each user on login)
o some time during squeeze development an extra line in
/etc/krb5.conf became
necessary:
[libdefaults]
default_realm = INTERN
allow_weak_crypto = true # needed for NFSv4
o using NFS4+Krb5 starts really making sense when using at least
sec=krb5i as
mount option. Then you really need a user's Krb5 ticket to be able to
connect to an NFS4 share
o for this to work you need Kerberos authentication (PAM, see above)
o and also a running idmapd (nfs-common package)
o Kerberos5 (MIT) has an LDAP backend, not sure about Heimdal.
Kerberos is or
was problematic about U.S. export restrictions/regulations. So in this
respect the choice should be Heimdal, but I am not sure if Heimdal has an
LDAP backend...
o authentication to LDAP via Kerberos can be handled by saslauthd (which is
very neat).
For NFSv4 on Skolelinux I do recommend
o sec=krb5p for teachers and
o sec=krb5i for students.
I also recommend one autofs rule for each user and to store them in
LDAP (nisMapName obejctclass). I am not sure, if Skolelinux's
automount mechanism already uses this setup. Then at least you can
store the NFS mount options in LDAP and differentiate between user
groups concerning nfs4-integrity mounts (sec=krb5i) and nfs4-privacy
mounts (sec=krb5p).
Mounting all NFS shares via krb5p (or NFS-encrypting one big mount point like /skole/home/tjener0) I do absolutely not recommend. NFSv4 encryption is quite CPU-sucking...
I am really interested in NFSv4+Kerberos5 integration in Skolelinux. So if I can be of any help, let me know.
Regards, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0x1943CA5B mail: m.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpuFWy7vqmOG.pgp
Description: Digitale PGP-Unterschrift
