> The problem that apparently both Tonni and I had was coming to terms > with the net group map command. It mucked with the DSA attributes of > 'displayName' 'sambaSID' 'objectclass' -
I'm confused by this statement. The attributes displayName and sambaSID are not relevant to a POSIX group, so the effect was merely additive - with the addition of the AUXILLARY objectclass sambaGroupMapping. AUXILLARY objectclasses are meant specifically for use in an additive capacity and there was no attribute name space collisions. What was "mucked"? > I had no idea of that when I > used the command - and the usage of this on an existing DSA seemed > rather like puppeteering. How so? I write internal documentation which covers Samba & LDAP usage in a relatively complicated and almost completely directory enabled network, so I'm seriously curious what this perceived gapeing hole is. > I think that a reference in the chapt 11 section on group mapping (Using > your own tools to integrate samba.schema required objects into your > existing DSA)... But this is documented. A user SID is {domain sid} . ((uidNumber * 2) + 1000) A group SID is {domain sid} . ((gidNumber * 2) + 1001) This is documented in many places. > # dom_users, Groups, example.com > dn: cn=dom_users,ou=Groups,dc=example,dc=com ... > sambaGroupType: 2 > sambaSID: S-1-5-21-9999999999-9999999999-9999999999-513 > displayName: Domain Users > > Note that the sambaGroupMapping objectclass and the last three > attributes are the parts of extreme significance to Samba/Windows users Yes. AND they are the attributes added by the sambaGroupMapping AUXILLIARY objectclass; this is very apparent if you use a decent schema browser to look at your DSA. > the net group commands I suppose are the only way to get these entries > into smbpasswd/tdbsam passdb's (does tdb support dump/reload where you > could hack it with a text editor?) but seemed entirely clumsy when you > can edit the DSA entries directly. There are a myriad of ways to add groups to DSA. > and I suppose for good measure - a note about the 'expected' > "Administrator" account in your users container... > # Administrator, People, Example, US > dn: uid=Administrator,ou=People,o=Example,c=US ... > where the sambaSID MUST be inclusive of the '500' RID and uidNumber: 0 But again, I (as a consumer of the documentation) think that this IS documented. > if you expect this account to have root privileges...necessary to be > able to join machines to domain (subject to the following > conditions...you not have another account with uidNumber: 0 in the DSA > i.e. root AND subject to anticipated changes in Policy objects) and > other privileged operations that may be required for samba use. The the additional of privileges support in 3.0.11 this is no longer true. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba