Why the SPN can't be arbitrary

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why the SPN can't be arbitrary

ZongtianHou
Hello, everyone:
I have some questions for the auth process. When the user get the tgt, it then send a request to the TGS in which it tell TGS the service principal it want to access. I have two questions here. First, how does the user know the service principal, I think it only know the service it want to access. Second, why the SPN must be service/[hidden email], if the user know the service principal, like [hidden email]. it just request a ticket for it, then send the ticket to the service, then it can access to it. What I misunderstood here?
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Why the SPN can't be arbitrary

Greg Hudson
On 06/24/2018 12:27 AM, ZongtianHou wrote:
> I have some questions for the auth process. When the user get the tgt, it then send a request to the TGS in which it tell TGS the service principal it want to access. I have two questions here. First, how does the user know the service principal, I think it only know the service it want to access. Second, why the SPN must be service/[hidden email], if the user know the service principal, like [hidden email]. it just request a ticket for it, then send the ticket to the service, then it can access to it. What I misunderstood here?

In the Kerberos protocol itself, the service name does not have to be
service/[hidden email]; it could be [hidden email].

The reason why you usually see service names of the form
service/[hidden email] is because of host-based service names in the
GSSAPI, which many applications use.  For these, the application
supplies a service name (like "host" or "HTTP") and a hostname.  The
Kerberos implementation then might canonicalize the hostname, and also
tries to look up what realm the host belongs to using local
configuration.  If it can't figure out the realm, it will guess its
local realm and possibly receive a referral to another realm.

In your Hadoop question, from the log you provided, it looks like the
application used a host-based service name with the service "gpadmin"
and the host "CW.COM", resulting in the server principal name
"gpadmin/[hidden email]", which does not appear to be present in the KDC
database.

> It seems the kutils tools are different between the MAC and linux, and I can’t find how to use it in Mac OS in the internet. Does anyone know how to display the principals in a keytab and how to kinit a specific principal on Mac?

In macOS, the native Kerberos implementation is based on Heimdal, while
on Linux distributions it is often MIT krb5.

To list the keys in a keytab on macOS, I believe you want "ktutil list",
or "ktutil -k /path/to/keytab list".

I am not sure what you mean by "kinit a specific principal".  For a
specific client principal, in both implementations you can just do
"kinit [hidden email]" or just "kinit aaa" if the default realm is
REALM.COM.  For a specific service principal (i.e. not
krbtgt/REALMNAME), you can use "kinit -S servername", optionally
followed by the client name as before.  Note that the client and server
principal names must be in the same realm for initial tickets.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Why the SPN can't be arbitrary

ZongtianHou
This is very clear explanation, make the conception much clearer to me, really appreciate it!! By the way, another question, if the other node want to access the service, it just need to be given the ticket from the credential cache file, it can do the job, right?

> On 26 Jun 2018, at 12:18 AM, Greg Hudson <[hidden email]> wrote:
>
> On 06/24/2018 12:27 AM, ZongtianHou wrote:
>> I have some questions for the auth process. When the user get the tgt, it then send a request to the TGS in which it tell TGS the service principal it want to access. I have two questions here. First, how does the user know the service principal, I think it only know the service it want to access. Second, why the SPN must be service/[hidden email], if the user know the service principal, like [hidden email]. it just request a ticket for it, then send the ticket to the service, then it can access to it. What I misunderstood here?
>
> In the Kerberos protocol itself, the service name does not have to be service/[hidden email]; it could be [hidden email].
>
> The reason why you usually see service names of the form service/[hidden email] is because of host-based service names in the GSSAPI, which many applications use.  For these, the application supplies a service name (like "host" or "HTTP") and a hostname.  The Kerberos implementation then might canonicalize the hostname, and also tries to look up what realm the host belongs to using local configuration.  If it can't figure out the realm, it will guess its local realm and possibly receive a referral to another realm.
>
> In your Hadoop question, from the log you provided, it looks like the application used a host-based service name with the service "gpadmin" and the host "CW.COM", resulting in the server principal name "gpadmin/[hidden email]", which does not appear to be present in the KDC database.
>
>> It seems the kutils tools are different between the MAC and linux, and I can’t find how to use it in Mac OS in the internet. Does anyone know how to display the principals in a keytab and how to kinit a specific principal on Mac?
>
> In macOS, the native Kerberos implementation is based on Heimdal, while on Linux distributions it is often MIT krb5.
>
> To list the keys in a keytab on macOS, I believe you want "ktutil list", or "ktutil -k /path/to/keytab list".
>
> I am not sure what you mean by "kinit a specific principal".  For a specific client principal, in both implementations you can just do "kinit [hidden email]" or just "kinit aaa" if the default realm is REALM.COM.  For a specific service principal (i.e. not krbtgt/REALMNAME), you can use "kinit -S servername", optionally followed by the client name as before.  Note that the client and server principal names must be in the same realm for initial tickets.


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos