summaryrefslogtreecommitdiff
path: root/source3/libnet/libnet_samsync_keytab.c
AgeCommit message (Collapse)AuthorFilesLines
2010-09-23s3-dsgetdcname: always pass in messaging context.Günther Deschner1-10/+12
Volker, please check. Guenther
2010-08-26s3-build: only include krb5 environment variables where required.Günther Deschner1-0/+1
Guenther
2010-08-13s3-krb5 Only build ADS support if arcfour-hmac-md5 is availableAndrew Bartlett1-2/+2
Modern Kerberos implementations have either defines or enums for these key types, which makes doing #ifdef difficult. This shows up in files such as libnet_samsync_keytab.c, the bulk of which is not compiled on current Fedora 12, for example. The downside is that this makes Samba unconditionally depend on the arcfour-hmac-md5 encryption type at build time. We will no longer support libraries that only support the DES based encryption types. However, the single-DES types that are supported in common with AD are already painfully weak - so much so that they are disabled by default in modern Kerberos libraries. If not found, ADS support will not be compiled in. This means that our 'net ads join' will no longer set the ACB_USE_DES_KEY_ONLY flag, and we will always try to use arcfour-hmac-md5. A future improvement would be to remove the use of the DES encryption types totally, but this would require that any ACB_USE_DES_KEY_ONLY flag be removed from existing joins. Andrew Bartlett Signed-off-by: Simo Sorce <idra@samba.org>
2010-08-13s3:libnet Add other required headers for libnet_samsync_keytab.cAndrew Bartlett1-0/+3
Due to missing defines in modern kerberos libraries, this code was not compiled and so this wasn't noticed. Andrew Bartlett Signed-off-by: Simo Sorce <idra@samba.org>
2010-07-13s3-libnet: better separate headers.Günther Deschner1-1/+1
Guenther
2009-02-19s3-libnet: fix coverity #848 (UNINIT).Günther Deschner1-1/+1
Guenther
2008-11-18s3-libnet-samsync: store samsync sequence number state in keytab.Günther Deschner1-1/+52
Guenther
2008-11-18s3-libnet-samsync: pass back sequence number from fetch_sam_entries_keytab.Günther Deschner1-1/+16
Guenther
2008-11-18s3-libnet-samsync: pass sequence number pointer to process routine.Günther Deschner1-0/+2
Guenther
2008-11-18s3-libnet-samsync: move all modules to startup,process,finish callbacks.Günther Deschner1-36/+76
Guenther
2008-11-18s3-libnet-samsync: use samsync_ops.Günther Deschner1-10/+10
Guenther
2008-11-18s3-libnet-samsync: add samsync_ops to all samsync modules.Günther Deschner1-0/+4
Guenther
2008-11-18s3-libnet: move add_to_keytab_entries to libnet_keytab.Günther Deschner1-15/+14
Guenther
2008-11-17s3-libnet-samsync: use enctype 23 for vampired keytab entries.Günther Deschner1-1/+1
Guenther
2008-10-22Fix net rpc vampire, based on an *amazing* piece of debugging work by ↵Jeremy Allison1-4/+1
"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-09-15Fixed "uninitialized variable" build warningSteven Danneman1-0/+1
With gcc 4.1.3 on Ubuntu 7.10 the following build warning occurs: Compiling libnet/libnet_samsync_keytab.c cc1: warnings being treated as errors libnet/libnet_samsync_keytab.c: In function ‘fetch_sam_entries_keytab’: libnet/libnet_samsync_keytab.c:102: warning: ‘entry.enctype’ is used uninitialized in this function Fixed by initializing to ENCTYPE_NULL
2008-07-01net_vampire: keep keytab context and flush keytab only after the last query.Günther Deschner1-14/+19
Guenther (This used to be commit 48efe7dbce1cde6689f94fafe2d7756f673bc050)
2008-06-26Fix the non-LDAP, non-krb5 build, fix gcc -O3 warnings.Jeremy Allison1-1/+1
Jeremy. (This used to be commit 9e2ab30d3cf6950fc79152b2169e7aeae8d6a366)
2008-06-27net_vampire: use bool for last_query information in samsync.Günther Deschner1-7/+12
Guenther (This used to be commit fa1976e23a33bd3fab17c3f6ab5573ee1fdf9e31)
2008-06-27net_vampire: separate keytab code from samsync code.Günther Deschner1-154/+18
Guenther (This used to be commit 69d8442bf3248f97ad23def424901d7fa87bfe48)
2008-06-24net_vampire: add code to vampire a SAM database to a keytab file.Günther Deschner1-0/+319
Guenther (This used to be commit ee6e422c0e035aa4779fa718bb6f142827cc2de0)