Apparently you used to be able to establish an interdomain trust with a user-specified name. Now the name has to match the name of the calling domain. This works OK for two domains sharing a single authentication backend, but blows up if you have three or more (I have four physical sites at this time, but we are still a-growing according to our CEO).
Pretend you have three sites named SITE1, SITE2, SITE3 and they all have a single authentication backend running syncrepl'd OpenLDAP. There are separate domains at each site named DOMAIN1, DOMAIN2, DOMAIN3 and each has his own samba PDC and WINS server. Each site has multiple ethernet segments. (This is a low cost, high performance, high reliability rig with excellent security and auditing capabilities by the way.) SITE1's PDC needs a domain trust account named "DOMAIN1" with a SID from DOMAIN2 to access resources in DOMAIN2. SITE1's PDC needs a domain trust account named "DOMAIN1" with a SID from DOMAIN3 to access resources in DOMAIN3. Net rpc trustdom doesn't allow you to use a domain trust name other than the name of the calling domain anymore. :( This would not be a problem if samba could make the call to LDAP with a filter string of (&(uid=DOMAIN1)(sambaSID=S-1-5-21-xxxxxxxx-xxxxxxx*)), and since sambaSID now requires a substring index in LDAP anyway that would be a perfectly legal filter. It would also not be a problem if samba could check the SID values whenever it gets multiple objects back from LDAP. It would then see that only one object with uid=DOMAIN1 had an appropriate SID and use that one, but the trust lookup just bombs out with an error message instead. It would also not be a problem if samba honored the "ldap machine suffix" setting in smb.conf when looking up interdomain trusts - but, instead, it uses "ldap suffix" so you can't just segregate the container objects by domain and use appropriate settings in each site's smb.conf files. It would not be a problem if there were an "ldap domain trust suffix" setting in smb.conf either. I know some people are aesthetically offended by the ever-multiplying options available in smb.conf, but personally I don't mind since the defaults are generally very good. And, of course, it would not be a problem if you could still use separate interdomain trust accounts named "DOMAIN1TRUST1" and "DOMAIN1TRUST2" et cetera. Looking at the data in LDAP and secrets.tdb, it appears that the restriction's in the software and not the data structures. There is a way around the problem, but it's a hack, and people who don't feel comfortable with rewriting their authentication backend access controls in a large live network probably shouldn't do it. If I have explained this poorly, I apologize - interpersonal communications skills are not my area of speciality. --Charlie On Tue, Jun 17, 2008 at 6:13 PM, Volker Lendecke <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 06:03:13PM -0400, Charlie wrote: >> If you need a feature from a later version of samba, obviously you'll >> have to upgrade. But you should be aware that current versions of >> samba seem to have lost some features you might take for granted in >> older versions (such as stacked backends and domain trusts with >> user-specified names, for example). > > Stacked backends -- you mean the passdb backends? Yes, they > were taken away because they caused quite a bit of trouble. > But "domain trusts with user-specified names" -- what is > that? I know we have bugs in winbind with trusts, but they > are bugs, not deliberately taken away features. > > Volker > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
