2008-06-13 11:57:09 +02:00
/*
Unix SMB / CIFS implementation .
Extract the user / system database from a remote SamSync server
Copyright ( C ) Andrew Bartlett < abartlet @ samba . org > 2004 - 2005
Copyright ( C ) Guenther Deschner < gd @ samba . org > 2008
This program is free software ; you can redistribute it and / or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation ; either version 3 of the License , or
( at your option ) any later version .
This program is distributed in the hope that it will be useful ,
but WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
GNU General Public License for more details .
You should have received a copy of the GNU General Public License
along with this program . If not , see < http : //www.gnu.org/licenses/>.
*/
# include "includes.h"
2008-07-30 17:47:40 +02:00
# include "libnet/libnet.h"
2008-06-13 11:57:09 +02:00
/**
* Decrypt and extract the user ' s passwords .
*
* The writes decrypted ( no longer ' RID encrypted ' or arcfour encrypted )
* passwords back into the structure
*/
static NTSTATUS fix_user ( TALLOC_CTX * mem_ctx ,
DATA_BLOB * session_key ,
enum netr_SamDatabaseID database_id ,
struct netr_DELTA_ENUM * delta )
{
uint32_t rid = delta - > delta_id_union . rid ;
struct netr_DELTA_USER * user = delta - > delta_union . user ;
struct samr_Password lm_hash ;
struct samr_Password nt_hash ;
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
unsigned char zero_buf [ 16 ] ;
2008-06-13 11:57:09 +02:00
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
memset ( zero_buf , ' \0 ' , sizeof ( zero_buf ) ) ;
/* Note that win2000 may send us all zeros
* for the hashes if it doesn ' t
* think this channel is secure enough . */
if ( user - > lm_password_present ) {
if ( memcmp ( user - > lmpassword . hash , zero_buf , 16 ) ! = 0 ) {
2008-06-13 11:57:09 +02:00
sam_pwd_hash ( rid , user - > lmpassword . hash , lm_hash . hash , 0 ) ;
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
} else {
memset ( lm_hash . hash , ' \0 ' , sizeof ( lm_hash . hash ) ) ;
2008-06-13 11:57:09 +02:00
}
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
user - > lmpassword = lm_hash ;
}
2008-06-13 11:57:09 +02:00
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
if ( user - > nt_password_present ) {
if ( memcmp ( user - > ntpassword . hash , zero_buf , 16 ) ! = 0 ) {
2008-06-13 11:57:09 +02:00
sam_pwd_hash ( rid , user - > ntpassword . hash , nt_hash . hash , 0 ) ;
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
} else {
memset ( nt_hash . hash , ' \0 ' , sizeof ( nt_hash . hash ) ) ;
2008-06-13 11:57:09 +02:00
}
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
user - > ntpassword = nt_hash ;
2008-06-13 11:57:09 +02:00
}
if ( user - > user_private_info . SensitiveData ) {
DATA_BLOB data ;
struct netr_USER_KEYS keys ;
enum ndr_err_code ndr_err ;
data . data = user - > user_private_info . SensitiveData ;
data . length = user - > user_private_info . DataLength ;
SamOEMhashBlob ( data . data , data . length , session_key ) ;
user - > user_private_info . SensitiveData = data . data ;
user - > user_private_info . DataLength = data . length ;
2008-09-23 09:49:56 +02:00
ndr_err = ndr_pull_struct_blob ( & data , mem_ctx , NULL , & keys ,
2008-06-13 11:57:09 +02:00
( ndr_pull_flags_fn_t ) ndr_pull_netr_USER_KEYS ) ;
if ( ! NDR_ERR_CODE_IS_SUCCESS ( ndr_err ) ) {
dump_data ( 10 , data . data , data . length ) ;
return ndr_map_error2ntstatus ( ndr_err ) ;
}
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
/* Note that win2000 may send us all zeros
* for the hashes if it doesn ' t
* think this channel is secure enough . */
2008-06-13 11:57:09 +02:00
if ( keys . keys . keys2 . lmpassword . length = = 16 ) {
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
if ( memcmp ( keys . keys . keys2 . lmpassword . pwd . hash ,
zero_buf , 16 ) ! = 0 ) {
2008-06-13 11:57:09 +02:00
sam_pwd_hash ( rid ,
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
keys . keys . keys2 . lmpassword . pwd . hash ,
lm_hash . hash , 0 ) ;
2008-06-13 11:57:09 +02:00
} else {
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
memset ( lm_hash . hash , ' \0 ' , sizeof ( lm_hash . hash ) ) ;
2008-06-13 11:57:09 +02:00
}
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
user - > lmpassword = lm_hash ;
2008-06-13 11:57:09 +02:00
user - > lm_password_present = true ;
}
if ( keys . keys . keys2 . ntpassword . length = = 16 ) {
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
if ( memcmp ( keys . keys . keys2 . ntpassword . pwd . hash ,
zero_buf , 16 ) ! = 0 ) {
2008-06-13 11:57:09 +02:00
sam_pwd_hash ( rid ,
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
keys . keys . keys2 . ntpassword . pwd . hash ,
nt_hash . hash , 0 ) ;
2008-06-13 11:57:09 +02:00
} else {
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
memset ( nt_hash . hash , ' \0 ' , sizeof ( nt_hash . hash ) ) ;
2008-06-13 11:57:09 +02:00
}
Fix net rpc vampire, based on an *amazing* piece of debugging work by "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.
2008-10-22 13:21:23 -07:00
user - > ntpassword = nt_hash ;
2008-06-13 11:57:09 +02:00
user - > nt_password_present = true ;
}
/* TODO: rid decrypt history fields */
}
return NT_STATUS_OK ;
}
/**
* Decrypt and extract the secrets
*
* The writes decrypted secrets back into the structure
*/
static NTSTATUS fix_secret ( TALLOC_CTX * mem_ctx ,
DATA_BLOB * session_key ,
enum netr_SamDatabaseID database_id ,
struct netr_DELTA_ENUM * delta )
{
struct netr_DELTA_SECRET * secret = delta - > delta_union . secret ;
SamOEMhashBlob ( secret - > current_cipher . cipher_data ,
secret - > current_cipher . maxlen ,
session_key ) ;
SamOEMhashBlob ( secret - > old_cipher . cipher_data ,
secret - > old_cipher . maxlen ,
session_key ) ;
return NT_STATUS_OK ;
}
/**
* Fix up the delta , dealing with encryption issues so that the final
* callback need only do the printing or application logic
*/
static NTSTATUS samsync_fix_delta ( TALLOC_CTX * mem_ctx ,
DATA_BLOB * session_key ,
enum netr_SamDatabaseID database_id ,
struct netr_DELTA_ENUM * delta )
{
NTSTATUS status = NT_STATUS_OK ;
switch ( delta - > delta_type ) {
case NETR_DELTA_USER :
status = fix_user ( mem_ctx ,
session_key ,
database_id ,
delta ) ;
break ;
case NETR_DELTA_SECRET :
status = fix_secret ( mem_ctx ,
session_key ,
database_id ,
delta ) ;
break ;
default :
break ;
}
return status ;
}
/**
* Fix up the delta , dealing with encryption issues so that the final
* callback need only do the printing or application logic
*/
2008-06-23 17:03:53 +02:00
static NTSTATUS samsync_fix_delta_array ( TALLOC_CTX * mem_ctx ,
DATA_BLOB * session_key ,
enum netr_SamDatabaseID database_id ,
struct netr_DELTA_ENUM_ARRAY * r )
2008-06-13 11:57:09 +02:00
{
NTSTATUS status ;
int i ;
for ( i = 0 ; i < r - > num_deltas ; i + + ) {
status = samsync_fix_delta ( mem_ctx ,
session_key ,
database_id ,
& r - > delta_enum [ i ] ) ;
if ( ! NT_STATUS_IS_OK ( status ) ) {
return status ;
}
}
return NT_STATUS_OK ;
}
2008-06-16 12:09:08 +02:00
/**
2008-06-23 17:03:53 +02:00
* libnet_samsync_init_context
2008-06-16 12:09:08 +02:00
*/
2008-06-23 17:03:53 +02:00
NTSTATUS libnet_samsync_init_context ( TALLOC_CTX * mem_ctx ,
const struct dom_sid * domain_sid ,
struct samsync_context * * ctx_p )
2008-06-16 12:09:08 +02:00
{
struct samsync_context * ctx ;
* ctx_p = NULL ;
ctx = TALLOC_ZERO_P ( mem_ctx , struct samsync_context ) ;
NT_STATUS_HAVE_NO_MEMORY ( ctx ) ;
if ( domain_sid ) {
ctx - > domain_sid = sid_dup_talloc ( mem_ctx , domain_sid ) ;
NT_STATUS_HAVE_NO_MEMORY ( ctx - > domain_sid ) ;
ctx - > domain_sid_str = sid_string_talloc ( mem_ctx , ctx - > domain_sid ) ;
NT_STATUS_HAVE_NO_MEMORY ( ctx - > domain_sid_str ) ;
}
* ctx_p = ctx ;
return NT_STATUS_OK ;
}
2008-06-17 19:49:58 +02:00
/**
* samsync_database_str
*/
static const char * samsync_database_str ( enum netr_SamDatabaseID database_id )
{
switch ( database_id ) {
case SAM_DATABASE_DOMAIN :
return " DOMAIN " ;
case SAM_DATABASE_BUILTIN :
return " BUILTIN " ;
case SAM_DATABASE_PRIVS :
return " PRIVS " ;
default :
return " unknown " ;
}
}
2008-06-16 12:09:08 +02:00
/**
* samsync_debug_str
*/
static const char * samsync_debug_str ( TALLOC_CTX * mem_ctx ,
enum net_samsync_mode mode ,
enum netr_SamDatabaseID database_id )
{
const char * action = NULL ;
switch ( mode ) {
case NET_SAMSYNC_MODE_DUMP :
action = " Dumping (to stdout) " ;
break ;
case NET_SAMSYNC_MODE_FETCH_PASSDB :
action = " Fetching (to passdb) " ;
break ;
case NET_SAMSYNC_MODE_FETCH_LDIF :
action = " Fetching (to ldif) " ;
break ;
2008-06-18 12:52:00 +02:00
case NET_SAMSYNC_MODE_FETCH_KEYTAB :
action = " Fetching (to keytab) " ;
break ;
2008-06-16 12:09:08 +02:00
default :
action = " Unknown " ;
break ;
}
2008-06-17 19:49:58 +02:00
return talloc_asprintf ( mem_ctx , " %s %s database " ,
action , samsync_database_str ( database_id ) ) ;
2008-06-16 12:09:08 +02:00
}
/**
2008-06-23 17:03:53 +02:00
* libnet_samsync
2008-06-16 12:09:08 +02:00
*/
2008-12-09 14:48:10 +01:00
static void libnet_init_netr_ChangeLogEntry ( struct samsync_object * o ,
struct netr_ChangeLogEntry * e )
2008-11-04 15:49:27 +01:00
{
ZERO_STRUCTP ( e ) ;
e - > db_index = o - > database_id ;
e - > delta_type = o - > object_type ;
switch ( e - > delta_type ) {
case NETR_DELTA_DOMAIN :
case NETR_DELTA_DELETE_GROUP :
case NETR_DELTA_RENAME_GROUP :
case NETR_DELTA_DELETE_USER :
case NETR_DELTA_RENAME_USER :
case NETR_DELTA_DELETE_ALIAS :
case NETR_DELTA_RENAME_ALIAS :
case NETR_DELTA_DELETE_TRUST :
case NETR_DELTA_DELETE_ACCOUNT :
case NETR_DELTA_DELETE_SECRET :
case NETR_DELTA_DELETE_GROUP2 :
case NETR_DELTA_DELETE_USER2 :
case NETR_DELTA_MODIFY_COUNT :
break ;
case NETR_DELTA_USER :
case NETR_DELTA_GROUP :
case NETR_DELTA_GROUP_MEMBER :
case NETR_DELTA_ALIAS :
case NETR_DELTA_ALIAS_MEMBER :
e - > object_rid = o - > object_identifier . rid ;
break ;
case NETR_DELTA_SECRET :
e - > object . object_name = o - > object_identifier . name ;
e - > flags = NETR_CHANGELOG_NAME_INCLUDED ;
break ;
case NETR_DELTA_TRUSTED_DOMAIN :
case NETR_DELTA_ACCOUNT :
case NETR_DELTA_POLICY :
e - > object . object_sid = o - > object_identifier . sid ;
e - > flags = NETR_CHANGELOG_SID_INCLUDED ;
break ;
default :
break ;
}
}
/**
* libnet_samsync_delta
*/
2008-11-18 09:49:37 +01:00
static NTSTATUS libnet_samsync_delta ( TALLOC_CTX * mem_ctx ,
enum netr_SamDatabaseID database_id ,
uint64_t * sequence_num ,
2008-11-04 15:49:27 +01:00
struct samsync_context * ctx ,
struct netr_ChangeLogEntry * e )
2008-06-16 12:09:08 +02:00
{
NTSTATUS result ;
2008-11-17 17:14:19 +01:00
NTSTATUS callback_status ;
2008-06-23 17:29:01 +02:00
const char * logon_server = ctx - > cli - > desthost ;
2008-06-16 12:09:08 +02:00
const char * computername = global_myname ( ) ;
struct netr_Authenticator credential ;
struct netr_Authenticator return_authenticator ;
uint16_t restart_state = 0 ;
uint32_t sync_context = 0 ;
DATA_BLOB session_key ;
ZERO_STRUCT ( return_authenticator ) ;
do {
struct netr_DELTA_ENUM_ARRAY * delta_enum_array = NULL ;
2008-06-23 17:29:01 +02:00
netlogon_creds_client_step ( ctx - > cli - > dc , & credential ) ;
2008-06-16 12:09:08 +02:00
2008-11-18 03:45:38 +01:00
if ( ctx - > single_object_replication & &
! ctx - > force_full_replication ) {
2008-11-04 15:49:27 +01:00
result = rpccli_netr_DatabaseRedo ( ctx - > cli , mem_ctx ,
logon_server ,
computername ,
& credential ,
& return_authenticator ,
* e ,
0 ,
& delta_enum_array ) ;
2008-11-18 09:49:37 +01:00
} else if ( ! ctx - > force_full_replication & &
sequence_num & & ( * sequence_num > 0 ) ) {
2008-11-18 03:45:38 +01:00
result = rpccli_netr_DatabaseDeltas ( ctx - > cli , mem_ctx ,
logon_server ,
computername ,
& credential ,
& return_authenticator ,
database_id ,
2008-11-18 09:49:37 +01:00
sequence_num ,
2008-11-18 03:45:38 +01:00
& delta_enum_array ,
0xffff ) ;
2008-11-04 15:49:27 +01:00
} else {
result = rpccli_netr_DatabaseSync2 ( ctx - > cli , mem_ctx ,
logon_server ,
computername ,
& credential ,
& return_authenticator ,
database_id ,
restart_state ,
& sync_context ,
& delta_enum_array ,
0xffff ) ;
}
2008-06-16 12:09:08 +02:00
if ( NT_STATUS_EQUAL ( result , NT_STATUS_NOT_SUPPORTED ) ) {
return result ;
}
/* Check returned credentials. */
2008-06-23 17:29:01 +02:00
if ( ! netlogon_creds_client_check ( ctx - > cli - > dc ,
2008-06-16 12:09:08 +02:00
& return_authenticator . cred ) ) {
DEBUG ( 0 , ( " credentials chain check failed \n " ) ) ;
return NT_STATUS_ACCESS_DENIED ;
}
if ( NT_STATUS_IS_ERR ( result ) ) {
break ;
}
2008-06-23 17:29:01 +02:00
session_key = data_blob_const ( ctx - > cli - > dc - > sess_key , 16 ) ;
2008-06-16 12:09:08 +02:00
samsync_fix_delta_array ( mem_ctx ,
& session_key ,
database_id ,
delta_enum_array ) ;
/* Process results */
2008-11-17 16:31:59 +01:00
callback_status = ctx - > ops - > process_objects ( mem_ctx , database_id ,
delta_enum_array ,
2008-11-18 09:49:37 +01:00
sequence_num ,
2008-11-17 16:31:59 +01:00
ctx ) ;
2008-06-17 19:49:58 +02:00
if ( ! NT_STATUS_IS_OK ( callback_status ) ) {
result = callback_status ;
goto out ;
}
2008-06-16 12:09:08 +02:00
TALLOC_FREE ( delta_enum_array ) ;
/* Increment sync_context */
sync_context + = 1 ;
} while ( NT_STATUS_EQUAL ( result , STATUS_MORE_ENTRIES ) ) ;
2008-06-17 19:49:58 +02:00
out :
2008-11-17 17:14:19 +01:00
2008-06-16 12:09:08 +02:00
return result ;
}
2008-06-17 21:22:06 +02:00
2008-11-04 15:49:27 +01:00
/**
* libnet_samsync
*/
NTSTATUS libnet_samsync ( enum netr_SamDatabaseID database_id ,
struct samsync_context * ctx )
{
NTSTATUS status = NT_STATUS_OK ;
2008-11-18 09:49:37 +01:00
NTSTATUS callback_status ;
TALLOC_CTX * mem_ctx ;
const char * debug_str ;
uint64_t sequence_num = 0 ;
2008-11-04 15:49:27 +01:00
int i = 0 ;
2008-11-18 09:49:37 +01:00
if ( ! ( mem_ctx = talloc_new ( ctx ) ) ) {
return NT_STATUS_NO_MEMORY ;
}
if ( ! ctx - > ops ) {
return NT_STATUS_INVALID_PARAMETER ;
}
if ( ctx - > ops - > startup ) {
status = ctx - > ops - > startup ( mem_ctx , ctx ,
database_id , & sequence_num ) ;
if ( ! NT_STATUS_IS_OK ( status ) ) {
goto done ;
}
}
debug_str = samsync_debug_str ( mem_ctx , ctx - > mode , database_id ) ;
if ( debug_str ) {
d_fprintf ( stderr , " %s \n " , debug_str ) ;
}
2008-11-04 15:49:27 +01:00
if ( ! ctx - > single_object_replication ) {
2008-11-18 09:49:37 +01:00
status = libnet_samsync_delta ( mem_ctx , database_id ,
& sequence_num , ctx , NULL ) ;
goto done ;
2008-11-04 15:49:27 +01:00
}
for ( i = 0 ; i < ctx - > num_objects ; i + + ) {
struct netr_ChangeLogEntry e ;
if ( ctx - > objects [ i ] . database_id ! = database_id ) {
continue ;
}
libnet_init_netr_ChangeLogEntry ( & ctx - > objects [ i ] , & e ) ;
2008-11-18 09:49:37 +01:00
status = libnet_samsync_delta ( mem_ctx , database_id ,
& sequence_num , ctx , & e ) ;
2008-11-04 15:49:27 +01:00
if ( ! NT_STATUS_IS_OK ( status ) ) {
2008-11-18 09:49:37 +01:00
goto done ;
2008-11-04 15:49:27 +01:00
}
}
2008-11-18 09:49:37 +01:00
done :
if ( NT_STATUS_IS_OK ( status ) & & ctx - > ops - > finish ) {
callback_status = ctx - > ops - > finish ( mem_ctx , ctx ,
database_id , sequence_num ) ;
if ( ! NT_STATUS_IS_OK ( callback_status ) ) {
status = callback_status ;
}
}
if ( NT_STATUS_IS_ERR ( status ) & & ! ctx - > error_message ) {
ctx - > error_message = talloc_asprintf ( ctx ,
" Failed to fetch %s database: %s " ,
samsync_database_str ( database_id ) ,
nt_errstr ( status ) ) ;
if ( NT_STATUS_EQUAL ( status , NT_STATUS_NOT_SUPPORTED ) ) {
ctx - > error_message =
talloc_asprintf_append ( ctx - > error_message ,
" \n Perhaps %s is a Windows native mode domain? " ,
ctx - > domain_name ) ;
}
}
talloc_destroy ( mem_ctx ) ;
2008-11-04 15:49:27 +01:00
return status ;
}
2008-06-17 21:22:06 +02:00
/**
* pull_netr_AcctLockStr
*/
NTSTATUS pull_netr_AcctLockStr ( TALLOC_CTX * mem_ctx ,
struct lsa_BinaryString * r ,
struct netr_AcctLockStr * * str_p )
{
struct netr_AcctLockStr * str ;
enum ndr_err_code ndr_err ;
DATA_BLOB blob ;
if ( ! mem_ctx | | ! r | | ! str_p ) {
return NT_STATUS_INVALID_PARAMETER ;
}
* str_p = NULL ;
str = TALLOC_ZERO_P ( mem_ctx , struct netr_AcctLockStr ) ;
if ( ! str ) {
return NT_STATUS_NO_MEMORY ;
}
blob = data_blob_const ( r - > array , r - > length ) ;
2008-09-23 09:49:56 +02:00
ndr_err = ndr_pull_struct_blob ( & blob , mem_ctx , NULL , str ,
2008-06-17 21:22:06 +02:00
( ndr_pull_flags_fn_t ) ndr_pull_netr_AcctLockStr ) ;
if ( ! NDR_ERR_CODE_IS_SUCCESS ( ndr_err ) ) {
return ndr_map_error2ntstatus ( ndr_err ) ;
}
* str_p = str ;
return NT_STATUS_OK ;
}