List, documenters; I'd like to exchange notes about the official Samba 3 LDAP doco. I'd like to do this off list, since doing it on list would simply confuse and confound users wit perfectly working systems. Background: Me, Samba relative newbie, though I can get *everything* Samba-orientated to work simply by using umpteen years Unix experience. Many years as Openldap admin. With Windows it's worse, since I'm beginning again after many years' absence - but it all works if I try hard enough and follow the docs (but more importantly my own intuition. Windows stinks, since changes in subversions nullify the experience gained in previous versions. However, we all knew that. Openldap experience is a couple or three years long, BUT I'm not prepared to discuss *anything* prior to OL 2.2.17 (the present stable version as notified by OpenLDAP.org is 2.2.23). For example, Red Hat's 2.0.27 or 2.1.22 are unstable and will break on extended loading or extended uptime. Worst is, that with OL 2.0.27 there's no method of repairing sparse/corrupted databases other than wit a rebuild from a dumped ldif; with Red Hat's 2.1.22 databases are guaranteed to become corrupted (Sleepycat BDB 4.1), though there is a way of repairing the DB (whilst the server is *down*). OL 2.2.17's and higher use patched Sleepycat's BDB 4.2.52, are mostly guaranteed against corruption (if correctly configured using DB_CONFIG) and even in the case of a corrupted DB (which I've *never* experienced, whatever) can be repaired. Samba's NT groups as documented in the HOWTO (Terpstra and Coupeau) are worthless. (Sorry JT). OL 2.2 don't like Unix GIDs or UIDs with spaces in their names (f.ex. "Domain Admins"). Worse, Linux don't like them. Worst of all, it looks like shit on an 'ls -l'. I have my own alternative method which works perfectly. That's what I'd like to discuss, off list. No, I haven't asked IDEALX, no I haven't consulted anyone else than Billy my Cat, my IT consultant. He's in perfect agreement with me - but then, he usually is, if he gets food and petting regularly. Best, --Tonni -- mail: tonye@billy.demon.nl http://www.billy.demon.nl
Tonni, Folks, The Samba-HOWTO-Collection and Samba-Guide documentation has worked for many people, but I am quick to admit that it can be significantly improved. There is little benefit in my continuously pounding this list with requests for patches and updates - even though we have demonstrated time after time that we act on every suggestion, patch or contribution. We do not know as much as the sum of experience that others can contribute. Some of us really appreciate little (or big) gems of knowledge and/or experience that may help us in our efforts or work. We do not accept the notion that the current documentation is "worthless". We will all be most pleased to receive an update or ammendment that may help any other user. The update or ammendment may be in pure text form, or any other form you care to submit, we will convert it to docbook format for inclusion in the documentation. In the past we have included updates regardless of our personal preferences, the only criteria we must insist on is that the information is not plain-wrong, and that it is legal for us to publish it. Documentation projects need to take account of technical correctness and must also recognize the significant degree to which personal preferences dictation people opinions. Just because someone does not like something does not make it wrong. I do not have time for lengthy discussion, my time is limited enough as it is. Please document and submit your patches, updates or contribution using bugzilla at: https://bugzilla.samba.org If the demands of posting to bugzilla are too much to ask, I am happy to receive bug reports and updates, etc. via direct email. Please document your "corrections" and let's get on with life. Cheers, John T. On Saturday 12 February 2005 11:18, Tony Earnshaw wrote:> List, documenters; > > I'd like to exchange notes about the official Samba 3 LDAP doco. > > I'd like to do this off list, since doing it on list would simply confuse > and confound users wit perfectly working systems. > > Background: > > Me, Samba relative newbie, though I can get *everything* Samba-orientated > to work simply by using umpteen years Unix experience. Many years as > Openldap admin. With Windows it's worse, since I'm beginning again after > many years' absence - but it all works if I try hard enough and follow the > docs (but more importantly my own intuition. Windows stinks, since changes > in subversions nullify the experience gained in previous versions. > However, we all knew that. > > Openldap experience is a couple or three years long, BUT I'm not prepared > to discuss *anything* prior to OL 2.2.17 (the present stable version as > notified by OpenLDAP.org is 2.2.23). For example, Red Hat's 2.0.27 or > 2.1.22 are unstable and will break on extended loading or extended uptime. > Worst is, that with OL 2.0.27 there's no method of repairing > sparse/corrupted databases other than wit a rebuild from a dumped ldif; > with Red Hat's 2.1.22 databases are guaranteed to become corrupted > (Sleepycat BDB 4.1), though there is a way of repairing the DB (whilst the > server is *down*). OL 2.2.17's and higher use patched Sleepycat's BDB > 4.2.52, are mostly guaranteed against corruption (if correctly configured > using DB_CONFIG) and even in the case of a corrupted DB (which I've > *never* experienced, whatever) can be repaired. > > Samba's NT groups as documented in the HOWTO (Terpstra and Coupeau) are > worthless. (Sorry JT). OL 2.2 don't like Unix GIDs or UIDs with spaces in > their names (f.ex. "Domain Admins"). Worse, Linux don't like them. Worst > of all, it looks like shit on an 'ls -l'. I have my own alternative method > which works perfectly. That's what I'd like to discuss, off list. No, I > haven't asked IDEALX, no I haven't consulted anyone else than Billy my > Cat, my IT consultant. He's in perfect agreement with me - but then, he > usually is, if he gets food and petting regularly. > > Best, > > --Tonni > > -- > mail: tonye@billy.demon.nl > http://www.billy.demon.nl-- John H Terpstra Samba-Team Member Phone: +1 (650) 580-8668 Author: The Official Samba-3 HOWTO & Reference Guide, ISBN: 0131453556 Samba-3 by Example, ISBN: 0131472216 Hardening Linux, ISBN: 0072254971 Other books in production.
On Sat, 2005-02-12 at 19:18 +0100, Tony Earnshaw wrote:> List, documenters; > > I'd like to exchange notes about the official Samba 3 LDAP doco. > > I'd like to do this off list, since doing it on list would simply confuse > and confound users wit perfectly working systems. > > Background: > > Me, Samba relative newbie, though I can get *everything* Samba-orientated > to work simply by using umpteen years Unix experience. Many years as > Openldap admin. With Windows it's worse, since I'm beginning again after > many years' absence - but it all works if I try hard enough and follow the > docs (but more importantly my own intuition. Windows stinks, since changes > in subversions nullify the experience gained in previous versions. > However, we all knew that. > > Openldap experience is a couple or three years long, BUT I'm not prepared > to discuss *anything* prior to OL 2.2.17 (the present stable version as > notified by OpenLDAP.org is 2.2.23). For example, Red Hat's 2.0.27 or > 2.1.22 are unstable and will break on extended loading or extended uptime. > Worst is, that with OL 2.0.27 there's no method of repairing > sparse/corrupted databases other than wit a rebuild from a dumped ldif; > with Red Hat's 2.1.22 databases are guaranteed to become corrupted > (Sleepycat BDB 4.1), though there is a way of repairing the DB (whilst the > server is *down*). OL 2.2.17's and higher use patched Sleepycat's BDB > 4.2.52, are mostly guaranteed against corruption (if correctly configured > using DB_CONFIG) and even in the case of a corrupted DB (which I've > *never* experienced, whatever) can be repaired. > > Samba's NT groups as documented in the HOWTO (Terpstra and Coupeau) are > worthless. (Sorry JT). OL 2.2 don't like Unix GIDs or UIDs with spaces in > their names (f.ex. "Domain Admins"). Worse, Linux don't like them. Worst > of all, it looks like shit on an 'ls -l'. I have my own alternative method > which works perfectly. That's what I'd like to discuss, off list. No, I > haven't asked IDEALX, no I haven't consulted anyone else than Billy my > Cat, my IT consultant. He's in perfect agreement with me - but then, he > usually is, if he gets food and petting regularly.---- yeah but how good is he at coding? I am pretty much in agreement with your assessments, both in this message and on previous messages but it's probably an exaggeration to call the HOWTO with respect to groups as worthless. What I find that I have issue with - an apparently so do you, is that the official HOWTO tends to view LDAP in a vacuum with respect to samba and that is too expedient to be practical for those who have implemented LDAP already and not entirely cooperative with Unix/Linux tools when you use the names such as "Domain Admins" etc. The documentation in the HOWTO does tell you how to assign windows type "Domain Users" to Unix "dom_users" via group map commands and it took me some time to figure out that the intent is to create an object in the DSA like this... # dom_users, Groups, azapple.com dn: cn=dom_users,ou=Groups,dc=azapple,dc=com objectClass: posixGroup objectClass: top objectClass: sambaGroupMapping cn: dom_users userPassword:: gidNumber: 500 memberUid: craig memberUid: jennifer memberUid: holly sambaGroupType: 2 sambaSID: S-1-5-21-9999999999-9999999999-9999999999-513 description: Netbios Domain Users displayName: Domain Users where the group map command puts the windows name for the group into the 'displayName' attribute and obviously the RID is important in this case. In fact, Windows needs the sambaSID to be right, the displayName to be consistent with the expectations of an experienced Windows administrator and this setup permits sanity when dealing with the posix type attributes as well. I found the IDEALX scripts interesting in that they create the necessary groups for Windows to be happy but obstructive if you try to use those groups added to the DSA because of the erratic behavior of various utilities dealing with group names such as "Domain Users". Thus, I haven't used them since my early fumbling. Whether you choose to populate your base with the IDEALX script or do 'net rpc vampire' you will bring these groups into your DSA and you will have to deal with them or not deal with them as you see fit. Interestingly enough, I used Gerry Carter's LDAP book which deals with LDAP first and then how to integrate samba (of course, this was 2.2 when book was published) which is clearly the approach that you and I have taken. There was a brief exchange last week where John Terpstra took me to task for expressing my opinion that root should not be used in the DSA at all which goes against his advice and against the current Samba documentation but Gerry Carter piped in with his agreement to my point of view so evidently, there is a fundamental disagreement between them that hasn't been resolved with clarity for us lowly and less sophisticated users. I guess I have come to the conclusion that the current documentation (I'm mostly referring to the HOWTO since I haven't studied the 'by Example' stuff) is geared towards LDAP used in a vacuum with Samba with the assumption that an experienced LDAP Administrator will be able to integrate samba into the existing DSA without resorting to the expedient methods described in the HOWTO. Perhaps there needs to be a section for using samba with LDAP for the novice LDAP administrator and a section for integrating samba into your existing DSA for the more sophisticated and experienced administrators. I think it would be best to keep this exchange on list as it does provide clarity for all who wish to consider the implications of their setups and the ability to find this info in the archive. Craig
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 namesGestapo 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 ;) Best, --Tonni -- mail: tonye@billy.demon.nl http://www.billy.demon.nl
Craig White: [...]>> > 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.There was no exchange off list. It was sent to me off list, but my mail proggies (mostly SquirrelMail, Evo and Thunderbird) all filter on subject etc. and send to my respective folders. My MDA (maildrop) has in advance already deleted duplicate Message-IDs, so there's only one copy to read. I replied in the forum to which the thread is dedicated. [...]> # 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-513A note for good measure: if you're adding a record with ldapadd, empty attributes will be refused. They must have a value to be accepted. However, LDAP clients such as GQ will in fact show you empty attributes; though if you export such an entry to an ldif, the empty attributes will not be included in your export.> where the sambaSID MUST be inclusive of the '500' RIDMy Win XP prof machine accepts any RID whatsoever for Administrator. Maybe a Win 2000 machine wouldn't. Moreover, using USRMGR/SRVMGR it issues out-of-context RIDS (e.g. 513 for a computer). It coexists with and accepts these quite happily. As I wrote, there are exceptions to all HOWTOs ;)> 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.I also wrote that there is *NO WAY* any UID other than root will get uidNumber 0 or gidNumber 0 on any Unix/Linux machine I administer. I have a serious problem with this. Think: you are empowering a probably clueless NTadmin running provenly corrupt software, subject to weekly security fixes, superuser access to one of your most valuable assets. Nobody cares if a Windows user box gets corrupted, everybody expects it, in fact. But neither it or the probable idiot administering it should be allowed to ... --Tonni -- Nothing sucksseeds like a pigeon without a beak ... mail: tonye@billy.demon.nl http://www.billy.demon.nl They love us, don't they, They feed us, won't they ... -- mail: tonye@billy.demon.nl http://www.billy.demon.nl