From owner-freebsd-fs@freebsd.org Sat Jun 24 04:55:57 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C7D3D9795B for ; Sat, 24 Jun 2017 04:55:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB30D83326 for ; Sat, 24 Jun 2017 04:55:56 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-4b3ff70000004b5a-c2-594df0d4aaa6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 15.16.19290.4D0FD495; Sat, 24 Jun 2017 00:55:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5O4tlxU019472; Sat, 24 Jun 2017 00:55:47 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5O4th4x030710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jun 2017 00:55:46 -0400 Date: Fri, 23 Jun 2017 23:55:44 -0500 From: Benjamin Kaduk To: Matt B Cc: "freebsd-fs@freebsd.org" Subject: Re: SMBv1 Deprecation Message-ID: <20170624045543.GY39245@kduck.kaduk.org> References: <9b556cbe-f9f3-ab15-6fcd-71397d18c126@freebsd.org> <20170623104654.07e5a3e0@ernst.home> <45b0864b-680c-8fe0-f5a5-353b6373d069@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrHvlg2+kQd9lbYtjj3+yWbxvUHFg 8pjxaT6Lx85Zd9kDmKK4bFJSczLLUov07RK4Mu6vfchW8Je/4sLTB8wNjM95uhg5OSQETCRO zzrF0sXIxSEksJhJ4uH2g+wgCSGBjYwSPZekIBJXmSTuNixg62Lk4GARUJXY/8IFpIZNQEWi ofsyM4gtAhSeOe0qG4jNLGAqsbn/NhOILSwgJ/Hg1lGwmbxAyz4tfsAKMXMqi8Ss58/YIBKC EidnPmGBaNaSuPHvJRPILmYBaYnl/zhAwpwCgRJb7qwB2yUqoCzx9/A9lgmMArOQdM9C0j0L oXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M4BCV5N/BOKfB+xCjAAej Eg9vhrdvpBBrYllxZe4hRkkOJiVR3tgzPpFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgPPAAq 501JrKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeJmAsSgkWJSanlqRlplT gpBm4uAEGc4DNJzxMsjw4oLE3OLMdIj8KUZFKXHeXe+BEgIgiYzSPLheUAqRyN5f84pRHOgV YV5rkCoeYPqB634FNJgJaPCMNT4gg0sSEVJSDYzmtf+ie5czvr5bftLr5O/DmzctX2QhqC4n eFx+yfkbL1TenOEWibC8fWVzCq/NkiXt0YFLl5//oRW7cU9Hy4sAJePbmy/svXvP4Ln+o1dr jJQ+a85QefNlm/bPkwo8LZ1Vy/Su9nOk3nkxlZXtkJ7kC6ndl8SN3xSX5xc4uv6p6ry9LcJw 40RTJZbijERDLeai4kQAnSaWivwCAAA= X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 04:55:57 -0000 On Fri, Jun 23, 2017 at 09:42:30AM -0400, Matt B wrote: > I am currently using the Win implementation of NFS 4.1 to provide share > access in the interim. NFS does work, and it works well, but due to spread > out local service accounts on the BSD systems, permissions has become a bit > of a challenge. I would have to set up idmapping in the Win environment and > then configure all shares with these new perms that Windows can understand. > Right now, when the scripts and programs run, they plop down files/folders > that have the perms of the user running the script/program. Windows loses > its mind and I have to force grab ownership of the files and folders and > re-inherit perms from the parent directory. Windows doesn't like that and > thus it is a slow process to cascade down the NTFS ACLs. The other prong to > the NFS approach is Kerberos. I would have to generate keytabs for all of > these systems, some of them live in a DMZ and navigate to the shares > through a firewall, which means I need to open up more ports from the DMZ > back to the core for Kerberos to work. Not something I want to do. What follows is a digression from the core point of the thread, but as one of the (upstream) developers for security/krb5, I would really like to know more about why you are reluctant ot open up ports for Kerberos traffic. Of course there is the sheer mundane work of actually changing the configuration to effect the opening of the ports, but it sounds like perhaps you are unhappy for some deeper reason, like perhaps a desire to reduce the overall number of open ports or a particular distrust of Kerberos. With respect to the latter, the Kerberos protocol is explicitly designed to run over a hostile network, and both the Heimdal and MIT implementations are mature projects that have many production deployments exposed to the internet. From my (presumably biased) perspective, switching to Kerberos+NFS would be a security win over SMBv1, even with the extra open ports. Thanks, Ben