From owner-freebsd-fs@freebsd.org Sat Jun 24 14:35:50 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 931CDD9FBE2 for ; Sat, 24 Jun 2017 14:35:50 +0000 (UTC) (envelope-from theunusualmatt@gmail.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8F26E77D for ; Sat, 24 Jun 2017 14:35:50 +0000 (UTC) (envelope-from theunusualmatt@gmail.com) Received: by mail-yb0-x22c.google.com with SMTP id b81so908200yba.2 for ; Sat, 24 Jun 2017 07:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Iopf1wB6JWwIGY7lG58PQGKNVRHylq20reFHVEyFSsY=; b=kbvzN+FKZoKppRVAIWa3q/ZKeztpvAabBZBCn/JZdbbMROVE8M5pDXa7bcOwxlUPsN eSPTNm/XhrRdwC2f3hLebdO0lbLvoHm9ir2Pb99EW/Gp/PHvLUvcE4WnLhuIQRWgJOmi Q1QNorSsdz2VmVe2IzFYq+2bnRAr5VQa90MqvonNgtARzpEWVHDwfunZ2EkyV0uyKD38 SG5C4ywgU8Ox2KE08AE9B7UXVoQ/xSctCiJgL/91U3UN8HbDU6k2Mo+A8wpld0XDKm/8 bLzEUIaoqTUPgK10nIl5KB5AA5r2nUOK/PSearZASeLPrp0GPiTGf6GYH0hslUm+F3cK uq2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Iopf1wB6JWwIGY7lG58PQGKNVRHylq20reFHVEyFSsY=; b=rUtvLo6Ayi90Y9OII+SvEOFoy6Q1nI+ycu5OB+mueJLUVrlWTaYXsiywsFPcqcQBfA 61rKSoD5VStIgLwBS5YfWKgLvsPS6IVlr+6UmAmntyo9L8GcjzBLNGlYxJj1nzTHxZu4 t8MVsCNtGFP08/xwWvpiUQJCjCdQnO7kmNqWKl5zAcVaiRqrmTihz3+UTKMHuI81IMww b20Pn07kloNWHE35JGN9pzVpMGrKuLnKxsvG3CKTzyTR3OGAiFK2tJmhnLJCbQCMtsjx yTvMxPh0WDMPw43z/Kl22iR9JqKQyJi9QCWofchWEqjOPkbfkhSFLgJD0SJbM1+oGH+u 6b4Q== X-Gm-Message-State: AKS2vOwKvTQL+aX7X3djc0OBKpGzZXT0BeTeBqS5nV4ub+UyMs+fny9x 3FZ3cEJE4Q+2B6zIw/EZ9GW2dUJxcA== X-Received: by 10.37.43.199 with SMTP id r190mr9597134ybr.118.1498314949323; Sat, 24 Jun 2017 07:35:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.103.70 with HTTP; Sat, 24 Jun 2017 07:35:48 -0700 (PDT) In-Reply-To: <20170624045543.GY39245@kduck.kaduk.org> References: <9b556cbe-f9f3-ab15-6fcd-71397d18c126@freebsd.org> <20170623104654.07e5a3e0@ernst.home> <45b0864b-680c-8fe0-f5a5-353b6373d069@freebsd.org> <20170624045543.GY39245@kduck.kaduk.org> From: Matt B Date: Sat, 24 Jun 2017 10:35:48 -0400 Message-ID: Subject: Re: SMBv1 Deprecation To: Benjamin Kaduk Cc: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 14:35:50 -0000 It is about decreasing the attack surface. I certainly trust the level of security and validation the Kerberos provides. The physical act of going into the security gateways and opening ports is quite the menial task. The main problem I have with the implementation is the deployment of keytabs to the physical systems, which is a bit of a process to actually get the key over there, then configuring idmapping in Windows, which brings another round of issues regarding AD structure and permissions on the shares. More ports open between the DMZ and the core is just one more negative reason (to me) to not go forward with an NFS Kerberos deployment. Kerberos and NFS are definitely a great combination when the configuration suites the situation. I am looking into figuring out how to just implement SMBv2 for BSD as I believe that is the best solution for my network architecture. On Sat, Jun 24, 2017 at 12:55 AM, Benjamin Kaduk wrote: > 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 >