I have a patch that includes the RFC2307 attributes as an alternative to the SFU attributes for Winbind and idmap_ad to function with Active Directory supporting these extensions. This patch also applies to 3.0.21 code tree. I have tested this in a Fedora 4 environment only using the RPM spec file shipped with Fedora 4 as the build platform, the test has been run using the 3.0.20b release. I will try 3.0.21 in the next few days. The configuration parameter "winbind nss info" has been extended to recognise "rfc2307" as an alternative to "sfu". I will submit this patch if someone will tell me how and where I should do so!
Created attachment 1629 [details] Patch to be applied to 3.0.20b for rfc2307 functionality use patch -p1 OK found out how to add a patch!
Howard, you are referring to an RFC2307 attributes implementation beside SFU that is already in Active Directory? Or do you use a separate extension to add these?
The RFC2307 standard uses different OID's to that used by SFU. The upcoming release of Windows 2003 (W2K3 R2) has these attributes as standard. This patch enables these in place of the SFU OID's. Thus it is closer to compatible with other LDAP implementations.
Created attachment 1762 [details] Version of the patch for 3.0.21c use patch -p1 3.0.21c made changes in the same area as the submitted patch, so I have reproduced the patch (with a couple of minor changes) to meet this version.
(In reply to comment #4) > Created an attachment (id=1762) [edit] > Version of the patch for 3.0.21c use patch -p1 > 3.0.21c made changes in the same area as the submitted patch, so I have > reproduced the patch (with a couple of minor changes) to meet this version. I have attached the wrong patch file will fix this later tonight after I have rerun the builds to ensure I have the right version.
Created attachment 1779 [details] Corrected path for 3.0.21c I found the right patch. This has been tested in a Fedora 4 Linux environment and compiles and functions when faced with an RFC2307 environment. Extensive testing has not been carried out but it has been live for 10 days now.
Created attachment 1810 [details] Additional patch to fix const problem with compilers other than gcc This is an additional patch for the 3.0.21c version which fixes a problem with a const declaration on compilers other than gcc
Created attachment 1811 [details] Additional patch to fix const problem with compilers other than gcc This is a further tidy up obsoletes the last patch.
Created attachment 1814 [details] Patch to fix a compiler optimisation problem You need this patch to fix the compiler optimisation problem that stops winbind from finding the uidnumber and gidnumber in some lookups.
Created attachment 1817 [details] Consolidated patch for 3.0.21c with a small bug fix OK this one contains all of the previous changes consolidated with a memory leak fixed. To use this you need to use an AD with RFC2307 oids. Windows 2003 R2 has these natively. The user need uidnumber, gidnumber, shell, homedir set (gecos can also be set) and must have a group that also has gidnumber set to match. This group must be set to be the primary group for the user.
Created attachment 1845 [details] Alternative patch (to 3.0.21c) that avoids new config parameter I notice someone has beaten me to it but my patch deals with both old and new schemas automatically so I thought I would offer it here as an alternative. Of course, I don't mind which ends up in the product!
The alternative patch has the advantage that it does not need a config option to switch on the facility. It does have the disadvantage that it does not allow an environment where both the RFC2307 and the SFU schema objects exist to select which set of data to utilise. A clean W2K3 R2 release would never suffer from this problem but upgraded W2K0 and W2k3 systems that have used SFU would. I had considered adding a facility to allow the RFC2307 attributes to override the SFU ones by searching for them first and if not found search for the SFU candidates. This has the disadvantage of needing 2 lookups or one lookup that brings back both sets of data. You win or lose depending on your environment. I would still prefer to be able to specify which attributes to use, and possibly enhance the code to allow both to be switched on at once for those environments that are migrating from SFu to RFC2307.
(In reply to comment #12) > A clean W2K3 R2 release would never suffer from this problem but upgraded W2K0 > and W2k3 systems that have used SFU would. Yes, I'd been wondering what to do about locations that had both schemas installed -- especially those which had tried to use RFC2307 in the past but had eventually installed SFU instead. They might have an AD that does not allow schema deletions so they may be unable to discard the now redundant bits of schema. On the whole I think that from the user's point of view a new config parameter isn't much to have to deal with, and now the code for that new parameter is written we may as well use it. So the original patch gets my vote. One concern though: does this patch require all domains to use the same schema? Is it possible that the set of domains that are accessible to a Samba server includes some rfc2307 domains and some sfu domains?
Bob, The schema for an Active Directory Forest must be the same in all domains - a strength/weakness of the AD model. So Schema extensions are propagated to all domain controllers. This is a real pain in a large global forest. Across forest boundaries then all bets are off. However, you would have to use trusts or work out how to make Samba a member of multiple forests (domains in different forests to be precise) which as far as I know does not exist as a capability in Samba today. I still think it might be worth looking to update the code to support environments where both sets of attributes exist in the schema and the data has been filled in using the RFC and SFU attributes. We should probably only accept data for one or the other for a User - RFC userid and SFU groupid would not make much sense. The advantage of this would be in supporting any environment that is doing a migration and did not want to globally update their users. As an alternative I could knock together a very simple LDAP update script (PERL of course) that would copy all SFU attributes into their RFC equivalents across a domain. I know of a couple of sites that are using this patch but I would be grateful for some more feedback. Not having written code for Samba before I would like to know whether my code follows the quality standards set for Samba and if not what I need to change.
*** Bug 3745 has been marked as a duplicate of this bug. ***
Ok, finally got around to look at the patches, looks quite good but there are some more issues we have to solve: one is the abilitiy to choose between sfu/rfc2307/template per trusted domain. I attach my own patch (work in progress).
Created attachment 1892 [details] another alternative patch (work in progress)
This has been adressed in subversion (http://websvn.samba.org/cgi-bin/viewcvs.cgi?rev=15697&view=rev) Thanks everybody involved! Please reopen if you see any issues with it.