| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This allows us to control what groups should be added in what use
cases, and in particular to more carefully control the introduction of
the 'authenticated' group.
In particular, in the 'service_named_pipe' protocol, we do not have
control over the addition of the authenticated users group, so we key
of 'is this user the anonymous SID'.
This also takes more care to allocate the right length ptoken->sids
Andrew Bartlett
|
|
We had to split up the auth module into a module loaded by main deamon
and a subsystem we manually init in the operational module.
Andrew Bartlett
|
|
This creates a new interface to the auth subsystem, to allow an
auth_context to be created from the ldb, and then tokenGroups to be
calculated in the same way that the auth subsystem would.
Andrew Bartlett
|
|
I need to change the functions this calls
Andrew Bartlett
|
|
recompiled by waf.
|
|
This means that the existing kvno will no longer be valid, all
unix-based domain members may need to be rejoined, and
upgradeprovision run to update the local kvno in
secrets.ldb/secrets.keytab.
This is required to match the algorithm used by Windows DCs, which we
may be replicating with. We also need to find a way to generate a
reasonable kvno with the OpenLDAP backend.
Andrew Bartlett
|
|
|
|
|
|
It's easier to just set it up when we can, then to deal with the
ordering issues in ldb startup. As long as we have it ready if a real
client ever asks for it, then we should be happy.
Andrew Bartlett
|
|
need them for more constructed attributes
With this patch we delete the helper attributes at the end where all constructed
attributes have already been computed.
|
|
No need to have signed counters here.
|
|
It contains the transitive SID closure (expand member/memberOf attributes) of a
certain SAM object. The "tokenGroups" attribute never contains the SID of the
object itself.
References: http://msdn.microsoft.com/en-us/library/ms680275(VS.85).aspx,
http://support.microsoft.com/kb/301916,
MS-ADTS 3.1.1.4.5.19.
|
|
"construct_primary_group_token"
Use the "msg" as temporary context and not "ldb" which lives much longer.
|
|
|
|
|
|
This matches the default handling order in the "password_hash" module (it's nice
to have this consistent).
|
|
msg->elements could be NULL before we add parentGUID
|
|
This avoids not only a possibly non-portable compiler expression, but
also the need to look up the schema each time.
Andrew Bartlett
|
|
The original code here would do a subtree search under each object,
attempting to determine if it was a group. This was incorrect, and
inefficient - we just need to ask for the objectClass attribute, and
check that value before returning the group's RID.
(Much of this patch reworks operational.c to allow a search for 2
attributes for this calculation).
Andrew Bartlett
|
|
This avoids doing a new search from the top of the module stack.
This also removes the helper function dsdb_find_parentguid_by_dn()
which is now unused.
Andrew Bartlett
|
|
|
|
In general functions that don't return any memory should not take a memory context.
Otherwise it is too easy to have a bug like this where memory is leaked
|
|
|
|
Let this perform the schema in the "objectclass" module.
|
|
(merged by Andrew Bartlett)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
|
|
|
|
|
|
|
|
Some attributes (like ntSecurityDescriptor) are stored in our db, but
should only be displayed if asked for. This also applied to parentGUID
from old installs, which is now generated.
|
|
This generated parentGUID on demand, rather than getting it from the
database
Signed-off-by: Andrew Tridgell <tridge@samba.org>
|
|
I think these modules ended up LGPL because someone based the module
on an existing LGPL module in the core ldb, and it spread from
there. Certainly there is no reason for the ldb modules that are not
distributed as part of ldb to be LGPL.
|
|
|
|
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.
|
