"algorithmic rid base" bogus?

[John H Terpstra]

On Tuesday 27 December 2005 15:22, Andrew Bartlett wrote:
> On Tue, 2005-12-27 at 23:06 +0100, Volker Lendecke wrote:
> > On Tue, Dec 27, 2005 at 10:49:44PM +0100, Volker Lendecke wrote:
> > > There's a caveat that I just found out one step later however: The
> > > samr_query_usergroups call can't return anything sensible if the groups
> > > a user is member of are not mapped. The primary group sid is fine, this
> > > is stored with the SAM_ACCOUNT structure, but the additional groups are
> > > lost. This might be important as this influences the token we're
> > > returning in the SamLogon call.  People might have (from my point of
> > > view invalidly) set workstation security descriptors based on
> > > non-explicitly-mapped groups. Question: Is this really an issue? If I
> > > pursue my plan further I might have to create a compatibility option
> > > just for this call to automagically create the group mapping entries
> > > based on the algorithm.
> >
> > Replying to myself: The reason why I'm not sure this is an issue is that
> > I don't have the slighest idea how an admin could be fooled to locally
> > assign such a security descriptor. They are not listed with
> > enum_domain_groups or query_dispinfo, only the mapped ones are. So none
> > of the non-mapped groups should show up in the windows security dialogue.
>
> The only thought I have was possibly by copying a file (with ACLs) off
> their file-server?

Simple solution. If foreign domain support (non-local SIDs) is disabled we 
refuse to copy the file across. In all other cases, we look up the name 
attached to the SID, then create a local mapping and call the "add group 
script" to create a UNIX user or group that is auto-mapped to the Windows 
account (user or group). In all cases preserving the original SID.

What am I missing here?

- John T.