On Wed, 2003-02-12 at 05:55, Antti Andreimann wrote: > Ühel kenal päeval (teisipäev, 11. veebruar 2003 13:39) kirjutas Andrew > Bartlett: > > > I'm not quite convinced about this. I'm quite willing (but see below) > > > to apply the rest of this patch, but I'll need a good explanation of > > > what this patch does. > > Well, It's purely because our internal needs but I think this could be useful > for other people as well. > Consider the following situation: > You have a kerberos realm that holds all the user accounts (COMPANY.COM) > Now You have an ADS server (AD.INTERNAL) that is set up to trust that realm. > All users are replicated in ADS, but their passwords remain in kerberos. This > is the standard method of getting kerberos and AD to play nicely with each > other. > Now if I configure samba to use ADS It should be configured to be part of the > realm AD.INTERNAL right? Therefore all users from COMPANY.COM are considered > as being from foreign realm and their usernames take a form like > "COMPANY.COM/username". This would be OK, if those users are in fact from > foreign realm, but in this kind of configuration where You are using kerberos > for authentication and AD merely acts as a bridge for Windows users, You want > Your Linux server to be part of the main kerberos realm (COMPANY.COM) and use > normal usernames (username instead of COMPANY.COM\username). > You cannot configure samba to be part of COMPANY.COM realm because in this > case samba tells clients that they should obtain tickets like > servername$@COMPANY.COM that Your primary kerberos is likely not to grant and > also Windows clients will actually ignore this and ask the ticket from AD > kerberos anyway. So the best way in my opinion is to add a configuration > option that allows one to define additional realms that are considered > "local", that is when a user from that realm connects, the realm is not added > to the username. This is what my patch does. In addition to checking if > incoming user is from primary realm (defined in smb.conf as realm = > SOMETHING) it also checks if it is from one of the realms mentioned via > "local realms" configuration option. > Ok, this could also be achieved by Samba to Unix user mapping table (smbusers) > but it will be a massive administrative overhead if You have to maintain > those tables on all samba servers.
I think we need to do a few things here: - We should record the principal name we joined with, and only ever send that to our clients. - We should look into the 'winbind use default domain' thing before 3.0 gets out of alpha, and possibly change it to 'default domain = foo'. > > > We need patches to be against current CVS - the patch does not apply > > > cleanly at present. > > I am really sorry about this. I do not have direct access to CVS from work. I > know it's bad in the long run anyway so Im working on resolving that issue > but until it's not resolved I'm sitting kinda in darkness. > > > I've cleaned up the patch (attached, for reference), and removed the > > session-setup changes for now. > > Thanx a lot. I owe You one ;) > > > need two copies. Also, you need to be careful to copy the attribution > > I gave it some thought and I decided to duplicate the code for two reasons. > I'm just not that familiar with samba code, maybe those issues can be > resolved in a snap and in this case the duplication is of course needless. > 1. The prototype generator does not generate prototypes for functions that > return krb5_error so I would of had to add the decalration into ads.h or > wherever manually. This I think breaks the spirit of sambas' header files > since I hardly saw any function prototypes in headers and I was too much of a > wuss to change the prototype generation script, since who knows what other > prototypes will get generated if I add krb5_error to the list ;) All global functions in Samba should be correctly prototyped. You do however need to watch out for platforms that don't run kerberos - you should add a typedef from krb5_error to somthing harmless, or better still look into our ADS_ERROR stuff (partly created for exactly this kind of thing). Returning an ADS_ERROR would probably be the best solution here. > 2. At least one client program (I do not remember which) was not linked > against libads. Maybe it should be, but since it was the first one I tried to > link and it failed, I backed off on trying to make kerberos_prompter global. Well, I don't think this is sufficient reason not to do this properly. Duplicated code *will* break as two slightly different versions emerge. > > with the code. You may also add your personal copyright, if you feel > > that way inclined. > > I'm sorry again. I'ts entirely my fault. I did some cleanups in comments like > the mentioning of correct internet drafts in kpasswd code and I guess I just > blindly removed the last two lines of comments before kerberos_prompter, > without looking at the author's notice. Sorry. Also make sure you check the copyright at the top of each file. > As You could see I did not add any copyright lines of my own and I do not plan > to, since those are only minor improvements and I can give the entire > copyright up to the samba project. That is up you you, Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part