[Samba] Problem Delegating Control of Inbuilt Users

[Linda W]

David Minard wrote:
> G'day All,
>
> 	We're having a problem with the following:	http://blogs.technet.com/b/askcore/archive/2010/03/30/access-denied-error-0x80070005-message-when-initializing-tpm-for-bitlocker.aspx
> 	We get this error: (See attached, but text below)
> 		"Select Users, Computers, or Groups
> 		X	Windows cannot process the object with the name "SELF" because of the following error:
> 			Name translation: Input name found, but not the associated output format."
>   
----
If I understand your question, "SELF" is a built-in user and you aren't 
able to modify
built-in user or groups?  Please forgive the long
post if this wasn't what you meant...

AFAIK (based on 3.x behavior), this was due to a check in the samba source
to disallow processing such requests for builtins rather than passing them
along to your name-resolution provider.

   I had this 'working' (for some value thereof) -- mostly, the server would
return configured built-ins if queried.  In my case, I was using the
idmap config backend = nss, which on my system was(is) mapping
the UID/GID to the appropriately reserved builtin.  It also allowed me
to assigned a UUID to a specific builtin so, indeed,
UID=18 == S-1-5-32-18.  By default, due to limitations implemented
in the code, you can't do such things with BUILT-IN or WELL-KNOWN
groups that are not part of your DOMAIN (like DOMAIN ADMINS,
DOMAIN USERS, are "normal" domain groups -- not builtins.

(this means passwd has entries reserving group ID's for my own sanity:)

SYSTEM:x:18:18:S-1-5-32-18:/:/bin/nologin
Domain Administrator:x:500:18:root account:/root:/bin/bash
Authenticated_Users:x:11511:11511:S-1-5-11:/var/lib/nobody:/bin/nologin
Terminal Server Users:x:11513:11513:S-1-5-13:/var/lib/nobody:/bin/nologin

I tend to think samba should be a bit more liberal by default
in how it handles built-ins so that normal Windows functionality
can be emulated, but last feature I lobbied for inclusion got
renamed to "allow insecure <feature>" rather than having
it be descriptive as to what the feature was.  (It isn't
any less secure than allowing users to login to your file server.

If  you did that,  it wasn't insecure, If you didn't allow
it, then it could be leveraged in an insecure way. 
With such renaming from "client_managed_wide_links"
(descriptive) to to "allow_insecure_widelinks" (value judgment
on site security policies and non-descriptive of action), I didn't
think supply compatibility improvement patches to samba was
very practical.  I have no idea if similar patches would work
in samba 4 or if nss mapping is still available (nss was
easiest for me as I have few users).  Larger would likely
have gone with LDAP -- which, conceptually, should
provide similar functionality, but as a practical matter,
I don't know.


LW