| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
libnet_samsync_delta().
We absolutely need to avoid messing with the sync_context as that breaks the
stream of replication data coming from the DC (only replicates ~350 instead of
~4000 groups).
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
"Cooper S. Blake" <the_analogkid@yahoo.com>.
"I believe I have found two bugs in the 3.2 code and one bug that
carried on to the 3.3 branch. In the 3.2 code, everything is
located in the utils/net_rpc_samsync.c file. What I believe is the
first problem is that fetch_database() is calling
samsync_fix_delta_array() with rid_crypt set to true, which means
the password hashes are unencrypted from the RID encryption.
However, I believe this call is redundant, and the corresponding
call for samdump has rid_crypt set to false. So I think the
rid_crypt param should be false in fetch_database().
If you follow the code, it makes its way to sam_account_from_delta()
where the password hashes are decrypted a second time by calling
sam_pwd_hash(). I believe this is what is scrambling my passwords.
These methods were refactored somewhere in the 3.3 branch. Now the
net_rpc_samsync.c class calls rpc_vampire_internals, which calls
libnet/libnet_samsync.c, which calls samsync_fix_delta_array() with
rid_crypt always set to false. I think that's correct. But the
second bug has carried through in the sam_account_from_delta()
function:
208 if (memcmp(r->ntpassword.hash, zero_buf, 16) != 0) {
209 sam_pwd_hash(r->rid, r->ntpassword.hash, lm_passwd, 0);
210 pdb_set_lanman_passwd(account, lm_passwd, PDB_CHANGED);
211 }
212
213 if (memcmp(r->lmpassword.hash, zero_buf, 16) != 0) {
214 sam_pwd_hash(r->rid, r->lmpassword.hash, nt_passwd, 0);
215 pdb_set_nt_passwd(account, nt_passwd, PDB_CHANGED);
If you look closely you'll see that the nt hash is going into the
lm_passwd variable and the decrypted value is being set in the lanman
hash, and the lanman hash is being decrypted and put into the nt hash
field. So the LanMan and NT hashes look like they're being put in
the opposite fields."
Fix this by removing the rid_crypt parameter.
Jeremy.
|
|
Guenther
|
|
Guenther
(This used to be commit 51062534fd58d7a914a6bbac2e52bb44e71363b7)
|
|
Guenther
(This used to be commit fa1976e23a33bd3fab17c3f6ab5573ee1fdf9e31)
|
|
Guenther
(This used to be commit ee6e422c0e035aa4779fa718bb6f142827cc2de0)
|
|
Guenther
(This used to be commit 3bcda522f025aff249678a8a086218679fc19c6b)
|
|
Guenther
(This used to be commit f020c947cfb1482176af8827ed9c361d7c21e26f)
|
|
Guenther
(This used to be commit 8ec64a96e43d2e55e81f725fe693178ecdc65e88)
|
|
Guenther
(This used to be commit e0b117200441f842fbc11cc817ab2cde4d63a22e)
|
|
Guenther
(This used to be commit 7e7f07ec59d23e909809ed32adc8fc399826310d)
|
|
Turns out the password hashes are not rid encrypted in the samsync reply.
Guenther
(This used to be commit 7d8d60bcbae79f3cdd55b27217145ffbd19f161d)
|
|
Guenther
(This used to be commit eb4232fec05cd87ea85a781b84a3fbe85f469703)
|
|
Guenther
(This used to be commit b3b6af0a3e25fab0a14c9c802dbabd3d03448ebe)
|
|
This code is vastly based on samba4 code.
Guenther
(cherry picked from commit 5b68be96996a710988b1fd1c176cd5dff0f2c6af)
(This used to be commit 2c53d87de4ecc5ac9c43bc7488a03bceecf35140)
|
