Hi,

        I have an issue accessing the file system after
        an OS upgrade on one of our KRB5 Heimdal KDCs
        (which is a Linux distribution called UCS(V3.2)
        based on debian).

        While the update process, a script was executed, that
        must have altered the enctypes (or more?) of the principals.

        I can do a kinit and a aklog on the clients fine, but
        trying to access files ends up in "Permission denied"
        klist -a shows:


---------------------------------------
    Credentials cache: FILE:/tmp/krb5cc_0
    Principal: john@MYCELL
    Cache version: 4

Server: krbtgt/MYCELL@MYREALM
Client: john@MYCELL
Ticket etype: aes256-cts-hmac-sha1-96, kvno 1
Ticket length: 315
Auth time:  Sep 26 10:49:19 2014
End time:   Sep 26 20:49:17 2014
Ticket flags: enc-pa-rep, pre-authent, initial, proxiable, forwardable
Addresses: addressless

Server: afs/MYCELL@MYREALM
Client: john@MYCELL
Ticket etype: aes256-cts-hmac-sha1-96, kvno 1
Session key: des-cbc-crc
Ticket length: 307
Auth time:  Sep 26 10:49:19 2014
End time:   Sep 26 20:49:17 2014
Ticket flags: transited-policy-checked, pre-authent, proxiable, forwardable
Addresses: addressless
-------------------------------------------------------


        The good thing is, that I have an old untouched
        KDC which can still be used for AFS authentication.

        If I check the features of the "good" old KDC for
        the afs/MYCELL principal I get:

------------------------------------------------------
        kadmin> get afs/MYCELL
            Principal: afs/MYCELL@MYREALM
    Principal expires: never
     Password expires: never
 Last password change: never
      Max ticket life: 1 week
   Max renewable life: 1 week
                 Kvno: 1
                Mkvno: 0
Last successful login: never
    Last failed login: never
   Failed login count: 0
        Last modified: 2014-09-25 07:51:29 UTC
             Modifier: unknown
           Attributes:
             Keytypes: des-cbc-md5(pw-salt), des-cbc-md4(pw-salt),
des-cbc-crc(pw-salt), aes256-cts-hmac-sha1-96(pw-salt),
des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt)
          PK-INIT ACL:
              Aliases:
---------------------------------------------------------
        
        on the new "bad" one I see:

---------------------------------------------------------
kadmin> get afs/MYCELL
            Principal: afs/MYCELL@MYREALM
    Principal expires: never
     Password expires: never
 Last password change: never
      Max ticket life: 1 week
   Max renewable life: 1 week
                 Kvno: 1
                Mkvno: unknown
Last successful login: never
    Last failed login: never
   Failed login count: 0
        Last modified: 2014-09-25 07:51:29 UTC
             Modifier: unknown
           Attributes:
             Keytypes: des-cbc-md5(pw-salt)[1], des-cbc-md4(pw-salt)[1],
des-cbc-crc(pw-salt)[1], aes256-cts-hmac-sha1-96(pw-salt)[1],
des3-cbc-sha1(pw-salt)[1], arcfour-hmac-md5(pw-salt)[1]
          PK-INIT ACL:
              Aliases:
----------------------------------------------------------

        I'm by no means a KRB expert, but my assumption is,
        that the differences here
        (e.g. Mkvno or des-cbc-crc(pw-salt)[1]) might cause the
        trouble. So the alterations of the afs service principal
        on the new KDC do not correctly correspond to the key
        that was once exported and provided to my AFSCell via
        bos addkey.

        My idea would be to extract the new altered key from
        the new KDC and add it via bos addkey to my cell.

        So my questions are:

        Does that sound reasonable, or am I totally wrong here? Would   
        there be other possibilities to debug that issue?

        Do I need to modify the afs/CELL principal in a certain way
        before the export?

        Is there a way to keep the old afs/CELL key in my environment,
        because I do not want to end up in not being able to
        access my cell at all, if the export/re-import of the
        new key fails?


Thanks for your advise
Bests
Andreas

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to