Re: [OmniOS-discuss] cifs smb 2.1 errors when using windows 10 backup tool

[Gordon Ross]

Interesting finding re. VHD support needing resiliency support in SMB 2.1.
Thanks for the KB article: https://support.microsoft.com/en-us/kb/2920193

We have resiliency support in NexentaStor 5.0 (shameless plug:)
https://nexenta.com/products/nexentastor
We should work on upstreaming that code soon.


On Wed, Oct 12, 2016 at 8:54 AM, Natxo Asenjo  wrote:
> hi,
>
> There is  a w10 system at the home and it's a bit critical for the wife ;-),
> so I want to have this up and running asap if some kind of trouble happens
> with it.
>
> Anyway, this windows 10 OS has a backup tool that allows you to dump an
> image to a network share using cifs, obviously.
>
> So I have a zfs file system, shared it for cifs, set the permissions for the
> share. Start the backup, and it will fail consistently when it has reached
> 57%.
>
> After much searching, I found this:
> https://social.technet.microsoft.com/Forums/windows/en-US/c2032e37-ebe9-4221-9d37-5525fcdaae19/windows-8-backup-win7-file-recovery-system-image-creation-to-nas-device-fails-with-error?forum=w8itprogeneral
>
> And yes, after:
>
> # sharectl set -p max_protocol=1 smb
>
> and restarting the cifs service, now the backup is running correctly (97%
> and counting).
>
> Apparently it has to do with 'resilency support', whatever that may be:
>
> https://support.microsoft.com/en-us/kb/2920193
>
> Which is a shame, because now the cifs host is limited to smb 1.5 instead of
> 2.1 (but at least it works).
>
> Hopefully I spare somebody some unnecessary pain with this info. And it
> would be awesome if this 'resiliciency support' made it to the cifs server
> in a next version ;-)
>
> Thanks!
>
> --
> Groeten,
> natxo
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LDAP external auth for CIFS service

[Gordon Ross]

I should also mention: The other solution for the problem of
"centralized Windows accounts in a Unix shop" is to run a Samba AD
server somewhere, and point your other clients that want LDAP to that.
That way you can just tell the Windows clients to use domain accounts.


On Fri, Aug 26, 2016 at 12:14 PM, Gordon Ross <gordon.w.r...@gmail.com> wrote:
> Sorry for the delay -- been quite busy.  I do look at this list, but
> only occasionally.
>
> The way LDAP auth. works in SMB servers like Samba is that the server
> allows SMB clients (i.e. Windows) to logon using accounts that work
> the same as "local" accounts (what Windows would call "local"
> accounts, meaning they are NOT domain accounts).  However, while the
> SMB clients think these are "local" accounts, the server uses
> something akin to the name service switch functions for LDAP to get
> the details of these accounts needed for SMB.
>
> Such accounts are not really "local", but are defined in your LDAP
> service.  The SMB server needs a way to get some Windows-specific
> details about those accounts from LDAP, including the "NT password
> hash" (for authentication) and some other Windows-ish details.
>
> The current LDAP libraries in illumos are sufficient for this (though
> for other reasons, it would be nice if we could update them some day).
> What's missing is some "glue" in the name service switch design, and
> perhaps a new lookup method for the "NT password hash", which is
> similar conceptually to the "shadow password" back-end functions.  One
> can probably pretty much copy/paste the LDAP back-end function for
> shadow passwd. to make the "ntpass" or whatever we call this new
> nsswitch method.  The current /var/smb/smbpasswd stuff, currently
> accessed directly from libsmb should really go through the "files"
> back-end, and we might want to consider taking the opportunity to
> change the format of that file (though that means doing some format
> conversion work during upgrades).  Once a new nsswitch method for
> "ntpass" (or whatever) is in place, the parts of this in the SMB
> server (mostly libsmb) are fairly easy.
>
> Requests for this feature have come up from time to time over the last
> few years, but (so far) not from anyone who wanted it badly enough to
> pay for the work.
>
> Gordon
>
>
> On Thu, Aug 18, 2016 at 11:15 AM, Dan McDonald <dan...@omniti.com> wrote:
>>
>>> On Aug 18, 2016, at 11:04 AM, Mick Burns <bmx1...@gmail.com> wrote:
>>>
>>> *bump*
>>> anyone ?
>>
>> I'm going to forward your note to someone I know who works on CIFS.  He's 
>> not on this list.
>>
>> Stay tuned,
>> Dan
>>
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LDAP external auth for CIFS service

[Gordon Ross]

