IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's very useful to know the exact result code when something fails and not
only a generic (by the module) created one.
Sure, there are some exception cases with specific results (special message
constellations, attributes, values...) which shouldn't be changed at all
(examples of them are in the "ldap.py" test). Therefore I looked very
carefully to not change them.
When you try to add a 2nd value to a single valued attribute you get
LDB_ERR_ATTRIBUTE_OR_VALUE_EXISTS. w2k8-r2 join to s4 relies on this
error, doing a replace after it sees the error
This reverts commit 767fce6fccf484b547219abd5e6abc941eacaf92.
Simo pointed out that the patch generates race conditions. We need to solve this
using a new control.
The main problem is that the "rdn_name" module launches on a rename request also
a modification one with the "special attributes" which can't be changed directly.
An introduced flag helps to bypass the restriction.
- Clean up and reorder it a bit
- Test which adds invalid attributes
- Test which makes sure that the 'distinguishedName' attribute cannot be modified
- Test which makes sure that we cannot change the RDN/'name' attribute through a modify request
I don't think that we really want to have this error printed out on the server
console (stdout) since this hasn't serious results as DB or data corruption
and similar.
This allows this control to be specified as critical. We support the
control because we choose to always be durable in our transactions.
We really, really need a 'duplicate request' API, as at the
moment we can't do this without a large, error-prone set of code that
cannot cope with new request fields or types.
Andrew Bartlett
AD has the concept of a DN prefixed with B:NN:XXXXXX: that contains a
binary blob. We need to support those in order to give correctly
formatted binary blobs for things like wellKnownObjects
This implementation is not ideal, as it allows for binary blobs on all
DNs, whereas it should only allow them on those with a syntax of
2.5.5.7. We should clean this up in the future, but meanwhile this
implementation at least gets us a working DC join of w2k8 to s4.
This patch also uses a static function for marking DNs as invalid,
which is very useful when debugging this code, as you can break on it
in gdb.
This reverts commit fb914640ad656b146f732ab33063575e2e47e37c.
Jelmer requested the revert since he feels better when we reapply this change
after his merge with the updated WMI branch.
