Segmentation fault when trying to start kadmind

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Segmentation fault when trying to start kadmind

Joshua Schaeffer

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Joshua Schaeffer

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Joshua Schaeffer
In reply to this post by Joshua Schaeffer
On 07/17/2017 04:59 PM, Greg Hudson wrote:
> (Sent unicast.)
>
> Hm, our mailing list software seems to have removed all of the content
> from both of your messages, due to some incompatibility with the way
> they were formatted.  Would it be possible to combine them and resend
> them as plain text?  Unfortunately I no longer have a copy of the
> contents after moderating them through.
>

Sure, no problem, here they are. Let me know if there are still issues with getting my content. I sent this one in plaintext:
 

I ran the kdb5_util program under valgrind as well and saw this, thought I'd pass it along:

    root@bllkrb501:~# valgrind kdb5_util stash -f /etc/krb5kdc/stash
    ==16389== Memcheck, a memory error detector
    ==16389== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
    ==16389== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
    ==16389== Command: kdb5_util stash -f /etc/krb5kdc/stash
    ==16389==
    stat(/usr/local/lib/krb5/plugins/kdb/kldap): No such file or directory
    get_plugin_data_sym(kdb_function_table)
    ==16389== Warning: invalid file descriptor -1 in syscall write()
    kdb5_util: Cannot find master key record in database while getting master key list
    kdb5_util: Warning: proceeding without master key list
    Enter KDC database master key:
    ==16389== Invalid read of size 2
    ==16389==    at 0x506DFA8: krb5_db_fetch_mkey (kdb5.c:1224)
    ==16389==    by 0x406D56: kdb5_stash (kdb5_stash.c:110)
    ==16389==    by 0x4048F1: main (kdb5_util.c:346)
    ==16389==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
    ==16389==
    ==16389==
    ==16389== Process terminating with default action of signal 11 (SIGSEGV)
    [...]

NULL pointer?

On 07/17/2017 03:35 PM, Joshua Schaeffer wrote:

