Hi, I use ldapsam:trusted and ran into a problem, described in detail in #6230. The (to me) counter-intuitive explanation was that some of my Unix users were members of Unix groups that had no sambaGroupMappings. To me, the intuitive behaviour would be for Samba to join all Unix groups the connecting user is a member of, regardless of whether they have sambaGroupMappings; as I understood it so far, sambaGroupMappings are only there for the benefit of Windows. If a group has no mapping, then Windows can't see it (meaning that Samba doesn't advertise it in any way). Why is it necessary for all groups, even the ones only used on the Unix side, to have sambaGroupMappings? If a group that has no such mapping owns a file, that ownership needn't be reported to Windows at all (as it's not necessary that a file be owned by a user as well as a group in Winland). It can be omitted from ACLs reported to Windows too. I can't currently think of a scenario that would make it necessary to insist on all Unix groups to have sambaGroupMappings, but there must be a good reason or else Samba wouldn't do it. Please enhance the documentation in this regard. Thanks Andras
This report appears to be asking for a change in functionality (how samba does group handling) as well as for enhancement of the documentation. I have read the thread of Bug#6230 and would like some clarification specifically what is being requested here. - John T.
The problem is that the bug reporter apparently needs ldapsam:trusted=yes. This option was meant as a performance optimization for large domains and assumes a very strictly set up directory tree. One thing for example it assumes is that every posix group also has a sambaGroupMapping entry. This assumption is made to optimize certain queries. Without this assumption we would end up with twice as many or even many more LDAP calls which in large and busy environments can make a significant difference. So for the huge domain the bug reporter has, I would be interested to know where exactly his performance pain points are. What are the exact operations that are so slow that he can not live without ldapsam:trusted=yes, while on the other hand it is not possible to straighten the LDAP database. We might have to fine-tune pdb_ldapsam to his environment, but we need to know much more about the specific operations that are too slow and why they are too slow. Volker
Volker, Thanks for that clarification. It appears to me that we need some additional information from Andras (the reporter) before we can determine the nest step. - John T.
Hi, sorry, I appear to have misled Volker, which was not my intention. I don't currently have a huge domain where ldapsam:trusted would make a large performance difference. I hit the problem described in Bug#6230 in what was basically a test setup, but even the real world deployment based on it won't qualify as "huge" by any standards (I don't expect more than about 100 users). Apparently I am, or was, under a misapprehension as to what ldapsam:trusted does, which is why I'm filing a bug report against the documentation. Quoting from the smb.conf manpage: > By default, Samba as a Domain Controller with an LDAP backend needs to use the Unix-style NSS subsystem to access user and group information. Due to the way Unix stores user information in /etc/passwd and /etc/group this inevitably leads to inefficiencies. One important question a user needs to know is the list of groups he is member of. The plain UNIX model involves a complete enumeration of the file /etc/group and its NSS counterparts in LDAP. UNIX has optimized functions to enumerate group membership. Sadly, other functions that are used to deal with user and group attributes lack such optimization. > > To make Samba scale well in large environments, the ldapsam:trusted = yes option assumes that the complete user and group database that is relevant to Samba is stored in LDAP with the standard posixAccount/posixGroup attributes. It further assumes that the Samba auxiliary object classes are stored together with the POSIX data in the same LDAP object. If these assumptions are met, ldapsam:trusted = yes can be activated and Samba can bypass the NSS system to query user group memberships. Optimized LDAP queries can greatly speed up domain logon and administration tasks. Depending on the size of the LDAP database a factor of 100 or more for common queries is easily achieved. The part where it says "complete user and group database that is relevant to Samba is stored in LDAP with the standard PosixAccount/posixGroup attributes. [...] the Samba auxiliary object classes are stored together with the POSIX data in the same LDAP object" is what I apparently misunderstood and what I'd like to see clarified. In particular, it was unclear to me that _all_ groups the Unix user is a member of need to have a sambaGroupMapping, and that things will break otherwise; I assumed it would be enough to have sambaGroupMappings in groups that are "relevant to Samba" in the sense that they should be visible on the Windows end. I now understand that the breakage resulting from a failure to provide sambaGroupMappings for all groups isn't intended behaviour per se but a (necessary?) side effect of query optimisations. FWIW, I had two reasons to enable ldapsam:trusted in the first place: one was the remark about increased performance (which I figured would almost always be nice to have); the other was that I was looking for the most straightforward and intuitive way to construct my LDAP tree and indeed the entire system, and making Samba independent of NSS seemed like a very good idea (because I find libnss-ldap to be messy). On a related note, there are other parts of the documentation I find confusing or unclear or incomplete (even from the perspective of a literate user, or one who fancies himself as such); would I be helping if I filed bugs about these, or just increasing the noise level? Andras
Andras, Instead of just reporting a bug you would expedite revision of the documentation if you could submit suggested changes and/or additions. Examples and contributions really make life much easier for all of us. We will review and respond where there are any concerns. In respect of documentation that is not clear, please direct that to me <jht@samba.org> and always copy the mailing list also. cheers, John T.
(In reply to comment #5) John, > Instead of just reporting a bug you would expedite revision of the > documentation if you could submit suggested changes and/or additions. Of course, but I can't easily do that when I don't know what should be there. :) In this particular case, I suggest adding a subsection to the smb.conf manpage section about ldapsam:trusted that says something like this: --- >8 --- When using ldapsam:trusted, all Unix groups and users Samba may be exposed to MUST have the appropriate Samba attributes in LDAP, because the query optimisations are built around this assumption. Users and groups that need these attributes include Samba users as well as all groups Samba users can be members of; additionally, all users and groups that can own files in any shares. Expect confusing errors if some users or groups don't have the necessary Samba attributes. An LDAP entry for a group should include the following attributes: dn: cn=users,ou=Group,dc=some,dc=domain objectClass: posixGroup objectClass: top objectClass: sambaGroupMapping cn: users description: Netbios Domain Ordinary users sambaSID: S-1-5-32-545 sambaGroupType: 5 userPassword:: e2NyeXB0fXg= gidNumber: 100 The necessary and sufficient attributes for a user entry are the following: dn: uid=someuser,ou=People,dc=some,dc=domain uid: someuser cn: someuser objectClass: account objectClass: posixAccount objectClass: sambaSamAccount objectClass: top loginShell: /bin/bash uidNumber: 4242 gidNumber: 4243 homeDirectory: /home/someuser sambaPrimaryGroupSID: S-1-5-21-655183313-499555889-1571944852-123 sambaAcctFlags: [U ] sambaSID: S-1-5-21-655183313-499555889-1571944852-456 sambaNTPassword: 8AFF61B22FAAF1DEADBEEFEC0ACED90D userPassword:: e1NTSEF9OTd0aEMvNVJISEdLc2FnSDdxa2FDYlNkdndWRlE5NUE= Of course, entries may have additional attributes and objectclasses (such as shadowAccount), and actual attribute values will probably not match those in the example. --- 8< --- (I don't know whether the above is factually correct, but something to this effect would IMO be a useful addition to the manpage.) Andras
(In reply to comment #6) > (In reply to comment #5) > > John, > > > Instead of just reporting a bug you would expedite revision of the > > documentation if you could submit suggested changes and/or additions. > > Of course, but I can't easily do that when I don't know what should be there. > :) > > In this particular case, I suggest adding a subsection to the smb.conf manpage > section about ldapsam:trusted that says something like this: > > --- >8 --- > > When using ldapsam:trusted, all Unix groups and users Samba may be exposed to > MUST have the appropriate Samba attributes in LDAP, because the query > optimisations are built around this assumption. Users and groups that need > these attributes include Samba users as well as all groups Samba users can be > members of; additionally, all users and groups that can own files in any > shares. Expect confusing errors if some users or groups don't have the > necessary Samba attributes. > > An LDAP entry for a group should include the following attributes: I refrain from specifying the exact object classes because there is a dependency here on which schema's have been imported into the LDAP directory. The two principal schemas that will impact this are nis.ldif v's rfc2307bis.ldif. > dn: cn=users,ou=Group,dc=some,dc=domain > objectClass: posixGroup > objectClass: top > objectClass: sambaGroupMapping > cn: users > description: Netbios Domain Ordinary users > sambaSID: S-1-5-32-545 > sambaGroupType: 5 > userPassword:: e2NyeXB0fXg= > gidNumber: 100 > > The necessary and sufficient attributes for a user entry are the following: Ditto the above comment. > dn: uid=someuser,ou=People,dc=some,dc=domain > uid: someuser > cn: someuser > objectClass: account > objectClass: posixAccount > objectClass: sambaSamAccount > objectClass: top > loginShell: /bin/bash > uidNumber: 4242 > gidNumber: 4243 > homeDirectory: /home/someuser > sambaPrimaryGroupSID: S-1-5-21-655183313-499555889-1571944852-123 > sambaAcctFlags: [U ] > sambaSID: S-1-5-21-655183313-499555889-1571944852-456 > sambaNTPassword: 8AFF61B22FAAF1DEADBEEFEC0ACED90D > userPassword:: e1NTSEF9OTd0aEMvNVJISEdLc2FnSDdxa2FDYlNkdndWRlE5NUE= > > Of course, entries may have additional attributes and objectclasses (such as > shadowAccount), and actual attribute values will probably not match those in > the example. > > --- 8< --- > > (I don't know whether the above is factually correct, but something to this > effect would IMO be a useful addition to the manpage.) Regrettably, this does not clarify, it provides a specific example that does not satisfy all cases. - John T.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > When using ldapsam:trusted, all Unix groups and users Samba may be exposed to > > MUST have the appropriate Samba attributes in LDAP, because the query > > optimisations are built around this assumption. Users and groups that need > > these attributes include Samba users as well as all groups Samba users can be > > members of; additionally, all users and groups that can own files in any > > shares. Expect confusing errors if some users or groups don't have the > > necessary Samba attributes. > > > > An LDAP entry for a group should include the following attributes: > > I refrain from specifying the exact object classes because there is a > dependency here on which schema's have been imported into the LDAP directory. > The two principal schemas that will impact this are nis.ldif v's > rfc2307bis.ldif. So maybe examples could be provided for at least some of the most common cases? > Regrettably, this does not clarify, it provides a specific example that does > not satisfy all cases. And yet it would have been tremendously useful to me. I found it pretty difficult to determine what attributes my LDAP entities needed to have in order for Samba to work with them correctly. Naturally you can't provide specific examples of all cases, but it's often easier to learn from a specific example that doesn't exactly apply to your situation than from no example at all. The topmost quoted paragraph in this comment would also have been helpful. Andras
Updating product.
a place for this might be a wiki page or some kind of external howto but not the man page.
I still think a sentence like "When using ldapsam:trusted, all Unix groups and users MUST have the appropriate Samba attributes (such as sambaSID and sambaGroupMapping) in LDAP." in the manpage would be very helpful. The manpage as it is now doesn't even imply this requirement.