rpcsec_gss, kadmind service principal, etc.

[Kevin Coffman]

> >>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:
> 
> 
>     Kevin> Since I
>     Kevin> made the above incompatible change, I didn't see the need
>     Kevin> to continue to support the older service names.  This is
>     Kevin> causing problems trying to run the unit tests since they
>     Kevin> run the OV kpasswd program which requires kadmind to handle
>     Kevin> 'kadmin/changepw' as well.  Should I be worrying about
>     Kevin> this?
> 
> Yes.  Quoting  the set-change-password draft:
> 
>    AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
>    message service ticket sname, srealm principal identifier is
>    kadmin/changepw at REALM where REALM is the realm of the change password
>    service. The same applies to a set password/key request except the
>    principal identifier is kadmin/setpw at REALM. The authenticator in the
>    AP-REQ MUST contain a subsession key (which will be used to encrypt
> 
> 
> You'll break all existing change password services if you don't
> support kadmin/changepw.

The kpasswd program from src/clients/kpasswd, which I believe
is what implements the above, still works fine using the
kadmin/changepw service name.  It is the kpasswd in
src/kadmin/passwd, which uses RPC to communicate with the
kadmind, that is broken by the changes.  Do both of these need
continued support?  AFAIKT, the only thing broken by these
changes are the unit tests.

> I'm not sure what I think about kadmin/fqdn instead of
> kadmin/admin.  I think that may cause problems if we ever
> go to multi-master admin servers.

The only other way to have compatibility with the SEAM kadmind
is to try both kadmin/admin and kadmin/fqdn from the client.
Would that be preferred?