Processing keytab in memory

classic Classic list List threaded Threaded
14 messages Options
T C
Reply | Threaded
Open this post in threaded view
|

Processing keytab in memory

T C
Hi,

I have read in a keytab file and store the content as a blob in database.  Later when I
try to process it I don't see how to do that in memory.  There is a keytab_memory file
but it doesn't seem to take a keytab content blob anywhere. 

All I can find is to read the contents directly from file into the cursor thru fkt_start_seq_get_int.
Is that true?  Is there any other lower level interface that doesn't need to go thru file
system?

Thanks,
Terry
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Matthew Andrews-2
Is there any reason why you are storing keytabs in you database instead
of keys?

-Matt

T C wrote:

> Hi,
>
> I have read in a keytab file and store the content as a blob in
> database.  Later when I
> try to process it I don't see how to do that in memory.  There is a
> keytab_memory file
> but it doesn't seem to take a keytab content blob anywhere.
>
> All I can find is to read the contents directly from file into the
> cursor thru fkt_start_seq_get_int.
> Is that true?  Is there any other lower level interface that doesn't
> need to go thru file
> system?
>
> Thanks,
> Terry

T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
What do you meant by keys?  Do you mean just the encryption
key, or other associated info like kvo, algorithm type, and all
the names.  Is there a data structure for storing all these info
into database?

Right now as soon as I import the keytab file I write it to
the approate location for configuration purposes, but I
store it into database for purposes of backup because
our system backs up database automatically but not files.
If there is a database API where you can feed all
relevant pieces of info into Heimdal when it initializes
the key table, I'll like to know.

Or if there is any other suggestion, I like to learn about
that as well.

Thanks,
Terry

On 11/9/05, Matthew N. Andrews <[hidden email]> wrote:
Is there any reason why you are storing keytabs in you database instead
of keys?

-Matt

T C wrote:

> Hi,
>
> I have read in a keytab file and store the content as a blob in
> database.  Later when I
> try to process it I don't see how to do that in memory.  There is a
> keytab_memory file
> but it doesn't seem to take a keytab content blob anywhere.
>
> All I can find is to read the contents directly from file into the
> cursor thru fkt_start_seq_get_int.
> Is that true?  Is there any other lower level interface that doesn't
> need to go thru file
> system?
>
> Thanks,
> Terry


Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Andrew Bartlett
In reply to this post by T C
On Tue, 2005-11-08 at 14:28 -0800, T C wrote:

> Hi,
>
> I have read in a keytab file and store the content as a blob in
> database.  Later when I
> try to process it I don't see how to do that in memory.  There is a
> keytab_memory file
> but it doesn't seem to take a keytab content blob anywhere.  
>
> All I can find is to read the contents directly from file into the
> cursor thru fkt_start_seq_get_int.
> Is that true?  Is there any other lower level interface that doesn't
> need to go thru file
> system?
Terry,

When I first read your mail I thought 'why would you want to do that'.
However, I seem to be in exactly the same situation.  I would like to
keep the keytab in a database (Samba4 ldb in this case), as it provides
a consistency with the rest of the records.

I might just bail and have a 'keytab reference' in the database, but
exactly this kind of functionality would be very useful.  I might even
try and hack it up in lorikeet-heimdal (the branch of Heimdal I maintain
for Samba4).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
Hi Andrew,
 
Thanks for the confirmation.  By "keytab reference" do you mean the name to the keytab file?
 
I chose to write it out to a file before parsing it because that seems to be the best option I got.  I can't hack it because I need to keep my patches at a minimum since our system needs to integrate newer versions easily. 
 
Thanks,
Terry

 
On 11/25/05, Andrew Bartlett <[hidden email]> wrote:
Terry,

When I first read your mail I thought 'why would you want to do that'.
However, I seem to be in exactly the same situation.  I would like to
keep the keytab in a database (Samba4 ldb in this case), as it provides
a consistency with the rest of the records.

I might just bail and have a 'keytab reference' in the database, but
exactly this kind of functionality would be very useful.  I might even
try and hack it up in lorikeet-heimdal (the branch of Heimdal I maintain
for Samba4).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College   http://hawkerc.net


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDiALGz4A8Wyi0NrsRAjwsAJ9D62GwKHW0WuiLfOjdCLJX9NwQyACdF4FB
/Byo1HCSZQxN0a6dvc/fdbk=
=zM7r
-----END PGP SIGNATURE-----



Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Andrew Bartlett
On Sun, 2005-11-27 at 20:34 -0800, T C wrote:
> Hi Andrew,
>  
> Thanks for the confirmation.  By "keytab reference" do you mean the
> name to the keytab file?

Yes.

> I chose to write it out to a file before parsing it because that seems
> to be the best option I got.  I can't hack it because I need to keep
> my patches at a minimum since our system needs to integrate newer
> versions easily.  

I've got a private directory I can point at, so I think this might be
the easiest option.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Love Hörnquist Åstrand
In reply to this post by T C

T C and Andrew,

> I chose to write it out to a file before parsing it because that seems to be
> the best option I got.  I can't hack it because I need to keep my patches at a
> minimum since our system needs to integrate newer versions easily.

I've been thinking about adding a text version of the keytab format so
keytab can easily be transported between systems. I think I would use the
same format as the file keytab. Basicly it would be a base64 encoded file
with appropriate header, see below. And to this there would be support
function in the kerberos libaries to import the text into a keytab (memory
or file).

Would this solve your problems ?

Love


------BEGIN KERBEROS 5 KEYTAB------
Format: 4
Created-by: Love <[hidden email]>

ntKSpAmri3nLPi6y8lRfFxs779Bzaoe3/RgEU3ASmTB20UOBJvmo8b42L6+AcAtx
TcnSfCbkRqN+FfjNNlnwUSYAA42lobvYnLh42hFTi/0js2pJ03S3ulXxhTcbDJLK
vOKK67KGlfGI1hct2jltGIbVwc4YH53Y3VBa5LpZT965rg
------END KERBEROS 5 KEYTAB------



attachment0 (487 bytes) Download Attachment
T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
Love,

This sounds like a good solution to my current problem.  Does this mean I will likely store the whole base64 text in the database?  In any case, this would prevent writing to file in order to build the key table, and thus it would be a great improvement. 

I have also encountered a different but related problem.  If I store the whole keytab in database,  since our field size maybe limited, this means to manually divide the keytab into chunks.  I wonder if there is a way to store key values into separate fields in database, and later fill back a krb5_keytab_entry, and reconstruct the keytab?  Maybe this functionality already exists?  Or maybe something for the future?

Thanks,
Terry

On 11/30/05, Love Hörnquist Åstrand <[hidden email]> wrote:

T C and Andrew,

> I chose to write it out to a file before parsing it because that seems to be
> the best option I got.  I can't hack it because I need to keep my patches at a
> minimum since our system needs to integrate newer versions easily.

I've been thinking about adding a text version of the keytab format so
keytab can easily be transported between systems. I think I would use the
same format as the file keytab. Basicly it would be a base64 encoded file
with appropriate header, see below. And to this there would be support
function in the kerberos libaries to import the text into a keytab (memory
or file).

Would this solve your problems ?

Love


------BEGIN KERBEROS 5 KEYTAB------
Format: 4
Created-by: Love <[hidden email]>

ntKSpAmri3nLPi6y8lRfFxs779Bzaoe3/RgEU3ASmTB20UOBJvmo8b42L6+AcAtx
TcnSfCbkRqN+FfjNNlnwUSYAA42lobvYnLh42hFTi/0js2pJ03S3ulXxhTcbDJLK
vOKK67KGlfGI1hct2jltGIbVwc4YH53Y3VBa5LpZT965rg
------END KERBEROS 5 KEYTAB------





Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Andrew Bartlett
On Wed, 2005-11-30 at 14:54 -0800, T C wrote:

> Love,
>
> This sounds like a good solution to my current problem.  Does this
> mean I will likely store the whole base64 text in the database?  In
> any case, this would prevent writing to file in order to build the key
> table, and thus it would be a great improvement.  
>
> I have also encountered a different but related problem.  If I store
> the whole keytab in database,  since our field size maybe limited,
> this means to manually divide the keytab into chunks.  I wonder if
> there is a way to store key values into separate fields in database,
> and later fill back a krb5_keytab_entry, and reconstruct the keytab?
> Maybe this functionality already exists?  Or maybe something for the
> future?
If you want to pull things apart to this level, then I would suggest
simply enumerating the keytab, and extracting the entries with the
existing functions.

