Bad fallover to next authentication module?

Tom Alsberg alsbergt at
Fri Jul 9 08:23:54 GMT 2004

On Fri, Jul 09, 2004 at 01:51:38PM +1000, Andrew Bartlett wrote:
> > I can bring similiar examples, but you get the point...
> So, could we just swap the order?  That's why we add 'guest' at the
> front, not the end, of the list.

That partially solves the problem here (not so well, though - other
problems arise from it, like sam trying to save a failure count for
every user which does not exist, complaining a few times in the log
every time), but it certainly isn't a real solution.

What if we have two modules, auth_foo and auth_bar, handling disjoint
sets of users (say, two different user databases), and also doing
some accounting/access control?

So if you put auth_foo before auth_bar, when auth_foo will 
successfully authenticate but reject the user (say, with 
NT_STATUS_ACCOUNT_DISABLED), auth_bar will not even know about that 
user and thus the returned code would be the (wrong) 

And if you put auth_bar before auth_foo, when auth_bar will
successfully authenticate but reject the user (say, with 
NT_STATUS_INVALID_WORKSTATION), auth_foo will not even know about 
that user and thus the returned code would be the (wrong, again) 

There are really problems with this here, even in the case of only one
custom module and a few of the stock modules (auth_guest, auth_sam)...

I see not why, if one module decided the account is disabled (or that
the user may not log in to that workstation), the next module should 
be able to decide something different...

Right now, I can only think of "not implemented", "no such user", and
"invalid authentication token/password" (which is special, because a 
user might be able to authenticate in more than one way) as reasons 
to go on to the next module.

> For an 'account' system, it would make sense to return the first
> failure.

True, although something like NT_STATUS_IGNORE would still be good

> Andrew Bartlett

  -- Tom

  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:
DISCLAIMER:  The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.

More information about the samba-technical mailing list