Sorry for the delay -- been quite busy.  I do look at this list, but
only occasionally.

The way LDAP auth. works in SMB servers like Samba is that the server
allows SMB clients (i.e. Windows) to logon using accounts that work
the same as "local" accounts (what Windows would call "local"
accounts, meaning they are NOT domain accounts).  However, while the
SMB clients think these are "local" accounts, the server uses
something akin to the name service switch functions for LDAP to get
the details of these accounts needed for SMB.

Such accounts are not really "local", but are defined in your LDAP
service.  The SMB server needs a way to get some Windows-specific
details about those accounts from LDAP, including the "NT password
hash" (for authentication) and some other Windows-ish details.

The current LDAP libraries in illumos are sufficient for this (though
for other reasons, it would be nice if we could update them some day).
What's missing is some "glue" in the name service switch design, and
perhaps a new lookup method for the "NT password hash", which is
similar conceptually to the "shadow password" back-end functions.  One
can probably pretty much copy/paste the LDAP back-end function for
shadow passwd. to make the "ntpass" or whatever we call this new
nsswitch method.  The current /var/smb/smbpasswd stuff, currently
accessed directly from libsmb should really go through the "files"
back-end, and we might want to consider taking the opportunity to
change the format of that file (though that means doing some format
conversion work during upgrades).  Once a new nsswitch method for
"ntpass" (or whatever) is in place, the parts of this in the SMB
server (mostly libsmb) are fairly easy.

Requests for this feature have come up from time to time over the last
few years, but (so far) not from anyone who wanted it badly enough to
pay for the work.

Gordon


On Thu, Aug 18, 2016 at 11:15 AM, Dan McDonald  wrote:
>
>> On Aug 18, 2016, at 11:04 AM, Mick Burns  wrote:
>>
>> *bump*
>> anyone ?
>
> I'm going to forward your note to someone I know who works on CIFS.  He's not 
> on this list.
>
> Stay tuned,
> Dan
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Auditing CIFS shares

[Gordon Ross]

Auditing support for SMB/CIFS access is incomplete.  The ZFS ACL
support for Auditing entries appears to be complete, but we're missing
the "hooks" that should be in the access control code paths (both
success and failure cases), and some "plumbing" to get the audit
events into the audit log in some useful form.

If anyone would like to work on this project, please reach out to me directly.

Thanks,
Gordon

On Mon, Aug 8, 2016 at 6:33 AM, Lawrence Giam
 wrote:
> Hi All,
>
> I am wondering if any of you folks does auditing of CIFS shares (eg. adding
> files, deleting files, moving files by domain users) running on OmniOS
> server serving SMB to Windows users in a domain environment?
>
> On a windows fileserver running Windows OS, this can be achieved by using
> this method
> https://mizitechinfo.wordpress.com/2014/07/01/folder-auditing-in-windows-server-2012-r2/
>
> Can anyone tell me know how do they do it on Openillumos? What software do
> they use and how they implement it?
>
> I am looking at open source solution but if that is not possible then I am
> willing to explore "paid" solution. Any recommendation?
>
> Thanks & Regards.
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Python and Kerberos libraries

[Gordon Ross]

You could also tweak the krb5-config to support what this package wants.
It's just a script...

On Wed, Jun 8, 2016 at 10:45 PM, Paul B. Henson  wrote:
>> From: Dan McDonald
>> Sent: Wednesday, June 08, 2016 9:45 AM
>>
>> > extra_link_args = check_krb5_config("--libs", "gssapi")
>>
>> I wonder if it's assuming Linux commands for some things?
>
> No, it's trying to use krb5-config options available under MIT kerberos that
> don't exist under illumos kerberos. You will note the illumos variant, shown
> second, is a bit sparse 8-/. I will say for the third time and then give up,
> he should probably just install from pkgsrc :).
>
> $ krb5-config --help
> Usage: /usr/bin/krb5-config [OPTIONS] [LIBRARIES]
> Options:
> [--help]  Help
> [--all]   Display version, vendor, and various values
> [--version]   Version information
> [--vendor]Vendor information
> [--prefix]Kerberos installed prefix
> [--exec-prefix]   Kerberos installed exec_prefix
> [--defccname] Show built-in default ccache name
> [--defktname] Show built-in default keytab name
> [--defcktname]Show built-in default client keytab name
> [--cflags]Compile time CFLAGS
> [--libs]  List libraries required to link [LIBRARIES]
> Libraries:
> krb5  Kerberos 5 application
> gssapiGSSAPI application with Kerberos 5 bindings
> gssrpcGSSAPI RPC application
> kadm-client   Kadmin client
> kadm-server   Kadmin server
> kdb   Application that accesses the kerberos database
>
>
> $ krb5-config --help
> Usage: /usr/bin/krb5-config [OPTIONS] [LIBRARIES]
> Options:
> [--help]  Help
> [--all]   Display version, vendor, and various values
> [--version]   Version information
> [--vendor]Vendor information
> [--prefix]Kerberos installed prefix
> [--exec-prefix]   Kerberos installed exec_prefix
> [--cflags]Compile time CFLAGS
> [--libs]  List libraries required to link [LIBRARIES]
> Libraries:
> krb5  Kerberos 5 application
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] cifs connectivity to DC gets lost

