[PATCH] Correctly handle !authoritative in the rpc-based auth backends

[Volker Lendecke]

On Fri, Mar 10, 2017 at 05:46:58PM +1300, Andrew Bartlett wrote:
> Just for thought: If we put an RODC on (say) a busy squid proxy, how
> would ntlm_auth go to the sam.ldb for cached passwords, but fallback to
> the real DC for others?

We have two entry points into winbind. One for ntlm_auth/smbd, and one
for netlogond. ntlm_auth/smbd right now go through the pipe, but this
is not set in stone, the main point is that netlogond has a special
entry into winbind, the irpc interface.

The flow would be:

ntlm_auth goes to winbind through the pipe. As part of the pipe
handler we ask netlogond over NCACN_UNIX. netlogond looks at dsdb,
finds that the password is cached, returns with ok/failure and
authoritative=1. If password is not cached, it returns
no_such_user/authoritative=0. Then winbind can go to the rw-dc. This
is a decision that netlogond has to make.

It is basically the same decision that netlogond has to do for domain
name and usn suffix searches. A non-cached password from this
perspective is the same as an unknown domain name.

Now what to do if netlogond has to authenticate a real client from the
network: netlogond can see which transport was used for the auth
request. When it's not local unix, then in the domain unknown /
password not cached case it asks winbind over the irpc interface. The
handler for this interface does not have the "look at local
netlogond" code.

Essentially what we need is a way for winbind to tell netlogond that
it should not ask winbind over irpc in the unkown domain / uncached
pwd case but return NO_SUCH_USER/!authoritative. How we do that is
mechanics. Different socket name for ncacn_unix, different schannel
type, metze even mentioned that a new, private dcerpc interface idl
would be possible. A new rpc interface could also enable passing more
information to netlogon for logging purposes. Client IP address for
example comes to mind.

> The other case we have to support, which is more difficult, is that
> when we are an RODC or even a full DC, we should present wrong password
> to the PDC emulator.  On the RODC this allows the bad password count to
> be updated (otherwise it can't be stored anywhere), and on an RW DC it
> is intended to give the user a second chance to authenticate with their
> new password before replication catches up.

Every logon failure against a DC via netlogon triggers a callback to
the PDC emulator done by the DC? Wow, I did not know that. Need to
think about it.

> I would really like a clear, different route for SMB or NETLOGON
> (trusted domain) authentication assistance (perhaps via IRPC from
> auth_winbind, which could be used to make the auth stack async) as for
> the ntlm_auth or wbinfo -a handler.  

If you look at one of the patches it has a comment:

                /*
                 * This is the place to asynchronously do a winbind
                 * trusted domain query
                 */

For netlogond4 I would do the irpc call asynchronously directly at
this piece of code. We don't have to make auth_check_password async to
get the trusted domains async without a nested event loop for this.

> The SMB or NETLOGON case has already checked the password locally, so
> should never talk to the auth subsystem again, it must just go directly
> to a remote DC.  The ntlm_auth case might be trying a local login. 

Please explain. For the AD DC, smbd would go to winbind even for local
authentication. If this turns out to be a performance problem, we can
introduce a call from smbd directly into netlogond ncacn_unix. On an
AD DC, we have the huge advantage to always have winbind around, and
we should make use of this.

> Thanks for the explanation and the patches.  They look really good!  It
> is great to get this dealt with properly, and I look forward to the
> final set.
> 
> I take it that "auth methods" now only controls the smb connection
> handler?

Yep. If you ask me, I would ditch the "auth methods" parameter from
smb.conf. I would really like to see the use cases that make them
necessary.

> The pdbtest patch looks wrong, we have been testing the different auth
> methods via that tool, so fixing it to 'sam' seems to be limiting what
> we are testing.

Well, it does survive autobuild.

> Regarding the last patch, my main thought is that I want the call to
> netlogon not to happen at all, unless we are servicing wbinfo or
> ntlm_auth.  I certainly appreciate that by going to netlogon the auth
> module list can be fixed, which certainly has advantages.  
> 
> When checking local passwords, I like the API call for the ability to
> pass in additional data (like the source IP of the auth I've added in
> the logging patches), but we could:
>  - use a private custom IRPC
>  - or just not worry for this particular case

See above.

My main reason for winbind to do netlogon rpc locally for sam auth is
that it reduces the number of places we call into the auth subsystem
loop. I really want to have canonical ways into the auth subsystem and
get them right and fast once and for all cases. And we have to get the
SamLogon call 100% right and fast anyway, so why not use it locally
too?

>From a progress perspective I'd call the patchset pretty much done and
ready for master. It survives autobuild and enables correct fallback
for !authoritative. Right, for ntlm_auth in the rodc case we don't look
locally, but the rodc is not a fully supported configuration yet.

The deeper reason why I want this is in rather sooner than later is
the removal of the call to is_trusted_domain() in the source3 auth
path. That call is just wrong, but to get it through autobuild I had
to cleanup the DC side of things.

Volker