[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS4 and Kerberos: A-records for same IP inflate the need for service principals



Hi,

On Thu, Jan 06, 2011 at 12:24:02PM +0100, Petter Reinholdtsen wrote:
> > However, to come back to the issue, the next step concerning
> > kerberos would be to switch to nfs4.
> 
> I assume you are talking about user home directories and shared
> folders, and not the LTSP root mount, because LTSP do not support NFS4
> yet, and Kerberos based mounting is not really sensible for stateless
> machines.  

Yes, only the home dirs (automounter) on NFS4.

> So we will end up with NFS3 and and NFS4 if we get NFS4
> working for home directories.  But I would love ot get user home
> directory mounting away from netgroup and IP based authentication.
>
> To me the next step with Kerberos would be to get Gosa, CUPS and
> Nagios to use Kerberos tickets when logging in to get rid of the last
> LDAP authentication user and ensure single signon for more services.
>

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?  

Maybe I miss something, but this looks more sensible to me than
creating all combination of A-records and service principals like
nfs/ldap.intern@INTERN where service and machine have absolutely
nothing in common. 

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). 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.   

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. 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.  

Any opinions? Something I missed? Better ideas?

Best regards
     
     Andi


Reply to: