krb1.5 plugin interface query - Kerberos

This is a discussion on krb1.5 plugin interface query - Kerberos ; hi all, As MIT_krb1.5 supports two plugin interfaces, one internal interface for new database layer and other public interface for KDC. here, can anyone tell me, 1.How i can use these interfaces to get most out of them? 2.is there ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: krb1.5 plugin interface query

  1. krb1.5 plugin interface query

    hi all,
    As MIT_krb1.5 supports two plugin interfaces, one internal interface for
    new database layer and other public interface for KDC.
    here, can anyone tell me,
    1.How i can use these interfaces to get most out of them?
    2.is there any reference doc. available for using these interfaces?

    Waiting for ur replies.

    Thanx in advance,
    -Vipin Rathor
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: krb1.5 plugin interface query

    On Sep 8, 2006, at 11:58, Vipin Rathor wrote:
    > As MIT_krb1.5 supports two plugin interfaces, one internal
    > interface for
    > new database layer and other public interface for KDC.
    > here, can anyone tell me,
    > 1.How i can use these interfaces to get most out of them?
    > 2.is there any reference doc. available for using these interfaces?


    No reference docs currently.

    kdc location: Are you doing anything interesting where krb5.conf
    entries or DNS SRV records won't cut it for locating your KDCs?

    db: This may be a moving target, at least for a little while. The
    1.6 release is going to have an LDAP-based back end. If you feel
    like writing one for, say, MySQL, or Postgres, that might be of
    interest to people. Depends on performance a lot -- latency per
    request, as well as throughput.


    Actually, Sam and I had an idea for a use for the KDC location plugin
    interface: You could use it for experimenting with new code to do the
    config-file or DNS lookups in different ways. Either for your own
    private use, without affecting other users, or as a way of testing
    code you might like to integrate into your source tree and/or submit
    to us, but without having to rebuild the whole tree for every change.

    For example: Our code for using DNS SRV records doesn't look at the
    "additional data" fields of the response, which may contain the
    network addresses of the hosts listed, so you don't have to make
    additional queries. (A question I haven't investigated: Does the
    presence of an A record there and no AAAA records mean there is no
    AAAA record, or would you still need to make that query? My guess
    would be the latter.)

    And depending on your environment, if the address queries are needed,
    it may be more efficient to find a way to fire off multiple requests
    to the DNS server and then collect the results as they come in (but
    you may not want to lose the /etc/hosts check).

    Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: krb1.5 plugin interface query



    On Friday, September 08, 2006 03:37:33 PM -0400 Ken Raeburn
    wrote:

    > (A question I haven't investigated: Does the
    > presence of an A record there and no AAAA records mean there is no
    > AAAA record, or would you still need to make that query? My guess
    > would be the latter.)


    I believe the latter. RFC3596 redefines query types that trigger type A
    additional section processing to also perform type AAAA additional section
    processing. However, the server is only required to return records it
    already has, not to perform additional queries to obtain records it does
    not have. So, it's fairly easy to construct a scenario in which A records
    are returned but AAAA records are not, even though they exist. IMHO this
    is unfortunate, since it means that the round-trip savings realized by use
    of the additional section are lost in many cases.

    -- Jeff
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: krb1.5 plugin interface query

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Sep 10, 2006, at 19:35, Andrew Bartlett wrote:
    >> kdc location: Are you doing anything interesting where krb5.conf
    >> entries or DNS SRV records won't cut it for locating your KDCs?

    >
    > Ahh, so this is the correct way to solve the disgusting hacks
    > currently
    > being placed in Samba 3.0, where we rewrite the krb5.conf for
    > DC-affinity and discovery purposes...


    That's the theory... let us know if it's not sufficient.

    There's a sample plugin included in the released sources, which
    demonstrates the use of the interface. (It also demonstrates how to
    load a Python interpreter and run a script, so it's a bit hairier
    than simply showing off the interface. And probably not thread-safe,
    and may have leaks, etc. It's just a quick demo, we don't install it.)

    Ken


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (Darwin)

    iD8DBQFFBKaoUqOaDMQ+e5gRAh4fAKCLC7r41DP/ZyJKfbcuVluPGqboMACeIXwS
    vPGg9yKtOmwNp5ffwYuPv/Q=
    =swVr
    -----END PGP SIGNATURE-----
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: krb1.5 plugin interface query

    Ken Raeburn wrote:
    > Actually, Sam and I had an idea for a use for the KDC location plugin
    > interface: You could use it for experimenting with new code to do the
    > config-file or DNS lookups in different ways. Either for your own
    > private use, without affecting other users, or as a way of testing
    > code you might like to integrate into your source tree and/or submit
    > to us, but without having to rebuild the whole tree for every change.
    >
    > For example: Our code for using DNS SRV records doesn't look at the
    > "additional data" fields of the response, which may contain the
    > network addresses of the hosts listed, so you don't have to make
    > additional queries. (A question I haven't investigated: Does the
    > presence of an A record there and no AAAA records mean there is no
    > AAAA record, or would you still need to make that query? My guess
    > would be the latter.)
    >


    There is no guarantee that the contents of the additional data section
    are complete. Most of this depends on how your resolver library
    implements this. If you follow up with a call to getaddrinfo() you will
    get IPv6 addresses first in the list if there are any, but there is no
    way to be sure what you get from an SRV request.

    Danny

    > And depending on your environment, if the address queries are needed,
    > it may be more efficient to find a way to fire off multiple requests
    > to the DNS server and then collect the results as they come in (but
    > you may not want to lose the /etc/hosts check).
    >
    > Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: krb1.5 plugin interface query

    On Fri, 2006-09-08 at 15:37 -0400, Ken Raeburn wrote:
    > On Sep 8, 2006, at 11:58, Vipin Rathor wrote:
    > > As MIT_krb1.5 supports two plugin interfaces, one internal
    > > interface for
    > > new database layer and other public interface for KDC.
    > > here, can anyone tell me,
    > > 1.How i can use these interfaces to get most out of them?
    > > 2.is there any reference doc. available for using these interfaces?

    >
    > No reference docs currently.
    >
    > kdc location: Are you doing anything interesting where krb5.conf
    > entries or DNS SRV records won't cut it for locating your KDCs?


    Ahh, so this is the correct way to solve the disgusting hacks currently
    being placed in Samba 3.0, where we rewrite the krb5.conf for
    DC-affinity and discovery purposes...

    Andrew Bartlett

    --
    Andrew Bartlett http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc. http://redhat.com

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

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

    iD8DBQBFBKFWz4A8Wyi0NrsRAivuAKCDaACEw0xOkEieEhWfmQ ZeEptChACfSGEW
    ryTfdy3boAtD0GKgwe47u/Y=
    =iEJQ
    -----END PGP SIGNATURE-----


+ Reply to Thread