SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

Luke Kenneth Casson Leighton lkcl at
Wed Feb 9 22:19:14 GMT 2000

> if it takes weeks, then you are approaching it in the wrong way. For
> example, what if you have a table in one place, giving the names of
> the functions and a set of flags that says whether the function can be
> run on an anonymous connection. Default all of them to no.

actually, unfortunately, the default on pretty much all of them is "yes"
to anonymous users, for read-only access.

the entire lsa_* API requires read-only access to anonymous users.

the entire samr_* API requires read-only and enumeration rights to
anonymous users.

ditto for srvsvc, wkssvc, browsess and spoolss.

winreg, svcctl are both "authenticated user" access, minimum.

netlogon is an odd one.  it provides... anonymous-only access, but
provides a totally separate authentication mechanism (effectively!) for
obtaining a sam database, and authenticating users.

_then_ there's various access rights for "authenticated users", depending
on who the authenticated user is _nd_ depending on the info level being
requested _and_ depending on wherether it's a write request
(samr_set_userinfo) or a read request (samr_get_userinfo).


lsa_query_secret() in NT4sp3 and below used to be an admin-only level
function.  in NT4sp4, they removed it from the IDL, making it only
possible to call the NT-equivalent of _lsa_query_secret() directly in the
LSA dll, on the local machine.


net_server_get_info at info level 100 and below is allowed to anonymous
users.  info level 102 is authenticated users only.  info levels 500+ are
administrators only.


samr_open_user() write permission is denied to anybody but the
local administrators group, or anyone _in_ the local admins group
S-1-5-32-544, or the system context.

samr_open_user() read permission is granted to everyone.

to find out full details of who is allowed to do this, issue the following
rpcclient command:

rpcclient -S ntserver -U% -l log
[ $] lsaq
[ $] enumusers
[ $] samquerysec some_nt_username

you will get a security descriptor back, which is broken down into
who-is-all-wed-access-to-this-user permissions.

all of this means that each function needs to be review on a case-by-case
basis, producing effectively what is a security descriptor for EACH
function, and EACH info level _in_ the function (unless we can come up
with some mathematical way to analyse the info level number to generate
access rights, i really think there is one).

More information about the samba-technical mailing list