Thank you, I just verified it. After enabling AES on accounts it does not work as key generated is different.
Found the details: For RC4-HMAC: key = MD4(UNICODE(password)) https://tools.ietf.org/html/rfc4757#page-3 For AES: tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) key = DK(tkey, "kerberos") https://tools.ietf.org/html/rfc3962 salt = [realm.ToUpper()] + "host" + [samAccountNameWithoutDollarSign] + "." [realm.ToLower()] https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-KILE/%5bMS-KILE%5d.pdf On Mon, Mar 22, 2021 at 11:13 PM Simo Sorce <s...@redhat.com> wrote: > Note that this is true only for RC4-HMAC keys, because the RC4-HMAC key > is unsalted. AES keys are salted so two machines will have different > AES keys even if the "password" is the same. > > HTH, > Simo. > > On Mon, 2021-03-22 at 01:24 +0530, Vipul Mehta wrote: > > Got it. Even if sname is encrypted, it won't make any difference as it > can > > be modified and re-encrypted as the key is equal. > > Signature also won't help for the same reason. So, it is clear that > > responsibility lies on AD admin to use unique passwords for accounts. > > > > On Sun, Mar 21, 2021 at 10:29 AM Benjamin Kaduk <ka...@mit.edu> wrote: > > > > > On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote: > > > > Hi, > > > > > > > > Suppose there are two servers A and B running under different > kerberos > > > > service principals. > > > > If both the service principals have same password and kvno then > kerberos > > > > long term encryption key will be same for both. Seems to be the case > for > > > > windows KDC. > > > > > > > > In such case, a client having service ticket for A tries to > authenticate > > > > with that ticket with server B, should it work ? It is working fine > in > > > JDK > > > > implementation. > > > > > > > > https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear > > > > whether server should validate server principal in the service ticket > > > when > > > > KRB_AP_REQ message is received. Looks like just decryption with key > is > > > > sufficient along with some other validations but i don't find server > name > > > > validation explicitly mentioned. > > > > > > I note that RFC 1510 has been obsoleted by RFC 4120 (but > > > https://tools.ietf.org/html/rfc4120#section-3.2.3 contains > essentially the > > > same text that you reference). > > > > > > My understanding is that the RFC authors assumed that different > services > > > would have different keys, so the scenario you describe would not occur > > > (though, as you know, the situation does occur quite often in Active > > > Directory environments). Since the Ticket sname is in the unencrypted > part > > > of the ticket, there is no value in validating its contents, as the > Ticket > > > could be re-encoded with an arbitrary sname value. It is, in essence, > just > > > a hint for locating the proper key, in the same that the realm is (and > the > > > realm is explicitly discussed as serving this role in the referenced > text). > > > > > > -Ben > > > > > > > > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > > -- Regards, Vipul ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos