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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As it breaks all tests which try to join a new machine account.
So more testing is needed...
metze
This reverts commit dd320c0924ce393a89b1cab020fd5cffc5b80380.
(This used to be commit cccb80b7b7980fbe1298ce266375e51bacb4a425)
get_trust_pw() just now computes the md4 hash of the result of
get_trust_pw_clear() if that was successful. As a last resort,
in the non-trusted-domain-situation, get_trust_pw() now tries to
directly obtain the hashed version of the password out of secrets.tdb.
Michael
(This used to be commit 4562342eb84e6fdcec15d8b7ae83aa146aabe2b7)
into a new function secrets_fetch_trust_account_password_legacy() that
does only try to obtain the hashed version of the machine password directly
from secrets.tdb.
Michael
(This used to be commit 91da12b751b3168dc40049f3e90c10d840393efc)
Up to now each caller used its own logic.
This eliminates code paths where there was a special treatment
of the following situation: the domain given is not our workgroup
(i.e. our own domain) and we are not a DC (i.e. it is not a typical
trusted domain situation). In situation the given domain name was
previously used as the machine account name, resulting in an account
name of DOMAIN\\DOMAIN$, which does not seem very reasonable to me.
get_trust_pw would not have obtained a password in this situation
anyways.
I hope I have not missed an important point here!
Michael
(This used to be commit 6ced4a7f88798dc449a667d63bc29bf6c569291f)
secrets_store_trust_account_password() and trust_password_delete()
are the write access functions to the SECRETS/$MACHINE.ACC/domain keys
in secrets.tdb, the md4 hashed machine passwords. These are not used
any more: Current code always writes the clear text password.
Michael
(This used to be commit 4788fe392427901f6b1c505e3a743136ac8a91ca)
This is a first patch aimed at fixing bug #4801.
It is still incomplete in that winbindd does not walk
the the trusted domains to lookup unqualified names here.
Apart from that this fix should be pretty much complete.
Michael
(This used to be commit dd320c0924ce393a89b1cab020fd5cffc5b80380)
New size calculation logic in tdb_trusted_dom_pass_pack()
and tdb_sid_pack() used accumulated sizes as successive offsets
to buffer pointer.
Michael
(This used to be commit 9c24713b402978e74dc8691be5cab71d8666eb41)
them with malloc'ing accessor functions. Should save a
lot of static space :-).
Jeremy.
(This used to be commit 52dc5eaef2106015b3a8b659e818bdb15ad94b05)
from pdb_ldap.c. I don't have an LDAP passdb setup here,
so I'm going to need some help on testing this.
Jeremy.
(This used to be commit 00760451b6c2b65f3a8a9187789ca4f270b622a2)
The point is doing the following associations:
- non discardable state data (all TDB files that may need to be backed
up) go to statedir
- shared data (codepage stuff) go to codepagedir
The patch *does not change* the default location for these
directories. So, there is no behaviour change when applying it.
The main change is for samba developers who have to think when dealing
with files that previously pertained to libdir whether they:
- go in statedir
- go in codepagedir
- stay in libdir
(This used to be commit d6cdbfd875bb2653e831d314726c3240beb0a96b)
We aren't currently leaking memory, but are leaving it around for
longer than we need to.
Jeremy.
(This used to be commit 25bbc9a6613bef0f3f73ecf634a38a9d56020f40)
bugs in various places whilst doing this (places that assumed
BOOL == int). I also need to fix the Samba4 pidl generation
(next checkin).
Jeremy.
(This used to be commit f35a266b3cbb3e5fa6a86be60f34fe340a3ca71f)
passdb backend = ldapsam.
Along with reproducing the functionality of the secrets.tdb
code, I have prepared the handling of the previous trust password
(in case we are contacting a dc which does not yet know of a recent
password change). This information has still to be propagated
to the outside, but this requires a change of the api and also
a change of the secrets.tdb code.
Michael
(This used to be commit 6c3c20e6c4a2b04de8111f2c79b431f0775c2a0f)
(for passdb backen = ldapsam). At a first step, add the hooks,
calling the secrets_ functions.
Michael
(This used to be commit 9c03cdf3a449149c50451a44deb420341e65af34)
> Here's the problem I hit:
>
> getgrnam("foo") -> nscd -> NSS -> winbindd ->
> winbindd_passdb.c:nam_to_sid() -> lookup_global_sam_name() ->
> getgrnam("foo") -> nscd -> ....
>
> This is in the SAMBA_3_0 specifically but in theory could happen
> SAMBA_3_0_25 (or 26) for an unknown group.
>
> The attached patch passes down enough state for the
> name_to_sid() call to be able to determine the originating
> winbindd cmd that came into the parent. So we can avoid
> making more NSS calls if the original call came in trough NSS
> so we don't deadlock ? But you should still service
> lookupname() calls which are needed for example when
> doing the token access checks for a "valid groups" from
> smb.conf.
>
> I've got this in testing now. The problem has shown up with the
> DsProvider on OS X and with nscd on SOlaris and Linux.
(This used to be commit bcc8a3290aaa0d2620e9d391ffbbf65541f6d742)
we have to take care to preserve the "special" values
for Windows of 0x80000000 and 0x7FFFFFFF when casting
between time_t and uint32. Add conversion functions
(and use them).
Jeremy.
(This used to be commit 4e1a0b2549f7c11326deed2801de19564af0f16a)
would flood at log level 2. We know when we're using the legacy
mapping code anyways since it will log an informative msg.
(This used to be commit 51aac0fcb4528df790aa3ae078f9ef639cc01363)