1
0
mirror of https://github.com/samba-team/samba.git synced 2024-12-23 17:34:34 +03:00
samba-mirror/lib/param
Andrew Bartlett d2a473a7b7 dsdb: Allow password history and password changes without an NT hash
We now allow this to be via the ENCTYPE_AES256_CTS_HMAC_SHA1_96 hash instead
which allows us to decouple Samba from the unsalted NT hash for
organisations that are willing to take this step (for user accounts).

(History checking is limited to the last three passwords only, as
ntPwdHistory is limited to NT hash values, and the PrimaryKerberosCtr4
package only stores three sets of keys.)

Since we don't store a salt per-key, but only a single salt, the check
will fail for a previous password if the account was renamed prior to a
newer password being set.

Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>

Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
2022-06-26 22:10:29 +00:00
..
loadparm_server_role.c CVE-2020-25717: Add FreeIPA domain controller role 2021-11-09 19:45:33 +00:00
loadparm.c dsdb: Allow password history and password changes without an NT hash 2022-06-26 22:10:29 +00:00
loadparm.h dsdb: Allow password history and password changes without an NT hash 2022-06-26 22:10:29 +00:00
param_table.c dsdb: Allow password history and password changes without an NT hash 2022-06-26 22:10:29 +00:00
param.h lib/param: add lpcfg_parm_is_unspecified() helper 2021-07-15 00:06:31 +00:00
README param: update the README with instructions for adding a parameter 2015-07-31 05:00:56 +02:00
s3_param.h lib: Remove init_names() 2021-03-16 17:09:32 +00:00
samba-hostconfig.pc.in lib/param move source4 param code to the top level 2011-10-11 13:41:34 +11:00
util.c CVE-2020-25717: Add FreeIPA domain controller role 2021-11-09 19:45:33 +00:00
wscript_build lib:param: Add lp(cfg)_weak_crypto() 2020-03-19 20:46:41 +00:00

libsamba-hostconfig
-------------------

This directory contains "libsamba-hostconfig". 

The libsamba-hostconfig library provides access to all host-wide configuration
such as the configured shares, default parameter values and host secret keys.


Adding a parameter
------------------

To add or change an smb.conf option, in general you only have to add
the documentation to docs-xml/smbdotconf, or change it.
In addition to that, if special defaults are needed, the functions
loadparm_init() in lib/param/loadparm.c and/or init_globals() in
source3/param/loadparm.c need to be adapted accordingly.
The rest is generated for you.

It is important to get the attributes right in the <samba:parameter ...>
tag of the xml files.  These determine the details of the generated code.

- Supported attributes are name, context, type, constant, function,
  generated_function, synonym, parm, enumlist, handler, and deprecated.
- Supported contexts are 'G' (for global) and 'S' (for share).
- Supported types are boolean, boolean-rev, boolean-auto, list,
  cmdlist, string, ustring, char, integer, bytes, octal, and enum.



Using smb.conf parameters in the code
-------------------------------------

Call the lpcfg_*() function.  To get the lp_ctx, have the caller pass
it to you.  To get a lp_ctx for the source3/param loadparm system, use:

struct loadparm_context *lp_ctx = loadparm_init_s3(tmp_ctx, loadparm_s3_helpers());

Remember to talloc_unlink(tmp_ctx, lp_ctx) the result when you are done!

To get a lp_ctx for the lib/param loadparm system, typically the
pointer is already set up by popt at startup, and is passed down from
cmdline_lp_ctx.

In pure source3/ code, you may use lp_*() functions, but are
encouraged to use the lpcfg_*() functions so that code can be made
common.


How does loadparm_init_s3() work?
---------------------------------

loadparm_s3_helpers() returns a initialised table of function
pointers, pointing at all global lp_*() functions, except for those
that return substituted strings (% macros).  The lpcfg_*() function
then calls this plugged in function, allowing the one function and
pattern to use either loadparm system.


There is a lot of generated code, here, what generates what?
------------------------------------------------------------

The regular format of the CPP macros in param_functions.c is used to
generate up the prototypes (mkproto.pl, mks3param_proto.pl), the service
and globals table (mkparamdefs.pl), the glue table (mmks3param.pl) and
the initilisation of the glue table (mks3param_ctx_table.pl).

I have tried combining some of these, but it just makes the scripts more
complex.

The CPP macros are defined in and expand in lib/param/loadparm.c and
source3/param/loadparm.c to read the values from the generated
stuctures.  They are CPP #included into these files so that the same
macro has two definitions, depending on the system it is loading into.


Why was this done, rather than a 'proper' fix, or just using one system or the other?
-------------------------------------------------------------------------------------

This was done to allow merging from both ends - merging more parts of
the loadparm handling, and merging code that needs to read the
smb.conf, without having to do it all at once.  Ideally
param_functions.c would be generated from param_table.c or (even
better) our XML manpage source, and the CPP macros would instead be
generated expanded as generated C files, but this is a task nobody has
taken on yet.