New Unix user and group domain

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Volker Lendecke wrote:

> On Sat, Feb 25, 2006 at 10:30:14AM -0600, Gerald (Jerry) Carter wrote:
>> The  line "on't have to present to anyone" has me
>> confused.  I'm pretty sure we are saying the same thing.
>> But we do have to present "Unix group\foo" in ACL
>> dialogs.  And we return the S-1-2-22-${gid} in the
>> other_sids portion of the samlogon() reply.
> 
> Do we? Let me look... No, we don't. We could, but so 
> far we don't. Look at parse_net.c:1435... :-)

Bad assumption on my part.  OK.  So the S-1-22-2-${gid}
SID is completely locally to a Samba host.

* jerry thinks a bit.

The scenario I was thinking of was a Samba member server
in a Samba domain sharing a uid/gid name (no \unixinfo
pipe yet).  When we create the token for the user from
the NET_USER_INFO_3.  Don't we need those SIDs ?

Now granted that domain groups are broken in this
scenario without the \unixinfo pipe support since the
sid_to_gid() will fail.  So are we any worse off now?
Probably not as long as the unmapped groups continue
to work as they do in 3.0.21.  Make sense?

>> Just to clarify, is this new net subcommand restricted to
>> Samba DCs?  I ask only because you used the term domain
>> groups.  Or do you simply mean groups within our SAM domain?
> 
> I mean Domain Groups in contrast to Local Groups ie Aliases.
> So yes, I mean SID_TYPE_DOM_GRP type objects, wherever they
> might be.

OK. That's fine.  an we just say then that local groups
require 'winbind nested groups = yes' ?







cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEAJi8IR7qMdg1EfYRAp8mAJ9RugvmYp8c3vmrwxyEarJJUF8g9wCfbMHu
1K5aYiUJMFNvPRW4UIkaA4o=
=DQ3+
-----END PGP SIGNATURE-----