[PATCH] Implement simple means of supporting pam_winbind UPN
logins.
simo
idra at samba.org
Sat Jun 30 23:13:55 GMT 2007
On Sat, 2007-06-30 at 17:50 -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Simo,
>
> > Ok, but in this case, why don't you simply pass the
> > unresolved name to winbind_auth_request() and let winbindd
> > resolve internally the name? I am not a fan of doing
> > stuff on the "client" side of the fence.
>
> Much bigger change. See Gunther's original patch.
Fair enough.
> What is your technical objection to the upn->sid->name
> conversion? Not "being a fan" is too vague.
I am not fond of the fact that we can retrieve the SID from the client
side at all, but I need to elaborate more to explain that so let just
put this discussion aside for now.
> IMO the client side is the perfect place to do much of
> this stuff and if "winbind use default domain" had been in
> the client code to begin with, winbindd itself would have
> had many fewer bugs wrt to name translation.
Well that may be true, or perhaps just translating immediately at the
entry/exit point would have been ok as well. I think the real problem
was that we let the untranslated name leak everywhere.
> Also doing combination operations like this prevent the
> winbindd API from inheriting esoteric calls. Why add a
> new call to the API when you can write a wrapper around
> to existing calls. Given that pam_winbind is not
> performance critical, as long as we don't introduce
> inappropriate delays, this should be fine.
It depends on the context in which you use pam authentication.
If you use it only for system/ssh login it is probably ok, while on a
busy POP/SMTP email server (or apache with pam_auth) with a few
thousands of users the pam_winbind performances may be much more
critical.
That said, the reduction in the number of lines of code, may still be a
good enough reason to prefer your patch over other approaches.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org
More information about the samba-technical
mailing list