[PATCH] ADS changes for joining accounts w/o full Administrator
Antti.Andreimann at mail.ee
Tue Feb 11 18:55:49 GMT 2003
Ü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.
> > 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 ;)
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.
> 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.
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.
Using Linux since 1993
Member of ELUG since 29.01.2000
More information about the samba-technical