> TL;DR
> I'm getting a segmentation error when I run kdb5_util stash from a compiled version of 1.15.1:
>
>     Program received signal SIGSEGV, Segmentation fault.
>         0x00007ffff799afa8 in krb5_db_fetch_mkey (context=0x61eb80, mname=0x678a60, etype=18, fromkeyboard=1, twice=0,
>             db_args=0x0, kvno=0x7fffffffe56c, salt=0x0, key=0x619c30 <master_keyblock>) at kdb5.c:1224
>         1224                    *kvno = (krb5_kvno) master_entry->key_data->key_data_kvno;
>
> --------------------------------------------------------
>
> Hey all,
>
> I'm trying to figure out why I'm getting a segmentation fault when I try to start the krb5-admin-server service. I have a server running in an LXD container, which I think is causing the issue, but I'm not sure what the container doesn't have permissions/rights to that is causing this problem and I've searched all my log files far and wide and can't find any smoking gun. So here is what I've done:
>
> First I tried installing MIT Kerberos using the package management system which installs version 1.13.2. Then I setup my krb5.conf file and initialize my database:
>
>     kdb5_ldap_util -D cn=admin,dc=appendata,dc=net create -subtrees 'ou=End Users,ou=People,dc=appendata,dc=net':'ou=Other Users,ou=People,dc=appendata,dc=net -r APPENDATA.NET -s -H ldaps://bllldap01.appendata.net
>
> This works without issue, so I proceed by stashing a few ldap user's passwords, create my kadm5.acl file and then I go and try to start kadmind:
>
>     root@bllkrb501:~# systemctl start krb5-admin-server
>     root@bllkrb501:~# systemctl status krb5-admin-server
>      krb5-admin-server.service - Kerberos 5 Admin Server
>        Loaded: loaded (/lib/systemd/system/krb5-admin-server.service; enabled; vendor preset: enabled)
>       Drop-In: /lib/systemd/system/krb5-admin-server.service.d
>                └─slapd-before-kdc.conf
>        Active: failed (Result: core-dump) since Mon 2017-07-17 15:00:36 MDT; 6s ago
>       Process: 3304 ExecStart=/usr/sbin/kadmind -nofork $DAEMON_ARGS (code=dumped, signal=SEGV)
>      Main PID: 3304 (code=dumped, signal=SEGV)
>
>     Jul 17 15:00:35 bllkrb501 systemd[1]: Started Kerberos 5 Admin Server.
>     Jul 17 15:00:36 bllkrb501 systemd[1]: krb5-admin-server.service: Main process exited, code=dumped, status=11/SEGV
>     Jul 17 15:00:36 bllkrb501 systemd[1]: krb5-admin-server.service: Unit entered failed state.
>     Jul 17 15:00:36 bllkrb501 systemd[1]: krb5-admin-server.service: Failed with result 'core-dump'.
>
> And if I try to start kadmind manually:
>
>     root@bllkrb501:~# kadmind -nofork
>     Segmentation fault (core dumped)
>
> Here is an strace of the same command:
>
>     [...]
>     write(11, "\27\3\3\2Y\0\0\0\0\0\0\0\3ZMi\3049\2256\337\17y}\361\237\4Kv\f\347\233"..., 606) = 606
>     poll([{fd=11, events=POLLIN|POLLPRI}], 1, 300000) = 1 ([{fd=11, revents=POLLIN}])
>     read(11, "\27\3\3\0&", 5)               = 5
>     read(11, "\0\0\0\0\0\0\0\4\313(H\177\362\376\4\34\251\266T\23\5\ndj\327\311\304\30\177\31\26b"..., 38) = 38
>     write(11, "\27\3\3\2[\0\0\0\0\0\0\0\4\244G3\341}F\35:\340\244\356\250\254T\365g\7\240r"..., 608) = 608
>     poll([{fd=11, events=POLLIN|POLLPRI}], 1, 300000) = 1 ([{fd=11, revents=POLLIN}])
>     read(11, "\27\3\3\0&", 5)               = 5
>     read(11, "\0\0\0\0\0\0\0\5\4\204S\v9\305v\217\324\r\316\313\207\2405\245\2749\242\356\341\361h\367"..., 38) = 38
>     write(11, "\27\3\3\2g\0\0\0\0\0\0\0\5\34\306\243F\177zh\370s\352\230\206\243\215\345\3719\\_"..., 620) = 620
>     poll([{fd=11, events=POLLIN|POLLPRI}], 1, 300000) = 1 ([{fd=11, revents=POLLIN}])
>     read(11, "\27\3\3\2\27", 5)             = 5
>     read(11, "\0\0\0\0\0\0\0\6\f\332:\226l\34J\0\344v\304K\203\242\0\356[X~\225\347\253\37P"..., 535) = 535
>     poll([{fd=11, events=POLLIN|POLLPRI}], 1, 299999) = 1 ([{fd=11, revents=POLLIN}])
>     read(11, "\27\3\3\0&", 5)               = 5
>     read(11, "\0\0\0\0\0\0\0\7v\215\202\33\312\325\316xL4&\305i^\310\21,X\226\211\357\317\323\354"..., 38) = 38
>     open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 23
>     fstat(23, {st_mode=S_IFREG|0644, st_size=2453, ...}) = 0
>     fstat(23, {st_mode=S_IFREG|0644, st_size=2453, ...}) = 0
>     read(23, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 2560) = 2453
>     lseek(23, -1559, SEEK_CUR)              = 894
>     read(23, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 2560) = 1559
>     close(23)                               = 0
>     --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---
>     +++ killed by SIGSEGV (core dumped) +++
>     Segmentation fault (core dumped)
>
> I wasn't able to determine too much from this. To me it looks like the system is opening /etc/localtime and then the program crashes. Next I resorted to debugging the error and that is where I'm currently at. I downloaded the source code for 1.15.1, installed it, and reran through all my steps. I wasn't able to get to my step of trying to start kadmind, because it complains the stash file doesn't exist for the master key, which it doesn't, and I'm not sure why it isn't created when I issued my krb5_ldap_util command above, but I was able to still get a segmentation fault when I try to create the stash file:
>
>     root@bllkrb501:~# kdb5_util stash
>     stat(/usr/local/lib/krb5/plugins/kdb/kldap): No such file or directory
>     get_plugin_data_sym(kdb_function_table)
>     kdb5_util: Cannot find master key record in database while getting master key list
>     kdb5_util: Warning: proceeding without master key list
>     Enter KDC database master key:
>     Segmentation fault (core dumped)
>
>     root@bllkrb501:~# ls -l /usr/local/lib/krb5/plugins/kdb/
>     total 407
>     -rw-r--r-- 1 root root 366680 Jul 17 12:51 db2.so
>     -rw-r--r-- 1 root root  21008 Jul 17 12:51 kldap.so
>
> I'm not sure why it is complaining about plugins/kdb/kldap not existing either. The shared object exists under that directory. Perhaps this is the problem. I compiled Kerberos with "--with-ldap". I've also run the same command through gdb and got the line it is failing at:
>
>     root@bllkrb501:~# gdb kdb5_util
>     [...]
>     Reading symbols from kdb5_util...done.
>     (gdb) run stash -f /etc/krb5kdc/stash
>     Starting program: /usr/local/sbin/kdb5_util stash -f /etc/krb5kdc/stash
>     [Thread debugging using libthread_db enabled]
>     Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>     stat(/usr/local/lib/krb5/plugins/kdb/kldap): No such file or directory
>     get_plugin_data_sym(kdb_function_table)
>     kdb5_util: Cannot find master key record in database while getting master key list
>     kdb5_util: Warning: proceeding without master key list
>     Enter KDC database master key:
>
>     Program received signal SIGSEGV, Segmentation fault.
>     0x00007ffff799afa8 in krb5_db_fetch_mkey (context=0x61eb80, mname=0x678a60, etype=18, fromkeyboard=1, twice=0,
>         db_args=0x0, kvno=0x7fffffffe56c, salt=0x0, key=0x619c30 <master_keyblock>) at kdb5.c:1224
>     1224                    *kvno = (krb5_kvno) master_entry->key_data->key_data_kvno;
>     (gdb) continue
>     Continuing.
>
>     Program terminated with signal SIGSEGV, Segmentation fault.
>     The program no longer exists.
>     (gdb) quit
>
> I looked at the code and this is where it is actually failing:
>
>     1218    if (kvno != NULL && *kvno == IGNORE_VNO) {
>     1219            krb5_error_code rc;
>     1220            krb5_db_entry *master_entry;
>
>     1222            rc = krb5_db_get_principal(context, mname, 0, &master_entry);
>     1223            if (rc == 0) {
>     1224                *kvno = (krb5_kvno) master_entry->key_data->key_data_kvno;
>     1225                krb5_db_free_principal(context, master_entry);
>     1226            } else
>     1227                *kvno = 1;
>     1228        }
>
> I don't really know where to go from here. I don't know this code well enough to figure out why the segmentation error is occurring. Can anybody help me out? If you need additional information, I'd be happy to provide.
>
> Thanks,
> Joshua Schaeffer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Greg Hudson
On 07/17/2017 07:48 PM, Joshua Schaeffer wrote:
>>     1222            rc = krb5_db_get_principal(context, mname, 0, &master_entry);
>>     1223            if (rc == 0) {
>>     1224                *kvno = (krb5_kvno) master_entry->key_data->key_data_kvno;
>>     1225                krb5_db_free_principal(context, master_entry);
>>     1226            } else
>>     1227                *kvno = 1;
>>     1228        }
>>
>> I don't really know where to go from here. I don't know this code well enough to figure out why the segmentation error is occurring. Can anybody help me out? If you need additional information, I'd be happy to provide.

