SURS / map username
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Thu Mar 1 20:07:18 GMT 2001
On Thu, 1 Mar 2001, Elrond wrote:
> I get the impression, I'm missing something from the SURS /
> map username discussion.
> So I'm going to outline, how I currently see the future,
> and aftet that ask some specific questions.
> [I'm ignoring Groups completely, mapping uid to gid and the
> like is left as an excercise to the reader.
> main thing:
> - NT Names (DOM\name) are unique
across all inter-trusted domains, _including_ the names of the domains:
> - SIDs are unique
> - (type, id), where type is either "gid" or "uid", id is
> then either a uid or a gid, are the other "namespace".
okay. so it's type=[gu] and id=id, so in regular expression language,
(type, id) = [gu]id.
> We have SAM in the way, NT has it.
> SURS is ONLY mapping between SIDS and (type, id)
... specifically, a SID could potentially simultaneously map to one and
only one uid [from one of the SURS tables] and one and only one gid [from
the other SURS table].
or it could just map to a gid. or it could map to just a uid.
but NOT, i repeat NOT, to multiple uids or to multiple gids.
> mapping between SIDs and NT Names is the job of
> mapping between (type, id) and unix names is the job of
> Assumptions (to make thinking easier):
> SURS is already properly filled, that is, all needed
> entries exist and it can be practicaly thought of as
> being read only
> None of the playing SAMs have aliases
> Groups are also completely ignored.
? ... okay.
> Okay, let's start:
> Samba TNG box trusting a remote Domain.
> I connect to the box as remotedomain\elrond, give my
> smbd feeds the request of to the local netlogond
> That forwards the request to the remote PDC, receives a
> nice NET_USER_INFO_3, with my SID in it.
> netlogond forwards that to smbd.
> smbd is happy and lets me in.
> smbd is about files, so it needs to act on the
> filesystem, for that it needs to know a uid to act as.
> smbd asks SURS with my SID and receives a ("uid", 1001).
this means that there is an entry in SURS with S-1-5-21-xxx-yyy-zzz-NNN
where S-1-5-21-xxx-yyy-zzz is remotedomain's SID and NNN is elrond's RID
> smbd is happy, it expect a uid, because it feeded SURS
> with a "User"-SID.
> smbd does a setuid(1001).
> smbd is happy.
> Now the questions, actualy only one:
> Where does map username get its teeth in?
ah ha :)
let's say that you have this:
map username entry:
this is a perfectly valid thing to do in "map username".
hmmm... you've highlighted a possible problem.
what you _actually need to consider "map username" as is a mapping from
windows users to windows users.
map username entry:
then, whenever you get an SMB request for remotedomain\administrator, you
say, "hm, this is _actually_ remotedomain\elrond" and go from there (back
to "Okay, let's start:" above).
trying to treat the rhs of the map username equation as unix users?
yeeessss... i suppose you could do that.
you'd need to do this:
for (mapentry = get_first_map_username_entry(); mapentry = me->next; ..)
uid = getuid(mapentry->unixname);
SID = SURS_map_uid_to_SID(uid);
NTname = lsa_lookup_names(SID);
if NTname == mapentry->nt_name
hey, can anyone tell i've been doing python for a long time now? :)
so, as you can see, this is going to be _horrendously_ expensive: that's
quite a lot of network traffic and work.
if you treat "map username" as windows-to-windows instead of
windows-to-unix, you bypass this expensive stage altogether [which i know
can be optimised by creating an array of SIDs to look up with
lsa_lookup_names, yeah yeah, but it's still horrible].
so, in the post earlier today when i was talking about using "map
username" to provide the many-to-one functionality that people keep
thinking ought to be in SURS, this is what i was referring to, and is
exactly why you _don't_ need it [many-to-one mappings in SURS].
----- Luke Kenneth Casson Leighton <lkcl at samba-tng.org> -----
"i want a world of dreams, run by near-sighted visionaries"
"good. that's them sorted out. now, on _this_ world..."
More information about the samba-technical