Samba under Coherant and Macintosh
Luke Kenneth Casson Leighton
lkcl at samba.org
Tue Dec 21 18:48:07 GMT 1999
On 21 Dec 1999, Todd Sabin wrote:
> Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> > On Sun, 19 Dec 1999, Jean Francois Micouleau wrote:
> > >
> > > I don't think so. You need only to check in the "open handle functions".
> > > NT will try the different info levels only if you allowed it to do so in
> > > the reply to the open handle function.
> > unfortunately not, jean-francois. "open handle" functions are where it
> > starts.
> > SamrConnect("\\PDC", SEC_ACCESS_MAXIMUM_ALLOWED, &pSamHnd)
> > SamrOpenDomain(pSamHnd, S-1-5-32, SEC_ACCESS_READ_ONLY, &pDomHnd)
> > SamrOpenDomain(pSamHnd, S-1-5-32, SEC_ACCESS_MAX_ALLOWED, &pDomHnd2)
> > each open call is checked against the permissions requested and the user
> > security context.
> > the requested permissions are associated with the handle returned
> > (SEC_ACCESS_MAXIMUM_ALLOWED with pSamHnd) _if_ allowed.
> MAXIMUM_ALLOWED is a bit special; instead of having that bit
> associated with your handle, you get whatever permission bits you're
> entitled to.
... which means that we need _another_ field associated with each "Open"
of permissions-related function, yes, i was trying to to have to think
about this too much.
> > in the case of the SamrOpenDomain, the permissions
> > SEC_ACCESS_MAXIMUM_ALLOWED are ANDed with the requested permissions (for
> > the first call, SEC_ACCESS_READ_ONLY) before proceeding. this can result
> > in zero bits being set, therefore can result in an instant "access
> > denied".
> I may be misunderstanding what you're saying here, but it sounds like
> you're saying that the SamrOpenDomain call is checking that the perms
> you're requesting for the pDomHnd is a subset of the ones you received
> in the SamrConnect call.
subset... subset... i _think_ that's what i'm saying, although i'm fairly
certain that i've seen requests that circumvent this behaviour.
SamrConnect(0x00000020) followed by a SamrOpenDomain(something else).
oh i don't know: i don't want to think about it!!!
> If so, that's not correct. In general, the
> way these things work are that when you do some operation on a handle,
> there's a check for whether the handle has been granted the necessary
> permission(s) for that operation. In the case of SamrOpenDomain, you
> need to have been granted the SAMR_OPEN_DOMAIN permission in your
> pSamHnd handle.
ah. makes sense.
> > _then_ you may receive calls such as SamrEnumDomUsers(&pDomHnd, ...) and
> > for each type of call:
> > - read
> > - write
> > - enumerate
> > we need to creaate a security descriptor. in the SamrEnumDomUsers
> > example, it would have an ACL entry:
> > "Everyone" is granted "SEC_ACCESS_ENUMERATE".
> > _except_ if we decide to implement "RestrictAnonymous", in which case this
> > changes to:
> > "Authenticated Users" is granted "SEC_ACCESS_ENUMERATE".
> > "Everyone" is denied access.
> > .. or something of the sort, in order to deny anonymous users the right
> > to enumerate domain users.
> Note that on NT, the SD isn't associated with a call, per se. There's
> actually an SD for each and every object in the SAM. That includes
> the SAM itself, the Builtin and Account domains, and every alias,
> group, and user within them. I don't think samba has a way of storing
> these currently, but you may want to allow for this in the future.
do i have any choice?
hmmm... objects sounds better.... and an "object" typically has a
"handle" associated with it...
hmmm... i've been thinking of using "handles" in this fashion in the SMB
/ MSRPC pipe code, too...
More information about the samba-technical