Hi, I have a Samba PDC that uses an LDAP passdb backend. All users and groups have pre-generated Samba attributes (sambaSID, sambaGroupMapping, sambaPrimaryGroupSID etc.) as well as posixGroup/posixAccount attributes. It'd be great to be able to point a member server at this same LDAP tree (but *without* also giving it the admin DN and password) so it would automatically have the same uidNumber-gidNumber-SID mappings as the PDC instead of having to go the much more convoluted winbindd+IDMAP route suggested in chapter 7.3.1 "Samba Domain with Samba Domain Member Server -- Using NSS LDAP" of the Samba-Guide. Currently this seems to be impossible because the member server would apparently insist on having its own SIDs in the ldapsam. However, in such a scenario, couldn't the local SIDs be generated as easily as replacing the domain part of the domain SID with the local SID? Is there really a need to actually store them? It's entirely possible I'm missing something (or several things), of course. Thanks.
Have you seen "net setlocalsid"?
(In reply to comment #1) > Have you seen "net setlocalsid"? I have, but I was under the impression that SIDs had to be unique (so that it would be invalid to set the local SID to the SID of the domain). If this is not the case, and the solution to my problem is really this simple (I'll try it, thanks for the hint), then I think this warrants some documentation. Proposed language, to be placed somewhere around chapter 7.3: "In a network where all users are stored in LDAP and all already have both Samba/Windows as well as Posix attributes (i.e. uidNumber, sambaSID, gidNumber, primaryGroupSID and so on), adding a member server is very simple. Just use net setlocalsid to set the SID of the member server to the SID of the domain; then copy the LDAP and SAM related configuration from the PDC to the member server, but omit the admin DN. You also don't need to run smbpasswd -w as the member server doesn't need write access to LDAP. There is no need for winbindd or the IDMAP mechanism in such a scenario."
what you describe here is a hack and we would not suggested to do this. The LDAP SAM is the SAM of the DCs. On a member server set up a idmap method (there are some possibilities) and winbind accordingly. If you insist on LDAP on the member ser, have a look at idmap nss. If there are questions about how to do that, please move the discussion to the samba mailing list.
(In reply to comment #3) > what you describe here is a hack and we would not suggested to do this. The > LDAP SAM is the SAM of the DCs. If this approach has drawbacks, then I think the documentation should point them out. > On a member server set up a idmap method (there > are some possibilities) and winbind accordingly. If you insist on LDAP on the > member ser, have a look at idmap nss. If there are questions about how to do > that, please move the discussion to the samba mailing list. No, this bug report really is not a support request. From what I understand (based on reading the documentation), Samba seems to insist on the relatively complex idmap-winbind approach (like you do above) even in cases where it's not really necessary. The underlying assumption seems to be that there will be users who have either only Unix or only Windows IDs (uidNumber, sambaSID), and that Samba must be configured to deal with these by dynamically allocating the missing IDs and storing these mappings persistently in a database; or that while all users may have all adequate IDs, Samba may not be able to look them up. I agree that in many (perhaps most) real world networks this is really the case. However, with careful design and some discipline, it is possible to make sure LDAP really does contain everything Samba needs, making winbind and idmap unnecessary. In these cases, what seems to be the hack is using winbind and idmap to allow Samba to create a faux mapping of uids to SIDs even though a perfectly valid mapping already exists in LDAP. If there is a good reason that Samba chooses not to support such complete LDAP setups, to the point of deliberately not documenting the possibility, I think the decision of deliberately not documenting it is wrong. Instead, the documentation should explain the good reason why this solution is shunned.
I'm reopening this as it's become a documentation issue.
Why don't you just make all members domain controllers? All you have to then do is replicate the NETLOGON share.
(In reply to comment #6) > Why don't you just make all members domain controllers? All you have to then do > is replicate the NETLOGON share. I suppose I could do that, yes. However, I'd still like to know (and the docs to say :) what's wrong with the "hack" you suggested, which seems like a natural solution to me. Something like: "When setting up a member server, you may be tempted to avoid the apparent complexity of winbind+idmap by making sure your LDAP tree contains all necessary ID attributes for Samba and pointing the member server at the same LDAP tree as the PDC. You'd then also set the local SID of the member server to the domain SID so that the SIDs Samba sees in LDAP are recognised as local. While this would work, it is not recommended, because it runs the following risks/has the following drawbacks: <list>. Instead, we recommend that you configure all member servers as BDCs in such a setup (or that you set up winbind+idmap on them, of course)."