[PATCH] ADS changes for joining accounts w/o full Administrator
abartlet at samba.org
Tue Feb 11 22:16:54 GMT 2003
On Wed, 2003-02-12 at 05:55, Antti Andreimann wrote:
> Ühel kenal päeval (teisipäev, 11. veebruar 2003 13:39) kirjutas Andrew
> > > 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
> 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
> 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 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030212/1d97db26/attachment.bin
More information about the samba-technical