| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The parameters "lmNewHash" and/or "ntNewHash" could be NULL and when we perform
write operations on them (look below in the code) we could get SIGSEGVs!
|
|
|
|
|
|
This replace the dsdb_syntax_FOOBAR_ldb_to_drsuapi function,
which was left as a TODO code. Implementation in both added functions
is completely identical and probably should differ in the future.
|
|
This one copes with deleted objects where linked attributes have been
set on the module. We hit this when we do the ldb wipe at the start of
a provision, which trigers linked attribute updates, but for objects
that have disappeared. We need to ensure that the linked attribute
updates only happen on the right object, and if the object gets
re-created (as happens with a provision) then it is not the right
object.
To cope with this we record the GUID of the object when the operation
that triggered the linked attribute update comes in, and then find the
DN by suing that GUID when we apply the change in the prepare commit
hook.
|
|
This allows for safe transaction end aborts
|
|
Now that ldb is calling prepare commit separately, the job of the
partition module on transaction end is much simpler (and more robust!)
|
|
This will be used by the linked_attribute module
|
|
When running at functional level 2 or above, the repl_meta_data module
can receive linked attribute structures from the repl replication
task. These attributes can come through DRS before the associated
objects have been created. To cope with this, we need to process
linked attributes in the end_transaction hook.
|
|
We need to call down to the next transaction function when we finish
in linked_attributes.
This also changes linked_attributes to use the common
dsdb_find_dn_by_guid() function
|
|
This exposes the linked_attributes to the repl_meta_data module
|
|
|
|
This came from the linked_attributes module, but now the
repl_meta_data module needs the same functionality, so move it to a
common routine.
|
|
items are added to the linked attribute list using DLIST_ADD(), which
means to commit them to the database in the same order they came from
the server we need to walk the list backwards when we traverse it
|
|
linked attribute changes can come in any order. This means it is
possible for a forward link to come over the wire in DRS before the
target even exists. To make this work this patch changed the linked
attributes module to gather up all the changes it needs to make in a
linked list, then execute the changes in the end_transaction hook for
the module.
During that commit phase we also fix up all the DNs that we got by
searching for their GUID, as the objects may have moved after the
linked attribute was sent, but before the end of the transaction
|
|
We know the partition DN from the DRS objects, we need to pass this
down the modules below us to ensure they operate on the right
partition
|
|
This structures was used in two ways. In one way it held variables
that are logically internal to the partition module, and in the other
way it was used to pass the partition DN down to other modules. This
change makes the structure contain just the dn which is being passed
down.
This change is part of the support for linked attributes. We will be
passing this control down from above the partition module to force
which partition a request acts upon. The partition module now only
adds this control if it isn't already there.
|
|
This helps a lot with debugging the DRS replication code
|
|
We should always apply a whole set of DRS changes or none of them. See
[MS-DRSR] 3.3.2
|
|
|
|
This changes dsdb_write_prefixes_from_schema_to_ldb() to use an
internal talloc hirarchy, so we can safely give it a NULL context from
the python.
It also fixes manual construction of the ldb_message - we now use the
right helper functions.
Andrew Bartlett
|
|
|
|
The aim is to create a function that is more easily wrapped for
python, so that we can write the updated prefixMap in an upgrade
script.
Andrew Bartlett
|
|
This revises tridge's commit 61ca4c491e1c13eb7d97847f743b0f540f1117c4
to use ldb_request_add_control() instead of a manual construction.
Andrew Bartlett
|
|
The objectclass module checks that the target parent exists, and
refuses renames if it doesn't exist. For this to work for deleted
objects we have to do the search in the objectclass module with the
"show deleted" control enabled.
|
|
Instead, use the fact that the ldb_parse_tree structure is public to
construct the 'and not deleted' clause as a structure, and apply each
filter tree to that template.
Andrew Bartlett
|
|
The OIDs are not NULL terminated by the python caller, in line with
the LDB API, but we need them to be here, as we were casting them to a
string.
Andrew Bartlett
|
|
|
|
|
|
The problem is that samdb_result_string() and
ldb_msg_find_attr_as_string() both simply cast the string, rather than
ensuring the return value is NULL terminated. This may be best
regarded as a flaw in LDB, but fixing it there is going to be more
difficult.
Andrew Bartlett
|
|
Added simple DRS rename support in replication. This should be done
async, and I'm not sure if we should also do any repl data updates to
indicate the rename. I'm still learning how this stuff works, but at
least this allows a rename on a DC to propogate correctly
|
|
|
|
|
|
Should finally fix bug #6136 ("groupType", "sAMAccountType" ... attributes).
|
|
This triggered a failure in the updateNow schema test, as the current
global schema was not being updated when a new schema element was
added
|
|
This helps ensure we don't load the schema too often in the provision
(allowing a reference in of the schema before the modules load).
Andrew Bartlett
|
|
This allows us to load the schema against one ldb context, but apply
it to another. This will be useful in the provision script, as we
need the schema before we start the LDAP server backend.
Adnrew Bartlett
|
|
one-line wrapper)
|
|
With the previous check I got random failures when trying to connect to the
LDAP server.
|
|
|
|
|
|
This moves the "operational" LDB module to the right place under "dsdb/samdb/ldb_modules"
(suggested by abartlet) and enhances it for supporting dynamic generated
"primaryGroupToken" for AD groups. This should fix bug #6466.
|
|
Before this change, the first opener of the sam ldb context would
become the owner of the global schema, then the autofree context got a
reference to the schema. Any subsequent opens of the sam ldb also got
a reference. This meant that the talloc hierarchy was inconsistent
between the first sam ldb open and subsequent opens. With this change
the autofree context becomes the owner of the global schema, and all
ldb contexts get a reference.
|
|
These references were triggering the ambiguous talloc_free errors from
the recent talloc changes when the server is run using the 'standard'
process model instead of the 'single' process model. I am aiming to
move the build farm to use the 'standard' process model soon, as part
of an effort to make our test environment better match the real
deployment of Samba4.
The references are not needed as the way that the event context is
used is as the 'top parent', so when the event context is freed then
all of the structures that were taking a reference to the event
context were actually freed as well, thus making the references
redundent.
|
|
This removes a number of cases where we did a cast into a const char *
of an ldb_val. While convention is to alway have an extra \0 at
data[length] in the ldb_val, this is not required, and does not occour
at least on build farm host 'svart'.
Andrew Bartlett
|
|
|
|
|
|
Some corrections which make the code a bit more readable (no functional changes here)
|
|
Rather than have the functional levels scattered in 4 different,
unconnected locations, the provision script now sets it, and the
rootdse module maintains it's copy only as a cached view onto the
original values.
We also use the functional level to determine if we should store AES
Kerberos keys.
Andrew Bartlett
|
