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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Keep all heimdal related plugin code within hdb_samba4.c
Move interfaces needed by multiple plugins in db-glue.c
Move sequence context in main db context so that we do
not depend on db->hdb_dbc in the common code.
Remove unnecessary paremeters from function prototypes
This allows to use a common structure not tied to hdb_samba4
Also allows to avoid many casts within hdb_samba4 functions
This is the first step to abstract samba kdc databse functions
so they can be used by the MIT forthcoming plugin.
The documentation shows that all these functions in fact use the same
flags variable type. To be consistent between functions, and to allow
easy reference to the WSPP docs, it is better for us to also use this
generic DrsOptions bitfield rather than one per operations.
The load of defaultObjectCategory as an extended DN means we need to
use the common parsing functions I just split out, rather than the
GET_DS_DN macro.
The objectGUIDs are loaded so that we can create the extended DN when
we load from LDIF (and are loaded for the other cases for
consistency).
Also adapt callers to API changes needed for common parsing code
Andrew Bartlett
dsdb_schema_pfm_contains_drsuapi_pfm() is part of reimplemented
prefixMap interface.
This name was choosen to clearly show, that this a week verification
in case we want to determine if remote schema is changed.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Also, dsdb_load_oid_mappings_drsuapi() was reimplemented to use
dsdb_schema_pfm_from_drsuapi_pfm() function to load
drsuapi_prefixMap into schema->prefixmap
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This allows us to reuse a ldb context if it is open twice, instead
of going through the expensive process of a full ldb open. We can
reuse it if all of the parameters are the same.
The change relies on callers using talloc_unlink() or free of a parent
to close a ldb context.
Add checks to make sure that we join only supported AD domains (we agreed that
those are >= (Windows) 2003 Native per default - this is changeable with the
"ads:function level" option).
Add also checks to make sure that we cannot join domains which have a bigger
function level than our DC capable function level (e.g. a (Windows) 2008 DC
cannot join a (Windows) 2008 R2 domain).
This ensures we only have one codepath to store the secret, and
therefore that we have a single choke point for setting the
saltPrincipal, which we were previously skipping.
Andrew Bartlett
We were creating the name resolution context as a child of lp_ctx,
which meant when we gave up on a connection the timer on name
resolution kept running, and when it timed out the callback crashed as
the socket was already removed.
Additional notes:
- Bump the level to Windows Server 2008 R2 (we should support always the latest
version - if we provision ourself)
- In "descriptor.c" the check for the "domainFunctionality" level shouldn't be
needed: ACL owner groups (not owner user) are supported since Windows 2000
Server (first AD edition)
- I took the argument from: http://support.microsoft.com/kb/329194
When we replicate from a remote DC, we need to note the new uSN that
the local changes have resulted in, and modify the uSN that the notify
task uses to determine if it should send a ReplicaSync message back to
the remote DC. Otherwise we end up always triggering a ReplicaSync
every time we replicate from another DC
We now show the total number of objects we have processed, which gives
the user a better idea of how much has been done. A vampire on a large
domain can take an hour or more (which needs to be fixed btw, it is a
problem with the lack of scalability of the ltdb index code). Watching
the same msg for an hour makes you wonder if any progress is being
made!
It is much easier to do decryption with wireshark when the keytab is
available for every host in the domain. Running 'net export keytab
<keytab name>' will export the current (as pointed to by the supplied
smb.conf) local Samba4 doamin.
(This uses Heimdal's 'hdb' keytab and then the existing hdb-samba4,
and so has a good chance of keeping working in the long term).
Andrew Bartlett
It is much easier to do decryption with wireshark when the keytab is
available for every host in the domain. Running 'net export keytab
<keytab name>' will export the current (as pointed to by the supplied
smb.conf) local Samba4 doamin.
(This uses Heimdal's 'hdb' keytab and then the existing hdb-samba4,
and so has a good chance of keeping working in the long term).
Andrew Bartlett
