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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Although it is not currently used in implementation,
my intention is for callers to clearly state what
action they want to execute.
Currently when a caller wants to pass the call to the next
module in the chain, this flag is either omitted or 0 is used
(which is somewhat hacky, isn't it)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Especially the "free"s after "ldb_msg_diff" are very important since the diff
message is allocated on the long-living LDB context.
Signed-off-by: Matthias Dieter Wallnöfer <mdw@samba.org>
The problem here is that if the schema has been modified on the source
domain, there may be attributes that appear over DRS with 0 values (to
indicate that any existing values on the target should be deleted).
This would confuse the previous version of this macro.
Andrew Bartlett
We should rename objects only after we make sure, that
changes on the partner DC are newer than what we have.
This fixes a bug, when we have following situation with 2 DCs:
- we have an object O on the two DCs
- we rename (delete) object O on DC1
- DC1 replicates from DC2
In the above scenario, object O will be renamed back
to its original name (i.e. it will be restored).
Now, we check that DC2 state is older than what we have,
so nothing happens with object's DN.
Using "#!/usr/bin/env python" is more portable. It still isn't ideal
though, as we should really use the python path found at configure
time. We do that in many places already, but some don't.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
These are just a subset of the DS_DOMAIN_ functionality flags, are compared and often confused with each other. Just make them one set.
Andrew Bartlett
When a user only provides only the lanman hash (and nothing else) and the
lanman authentication is deactivated then we end in an account with no
password attribute at all! Lock this down.
O(n) search for dsdb_attribute by msDS-IntId value was
replaced by binary-search in ordered index.
I've choosen the approach of separate index on msDS-IntId values
as I think it is more clear what we are searching for.
And it should little bit faster as we can clearly determine
in which index to perform the search based on ATTID value -
ATTIDs based on prefixMap and ATTIDs based on msDS-IntId
are in separate ranges.
Other way to implement this index was to merge msDS-IntId values
in attributeID_id index.
This led me to a shorted but not so obvious implementation.
As far as I can tell and the test show the DN gets now normalised automatically
when stored into the database.
Anyway, if we find a case where this doesn't happen then I propose to do it
centrally for all DN attributes in common since we should get away from special
attribute hacks as far as possible.
This isn't quitted with a normal "NO_SUCH_OBJECT" (parent not found) but with a
very special referral: one with the DN itself and the hostname is the last
component value of the DN.