The proximal bug is that master_entry->key_data is an array, bounded by
master_entry->n_key_data, and this code isn't checking if
master_entry->n_key_data > 0 before dereferencing the first element.
You could fix that bug (set *kvno = 1 if n_key_data is 0) and probably
get kdb5_util stash and kadmind to report an error rather than crash.

That leaves several mysteries, which I don't have the answer to:

* Why does the master DB entry (K/M) have no key data?

* Why isn't the code able to load the shared object from
/usr/local/lib/krb5/plugins/kdb/kldap?  (It is probably falling back to
the module in the system directory which is the 1.13.x code, which is
why it continues to work at all.)

* Where is that "invalid file descriptor -1 in syscall write()" event
occurring in the code, and why?  It happens before the master password
is read, so it's presumably not from the code that writes the stash file.

* Why didn't kdb5_ldap_util create -s make a stash file?  (Did you
re-run kdb5_ldap_util create after locally building 1.15.1?  If not, the
stash file might be in a different place than the 1.15.1 code is looking
for it.)
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Joshua Schaeffer
On 07/18/2017 09:50 AM, Greg Hudson wrote:
> The proximal bug is that master_entry->key_data is an array, bounded by
> master_entry->n_key_data, and this code isn't checking if
> master_entry->n_key_data > 0 before dereferencing the first element.
> You could fix that bug (set *kvno = 1 if n_key_data is 0) and probably
> get kdb5_util stash and kadmind to report an error rather than crash.

