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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is a reworked version of the mentioned test which passes against Windows
Server 2008. The previous version, also mainly written by me passed only against
Windows Server <= 2003.
Find the "Enterprise Admins" group which does exist on s4 and Windows
directories and is always per default universal. Test this only when the target
is set to s4 (s3 deployments don't contain this group). If the number of
returned objects is "0" (count) then we are likely testing the builtin domain of
an AD deployment.Then we ignore the inexistent "Enterprise Admins" group.
I didn't enhance the test for "QueryDomainInfo" since this does itself a
comparison of all returned objects with the "EnumDomainGroups" call. Therefore
if the latter passes, and the "QueryDomainInfo" test passes also the
"QueryDomainInfo" call is okay regarding groups.
This is needed because we don't (want) to specify an explicit
local address. And the socket family (ipv4 vs. ipv6) needs to
be autodetected based on the remote address before the
socket() syscall.
Otherwise we would try to connect to a ipv4 address through an
ipv6only socket.
metze
I implemented this referral test in C since the LDB python API isn't capable
to extract referrals from search result sets (there the result sets are simple
lists which contain only the matching entries).
First I enhanced the RootDSE test to return all partition base DNs in a new
null-terminated list "partitions". Then I used this in my referrals test which
I've implemented in the LDB api since I needed some certain DN functions.
After looking at the s4 side of the (s)channel :) I found out that it makes
more sense to simply make it use the tdb based code than redo the same changes
done to s3 to simplify the interface.
Ldb is slow, to the point it needs haks to pre-open the db to speed it up, yet
that does not solve the lookup speed, with ldb it is always going to be slower.
Looking through the history it is evident that the schannel database doesn't
really need greate expanadability. And lookups are always done with a single
Key. This seem a perfet fit for tdb while ldb looks unnecessarily complicated.
The schannel database is not really a persistent one. It can be discared during
an upgrade without causing any real issue. all it contains is temproary session
data.
In addition I removed a "talloc_free(req)" since we never free elsewhere the
requests explicitly and do it only indirectly with freeing the "conn" object
when the testsuite terminates.
