[PATCH] ADS changes for joining accounts w/o full Administrator rights

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 
> 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                                 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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030212/1d97db26/attachment.bin