Why can't you store an arbitary BLOB in your database?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
I can extract the entries and store the info into database, but how do I build the key table in memory later using these separate pieces of info, without the blob?

I can store the blob, but I would rather store small fields of info, not an arbitrary size piece of data.  I need to store some of those separate fields currently for display purposes anyway.

Terry

On 11/30/05, Andrew Bartlett <[hidden email]> wrote:
If you want to pull things apart to this level, then I would suggest
simply enumerating the keytab, and extracting the entries with the
existing functions.

Why can't you store an arbitary BLOB in your database?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College   http://hawkerc.net


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDji5Pz4A8Wyi0NrsRAtxTAJsEJ1dkd3Z9GYS5rqs9ajKqsCVGzwCgmAWh
bcApG0t/JWgWBR3cYWYgpQc=
=C7c3
-----END PGP SIGNATURE-----



Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Andrew Bartlett
On Wed, 2005-11-30 at 15:15 -0800, T C wrote:
> I can extract the entries and store the info into database, but how do
> I build the key table in memory later using these separate pieces of
> info, without the blob?

See krb5_kt_add_entry().  It takes the same krb5_keytab_entry structure
that the enumeration gives you.

> I can store the blob, but I would rather store small fields of info,
> not an arbitrary size piece of data.  I need to store some of those
> separate fields currently for display purposes anyway.

In Samba4, I'm going to store a little metadata (principal, plaintext,
kvno, last changed time), then either the blob or a reference to a real
keytab.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
That's good to know.  But how easy is it to build krb5_keytab_entry from individual fields?  Or is that function intended for adding an entry from one keytab to another only?

Thanks,
Terry

On 11/30/05, Andrew Bartlett <[hidden email]> wrote:
On Wed, 2005-11-30 at 15:15 -0800, T C wrote:
> I can extract the entries and store the info into database, but how do
> I build the key table in memory later using these separate pieces of
> info, without the blob?

See krb5_kt_add_entry().  It takes the same krb5_keytab_entry structure
that the enumeration gives you.

> I can store the blob, but I would rather store small fields of info,
> not an arbitrary size piece of data.  I need to store some of those
> separate fields currently for display purposes anyway.

In Samba4, I'm going to store a little metadata (principal, plaintext,
kvno, last changed time), then either the blob or a reference to a real
keytab.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College   http://hawkerc.net


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDjjTYz4A8Wyi0NrsRAjKaAJ9szOFB8KG9YV/EBWK8M8UscA7rEgCeKfxY
N5SgmY6cnKk3AQSevzu5/IY=
=0RLN
-----END PGP SIGNATURE-----



Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

Andrew Bartlett
On Wed, 2005-11-30 at 17:47 -0800, T C wrote:
> That's good to know.  But how easy is it to build krb5_keytab_entry
> from individual fields?  Or is that function intended for adding an
> entry from one keytab to another only?

I fill out the keytab both from a plaintext password and from a keyblock
here in Samba4.  See for an example:
ftp://ftp.samba.org/pub/unpacked/samba4/source/auth/kerberos/kerberos_util.c

(Watch out, the GPL will stain your fingers if you copy&paste ;-)

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
T C
Reply | Threaded
Open this post in threaded view
|

Re: Processing keytab in memory

T C
Thanks for the info, and the warning. :-)

Terry

On 11/30/05, Andrew Bartlett <[hidden email]> wrote:
On Wed, 2005-11-30 at 17:47 -0800, T C wrote:
> That's good to know.  But how easy is it to build krb5_keytab_entry
> from individual fields?  Or is that function intended for adding an
> entry from one keytab to another only?

I fill out the keytab both from a plaintext password and from a keyblock
here in Samba4.  See for an example:
ftp://ftp.samba.org/pub/unpacked/samba4/source/auth/kerberos/kerberos_util.c

(Watch out, the GPL will stain your fingers if you copy&paste ;-)

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College   http://hawkerc.net


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDjlecz4A8Wyi0NrsRAvEsAKCjlTGFc8BR6RStw3Gv5LOgylnDjACgqICv
ke+HsoW8HxRVsM3kzJ3ZfEU=
=PX0V
-----END PGP SIGNATURE-----