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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We need to keep the names around on the search. Probably a tdb_move would do it
here as well, but RPC is not the fastest thing on earth anyway...
Thanks to Günther for pointing that out to me!
One lp_private_dir() has to be used instead of get_dyn_PRIVATE_DIR()
to determine the location of the passdb.tdb.
I noticed this when running make test as a "normal user" from a
build, where I had done "make install" as root before, and so
the passdb.tdb could not be accessed during the startup phase
"CREATE TEST ENVIRONMENT IN ./st ..." in selftest.sh.
Michael
Jerry, as part of d6cdbfd87 the default location of passdb.tdb has changed from
the private directory to the state directory. I think because passdb.tdb holds
the password hashes, it is reasonable to keep this next to the smbpasswd file.
Please review and potentially push.
Thanks,
Volker
This patch 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
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
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
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
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 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