Thanks for the suggestion, this has gotten me farther. I changed the code, started from a fresh container, and reran through my steps and I was able to get past the seg fault (See below for results).

> That leaves several mysteries, which I don't have the answer to:
>
> * Why does the master DB entry (K/M) have no key data?

Well, I believe this is the key question. When I run kdb5_util stash I now get this error:

    root@bllkrb501:/usr/local/lib/krb5/plugins/kdb# kdb5_util stash -f /usr/local/etc/krb5kdc/stash
    get_plugin_data_sym(kdb_function_table)
    kdb5_util: Can not fetch master key (error: No such file or directory). while reading master key
    kdb5_util: Warning: proceeding without master key
    Enter KDC database master key:
    kdb5_util: Cannot find master key record in database while getting master key list

But the problem is the record does exist:

    root@bllkrb501:/usr/local/lib/krb5/plugins/kdb# ldapsearch -LLL -D cn=kdc-srv,dc=appendata,dc=net -W -H ldaps://bllldap01.appendata.net -b cn=krbContainer,dc=appendata,dc=net '(krbPrincipalName=K/M*)'
    Enter LDAP Password:
    dn: krbPrincipalName=K/[hidden email],cn=APPENDATA.NET,cn=krbContainer,dc=appendata,dc=net
    krbLoginFailedCount: 0
    krbMaxTicketLife: 36000
    krbMaxRenewableAge: 604800
    krbTicketFlags: 192
    krbPrincipalName: K/[hidden email]
    krbPrincipalExpiration: 19700101000000Z
    krbLastPwdChange: 19700101000000Z
    krbExtraData:: ...
    krbExtraData:: ...
    krbExtraData:: ...
    objectClass: krbPrincipal
    objectClass: krbPrincipalAux
    objectClass: krbTicketPolicyAux

So, are you saying that something is missing from this record?

I'm leaning towards it not being an LDAP connection issue or access list problem, because I can destroy the realm successfully and recreate it many times over from the Kerberos server. However, I'm going to look through the LDAP logs when I get a chance tomorrow, just to make sure nothing pops up from the LDAP side.

> * Why isn't the code able to load the shared object from
> /usr/local/lib/krb5/plugins/kdb/kldap?  (It is probably falling back to
> the module in the system directory which is the 1.13.x code, which is
> why it continues to work at all.)

