Simon Wilkinson <[email protected]> writes: > Actually, I'm not sure that GSSAPI will let us do this. A > GSS_C_NT_HOSTBASED_SERVICE is defined as being "serv...@hostname", with > no provision for specifying a realm.
> We could define the acceptor identity as a GSS_KRB5_NT_PRINCIPAL_NAME, > but that completely ties us to using Kerberos as the GSSAPI mechanism. > It's not clear to me whether a name defined using one OID can be > portably used by an endpoint expecting a different OID. Surely the client is not passing either of those into the core of rxgk but instead is passing in the results of gss_import_name(), no? So the client (be it aklog or something else) can use whatever OID is most appropriate when calling gss_import_name() for what it's attempting to do. Or do I misunderstand what gss_import_name() can do in this situation? remctl uses either GSS_C_NT_USER_NAME or GSS_C_NT_HOSTBASED_SERVICE depending on whether the user has forced the server principal to a particular value, but it's not tested with multimechanism GSSAPI. I would expect that forcing the principal name wouldn't work if the GSSAPI mechanism chosen ended up not being Kerberos, but that's fine. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
