On Sun, 2005-02-13 at 16:16 +0100, Tony Earnshaw wrote: > John H Terpstra: > > [...] > > > FYI. I run Samba training classes around the world. I use SuSE Linux > > Enterprise Server 9 and SuSE Linux 9.2 Professional to host Samba. All > > classes are run using OpenLDAP 2.2 and the Idealx scripts. > > > > I have deployed Samba-3 and OpenLDAP 2.2.x in several large sites - they > > are operating without problems. > > I'll believe it. I'm a newbie at Samba - but as Craig has pointed out, > and for the same reasons, the methods used by IDEALX and repeated in the > official Samba doco and Coupeau's "HOWTO" were screwing up my ldapsam DB > and uglifying my servers. There had to be a better way, and both Craig and > I discovered that independently of one another. Actually, I find it > marvelous that it works :) > > > I concur that the use of use names and group names that have spaces and > > upper-case characters does is not to my taste either, > > What is achieved works, and that's the best that can be said about it. > However, it's totally unnecessary and can easily be avoided. > > Furthermore, whatever one does, SWAT (which I don't normally use - apart > form reading about the defaults) makes a complete mess of groups with > spaces in them. > > > however, it is a > > compromise that is easier than any attempt to render another solution > > viable at this time. > > That is not so. An alternative solution is available with Samba 3.0.7 thru > 3.0.11. Both Craig and I have posted (this thread) what that method is. > However, it makes use of the IDEALX scripts impossible. > > > Much of this is likely to change for Samba-4. Samba-4 > > may go into beta during the later half of this year. > > > > I am well aware that part of the Open Source Gestapo has implemented > > means in Linux of enforcing particular tastes. Examples include: > > > > 1. No upper-case characters in user names and group names > > 2. No spaces in user names and group names > > Gestapo in Open Source? Wouldn't that rather be Posix, many years ago (in > an attempt to clean up a diversity of alternative systems)? Red Hat > (Linux) accepts both, but they are *ugly* and lead to all sorts of > complications. IIRC SCO Openserver 5 accepted neither. > > > This is not universal in Linux distributions - some preserve the old > > behaviour. > > > > 3. Voiding the ability to use /dev/null as a valid home directory. > > 4. Voiding the ability to specify /bin/false as a shell. > > I have no problems with either? > > > I recognize that we need a work-around solution for platforms that > > implement Gestapo admin policies. > > It really has nothing to do with the gestapo, maybe a bit of history > reading wouldn't come amiss? > > > Please bear in mind that Samba interfaces between MS Windows and > > UNIX-like > > platforms. The issues we are touching on here are deeper than the > > cosmetics of user names and group names. To change the behaviour will > > require changes deep inside the smbd source code to affect new mapping > > semantics and to enforce conversion of all Windows user and group names > > before making any reference to the UNIX environment for name look-ups > > and/or for identity resolution. > > That is not so. The solution lies for the hand and is already present in > the current code. Craig and I both implement it ;) ---- I have to believe that some of this exchange has occurred off channel.
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 had no idea of that when I used the command - and the usage of this on an existing DSA seemed rather like puppeteering. 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)... If you have an existing DSA and want to change it directly with the tools you use to modify your entries, the following types of group entries need to be absorbed into your DSA for expected Windows behavior... Groups that have the following type of attributes... # dom_users, Groups, example.com dn: cn=dom_users,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top objectClass: sambaGroupMapping cn: dom_users userPassword:: gidNumber: 500 memberUid: craig description: Netbios Domain Users 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 obviously, substitute your SID for the 'S-1-5-21-9999999999-9999999999-9999999999' there should be groups with sambaSID's / sambaGroupType: 2 at least for... sambaSID sambaGroupType displayName S-1-5-21-9999999999-9999999999-9999999999-512 2 Domain Admins S-1-5-21-9999999999-9999999999-9999999999-513 2 Domain Users S-1-5-21-9999999999-9999999999-9999999999-514 2 Domain Guests S-1-5-21-9999999999-9999999999-9999999999-515 2 Domain Computers etc. also the following 'local' type entries should be included to track the account groups normally seen on a Windows NT/2000 type system... sambaSID sambaGroupType displayName S-1-5-32-550 5 Print Operators etc. 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. 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 gecos: System User description: Built-in account for administering the computer/domain displayName: Administrator sambaLogonTime: sambaLogoffTime: sambaPwdLastSet: sambaLMPassword: sambaNTPassword: sambaPwdCanChange: sambaPwdMustChange: sambaProfilePath: sambaHomePath: uid: Administrator cn: Administrator homeDirectory: uidNumber: objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: sambaSamAccount sambaDomainName: gidNumber: sambaSID: S-1-5-21-9999999999-9999999999-9999999999-500 sambaAcctFlags: [U ] sambaHomeDrive: sn: Administrator loginShell: userPassword:: sambaPrimaryGroupSID: S-1-5-21-9999999999-9999999999-9999999999-513 where the sambaSID MUST be inclusive of the '500' RID and uidNumber: 0 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. Craig -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