I just created a symlink and this error now goes away. You can see from the command above that all that gets reported now is "get_plugin_data_sym(kdb_function_table)".

    root@bllkrb501:/usr/local/lib/krb5/plugins/kdb# ls -l
    total 408
    -rw-r--r-- 1 root root 366680 Jul 18 20:53 db2.so
    lrwxrwxrwx 1 root root      8 Jul 18 20:59 kldap -> kldap.so
    -rw-r--r-- 1 root root  21008 Jul 18 20:53 kldap.so

I don't know why a symlink wouldn't get created when I installed Kerberos from the package management system. I would think something like this would be included in the post install scripts. Ultimately this seems to fix/change nothing. I'm still seeing my core issue. I just don't get that annoying warning anymore. :/
>
> * Where is that "invalid file descriptor -1 in syscall write()" event
> occurring in the code, and why?  It happens before the master password
> is read, so it's presumably not from the code that writes the stash file.

Currently unsure on this one. Need to do more debugging and research.

>
> * Why didn't kdb5_ldap_util create -s make a stash file?  (Did you
> re-run kdb5_ldap_util create after locally building 1.15.1?  If not, the
> stash file might be in a different place than the 1.15.1 code is looking
> for it.)
I thought the same thing. The first time I compiled the code I used "--sysconfdir=/etc". I couldn't find a stash file anywhere under this directory. When I changed the code and recompiled I just used all the /usr/local/... defaults this time, thinking maybe this time it will just create the stash file under /usr/local/etc instead, but still no luck. After I do a make install I get nothing under that directory.

I've searched my entire system for a file called "stash" (that's what KRB5 creates when you add the -s, right?) and I can't find anything. I guess I need to do more debugging on this too to see why it isn't actually creating the stash file. My assumption is that it isn't being created because of the error above.

Thanks,
Joshua Schaeffer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Greg Hudson
On 07/18/2017 11:49 PM, Joshua Schaeffer wrote:
>> * Why does the master DB entry (K/M) have no key data?
>
> Well, I believe this is the key question. When I run kdb5_util stash I
> now get this error:
[...]
>     kdb5_util: Cannot find master key record in database while getting
> master key list
>
> But the problem is the record does exist: [...]

This error message is likely conflating "K/M doesn't exist" with "K/M
exists but has no key data".

In the LDAP record you included, there is no krbPrincipalKey attribute,
as one would ordinarily see in the K/M record.  That key data should be
included when the DB is created by kdb5_ldap_util; I have no theories as
to why it's not showing up in your scenario.

>> * Why isn't the code able to load the shared object from
>> /usr/local/lib/krb5/plugins/kdb/kldap?
[...]
> I just created a symlink and this error now goes away.

That suggests the code is looking for the wrong thing at runtime (kldap
instead of kldap.so), which is not normal.  That symlink shouldn't be
needed.  As you noted, this issue appears to be of ancillary importance,
but it adds to the confusion.

> I've searched my entire system for a file called "stash" (that's what
> KRB5 creates when you add the -s, right?) and I can't find anything.

The default name for the stash file is .k5.<REALM> in the KDC directory.
 (That default was chosen some decades ago and would not be my choice
today.)  So I guess search for ".k5.".  The key_stash_file profile
variable in the kdc.conf realm subsection can be used to override the
filename.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Joshua Schaeffer
On 07/19/2017 09:45 AM, Greg Hudson wrote:
>
> This error message is likely conflating "K/M doesn't exist" with "K/M
> exists but has no key data".
>
> In the LDAP record you included, there is no krbPrincipalKey attribute,
> as one would ordinarily see in the K/M record.  That key data should be
> included when the DB is created by kdb5_ldap_util; I have no theories as
> to why it's not showing up in your scenario.