[Gordon Ross]

On Tue, May 24, 2016 at 6:52 PM, Geoff Nordli  wrote:
> On 16-05-24 03:41 PM, Geoff Nordli wrote:
>>
>> I just upgraded a server from OI to OmniOS-r151018.
>>
>> I am having a few issues with the connectivity to AD.
>>
>> I was able to join the domain no problem, but then the domain is getting
>> disconnected and after several hours I need to join the domain again.
>>
>> May 24 15:25:12 stor1 idmap[472]: [ID 849457 daemon.error]   >
>> :::172.16.100.10 rc=0
>> May 24 15:25:12 stor1 idmap[472]: [ID 778215 daemon.error] DC name
>> dc1.domain.ca != 172.16.100.10?
>> May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration
>> changed
>> May 24 15:25:12 stor1 idmap[472]: [ID 452651 daemon.error] adutils:
>> ldap_lookup_init failed
>> May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration
>> changed
>> May 24 15:25:13 stor1 smbd[15085]: [ID 511178 daemon.notice] Failed to
>> establish NETLOGON credential chain with DC: 172.16.100.10 (UNSUCCESSFUL)
>> May 24 15:25:13 stor1 smbd[15085]: [ID 714496 daemon.notice] The machine
>> account information on the domain controller does not match the local
>> storage.
>> May 24 15:25:13 stor1 smbd[15085]: [ID 777225 daemon.notice] To correct
>> this, use 'smbadm join'
>> May 24 15:25:13 stor1 smbd[15085]: [ID 527292 daemon.notice] failed to
>> establish NETLOGON credential chain
>> May 24 15:25:13 stor1 smbd[15085]: [ID 505820 daemon.notice]  with server
>> 172.16.100.10 for domain domain.ca (UNSUCCESSFUL)
>>
>> time is synced between the two machines.
>>
>> When I issue the join, I am able to get things connected again.
>>
>> any thoughts?
>>
>
> Pulled from the idmap log:
>
> adutils: ldap_lookup_init, host 172.16.100.10
> LDAP: 172.16.100.10:3268: Local error
> 172.16.100.10: Local error
> 172.16.100.10: additional info: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (Server
> not found in Kerberos database)
> adutils: ldap_lookup_init failed
> unable to discover Domains in the Forest

You figured it out.  Kerberos can only authenticate with a named host,
and the log message above say that idmap/libadutils is trying to use
ldap+gssapi+kerberos to authenticate with a DC specified only by IP
address.
That's never going to work...
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Dfs root with in-kernel SMB server?

[Gordon Ross]

DFS root support is there (it came out before the "lawnmower incident").
Should work the same as described in the S11 docs.

On Tue, Apr 26, 2016 at 10:53 PM, Paul B. Henson  wrote:
> I was curious if it is possible to set up a share that acts as a Windows Dfs
> root using the illumos in-kernel SMB server, similar to what samba allows
> you to do. I found some less than helpful Solaris 11 documentation that
> mentioned it in passing, but I don't know if that's a pre or post lawnmower
> breakup feature, and it also said something about having to manage it from a
> Windows server with Windows tools, which would be a no go from my
> perspective 8-/. With the release of SMB2 support in 018, we are looking at
> migrating our filesharing services away from samba, but we also use it for
> Dfs root purposes.
>
> Thanks.
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] AD integration problems

[Gordon Ross]

I haven't heard of anyone using autohome shares in a while, so it's
possible that functionality regressed.
As usual, I recommend grabbing a network trace (port 445) and dtrace
outputs from both /usr/lib/smbsrv/dtrace/smbsrv.d and
/usr/lib/smbsrv/dtrace/smbd-all.d  -- all running while you reproduce
the problem.
If you need help figuring out what those tell you, put them up
somewhere we can see.

Thanks,
Gordon


