lsa policy handle
Jean Francois Micouleau
Jean-Francois.Micouleau at dalalu.fr
Thu Nov 29 02:32:03 GMT 2001
On Thu, 29 Nov 2001, Tim Potter wrote:
> Yes. The discussion on tng had something to do with different objects
> having different permissions on them so you could achieve finer
> grained access to resources on a NT system. I'm not sure how this
> usefully translates to Samba. I guess if it was necessary for
> basic interoperability then someone would have coded it up by now.
Up until now we didn't have a need to check the desired_access and who was
the user doing the open_policy(). As all the lsa functions we had were
only 'read' functions.
since I have added some 'write' functions, we now need to check.
Tim, that's like the spoolss_open_printer() call.
The problem I have is simple: basically on NT you have an SD (or a DACL
doesn't make a difference) attached to the LSA process. The DACL contains:
- (WORLD, GENERIC_EXECUTE)
- (SYSTEM, POLICY_ALL_ACCESS)
- (admins alias, GENERIC_FULL)
and you can't change that DACL, it's hardcoded somewhere (or maybe stored
in the registry doesn't matter).
As on samba we don't have nested groups, and as I don't want to add yet
another "lsa admin" param to smb.conf, that would be not fine grained
enough, I'm stuck with adding either 3 or around 25 privileges to the
group mapping code.
3 is GENERIC_ EXECUTE|READ|WRITE and we can emulate correctly an NT box.
GENERIC_EXECUTE is used in the Lsa Enum functions
GENERIC_READ is used in the Lsa Query functions
GENERIC_WRITE is used in the Lsa Set functions
Or we go the full fine grained way, and for each Lsa function we have a
privilege. Btw that's what NT does, but you don't have access to it as you
can't change the default DACL !
and now the fun is: I can replace LSA by SAM and duplicate this long and
More information about the samba-technical