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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
when checking for a trusted domain situation.
This is how it was meant to be:
Otherwise, with a dc-trusted-domain situation but trusted domains disabled,
we would attempt to do a session setup and fail (wouldn't even get a trust
password).
Michael
Win2008 domain (merged from v3-0-test).
commit 8dc4e979776aae0ecaa74b51dc1eac78a7631405
Author: Steven Danneman <sdanneman@isilon.com>
Date: Wed May 7 13:34:26 2008 -0700
spnego SPN fix when contacting trusted domains
cli_session_setup_spnego() was not taking into consideration the situation
where we're connecting to a trusted domain, specifically one (like W2K8)
which doesn't return a SPN in the NegTokenInit.
This caused two problems:
1) When guessing the SPN using kerberos_get_default_realm_from_ccache() we
were always using our default realm, not the realm of the domain we're
connecting to.
2) When falling back on NTLMSSP for authentication we were passing the name
of the domain we're connecting to for use in our credentials when we should be
passing our own workgroup name.
The fix for both was to split the single "domain" parameter into
"user_domain" and "dest_realm" parameters. We use the "user_domain"
parameter to pass into the NTLM call, and we used "dest_realm" to create an SPN
if none was returned in the NegTokenInit2 packet. If no "dest_realm" is
provided we assume we're connecting to our own domain and use the credentials
cache to build the SPN.
Since we have a reasonable guess at the SPN, I removed the check that defaults
us directly to NTLM when negHint is empty.
looking up trust credentials in our tdb.
commit fd0ae47046d37ec8297396a2733209c4d999ea91
Author: Steven Danneman <sdanneman@isilon.com>
Date: Thu May 8 13:34:49 2008 -0700
Use machine account and machine password from our domain when
contacting trusted domains.
We now open messages.tdb even before we do the become_daemon. become_daemon()
involves a fork and an immediate exit of the parent, thus the
parent_is_longlived argument must be set to false in this case. The parent is
not really long lived :-)
In order to avoid receiving NT_STATUS_DOWNGRADE_DETECTED from a w2k8
netr_ServerAuthenticate2 reply, we need to start with the AD netlogon negotiate
flags everywhere (not only when running in security=ads). Only for NT4 we need
to do a downgrade to the returned negotiate flags.
Tested with w2k8, w2ksp4, w2k3r2 and nt4sp6.
Guenther
Another preparation to convert secrets.c to dbwrap: The dbwrap API does not
provide a sane tdb_lock_with_timeout abstraction. In the clustered case the DC
mutex is needed per-node anyway, so it is perfectly fine to use a local mutex
only.
This allows us to deal with child domains in transitive forest trusts.
It also allows us to fill in the forest name to the target domain to the
struct winbindd_domain *.
Even if the session setup was anonymous, try and collect
trust creds with get_trust_creds() and use these before
falling back to schannel.
This is the first attempt to fix interdomain trusts.
(get password policy and stuff)
Michael
Do not attempt to do a session setup when in a trusted domain
situation (this gives STATUS_NOLOGON_TRUSTED_DOMAIN_ACCOUNT).
Use get_trust_pw_clear to get machine trust account.
Only call this when the results is really used.
Use the proper domain and account name for session setup.
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
