Project

General

Profile

Feature #1122

smbsrv should use SPNEGO (inbound authentication)

Added by Gordon Ross over 8 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2011-06-17
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

When smbsrv accepts connections from clients (which are
typically Windows clients) it does not offer any of the
modern SPNEGO (a.k.a. "extended security") mechanisms
for authentication. This can cause some clients to refuse
to talk to this server unless policy adjustments are made.


Related issues

Related to illumos gate - Bug #1087: Unable to connect to the CIFS server using \\servername.fqdnClosed2011-06-01

Actions

History

#2

Updated by Gordon Ross about 4 years ago

Some design notes:

The (in-kernel) smbsrv module, by design, knows very little about authentication.
The smbsrv kmod handles each SMB "session setup" request as follows:
- unwrapping the "security blob",
- write it into the "smbauth" named pipe
- wait for a and read a response "blob"
- send the SMB response with that blob.

All the interesting work happens in the smbd_authsvc. In there, we:
- receive a "security blob" from the kernel module
- unwrap the SPNEGO wrapper,
- figure out what security flavor we're using and pass the unwrapped stuff to one of the "back ends".
- add an SPNEGO wrapper over the response from the "back end" and send that back down the pipe.

Each such conversation happens on a separate pipe instance,
each such instance serviced by a single thread. The smbauth pipe
serializes the the authentication converstaion, which in the smbsrv
kmod is handled by potentially many threads (taskq workers), but in
the smbd_authsvc each conversation is handled in just one thread.

There are three "back end" modules selectable by the SPNEGO
mechanism (sort-of - "raw" NTLMSSP "cheats" here).
1: raw NTLMSSP (NTLMSSP protocol without an SPNEGO wrapper)
2: NTLMSSP (normal NTLMSSP three message exchange)
3: Kerberos (essentially gsssapi)

The Kerberos back-end is the tricky one, as in this back end, we
have to get the authorization information out of the Kerberos ticket
used for authentication. That authorization data is RPC encoded,
carried in a KRB5_AUTHDATA_IF_RELEVANT blob in the ticket.
Some updates in the Kerberos code are required to correctly
dig that authorization data out of the ticket.

#3

Updated by Electric Monk almost 4 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit 12b65585e720714b31036daaa2b30eb76014048e

commit  12b65585e720714b31036daaa2b30eb76014048e
Author: Gordon Ross <gwr@nexenta.com>
Date:   2015-10-26T14:16:22.000Z

    1122 smbsrv should use SPNEGO (inbound authentication)
    Portions contributed by: Matt Barden <Matt.Barden@nexenta.com>
    Portions contributed by: Kevin Crowe <kevin.crowe@nexenta.com>
    Portions contributed by: Alek Pinchuk <alek@nexenta.com>
    Reviewed by: Bayard Bell <bayard.bell@nexenta.com>
    Reviewed by: Dan Fields <dan.fields@nexenta.com>
    Reviewed by: Kevin Crowe <kevin.crowe@nexenta.com>
    Reviewed by: Matt Barden <Matt.Barden@nexenta.com>
    Approved by: Robert Mustacchi <rm@joyent.com>

Also available in: Atom PDF