Hi, On Do 06 Jan 2011 19:57:43 CET "Andreas B. Mundt" wrote:
Ok. But currently there is no service working propperly at all with kerberos tickets, because of the issue with the multiple A-records. So this is the first thing we have to solve. I suggest to switch back to CNAME-records and use tjener for the service records. If someone wants to move a service (say ldap) to another machine, he has to change the corresponding service record, add an A-record and a principal for that new machine ldap.intern and remove the ldap-CNAME for tjener. Makes sense?
I am not yet convinced that Kerberos bothers about the A recordsYou may take a look at this document that dives into diverse DNS+Kerberos setup possibilities:
http://www.faqs.org/faqs/kerberos-faq/general/section-47.htmlAnother solution might be the "one IP adresse per interface per service" approach where the interfaces on tjener then would be virtual (eth0:1, eth0:2, etc.).
When pulling a single service to a standalone machine then for load sharing you then have to use the service's IP on the new machine and shutdown the virtual interface on the main tjener, which is a bit more of a hassle compared to a DNS A record change via a nice WebGUI.
Maybe I miss something, but this looks more sensible to me than creating all combination of A-records and service principals like nfs/ldap.int...@intern where service and machine have absolutely nothing in common.
The nfs/<client>.int...@intern principal is for NFS clients only (as far as I remember), not for the server (unless you want to NFS-mount locally). On my root servers I tried to create service keys with <service>/<alias>.dom...@realm, which failed because my provider IP reverse-resolved to the systems FQDN and not to its <alias>.
If you have only one IP set up on tjener then you can use only <service>/tjener.int...@intern because you can only reverse-resolve this one IP to one name (which probably is tjener.intern).
If you want to use aliase names on the clients during Kerberized authentications then you probably really need one IP address per service (so that the IP address always reverse-resolves to the quasi-service-alias (being an A record with RevDNS entry).
BTW: You also have to make sure that DNS returns long hostnames of the form host.domain. Some DNS servers can be configure to return the local zone's hostnames only. Don't know if tjener's powerDNS setup does this.
Ok, assume we have found a solution and implemented it, single sign on works again. How to continue?
Sure we can start to implement Kerberos for GOsa, CUPS and Nagios. For CUPS it should be a matter of configuration, for GOsa it's hacking the source, implementing kerberos, preparing patches and asking upstream to include them. I don't know if this is our goal and I don't see the advantage either; looks like replacing a root-readable password by a root-readable keytab (correct me if I'm wrong).
This really sound like a bunch of work that should only be addressed if is sustainable...
Perhaps we can look if apache can be configured to demand a Kerberos ticket to access the GOsa page. And Nagios is a "nice to have", I assume.
Apache can authenticate (and authorize) against LDAP, LDAP can proxy the authentication request via saslauthd (I start repeating myself on this list, sorry!!!) to KDC... (this catches NAGIOS).
CUPS can use PAM auth which can authenticate against KDC directly...
However, if we manage to get NFS4 working for the home directories, I see only advantages: We can try to get also sec=krb5p or sec=krb5i (as Mike suggested: for teachers and students) working.
Cool!!!
And if this is possible we might gain the potential to finally get rid of IP/netgroup stuff solving us many headaches. If not, we have not lost anything at all, because we can keep NFS4 without added security features, something we will need anyway sooner or later.
COOL!!!
Any opinions? Something I missed? Better ideas?
Just as a side note along DNS+Kerberos...There is a DNS implementation that lets clients detect the REALM's KDC via DNS. The Shishi people have written a quite easy-to-read docpage on it...
http://www.gnu.org/software/shishi/manual/html_node/Configuring-DNS-for-KDC.html Being quite verbose tonight... 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
pgplexwle5siE.pgp
Description: Digitale PGP-Unterschrift