Greg, thanks for pointing this out, it got me on the right track to fixing the problem. It turned out to be an LDAP access issue. I started by deleting everything from LDAP and then recreating the realm and when I checked LDAP again I saw the krbPrincipalKey attribute, but then when I tried to create the stash I got the same error. So I re-queried LDAP again and I could no longer see the krbPrincipalKey. This got me thinking about the access lists I had setup. I had these two:
**
    olcAccess: {0}to attrs=shadowLastChange,krbPrincipalKey
     by self write
     by anonymous auth
     by dn="cn=admin,dc=appendata,dc=net" write
     by * none
    olcAccess: {6}to dn.sub="cn=krbContainer,dc=appendata,dc=net"
     by dn="cn=kdc-srv,dc=appendata,dc=net" read
     by dn="cn=adm-srv,dc=appendata,dc=net" write
     by * break

Since the ACL that gives the ldap_kdc_dn and ldap_kadmind_dn come after the ACL that controls the krbPrincipalKey attribute, it was never getting to the second ACL and was not able to actually see the krbPrincipalKey attribute. That's why I was able to see the attribute at first, because I was using the admin user from the LDAP server (its just habit for me to do that when I'm on the actual LDAP server). Then I switched to using the adm-srv user when I was on the Kerberos server since this is the actual user that queries LDAP for Kerberos. I updated my ACL's and was able to get pass all my errors and issues, including the segmentation fault.

I do have a couple more questions though:

* Do you know if ldap_kdc_dn needs read rights to the krbPrincipalKey attribute? My understanding is that it just needs read rights to everything under my krbContainer, which is what I have, but does it need to actually read the keys. If not, I'd like to take this access away. Obviously I'll keep the read and write rights for ldap_kadmind_dn.

* Would you consider the segmentation fault a bug? I know it was a configuration problem, but it was not necessarily easy or quick to track this down
and it was not obvious an access issue was the problem. An actual error might be more helpful. I'm sure this problem can be duplicated by simply setting up KRB5 to connect to LDAP and configure the ACL's like I did.

>
> The default name for the stash file is .k5.<REALM> in the KDC directory.
>  (That default was chosen some decades ago and would not be my choice
> today.)  So I guess search for ".k5.".  The key_stash_file profile
> variable in the kdc.conf realm subsection can be used to override the
> filename.
This is good to know, thanks.

Thanks,
Joshua Schaeffer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Greg Hudson
On 07/19/2017 08:22 PM, Joshua Schaeffer wrote:
> * Do you know if ldap_kdc_dn needs read rights to the krbPrincipalKey
> attribute?

It does.  The KDC is the primary user of principal long-term keys; it
uses them to verify pre-authentication, encrypt KDC replies, and encrypt
service tickets.

> * Would you consider the segmentation fault a bug?

I filed a PR for the crash bug and it should be fixed in upcoming patch
releases.  This bug only occurs when the master key is manually entered
(no stash file) and the K/M entry has no key data (LDAP access error).
I'm still not sure why kdb5_ldap_util create -s didn't create a stash
file in your scenario.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation fault when trying to start kadmind

Joshua Schaeffer
On 07/19/2017 06:54 PM, Greg Hudson wrote:
> On 07/19/2017 08:22 PM, Joshua Schaeffer wrote:
>> * Do you know if ldap_kdc_dn needs read rights to the krbPrincipalKey
>> attribute?
> It does.  The KDC is the primary user of principal long-term keys; it
> uses them to verify pre-authentication, encrypt KDC replies, and encrypt
> service tickets.

Okay, good to know. I will leave that account as is.

>
>> * Would you consider the segmentation fault a bug?
> I filed a PR for the crash bug and it should be fixed in upcoming patch
> releases.  This bug only occurs when the master key is manually entered
> (no stash file) and the K/M entry has no key data (LDAP access error).
> I'm still not sure why kdb5_ldap_util create -s didn't create a stash
> file in your scenario.
Yes, I am unsure about this too. If I had to guess it was just a combination of running through my steps multiple times which created some weird environment situation. Or, more likely, it was just an EBKAC error :)

Thanks again for all your help.
Joshua Schaeffer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Loading...