Sorry, I mis-typed.  A realm is an authentication domain.
I think we are in agreement.
(Thats what I get for typing mail too early in the moring.)

Jeffrey Altman wrote:

Douglas E. Engert wrote:

The issue is the AFS cell name is not the same as the user's realm name.
The K5 is using cross realm, where as in the past the krb524d could have
covered this up.

This goes back to what is the difference between a realm and a cell.
I would argue a cell is an authorization domain, a realm is authorization
domain. AFS needs to be able to map a principal in a realm to an afs
user in it cell. By default AFS is assuming the cell name matches the
realm name, or if the realm-of-cell file (forgot the name) is set, then
the cell is in that realm. It needs more flexibility to map foreign
principals to local cell.

This is a practical issue, as newer realms are coming on line which
don't match the older AFS cell names.


I disagree with the statement that a realm is an authorization domain.

Sory, see above. I agree with you.


A realm is an authentication domain. Kerberos authentication provides
an authenticated name and a trust path by which the name was authenticated. It does not provide any form of authorization UNLESS
the Kerberos ticket contains a PAC of ACLs.


In the traditional Kerberos model, the authenticated Kerberos principal
name would be used in an authorization exchange by the service to
determine what that principal is allowed to use.  In the case of AFS
the authorization database is PTS.

I agree.


I believe it is very important that the authenticated name be preserved
for logging and because you never know when some admininstrator might
screw up and issue [EMAIL PROTECTED] to [EMAIL PROTECTED] to different
users when both the FOO.COM and BAR.COM realms are trusted by the foobar.com cell.



Actually they may want to do this, to map two differnet principals to the same authorization name. ~/.k5login is an example of this.

If there is a mapping to be applied it should be applied within the
authorization database (ptserver) not in something that modifies
authentication names.

OK, that would be acceptable. I would also agrue that the krb524d or gssklogd where principals in a k5 realm where mapped to users in a AFS realm was in effect an extension of the PTS authorization. Maping authentication names to a authorization name.


Jeffrey Altman


--

 Douglas E. Engert  <[EMAIL PROTECTED]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to