MIT Kerberos clients and Windows KDC

[swbell]

in article 1132304089.372626.30620 at g49g2000cwa.googlegroups.com,
sandypossible at gmail.com at sandypossible at gmail.com wrote on 11/18/05 2:54
AM:

> Hi all,
> 
> I am trying to make an embedded device part of the windows domain and
> use windows DC as KDC for my embedded divice. Embedded device has MIT
> Kerberos. I am using GSS API .
> 
> * How can we get the TGT for the server programatically ( transperently
> )  with out user intervention ?

Just think of the device as a person - you create an AD account and assign a
password.  Put the password in the device in a way that does not disclose
the password to anyone that should not know it.  You also need to put the
device account's user principal name in the device.

Store the device password in non-volatile memory.  Use the password and
device account user principal name to call krb5_get_init_creds_password.
You need to store the The TGT lifetime will be 10 hours by default.

> 
> * If the device restarts, then do I need to store the TGT in persistent
> memory ?
You would probably be better off just using your stored password to get a
new TGT using krb5_get_init_creds_password.
> 
> * If I am not wrong, microsoft adds the PAC data which no limitation of
> size. I have memory constraints. Is it required to store the TGT in non
> volatile memory ? I need this info since I am trying to find in case if
> the embedded device reboots ,then do I need to store the TGT in non
> volatile memory or I can get it again after the device comes up.
I doubt that you would need to put an embedded device account into very many
groups.  The fewer groups, the less PAC data.  PAC data doesn't just get
added for no reason, so you can limit its size by limiting the data that
gets stored in PAC.  Limit the groups the embedded device is in.
> 
> * Assuming that a client is accessing services on embedded device via
> Kerberos and there is already  a successful kerberos session is
> established. If at this point, if the embedded  device reboots and the
> device gets TGT again, will it alter the communication in any way ?
> 
It is hard to imagine how your device can reboot, but maintain its network
connection state.  If the device needs to make new network connections.
Getting new service tickets should not really be a concern to you, since it
happens automatically when you use GSSAPI.  All you really need to worry
about is getting your initial credentials (tgt) using the device password.

> Could anybody please respond to these queries?
> 
> Regards
>