[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