Thanks, sounds like quick and dirty would solve my problem sufficiently
until the 16-bit issue starts to annoy me or the principals in my MIT KDC
start breeding...
If (or when) patches exist, I'm willing to test...
On Sun, 20 Nov 2005, Jeffrey Altman wrote:
The problem you are trying to solve "multiple names from multiple
sources represent the same identity" is being worked on. I expect
that there will be a cheap and dirty solution available in a future
1.4 release in the next few months plus a more permanent solution
in OpenAFS 2.0.
The quick and dirty solution will provide more than a single realm
which can be considered the same as the local realm with a list of
exclusion names for which you want to continue treatment as a foreign
user.
What site in your situation currently do is require the use of
a modified krb524 daemon that performs name translation. Public
distribution of these hacks is very much discouraged.
Jeffrey Altman
[EMAIL PROTECTED] wrote:
It looks like cross-realm AFS IDs are required to have the group ID of
the cross-realm group (system:[EMAIL PROTECTED]) in the lower 16-bits of
the ID:
user id & 0x0000ffff = group id
Does this imply that you only get 16-bits of local IDs and 16-bits for
each cross-realm realm?
What would break if you assigned arbitrary AFS IDs to cross-realm users,
particularly in the <= 0x0000ffff ID space? What expects to be able to
take a user id and strip out the group id from it?
I've got cross-realm users which are in an AD REALM that I want to use
while keeping my cell principal in an MIT KDC. Those cross-realm users
are already in my /etc/passwd file with a globally unique uid that it
would simply my life greatly if I could use for an AFS ID. Also, all
the foreign cells that I'll access will have exactly the same mapping of
IDs to the AD realm.
Is there any way around this, or am I stuck with only 16-bits of
0xnnnnff2e IDs and the need to use some kind of nss_afs to resolve those
names with getpwuid()?
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
