Hi, I'm am trying to change the behavior of a functioning GSS-enabled application server such that the server principal and corresponding keytab entry used by gss_accept_sec_context is determined dynamically based on the server principal named in the client's ticket (implicitly specified by the input token to gss_accept_sec_context).
There are various reasons for wanting to do this. Migrating to DNS is one - we would like to isolate applications from naming changes on the client hosts (or the server hosts for that matter) so that application servers can accept tickets for either: <service>/<short_name>@MS.COM <service>/<short_name>[EMAIL PROTECTED] thereby, allowing various client/hosts to migrate to DNS independently. <service> is generally the name of the application. <short_name> is the short name (our current hostname resolution renders short names). This short name could either be an actual host name or a one of several VCS service name. In other words, there could be many permutations, and I would like avoid any brute force approaches where I try every possible server principal name. [of course, I would populate the application server's keytab file with all of the necessary keytab entries so that it can assume any of the above identities - in fact this works already for kshd/klogind, which of course are not written with GSSAPI] My first attempt was to specify GSS_C_NO_CREDENTIAL for the verifier credential handle. This appeared to reveal a bug in gss_accept_sec_context(): (I'll send a separate email to [EMAIL PROTECTED] about this). == start bug description == krb5_gss_accept_sec_context acquires a default cred via krb5_gss_acquire_cred, if the supplied verifier_cred handle is GSS_C_NO_CREDENTIAL - which is places in the variable "cred_handle" It then proceeds to try to validate verifier_cred_handle, which in my case is GSS_C_NO_CREDENTIAL, rather than the new obtained credential (cred_handle). So this fails unnecessarily. So I fix this so that it validates cred_handle (which it obtains) rather than verifier_cred_handle (GSS_C_NO_CREDENTIAL). == end bug description == Nonetheless, in obtaining a credential handle, krb5_gss_acquire_cred will determine the server principal name. As invoked by krb5_gss_accept_sec_context, it will obtain a handle to the credential based on logic for GSS_C_NO_NAME and GSS_C_ACCEPT (cred_usage supplied by krb5_gss_accept_sec_context). In doing so, it invokes krb5_sname_to_principal, which determine the default principal name based on hostname and sname arguments (both NULL). This results in a server principal name constructed from an sname of "host" and a hostname based on gethostname which is then resolved via gethostbyname/gethostbyaddr. krb5_gss_acquire_cred then attempts to extract the keytab entry for this principal. Of course, this is not what I want. Calling gss_acquire_cred from my application using GSS_C_NO_NAME has the same affect. Has anyone attempted to write a GSS-enabled application server that can assume more than one different identities, based on the server principal name specified in the client's ticket. Is there another approach that will allow me to do this? The only other thought I have is to try to extract the server principal name for the token supplied by the client. This, however, seems like I am breaking rules by not treating tokens as opaque objects. I haven't investigated this approach yet, I was hoping there was a more natural approach than this. Any suggestions are highly appreciated. Thanks, Cesar ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
