tag:old.nabble.com,2006:forum-961Nabble - Kerberos2009-11-28T04:31:30ZKerberos is the Network Authentication Protocol. Kerberos home is <a href="http://web.mit.edu/kerberos/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26552735Missing library in krb5-config --libs krb5 ?2009-11-28T04:31:30Z2009-11-28T04:31:30ZMarkus MoellerHi,
<br><br> I use something like below in my application, but now it doesn't link
<br>because the external symbol has moved to a library which is not part of the
<br>krb5-config --libs krb5 command. Can -lotp be added to it please ?
<br><br>Thank you
<br>Markus
<br><br>#include <stdio.h>
<br>#include <stdlib.h>
<br>#include <krb5.h>
<br>main () {
<br>printf("Version %s\n",heimdal_version);
<br>}
<br><br>Version < 1.3.0
<br><br>> gcc `/opt/heimdal-1.2.1/bin/krb5-config --cflags krb5` -o/tmp/print_hv
<br>> /tmp/print_hv.c `/opt/heimdal-1.2.1/bin/krb5-config --libs krb5`
<br>> export LD_LIBRARY_PATH=/opt/heimdal-1.2.1/lib
<br>> /tmp/print_hv
<br>Version Heimdal 1.2.1
<br><br><br>Version > 1.3.0
<br><br>> gcc `/opt/heimdal-1.3.1/bin/krb5-config --cflags krb5` -o/tmp/print_hv
<br>> /tmp/print_hv.c `/opt/heimdal-1.3.1/bin/krb5-config --libs krb5`
<br>/tmp/ccWRvMqL.o: In function `main':
<br>print_hv.c:(.text+0x12): undefined reference to `heimdal_version'
<br>collect2: ld returned 1 exit status
<br><br><br>adding -lotp fixes it
<br><br>> gcc `/opt/heimdal-1.3.1/bin/krb5-config --cflags krb5` -o/tmp/print_hv
<br>> /tmp/print_hv.c `/opt/heimdal-1.3.1/bin/krb5-config --libs krb5` -lotp
<br>> export LD_LIBRARY_PATH=/opt/heimdal-1.3.1/lib
<br>> /tmp/print_hv
<br>Version Heimdal 1.3.1
<br><br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26548817Re: GSSAPI Question2009-11-27T14:49:14Z2009-11-27T14:49:14ZGreg HudsonOn Wed, 2009-11-25 at 16:12 -0500, Shirish Rai wrote:
<br>> I have looked at the code a bit and it seem GSS creates a new KRB context.
<br>> Is there a way to tell GSS to use an existing context and/or ccache. I tried
<br>> this with the gss_krb5_ccache_name API. But that did not change anything.
<br><br>There's no way to make it use an existing context, but that should not
<br>be necessary. gss_krb5_ccache_name should make it use an existing
<br>ccache.
<br><br>> I guess there must be a way to only user GSSAPI as well. If that is the
<br>> correct way to go about his, is there an example I can look at.
<br><br>GSSAPI does not currently have a way to acquire initial credentials (in
<br>current MIT krb5, at least; I believe there are extensions unde
<br>consideration for the future). So you have the right general approach.
<br><br>I think what's tripping you up is that krb5_get_init_creds_password
<br>doesn't store the resulting credential in a ccache. You need to
<br>explicitly store my_creds into the default ccache or into one you create
<br>for this purpose.
<br><br><br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26548817&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26536396[krbdev.mit.edu #6576] SVN Commit2009-11-26T16:00:07Z2009-11-26T16:00:07ZGreg Hudson via RT<br>Add krb5_k_prf, the krb5_key version of krb5_c_prf.
<br><br><br><a href="http://src.mit.edu/fisheye/changelog/krb5/?cs=23365" target="_top" rel="nofollow">http://src.mit.edu/fisheye/changelog/krb5/?cs=23365</a><br>Commit By: ghudson
<br>Revision: 23365
<br>Changed Files:
<br>U trunk/src/include/krb5/krb5.hin
<br>U trunk/src/lib/crypto/krb/prf.c
<br>U trunk/src/lib/crypto/libk5crypto.exports
<br><br>_______________________________________________
<br>krb5-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26536396&i=0" target="_top" rel="nofollow">krb5-bugs@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krb5-bugs" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krb5-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Bugs-f963.html" embed="fixTarget[963]" target="_top" >Kerberos - Bugs</a></p>tag:old.nabble.com,2006:post-26535629Re: Revisiting krb5_gic_opt_ext2009-11-26T14:15:47Z2009-11-26T14:15:47ZLukeh-3<br>On 26/11/2009, at 10:39 PM, Love Hörnquist Åstrand wrote:
<br><br>>> The get_init_creds API is very clunky. Time for a new one?
<br>>
<br>> The 4th try ? see krb5_init_creds_init() before you start the
<br>> revolution.
<br><br>This is in trunk now, BTW, so same as Heimdal (krb5_tkt_creds_XXX and
<br>IAKERB not yet merged).
<br><br>-- Luke
<br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26535629&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26535236Re: Revisiting krb5_gic_opt_ext2009-11-26T13:39:18Z2009-11-26T13:39:18ZLove Hörnquist Åstrand> The get_init_creds API is very clunky. Time for a new one?
<br><br>The 4th try ? see krb5_init_creds_init() before you start the revolution.
<br><br>Love
<br><br><br><br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26535236&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26535024Re: Revisiting krb5_gic_opt_ext2009-11-26T13:05:23Z2009-11-26T13:05:23ZNicolas WilliamsThe get_init_creds API is very clunky. Time for a new one?
<br><br>Nico
<br>--
<br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26535024&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26533218Re: How to get pre-authentication work with AD?2009-11-26T10:18:53Z2009-11-26T10:18:53ZLove Hörnquist Åstrand<br>> I'm trying to get a simple user authentication working against AD KDC. I'm using krb5_get_init_creds_password function. I observe that this function fails with the message "Looping 11 times while getting initial credentials". After deep diving into the code I see that the krb5_init_creds_step function is looping with the internal code KRB5KDC_ERR_PREAUTH_REQUIRED.
<br>> I figure out that I should initialize the context in some way to send a pre-auth request to KDC. Could you explain how to do that? A sample code would be very appreciated.
<br><br>It looks on the function you mentioned that you are using 1.3.x
<br><br>Does your principal only have DES configured ?
<br><br>Try enabling DES on the client (or even better, use aes or arcfour enctypes) by adding the following to your krb5.conf
<br><br>[libdefaults]
<br> allow_weak_crypto = true
<br><br><a href="http://www.h5l.org/blog/index.php/2008/10/des-will-die-in-heimdal/" target="_top" rel="nofollow">http://www.h5l.org/blog/index.php/2008/10/des-will-die-in-heimdal/</a><br><br>Love
<br><br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26533086How to get pre-authentication work with AD?2009-11-26T10:08:25Z2009-11-26T10:08:25ZSerge EmantayevHi,
<br><br>I'm trying to get a simple user authentication working against AD KDC. I'm using krb5_get_init_creds_password function. I observe that this function fails with the message "Looping 11 times while getting initial credentials". After deep diving into the code I see that the krb5_init_creds_step function is looping with the internal code KRB5KDC_ERR_PREAUTH_REQUIRED.
<br>I figure out that I should initialize the context in some way to send a pre-auth request to KDC. Could you explain how to do that? A sample code would be very appreciated.
<br><br>Thanks
<br>Sergey Emantayev
<br><br><br><br>
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26524033[krbdev.mit.edu #6584] SVN Commit2009-11-25T19:55:01Z2009-11-25T19:55:01ZGreg Hudson via RT<br>Pullup to 1.7-branch is only for the test case, as krb5-1.7 behaved
<br>correctly for these checksums.
<br><br>Fix regression in MD4-DES and MD5-DES keyed checksums. The original
<br>key was being used for the DES encryption, not the "xorkey". (key
<br>with each byte XORed with 0xf0)
<br><br>Add a test case that will catch future regressions of this sort, by
<br>including a verification of a "known-good" checksum (derived from a
<br>known-to-be-interoperable version of the implementation).
<br><br><a href="http://src.mit.edu/fisheye/changelog/krb5/?cs=23361" target="_top" rel="nofollow">http://src.mit.edu/fisheye/changelog/krb5/?cs=23361</a><br>Commit By: tlyu
<br>Revision: 23361
<br>Changed Files:
<br>U trunk/src/lib/crypto/crypto_tests/Makefile.in
<br>U trunk/src/lib/crypto/crypto_tests/t_cksum.c
<br>U trunk/src/lib/crypto/krb/keyhash_provider/k5_md4des.c
<br>U trunk/src/lib/crypto/krb/keyhash_provider/k5_md5des.c
<br><br>_______________________________________________
<br>krb5-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26524033&i=0" target="_top" rel="nofollow">krb5-bugs@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krb5-bugs" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krb5-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Bugs-f963.html" embed="fixTarget[963]" target="_top" >Kerberos - Bugs</a></p>tag:old.nabble.com,2006:post-26523873Re: [krbdev.mit.edu #6584] r22778 breaks zephyr; probable incompatible2009-11-25T19:23:44Z2009-11-25T19:23:44ZGreg Hudson via RTI can confirm the patch works.
<br><br>_______________________________________________
<br>krb5-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523873&i=0" target="_top" rel="nofollow">krb5-bugs@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krb5-bugs" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krb5-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Bugs-f963.html" embed="fixTarget[963]" target="_top" >Kerberos - Bugs</a></p>tag:old.nabble.com,2006:post-26523521pam-krb5 4.2 released2009-11-25T18:17:45Z2009-11-25T18:17:45ZRuss AllberyI'm pleased to announce release 4.2 of pam-krb5.
<br><br>pam-krb5 is a Kerberos v5 PAM module for either MIT Kerberos or Heimdal.
<br>It supports ticket refreshing by screen savers, configurable authorization
<br>handling, authentication of non-local accounts for network services,
<br>password changing, and password expiration, as well as all the standard
<br>expected PAM features. It works correctly with OpenSSH, even with
<br>ChallengeResponseAuthentication and PrivilegeSeparation enabled, and
<br>supports extensive configuration either by PAM options or in krb5.conf or
<br>both. PKINIT is supported with recent versions of both MIT Kerberos and
<br>Heimdal.
<br><br>Changes from previous release:
<br><br> Add a new fail_pwchange option, which suppresses password changes for
<br> expired passwords and treats expired passwords the same as incorrect
<br> passwords.
<br><br> Include all the new header files from the portability code so that
<br> it will actually compile on non-Linux platforms.
<br><br>You can download it from:
<br><br> <<a href="http://www.eyrie.org/~eagle/software/pam-krb5/" target="_top" rel="nofollow">http://www.eyrie.org/~eagle/software/pam-krb5/</a>>
<br><br>This package is maintained using Git; see the instructions on the above
<br>page to access the Git repository.
<br><br>Debian packages have been uploaded to Debian unstable.
<br><br>Please let me know of any problems or feature requests not already listed
<br>in the TODO file.
<br><br>--
<br>Russ Allbery (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523521&i=0" target="_top" rel="nofollow">rra@...</a>) <<a href="http://www.eyrie.org/~eagle/" target="_top" rel="nofollow">http://www.eyrie.org/~eagle/</a>>
<br>________________________________________________
<br>Kerberos mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523521&i=1" target="_top" rel="nofollow">Kerberos@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/kerberos" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/kerberos</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---General-f965.html" embed="fixTarget[965]" target="_top" >Kerberos - General</a></p>tag:old.nabble.com,2006:post-26523417kerberos in a virtual environment2009-11-25T17:58:28Z2009-11-25T17:58:28Zmichelle zhaoHi there,
<br>We are trying to set up a virtual domain under vmware with microsoft kdc,
<br>IIS and xp client.
<br>I noticed the naming difference. My content server is accessed through
<br><a href="http://*virtualname*.comp.com" target="_top" rel="nofollow">http://*virtualname*.comp.com</a>. But the system propery/computer name is "*
<br>realname*". And "realname" is used in the kdc machine's active directory.
<br>NTLM works fine for the content server. But I can't see any kerberos
<br>handshake when I try to get the http page.
<br><br>I don't see the name is used for kerberos protocol, but rather ip. Does
<br>anybody get similar setup working? Any idea?
<br><br>thanks,
<br>Michelle
<br>________________________________________________
<br>Kerberos mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523417&i=0" target="_top" rel="nofollow">Kerberos@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/kerberos" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/kerberos</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---General-f965.html" embed="fixTarget[965]" target="_top" >Kerberos - General</a></p>tag:old.nabble.com,2006:post-26523377Re: password expiration not prompting - solaris 102009-11-25T17:55:57Z2009-11-25T17:55:57ZRuss AllberyCT <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523377&i=0" target="_top" rel="nofollow">caltri@...</a>> writes:
<br><br>> Having an issue where when an account password has expired it doesn't
<br>> prompt user to change it and lets user login. It does show a message
<br>> saying the it has expired.
<br><br>Sun intentionally disables the normal Kerberos library support for
<br>changing passwords when authenticating with expired passwords. I'm not
<br>sure why they chose to do that.
<br><br>If you're running into this in the PAM context, you can work around this
<br>by using a PAM module and an application that supports the fully correct
<br>PAM method of handling expired accounts (return success from auth and then
<br>indicate a password change is needed in the account stack), or you can use
<br>a PAM module that detects and works around this case by doing the password
<br>change prompting itself in the auth stack (my pam-krb5 with force_pwchange
<br>set in the options, for instance).
<br><br>--
<br>Russ Allbery (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523377&i=1" target="_top" rel="nofollow">rra@...</a>) <<a href="http://www.eyrie.org/~eagle/" target="_top" rel="nofollow">http://www.eyrie.org/~eagle/</a>>
<br>________________________________________________
<br>Kerberos mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26523377&i=2" target="_top" rel="nofollow">Kerberos@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/kerberos" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/kerberos</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---General-f965.html" embed="fixTarget[965]" target="_top" >Kerberos - General</a></p>tag:old.nabble.com,2006:post-26522511[krbdev.mit.edu #6586] SVN Commit2009-11-25T16:05:09Z2009-11-25T16:05:09ZGreg Hudson via RT<br>Merge Luke's iakerb-libkrb5-as-only branch into trunk with several bug
<br>fixes. Adds support for the krb5_init_creds APIs (same as Heimdal's)
<br>which allow AS requests to be performed via a different transport than
<br>the blocking send_to_kdc.
<br><br><br><a href="http://src.mit.edu/fisheye/changelog/krb5/?cs=23358" target="_top" rel="nofollow">http://src.mit.edu/fisheye/changelog/krb5/?cs=23358</a><br>Commit By: ghudson
<br>Revision: 23358
<br>Changed Files:
<br>U trunk/src/include/krb5/krb5.hin
<br>U trunk/src/lib/krb5/krb/fast.c
<br>U trunk/src/lib/krb5/krb/gc_via_tkt.c
<br>U trunk/src/lib/krb5/krb/get_in_tkt.c
<br>U trunk/src/lib/krb5/krb/gic_keytab.c
<br>U trunk/src/lib/krb5/krb/gic_pwd.c
<br>A trunk/src/lib/krb5/krb/init_creds_ctx.h
<br>U trunk/src/lib/krb5/krb/int-proto.h
<br>U trunk/src/lib/krb5/krb/mk_req_ext.c
<br>U trunk/src/lib/krb5/krb/send_tgs.c
<br>U trunk/src/lib/krb5/libkrb5.exports
<br><br>_______________________________________________
<br>krb5-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26522511&i=0" target="_top" rel="nofollow">krb5-bugs@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krb5-bugs" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krb5-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Bugs-f963.html" embed="fixTarget[963]" target="_top" >Kerberos - Bugs</a></p>tag:old.nabble.com,2006:post-26521523Re: Revisiting krb5_gic_opt_ext2009-11-25T14:38:43Z2009-11-25T14:38:43ZGreg HudsonOn Wed, 2009-11-25 at 16:58 -0500, Sam Hartman wrote:
<br>> Why does krb5_get_init_creds (the synchronous wrapper) need to call
<br>> opt_to_opte?
<br>> Why not defer opt_to_opte until the init function?
<br><br>The direct answer is: it receives an already opt_to_opte'd argument.
<br><br>But the indirect answer is: I don't think any of the callers need to do
<br>that conversion. So we can change krb5_get_init_creds to accept a
<br>non-opte'd options argument and sidestep the problem by only doing the
<br>conversion once, in krb5_init_creds_init. No need to alter the
<br>opt_to_opte contract if we do that.
<br><br>This change is slightly complicated because of all of the compatibility
<br>code which calls krb5_get_init_creds, but I will try to make it work.
<br><br><br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521523&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26521014Re: Revisiting krb5_gic_opt_ext2009-11-25T13:58:53Z2009-11-25T13:58:53ZSam HartmanWhy does krb5_get_init_creds (the synchronous wrapper) need to call
<br>opt_to_opte?
<br>Why not defer opt_to_opte until the init function?
<br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521014&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26520580Re: Revisiting krb5_gic_opt_ext2009-11-25T13:24:58Z2009-11-25T13:24:58ZGreg HudsonOn Wed, 2009-11-25 at 15:58 -0500, Jeffrey Hutzelman wrote:
<br>> 4. Make opt_to_opte copy the structure only when the input is non-extended,
<br>> and add a refcount to the extended version of the structure. Creating an
<br>> alias increments the refcount, and callers that currently free when the
<br>> "shadowed" flag is set should instead call a put operation that decs the
<br>> refcount and frees when appropriate.
<br><br>I might do this as the stopgap for merging Luke's code. The options I
<br>listed involve either copying an extended options structure (kind of a
<br>pain in the butt due to the complexity of the preauth_data field) or
<br>creating merge hassles for Sam and Luke by touching a bunch of code in
<br>the AS path.
<br><br>There are only three places where we call opt_to_opte with the force
<br>flag set, so converting the corresponding frees should be fairly
<br>painless.
<br><br>I'll amend #6034 to note the possiblity of eliminating the copies to
<br>simplify memory management, and that will be a future cleanup task.
<br><br><br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520580&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26520396GSSAPI Question2009-11-25T13:12:19Z2009-11-25T13:12:19ZShirish RaiI am trying to get GSSAPI client working with a Java based GSSAPI server.
<br>The underlying mechanism is of Kerberos. I first get a TGT and Service
<br>Ticket via Kerberos and then try to start the GSSAPI. I need to explicitly
<br>pass the credentials to be used. They cannot be the default user logged on
<br>etc. However I keep getting the following error:
<br><br>
<br><br>GSS-API error gss_krb5_acquire_cred: Unspecified GSS failure. Minor code
<br>may pro
<br><br>vide more information
<br><br>GSS-API error gss_krb5_acquire_cred: No credentials cache found
<br><br>
<br><br>I have looked at the code a bit and it seem GSS creates a new KRB context.
<br>Is there a way to tell GSS to use an existing context and/or ccache. I tried
<br>this with the gss_krb5_ccache_name API. But that did not change anything.
<br><br>
<br><br>I guess there must be a way to only user GSSAPI as well. If that is the
<br>correct way to go about his, is there an example I can look at.
<br><br>
<br><br>Here is the relevant code:
<br><br>
<br><br>Any help would be greatly appreciated.
<br><br>
<br><br>Thanks.
<br><br>
<br><br>Shirish.
<br><br>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<br><br>
<br><br>struct k5_data {
<br><br> krb5_context ctx;
<br><br> krb5_ccache cc;
<br><br> krb5_principal me;
<br><br> char* name;
<br><br>};
<br><br>
<br><br>
<br><br>int _tmain(int argc, _TCHAR* argv[])
<br><br>{
<br><br> struct k5_data k5;
<br><br> memset(&k5, 0, sizeof(k5));
<br><br> krb5_error_code code = 0;
<br><br> krb5_creds my_creds;
<br><br> krb5_get_init_creds_opt *options = NULL;
<br><br> display_file = stdout;
<br><br>
<br><br> cout << "Starting Program " << endl;
<br><br>
<br><br> code = krb5_init_context(&k5.ctx);
<br><br> if (code) {
<br><br> com_err("GSSAPI", code, " while initializing library");
<br><br> goto done;
<br><br> }
<br><br> cout << "done context" << endl;
<br><br> code = krb5_cc_default(k5.ctx, &k5.cc);
<br><br> if (code) {
<br><br> com_err("GSSAPI", code, " while initializing cache");
<br><br> goto done;
<br><br> }
<br><br> const char* cache_name = krb5_cc_get_name(k5.ctx, k5.cc);
<br><br> cout << "The name of default cache is " << cache_name << endl;
<br><br> cout << "done cc cache" << endl;
<br><br> code = krb5_parse_name(k5.ctx, USER_PRINCIPAL, &k5.me);
<br><br> if (code) {
<br><br> com_err("GSSAPI", code, " while parsing principal");
<br><br> goto done;
<br><br> }
<br><br> cout << "done parse name" << endl;
<br><br> code = krb5_get_init_creds_opt_alloc(k5.ctx, &options);
<br><br> if (code) {
<br><br> com_err("GSSAPI", code, " while allocating options");
<br><br> goto done;
<br><br> }
<br><br> cout << "done alloc of options" << endl;
<br><br> code = krb5_get_init_creds_password(k5.ctx, &my_creds, k5.me,
<br>"Secret00",
<br><br> NULL, NULL, 0, SERVICE_PRINCIPAL, NULL);
<br><br> if (code) {
<br><br> com_err("GSSAPI", code, " while init_creds_password");
<br><br> goto done;
<br><br> }
<br><br> cout << "Got service ticket" << endl;
<br><br>
<br><br> cout << "Establishing GSS context " << endl;
<br><br> OM_uint32 min_stat;
<br><br> const char* out_name;
<br><br> OM_uint32 maj_stat = gss_krb5_ccache_name(&min_stat, cache_name,
<br>&out_name);
<br><br> if (maj_stat != GSS_S_COMPLETE) {
<br><br> display_status("gss_krb5_ccache_name", maj_stat, min_stat);
<br><br> }
<br><br>
<br><br> gss_name_t desired_name;
<br><br> gss_cred_id_t cred;
<br><br> gss_buffer_desc name_tok;
<br><br> name_tok.value = USER_PRINCIPAL;
<br><br> name_tok.length = strlen(USER_PRINCIPAL);
<br><br> memset(&cred, 0, sizeof(cred));
<br><br> maj_stat = gss_import_name(&min_stat, &name_tok,
<br><br> (gss_OID) gss_nt_service_name,
<br><br> &desired_name);
<br><br> if (maj_stat != GSS_S_COMPLETE) {
<br><br> display_status("parsing name", maj_stat, min_stat);
<br><br> goto done;
<br><br> }
<br><br> maj_stat = gss_acquire_cred(&min_stat, desired_name, GSS_C_INDEFINITE,
<br><br><br> GSS_C_NULL_OID_SET, GSS_C_INITIATE, &cred, NULL, NULL);
<br><br> if (maj_stat != GSS_S_COMPLETE) {
<br><br> display_status("gss_krb5_acquire_cred", maj_stat, min_stat);
<br><br> goto done;
<br><br> }
<br><br>
<br><br> [snip]
<br><br> .
<br><br> .
<br><br>
<br><br>
<br><br><br /> <br />_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520396&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (6K) <a href="http://old.nabble.com/attachment/26520396/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26520191Re: Revisiting krb5_gic_opt_ext2009-11-25T12:58:32Z2009-11-25T12:58:32ZJeffrey Hutzelman--On Wednesday, November 25, 2009 02:40:56 PM -0500 <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520191&i=0" target="_top" rel="nofollow">ghudson@...</a> wrote:
<br><div class='shrinkable-quote'><br>> Warning: grotty stuff ahead.
<br>>
<br>> The background: the krb5_get_init_creds system was originally
<br>> specified using a caller-allocated options structure
<br>> (krb5_get_init_creds_opt), which meant options fields couldn't be
<br>> added without breaking the ABI.
<br>>
<br>> To address this, krb5_gic_opt_ext was created. This is a
<br>> library-allocated structure which is ABI-compatible with
<br>> krb5_get_init_creds_opt (sort of; see below). If you're an API which
<br>> takes an options argument, you call krb5int_gic_opt_to_opte on it,
<br>> with the "force" flag set.
<br>>
<br>> opt_to_opte has an "interesting" contract: if the input is already an
<br>> extended structure, it creates an alias; otherwise, it creates a copy
<br>> and sets a "shadowed" flag. The caller is supposed to check the
<br>> shadowed flag and free the structure when it is done.
<br>>
<br>> The problem: this contract is not nestable. If the input of
<br>> opt_to_opte is a copy created by a previous call to opt_to_opte, then
<br>> the output will be an alias which looks like a copy, and that will
<br>> result in a double-free.
<br>>
<br>> We haven't run into this problem yet because we've never had a reason
<br>> to pass an opt_to_opte'd options structure to an external API. But
<br>> I'm preparing to integrate some IAKERB support code which does;
<br>> specifically, the synchronous wrapper function krb5_get_init_creds
<br>> needs to supply options to krb5_init_creds_init.
<br>>
<br>> Possible solutions:
<br>>
<br>> 1. Make opt_to_opte copy the structure if the input is shadowed and
<br>> the force flag is set. This solves the immediate problem and creates
<br>> no extra work if the original caller used the new API.
<br>>
<br>> 2. Make opt_to_opte copy the structure all the time. This is extra
<br>> work in the common case, but makes the code easier to analyze.
<br>> ("Maybe this is allocated and maybe this is an alias" is not a very
<br>> safe construction.)
<br>>
<br>> 3. Eliminate the copies. Instead, when peering at new options fields,
<br>> use accessors which can deal with either an extended or non-extended
<br>> options structure. This would touch the most code, but would have the
<br>> same benefits of (2) without the extra allocation-and-copy work. This
<br>> would probably entail changing internal interfaces like
<br>> krb5_get_init_creds to use pointers to krb5_get_init_creds_opt instead
<br>> of krb5_gic_opt_ext.
</div><br><br>4. Make opt_to_opte copy the structure only when the input is non-extended,
<br>and add a refcount to the extended version of the structure. Creating an
<br>alias increments the refcount, and callers that currently free when the
<br>"shadowed" flag is set should instead call a put operation that decs the
<br>refcount and frees when appropriate.
<br><br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520191&i=1" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26519055Revisiting krb5_gic_opt_ext2009-11-25T11:40:56Z2009-11-25T11:40:56ZGreg HudsonWarning: grotty stuff ahead.
<br><br>The background: the krb5_get_init_creds system was originally
<br>specified using a caller-allocated options structure
<br>(krb5_get_init_creds_opt), which meant options fields couldn't be
<br>added without breaking the ABI.
<br><br>To address this, krb5_gic_opt_ext was created. This is a
<br>library-allocated structure which is ABI-compatible with
<br>krb5_get_init_creds_opt (sort of; see below). If you're an API which
<br>takes an options argument, you call krb5int_gic_opt_to_opte on it,
<br>with the "force" flag set.
<br><br>opt_to_opte has an "interesting" contract: if the input is already an
<br>extended structure, it creates an alias; otherwise, it creates a copy
<br>and sets a "shadowed" flag. The caller is supposed to check the
<br>shadowed flag and free the structure when it is done.
<br><br>The problem: this contract is not nestable. If the input of
<br>opt_to_opte is a copy created by a previous call to opt_to_opte, then
<br>the output will be an alias which looks like a copy, and that will
<br>result in a double-free.
<br><br>We haven't run into this problem yet because we've never had a reason
<br>to pass an opt_to_opte'd options structure to an external API. But
<br>I'm preparing to integrate some IAKERB support code which does;
<br>specifically, the synchronous wrapper function krb5_get_init_creds
<br>needs to supply options to krb5_init_creds_init.
<br><br>Possible solutions:
<br><br>1. Make opt_to_opte copy the structure if the input is shadowed and
<br>the force flag is set. This solves the immediate problem and creates
<br>no extra work if the original caller used the new API.
<br><br>2. Make opt_to_opte copy the structure all the time. This is extra
<br>work in the common case, but makes the code easier to analyze.
<br>("Maybe this is allocated and maybe this is an alias" is not a very
<br>safe construction.)
<br><br>3. Eliminate the copies. Instead, when peering at new options fields,
<br>use accessors which can deal with either an extended or non-extended
<br>options structure. This would touch the most code, but would have the
<br>same benefits of (2) without the extra allocation-and-copy work. This
<br>would probably entail changing internal interfaces like
<br>krb5_get_init_creds to use pointers to krb5_get_init_creds_opt instead
<br>of krb5_gic_opt_ext.
<br><br>My current preference is for (3).
<br><br>Some ancillary issues while I am in the neighborhood:
<br><br>1. In RT #6034, Tom notes that krb5_gic_opt_ext is not guaranteed to
<br>be ABI-compatible with krb5_get_init_creds_opt simply because it has
<br>the same initial fields, and instead suggests making krb5_gic_opt_ext
<br>have a krb5_get_init_creds_opt as its first field. It would be
<br>easy to make this change in concert with solution (3) above.
<br><br>2. All of the new fields in krb5_gic_opt_ext are indirected through a
<br>field opt_private, which is a pointer to a krb5_gic_opt_private
<br>structure. This feels needless; does anyone know why it was done this
<br>way, instead of just adding fields directly to krb5_gic_opt_ext?
<br>_______________________________________________
<br>krbdev mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26519055&i=0" target="_top" rel="nofollow">krbdev@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/krbdev" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/krbdev</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---Dev-f964.html" embed="fixTarget[964]" target="_top" >Kerberos - Dev</a></p>tag:old.nabble.com,2006:post-26518306password expiration not prompting - solaris 102009-11-25T10:48:17Z2009-11-25T10:48:17ZCT-8Hi,
<br><br>Having an issue where when an account password has expired it doesn't
<br>prompt user to change it and lets user login. It does show a message
<br>saying the it has expired.
<br>Running Solaris 10 client authenticating to AD kerberos. Does anyone
<br>know how I can configure pam/kerberos to prompt ?
<br><br>Thanks.
<br>________________________________________________
<br>Kerberos mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26518306&i=0" target="_top" rel="nofollow">Kerberos@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/kerberos" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/kerberos</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---General-f965.html" embed="fixTarget[965]" target="_top" >Kerberos - General</a></p>tag:old.nabble.com,2006:post-26516699Re: create principals fails2009-11-25T09:10:27Z2009-11-25T09:10:27ZGreg HudsonOn Tue, 2009-11-24 at 05:20 -0500, "kai plückhahn" wrote:
<br>> kadmin.local: Server error while initializing kadmin.local interface
<br><br>Unfortunately, as noted in previous threads
<br>(<a href="http://mailman.mit.edu/pipermail/kerberos/2009-August/015187.html" target="_top" rel="nofollow">http://mailman.mit.edu/pipermail/kerberos/2009-August/015187.html</a>) the
<br>KDC LDAP code is generating a much more informative error message, but
<br>it isn't printed due to a problem with contexts. That problem is fixed
<br>for 1.8, but that doesn't help you right now.
<br><br>One workaround is to make a debugging build of the krb5 sources and step
<br>through the process with a debugger. This is painful and laborious,
<br>though. Another option is to run kadmin.local under a system call
<br>tracing tool like strace (Linux) or truss (Solaris) to see what system
<br>interactions kadmin.local made shortly before printing the error
<br>message, but that doesn't always yield helpful information.
<br><br>The most common problem I've seen with using the KDC LDAP back end is in
<br>setting up the stash file containing the LDAP passwords for the DNs used
<br>by the KDC and kadmind. This filename is specified with the variable
<br>ldap_service_password_file inside the database settings. If you created
<br>it correctly, it should look like:
<br><br>cn=admin,dc=directorate,dc=org#{HEX}abcde12345
<br><br>where the DNs on the left should match the DNs specified in the
<br>ldap_kdc_dn and ldap_kadmind_dn variables. You say that the file is
<br>there with both passwords, but you might want to double check.
<br><br>There is a different file which holds the KDB master password. This
<br>filename is specified with the variable key_stash_file inside the realm
<br>settings, and should point to a different filename. It should contain
<br>binary data. Make sure this is separate from your LDAP password stash.
<br><br><br>________________________________________________
<br>Kerberos mailing list <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516699&i=0" target="_top" rel="nofollow">Kerberos@...</a>
<br><a href="https://mailman.mit.edu/mailman/listinfo/kerberos" target="_top" rel="nofollow">https://mailman.mit.edu/mailman/listinfo/kerberos</a><br><p>From forum: <a href="http://old.nabble.com/Kerberos---General-f965.html" embed="fixTarget[965]" target="_top" >Kerberos - General</a></p>tag:old.nabble.com,2006:post-26514545Re: Multiple database definitions are not parsed correctly2009-11-25T07:18:32Z2009-11-25T07:18:32ZGabor GombasOn Wed, Nov 25, 2009 at 07:15:35AM -0800, Love Hörnquist Ĺstrand wrote:
<br><div class='shrinkable-quote'><br>> You are right, the syntax is:
<br>>
<br>> [kdc]
<br>> database = {
<br>> label = {
<br>> realm = TEST.H5L.SE
<br>> ...
<br>> }
<br>> label2 = {
<br>> realm = TEST2.H5L.SE
<br>> ...
<br>> }
<br>> }
</div><br>Yes, that works. Thanks.
<br><br>Gabor
<br><br>--
<br> ---------------------------------------------------------
<br> MTA SZTAKI Computer and Automation Research Institute
<br> Hungarian Academy of Sciences
<br> ---------------------------------------------------------
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26514493Re: Multiple database definitions are not parsed correctly2009-11-25T07:15:35Z2009-11-25T07:15:35ZLove Hörnquist Åstrand<div class='shrinkable-quote'>>>
<br>>> The "database = {" are labels and not used by the hdb backend, change that database1 = { and database2 = { and your file should be parsed correctly.
<br>>
<br>> It may parse correctly, but it won't work, since hdb_get_dbinfo() does
<br>> this:
<br>>
<br>> db_binding = krb5_config_get_list(context, NULL,
<br>> "kdc",
<br>> "database",
<br>> NULL);
<br>>
<br>> AFAIK that won't match "database1" or "database2".
</div><br>You are right, the syntax is:
<br><br>[kdc]
<br> database = {
<br> label = {
<br> realm = TEST.H5L.SE
<br> ...
<br> }
<br> label2 = {
<br> realm = TEST2.H5L.SE
<br> ...
<br> }
<br> }
<br><br><br>Love
<br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26514110Re: Multiple database definitions are not parsed correctly2009-11-25T06:59:08Z2009-11-25T06:59:08ZGabor GombasOn Wed, Nov 25, 2009 at 02:32:24PM +0100, Love Hörnquist Ĺstrand wrote:
<br>> Gabor,
<br>>
<br>> The "database = {" are labels and not used by the hdb backend, change that database1 = { and database2 = { and your file should be parsed correctly.
<br><br>It may parse correctly, but it won't work, since hdb_get_dbinfo() does
<br>this:
<br><br> db_binding = krb5_config_get_list(context, NULL,
<br> "kdc",
<br> "database",
<br> NULL);
<br><br>AFAIK that won't match "database1" or "database2".
<br><br>> the reason you this behavior most of the time is if you have mutiple
<br>>
<br>> [realms]
<br>> REALM = {
<br>> kdc =
<br>> }
<br>>
<br>> entries in multiple files, you want the appended,and the current get_config_* doesn't understand to search for the same entry twice, so the tree is flatten on insert.
<br><br>The problem is that in the case of "database", the kdc really wants to
<br>see multiple entries with the same name.
<br><br>A possible solution would be to introduce a new key, say "databases",
<br>that in turn contain the names of the database definition sections, so
<br>kdc.conf would look like:
<br><br>[kdc]
<br> databases = database1 database2
<br> database1 = { ... }
<br> database2 = { ... }
<br><br>If "databases" is missing, it would default to "database" so existing
<br>configurations would continue to work.
<br><br>Gabor
<br><br>--
<br> ---------------------------------------------------------
<br> MTA SZTAKI Computer and Automation Research Institute
<br> Hungarian Academy of Sciences
<br> ---------------------------------------------------------
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26512693Re: Multiple database definitions are not parsed correctly2009-11-25T05:32:24Z2009-11-25T05:32:24ZLove Hörnquist ÅstrandGabor,
<br><br>The "database = {" are labels and not used by the hdb backend, change that database1 = { and database2 = { and your file should be parsed correctly.
<br><br><div class='shrinkable-quote'><br>> "verify_krb5_conf --dumpconfig" shows it is parsed incorrectly:
<br>>
<br>> [kdc]
<br>> database = {
<br>> realm = A.EXAMPLE.COM
<br>> dbname = /var/lib/heimdal-kdc/a
<br>> mkey_file = /var/lib/heimdal-kdc/a.mkey
<br>> log_file = /var/lib/heimdal-kdc/a.log
<br>> acl_file = /var/lib/heimdal-kdc/a.acl
<br>> realm = B.EXAMPLE.COM
<br>> dbname = /var/lib/heimdal-kdc/b
<br>> mkey_file = /var/lib/heimdal-kdc/b.mkey
<br>> log_file = /var/lib/heimdal-kdc/b.log
<br>> acl_file = /var/lib/heimdal-kdc/b.acl
<br>> }
</div><br>the reason you this behavior most of the time is if you have mutiple
<br><br>[realms]
<br> REALM = {
<br> kdc =
<br> }
<br><br>entries in multiple files, you want the appended,and the current get_config_* doesn't understand to search for the same entry twice, so the tree is flatten on insert.
<br><br><br>> I have sent a patch more than two years ago to fix the parser and it
<br>> seems it is still needed:
<br><br>Sorry for not catching it last time.
<br><br>Love
<br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26512555Re: Build fixes2009-11-25T05:22:50Z2009-11-25T05:22:50ZLove Hörnquist ÅstrandHello Gabor,
<br><br>Please use git format-patch next time, that makes applies deltas a lot faster. Also please send it as a attached file since somehow patches usually get destroyed before arriving to me.
<br><br>> I needed the following patches to make current git master build on
<br>> Linux:
<br>>
<br>> - "unix" is a built-in preprocessor symbol, so it cannot be used as a
<br>> variable name
<br><br>Applied
<br><br>> - kdc and kinit wanted to use some symbols that were not exported by
<br>> libkrb5/libkdc
<br><br>renamed the libkdc symbol
<br><br>> - the MIT DB code is between "#if HAVE_DB1... #endif", so use the same
<br>> check in the descriptor table
<br><br>applied
<br><br>> - glob.h did not define ROKEN_LIB_CALL and that caused havoc when it was
<br>> included before other roken headers, because those only check for the
<br>> existence of ROKEN_LIB_FUNCTION
<br><br>did the same for the other generate header too.
<br><br>Thanks for the patch,
<br>Love
<br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26509425Multiple database definitions are not parsed correctly2009-11-25T01:04:48Z2009-11-25T01:04:48ZGabor GombasHi,
<br><br>Given the following config file:
<br><br>[kdc]
<br> database = {
<br> realm = A.EXAMPLE.COM
<br> dbname = /var/lib/heimdal-kdc/a
<br> mkey_file = /var/lib/heimdal-kdc/a.mkey
<br> log_file = /var/lib/heimdal-kdc/a.log
<br> acl_file = /var/lib/heimdal-kdc/a.acl
<br> }
<br> database = {
<br> realm = B.EXAMPLE.COM
<br> dbname = /var/lib/heimdal-kdc/b
<br> mkey_file = /var/lib/heimdal-kdc/b.mkey
<br> log_file = /var/lib/heimdal-kdc/b.log
<br> acl_file = /var/lib/heimdal-kdc/b.acl
<br> }
<br><br>"verify_krb5_conf --dumpconfig" shows it is parsed incorrectly:
<br><br>[kdc]
<br> database = {
<br> realm = A.EXAMPLE.COM
<br> dbname = /var/lib/heimdal-kdc/a
<br> mkey_file = /var/lib/heimdal-kdc/a.mkey
<br> log_file = /var/lib/heimdal-kdc/a.log
<br> acl_file = /var/lib/heimdal-kdc/a.acl
<br> realm = B.EXAMPLE.COM
<br> dbname = /var/lib/heimdal-kdc/b
<br> mkey_file = /var/lib/heimdal-kdc/b.mkey
<br> log_file = /var/lib/heimdal-kdc/b.log
<br> acl_file = /var/lib/heimdal-kdc/b.acl
<br> }
<br><br>I have sent a patch more than two years ago to fix the parser and it
<br>seems it is still needed:
<br><br>diff --git a/lib/krb5/config_file.c b/lib/krb5/config_file.c
<br>index 821578d..61069ea 100644
<br>--- a/lib/krb5/config_file.c
<br>+++ b/lib/krb5/config_file.c
<br>@@ -107,6 +107,26 @@ get_entry(krb5_config_section **parent, const char *name, int type)
<br> return *q;
<br> }
<br>
<br>+static krb5_config_section *
<br>+get_new_entry(krb5_config_section **parent, const char *name, int type)
<br>+{
<br>+ krb5_config_section **q;
<br>+
<br>+ for(q = parent; *q != NULL; q = &(*q)->next)
<br>+ /* Nothing */;
<br>+ *q = calloc(1, sizeof(**q));
<br>+ if(*q == NULL)
<br>+ return NULL;
<br>+ (*q)->name = strdup(name);
<br>+ (*q)->type = type;
<br>+ if((*q)->name == NULL) {
<br>+ free(*q);
<br>+ *q = NULL;
<br>+ return NULL;
<br>+ }
<br>+ return *q;
<br>+}
<br>+
<br> /*
<br> * Parse a section:
<br> *
<br>@@ -216,7 +236,7 @@ parse_binding(struct fileptr *f, unsigned *lineno, char *p,
<br> ++p;
<br> *p2 = '\0';
<br> if (*p == '{') {
<br>- tmp = get_entry(parent, p1, krb5_config_list);
<br>+ tmp = get_new_entry(parent, p1, krb5_config_list);
<br> if (tmp == NULL) {
<br> *error_message = "out of memory";
<br> return KRB5_CONFIG_BADFORMAT;
<br><br>With the patch applied, the output of "verify_krb5_conf --dumpconfig" is
<br>identical to its input.
<br><br>Gabor
<br><br>--
<br> ---------------------------------------------------------
<br> MTA SZTAKI Computer and Automation Research Institute
<br> Hungarian Academy of Sciences
<br> ---------------------------------------------------------
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26509135Build fixes2009-11-25T00:39:19Z2009-11-25T00:39:19ZGabor GombasHi,
<br><br>I needed the following patches to make current git master build on
<br>Linux:
<br><br>- "unix" is a built-in preprocessor symbol, so it cannot be used as a
<br> variable name
<br>- kdc and kinit wanted to use some symbols that were not exported by
<br> libkrb5/libkdc
<br>- the MIT DB code is between "#if HAVE_DB1... #endif", so use the same
<br> check in the descriptor table
<br>- glob.h did not define ROKEN_LIB_CALL and that caused havoc when it was
<br> included before other roken headers, because those only check for the
<br> existence of ROKEN_LIB_FUNCTION
<br><br>Gabor
<br><br>diff --git a/kcm/main.c b/kcm/main.c
<br>index 443c71b..2b3af22 100644
<br>--- a/kcm/main.c
<br>+++ b/kcm/main.c
<br>@@ -110,8 +110,8 @@ main(int argc, char **argv)
<br> heim_sipc mach;
<br> heim_sipc_launchd_mach_init(service_name, kcm_service, NULL, &mach);
<br> } else {
<br>- heim_sipc unix;
<br>- heim_sipc_service_unix(service_name, kcm_service, NULL, &unix);
<br>+ heim_sipc un;
<br>+ heim_sipc_service_unix(service_name, kcm_service, NULL, &un);
<br> }
<br>
<br> heim_ipc_main();
<br>diff --git a/kdc/version-script.map b/kdc/version-script.map
<br>index 47e90a9..91b0319 100644
<br>--- a/kdc/version-script.map
<br>+++ b/kdc/version-script.map
<br>@@ -13,6 +13,7 @@ HEIMDAL_KDC_1.0 {
<br> krb5_kdc_process_request;
<br> krb5_kdc_save_request;
<br> krb5_kdc_update_time;
<br>+ _kdc_pk_initialize;
<br> local:
<br> *;
<br> };
<br>diff --git a/lib/hdb/hdb.c b/lib/hdb/hdb.c
<br>index 913e71a..97de918 100644
<br>--- a/lib/hdb/hdb.c
<br>+++ b/lib/hdb/hdb.c
<br>@@ -66,6 +66,8 @@ const int hdb_interface_version = HDB_INTERFACE_VERSION;
<br> static struct hdb_method methods[] = {
<br> #if HAVE_DB1 || HAVE_DB3
<br> { HDB_INTERFACE_VERSION, "db:", hdb_db_create},
<br>+#endif
<br>+#if HAVE_DB1
<br> { HDB_INTERFACE_VERSION, "mit-db:", hdb_mdb_create},
<br> #endif
<br> #if HAVE_NDBM
<br>diff --git a/lib/ipc/ts.c b/lib/ipc/ts.c
<br>index c5594c2..a10b0d3 100644
<br>--- a/lib/ipc/ts.c
<br>+++ b/lib/ipc/ts.c
<br>@@ -74,7 +74,7 @@ test_service(void *ctx, const heim_idata *req,
<br> int
<br> main(int argc, char **argv)
<br> {
<br>- heim_sipc unix;
<br>+ heim_sipc un;
<br> int optidx = 0;
<br>
<br> setprogname(argv[0]);
<br>@@ -98,7 +98,7 @@ main(int argc, char **argv)
<br> }
<br> #endif
<br> heim_sipc_service_unix("org.h5l.test-ipc",
<br>- test_service, NULL, &unix);
<br>+ test_service, NULL, &un);
<br> heim_ipc_main();
<br>
<br> return 0;
<br>diff --git a/lib/krb5/version-script.map b/lib/krb5/version-script.map
<br>index 898f992..71e99b1 100644
<br>--- a/lib/krb5/version-script.map
<br>+++ b/lib/krb5/version-script.map
<br>@@ -94,6 +94,7 @@ HEIMDAL_KRB5_2.0 {
<br> krb5_cc_get_config;
<br> krb5_cc_get_friendly_name;
<br> krb5_cc_get_full_name;
<br>+ krb5_cc_get_kdc_offset;
<br> krb5_cc_get_lifetime;
<br> krb5_cc_get_name;
<br> krb5_cc_get_ops;
<br>@@ -115,6 +116,7 @@ HEIMDAL_KRB5_2.0 {
<br> krb5_cc_set_flags;
<br> krb5_cc_start_seq_get;
<br> krb5_cc_store_cred;
<br>+ krb5_cc_support_switch;
<br> krb5_cc_switch;
<br> krb5_cc_set_friendly_name;
<br> krb5_change_password;
<br>diff --git a/lib/roken/glob.hin b/lib/roken/glob.hin
<br>index ffb6081..5cdcdf2 100644
<br>--- a/lib/roken/glob.hin
<br>+++ b/lib/roken/glob.hin
<br>@@ -38,8 +38,10 @@
<br> #ifndef ROKEN_LIB_FUNCTION
<br> #ifdef _WIN32
<br> #define ROKEN_LIB_FUNCTION _stdcall
<br>+#define ROKEN_LIB_CALL __cdecl
<br> #else
<br> #define ROKEN_LIB_FUNCTION
<br>+#define ROKEN_LIB_CALL
<br> #endif
<br> #endif
<br>
<br><br>--
<br> ---------------------------------------------------------
<br> MTA SZTAKI Computer and Automation Research Institute
<br> Hungarian Academy of Sciences
<br> ---------------------------------------------------------
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507718Re: krb5/locate_plugin.h issue - heimdal-1.3.12009-11-24T21:23:40Z2009-11-24T21:23:40ZLove Hörnquist Åstrand<div class='shrinkable-quote'>>>>
<br>>>> Looking into this further, the above include was dropped deliberately
<br>>>> (commit ecfa87ed), although the commit message does not say why. Should
<br>>>> that commit be reverted or is there another fix I am missing?
<br>>>
<br>>> I assume this is done since we don't want to hardwire in the location of <krb5.h> in the header file, it should really be <krb5/krb5.h>, but we don't do that yet.
<br>>>
<br>>
<br>> OK. So this is a transition thing. Although it seems a bit strange to
<br>> me that a header file does not include all its needed headers.
</div><br>If it was up to me I would just require the caller to pull in <krb5/krb5.h> and thats it for all public interfaces.
<br><br>Love
<br><br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507598Re: krb5/locate_plugin.h issue - heimdal-1.3.12009-11-24T21:02:11Z2009-11-24T21:02:11ZAllan McRae-3Love Hörnquist Åstrand wrote:
<div class='shrinkable-quote'><br>> 25 nov 2009 kl. 05:30 skrev Allan McRae:
<br>>
<br>>> Hi,
<br>>>
<br>>> When compiling samba against heimdal-1.3.1, I get warnings like:
<br>>>
<br>>> configure: WARNING: krb5/locate_plugin.h: present but cannot be compiled
<br>>>
<br>>> Testing with compiling a program with only "#include
<br>>> <krb5/locate_plugin.h>" in it, I get the following error:
<br>>>
<br>>> In file included from test.c:1:
<br>>> /usr/include/krb5/locate_plugin.h:50: error: expected declaration
<br>>> specifiers or ‘...’ before ‘*’ token
<br>>> /usr/include/krb5/locate_plugin.h:53: error: ‘krb5_error_code’ declared
<br>>> as function returning a function
<br>>> /usr/include/krb5/locate_plugin.h:58: error: expected ‘)’ before ‘void’
<br>>> /usr/include/krb5/locate_plugin.h:59: error: expected ‘;’ before ‘void’
<br>>>
<br>>>
<br>>> Re-adding "#include <krb5.h>" at the top of the include file fixes the
<br>>> compile error. This include was present in the heimdal-1.2 releases.
<br>>>
<br>>> Looking into this further, the above include was dropped deliberately
<br>>> (commit ecfa87ed), although the commit message does not say why. Should
<br>>> that commit be reverted or is there another fix I am missing?
<br>>
<br>> I assume this is done since we don't want to hardwire in the location of <krb5.h> in the header file, it should really be <krb5/krb5.h>, but we don't do that yet.
<br>>
</div><br>OK. So this is a transition thing. Although it seems a bit strange to
<br>me that a header file does not include all its needed headers.
<br><br>> The samba folks should really include approriate krb5.h before pulling in locate_plugin.h in the autoconf test.
<br><br>I will send them a message to let them know.
<br><br>Allan
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507516Re: replay cache2009-11-24T20:46:12Z2009-11-24T20:46:12ZQuanah Gibson-Mount-3--On Wednesday, November 25, 2009 5:37 AM +0100 Love Hörnquist Åstrand
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26507516&i=0" target="_top" rel="nofollow">lha@...</a>> wrote:
<br><br>>
<br>> 25 nov 2009 kl. 04:59 skrev Quanah Gibson-Mount:
<br>>
<br>>> Is there a way to disable the replay cache in Heimdal? MIT provided
<br>>> that functionality via an environment variable some time ago because of
<br>>> the performance hit it can cause. I didn't see anything immediate in
<br>>> browsing the 1.2.1 source.
<br>>
<br>> Replay cache is disabled by default.
<br><br>Great, thanks!
<br><br>--Quanah
<br><br>--
<br><br>Quanah Gibson-Mount
<br>Principal Software Engineer
<br>Zimbra, Inc
<br>--------------------
<br>Zimbra :: the leader in open source messaging and collaboration
<br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507472Re: krb5/locate_plugin.h issue - heimdal-1.3.12009-11-24T20:40:07Z2009-11-24T20:40:07ZLove Hörnquist Åstrand<br>25 nov 2009 kl. 05:30 skrev Allan McRae:
<br><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> When compiling samba against heimdal-1.3.1, I get warnings like:
<br>>
<br>> configure: WARNING: krb5/locate_plugin.h: present but cannot be compiled
<br>>
<br>> Testing with compiling a program with only "#include
<br>> <krb5/locate_plugin.h>" in it, I get the following error:
<br>>
<br>> In file included from test.c:1:
<br>> /usr/include/krb5/locate_plugin.h:50: error: expected declaration
<br>> specifiers or ‘...’ before ‘*’ token
<br>> /usr/include/krb5/locate_plugin.h:53: error: ‘krb5_error_code’ declared
<br>> as function returning a function
<br>> /usr/include/krb5/locate_plugin.h:58: error: expected ‘)’ before ‘void’
<br>> /usr/include/krb5/locate_plugin.h:59: error: expected ‘;’ before ‘void’
<br>>
<br>>
<br>> Re-adding "#include <krb5.h>" at the top of the include file fixes the
<br>> compile error. This include was present in the heimdal-1.2 releases.
<br>>
<br>> Looking into this further, the above include was dropped deliberately
<br>> (commit ecfa87ed), although the commit message does not say why. Should
<br>> that commit be reverted or is there another fix I am missing?
</div><br>I assume this is done since we don't want to hardwire in the location of <krb5.h> in the header file, it should really be <krb5/krb5.h>, but we don't do that yet.
<br><br>The samba folks should really include approriate krb5.h before pulling in locate_plugin.h in the autoconf test.
<br><br>Love
<br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507462Re: replay cache2009-11-24T20:37:39Z2009-11-24T20:37:39ZLove Hörnquist Åstrand<br>25 nov 2009 kl. 04:59 skrev Quanah Gibson-Mount:
<br><br>> Is there a way to disable the replay cache in Heimdal? MIT provided that
<br>> functionality via an environment variable some time ago because of the
<br>> performance hit it can cause. I didn't see anything immediate in browsing
<br>> the 1.2.1 source.
<br><br>Replay cache is disabled by default.
<br><br>Love
<br><br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>tag:old.nabble.com,2006:post-26507420krb5/locate_plugin.h issue - heimdal-1.3.12009-11-24T20:30:33Z2009-11-24T20:30:33ZAllan McRae-3Hi,
<br><br>When compiling samba against heimdal-1.3.1, I get warnings like:
<br><br>configure: WARNING: krb5/locate_plugin.h: present but cannot be compiled
<br><br>Testing with compiling a program with only "#include
<br><krb5/locate_plugin.h>" in it, I get the following error:
<br><br>In file included from test.c:1:
<br>/usr/include/krb5/locate_plugin.h:50: error: expected declaration
<br>specifiers or ‘...’ before ‘*’ token
<br>/usr/include/krb5/locate_plugin.h:53: error: ‘krb5_error_code’ declared
<br>as function returning a function
<br>/usr/include/krb5/locate_plugin.h:58: error: expected ‘)’ before ‘void’
<br>/usr/include/krb5/locate_plugin.h:59: error: expected ‘;’ before ‘void’
<br><br><br>Re-adding "#include <krb5.h>" at the top of the include file fixes the
<br>compile error. This include was present in the heimdal-1.2 releases.
<br><br>Looking into this further, the above include was dropped deliberately
<br>(commit ecfa87ed), although the commit message does not say why. Should
<br>that commit be reverted or is there another fix I am missing?
<br><br>Thanks,
<br>Allan
<br><br><p>From forum: <a href="http://old.nabble.com/Heimdal---General-f969.html" embed="fixTarget[969]" target="_top" >Heimdal - General</a></p>