On Wed, May 18, 2016 at 4:59 AM, OmniOS-discuss  wrote:
> Hi,
>
>
>
> after upgrading from Windows Server 2008 to 2012 R2 Standard I have some
> more or less strange problems where I cannot find a solution.
>
>
>
> My environment is:
>
> Two Windows DC’s (Windows Server 2012 R2) one on local site, one on remote
> site
>
> Two (productive) storage boxes (one for cifs shares and iscsi the other one
> as read only backup for the cifs shares)
>
> smbautohome with wildcard rule on both boxes
>
> Windows 8.1 client systems
>
>
>
> After upgrading to Windows 2012 I could not access the automatically created
> and still visible user shares anymore (network error – path not found)
>
> After upgrading one storage box to  „omnios-master-5409e8f April 2016“ the
> share is not created anymore and of course still not accessible.
>
>
>
> Another problem is that I’m unable to mount iso-files directly from a cifs
> share on my windows workstation which was possible before without any
> problems.
>
> The German error message is “Problem beim Bereitstellen der Datei” which
> means “ Sorry, there was a problem mounting the file”
>
>
>
> Any help is welcome – no idea anymore
>
>
>
> Regards
>
> Robert
>
>
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> E.F.A. Project, and is believed to be clean.
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

[Gordon Ross]

On Thu, Apr 21, 2016 at 9:53 PM, Gordon Ross <gordon.w.r...@gmail.com> wrote:
> I'm not sure how anyone ever gets access when your ACL has this ACE:
> everyone@:rwxpdDaARWcCos:fd-:deny
>
> Every long has the group ...

Hah!   Spell checkers - Gr!   That should have read:

Every logon  has the group...
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

[Gordon Ross]

I'm not sure how anyone ever gets access when your ACL has this ACE:
everyone@:rwxpdDaARWcCos:fd-:deny

Every long has the group "everyone" as a member, therefore that ACE
will match every logon.  The ace also lists every possible permission,
so nothing should get through, no matter what allow ACEs might also
exist.

One thing to be aware of is that ZFS (and Unix in general) checks
Execute access when you try to "traverse" through a directory (path
name resolution).  If you're copying ACLs from a Windows server, you
may need to add some ACEs at various levels in your file hierarchy to
grant execute to whatever users and/or groups should be able to
traverse.
(The easiest way would be: chmod A+everyone@:x:fd:allow)

Windows servers normally run with a special privilege that makes the
SMB server threads exempt from traverse permission checking, for
reasons of efficiency.

On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi  wrote:
> I updated as indicated in the guide and to do that I had to uninstall some
> packages:
>
> serf@1.3.8,5.11-0.151014:20151015T214958Z
> apr-util@1.4.1,5.11-0.151014:20150508T204811Z
> apr@1.5.1,5.11-0.151014:20150529T175834Z
> uuid@1.41.14,5.11-0.151014:20150508T153803Z
>
> After reboot I got two main issues.
>
> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I usually did in
> the past, both for SMB, local webserver/services, ... but I can still access
> the box when I use the plain IP.
>
> OmniOS-Xeon:~ olaf$ cat /etc/nodename
> OmniOS-Xeon
>
>
> 2) I cannot access one specific SMB share ("olaf") that was working
> perfectly before the update. Using the IP of the machine allows me to access
> the other shares, but not this one. It was also the one with the most
> restrictive access ACLs, but they look fine to me.
>
> OmniOS-Xeon:~ olaf$ sharemgr show
> ...
> zfs
> zfs/tank/home/olaf
>   /tank/home/olaf
> [and more shares, all working]
>
> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
> total 34
> drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: temporar share not found
> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: olaf share not found
> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>
> As you can see, the last letter of the share name in /var/adm/messages gets
> cut for the share "temporary", but not for my own share "olaf". However, my
> own share is neither visible nor accessible, while the other ones are.
>
> Has anything changed about permissions with SMB2?
>
> Thanks
> Olaf
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] cifs anonymous troubles

[Gordon Ross]

Hi Dan,

I can take a guess what this might be about.

There were several bugs fixed as part of the "extended security" work:
1122 smbsrv should use SPNEGO (inbound authentication)

One of those was that we used to give a client a "guest" logon
if they tried to logon to SMB with _any_ unrecognized account.
No, that was never a good idea. Not only was it questionable
for security, but it confused issues about failed logon.  Example:
Windows user does NOT get the expected pop-up dialog asking
for new credentials when they try to connect to a share using
an invalid user name.  Instead, they would get connected,
but would fail to have access to anything in the share.

So with that bug fixed, one can logon as "guest" only if:
(1) you actually ask for guest in your logon request,
(2) a local Unix account named "guest" exists, and
(3) the guest account is enabled for SMB

Therefore, if you were using guest access before 1122 was fixed,
(and were depending on accidental guest access working),
you'll need to do the following to re-enable guest access:

useradd (options] guest
smbadm enable-user guest

The guest account password is ignored by SMB, so
all that matters to SMB is whether that account is
marked as enabled in /var/smb/smbpasswd

To keep Unix users from using guest for login, you can
set the Unix password hash to something invalid, etc.

On Fri, Apr 15, 2016 at 4:05 PM, Natxo Asenjo  wrote:
> hi,
>
> trying to set up an anonymous share on workgroup mode  I do not get it
> working.
>
> I have a dataset tank/test with these sharesmb properties:
>
> zfs get sharesmb tank/testshare
> NAMEPROPERTY  VALUE   SOURCE
> tank/testshare  sharesmb  name=test,guestok=true  local
>
> These are the permissions on that path:
>
> # /usr/bin/ls -Vd /tank/testshare/
> drwxrwxrwx+ 14 root root  14 Sep 11  2015 /tank/testshare/
>   everyone@:rwxpdDaARWcCos:fd-:allow
>
> Both using a windows client (win 2012r2) as a linux smbclient (fedora 23),
> both quite modern, I cannot access the share:
>
> Linux smbclient:
> $ smbclient -U " " -L //192.168.0.172 -N
> Anonymous login successful
> Domain=[WORKGROUP] OS=[SunOS 5.11 omnios-r151018-ae314] Server=[Native SMB
> service]
>
> Sharename   Type  Comment
> -     ---
> c$  Disk  Default Share
>
> testDisk
> Connection to 192.168.0.172 failed (Error NT_STATUS_CONNECTION_REFUSED)
> NetBIOS over TCP disabled -- no workgroup available
>
>
> Windows client:
> C:\Users\Administrator>net view \\192.168.0.172
> System error 5 has occurred.
>
> Access is denied.
>
>
> Using a local user works, with smb2 ;-)
>
> Any one success with guestok=true and cifs?
>
> --
> Groeten,
> natxo
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Badlock -- illumos Native SMB server is not affected

[Gordon Ross]

Some of you may have heard about the vulnerability in SMB that affects
Windows and Samba systems, disclosed on April 12 and named "BadLock"
(www.badlock.org).
The native SMB service in Illumos is not subject to the Badlock vulnerabilities.

The main issues discovered by badlock.org relate to downgrade
opportunities using "man in the middle" attacks where DCERPC traffic
is supported over "plain TCP". The Native SMB server in illumos does
not support DCERPC over "plain TCP" (electing to support  DCERPC only
over "SMB named pipes") and is therefore not affected.

For more detailed information about the CVEs, refer to this wiki page:
http://wiki.illumos.org/display/illumos/Response+to+the+badlock.org+CVEs
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [discuss] disable NetBIOS-Over-TCP for smb server

[Gordon Ross]

At the moment, no, there's no way to disable the NetBIOS listener.  We
have a knob for that in updated SMB server code we're developing for
NexentaStor, so once that makes its way to illumos you'll have it.


On Fri, Jan 3, 2014 at 7:59 PM, Paul B. Henson hen...@acm.org wrote:
 Is there any way to disable netbios for the in-kernel smb server? Per
 the man page:

  The smbd  daemon  is  automatically  invoked  by  using  the
  sharemgr  command over all available transports. By default,
  smbd starts over the NetBIOS-Over-TCP (NBT)  and  TCP  tran-
  sports.

  When smbd is started over NBT, the  following  services  are
  started:

  oThe NetBIOS name service is  started  on  UDP  port
   137.

  oThe NetBIOS datagram service is started on UDP port
   138.

  oThe NetBIOS session service is started on TCP  port
   139.

  When the smbd daemon is started over TCP, the  CIFS  service
  is started on TCP port 445.

 If this is the default, it kinda implies you could change it, but I
 haven't been able to figure out how. I don't really want to run NetBIOS,
 I just want to listen on port 445.

 Thanks...



 ---
 illumos-discuss
 Archives: https://www.listbox.com/member/archive/182180/=now
 RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175550-721fcbaf
 Modify Your Subscription: 
 https://www.listbox.com/member/?member_id=21175550id_secret=21175550-eae52450
 Powered by Listbox: http://www.listbox.com



-- 
Gordon Ross g...@nexenta.com
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss