Greetings samba-users another "design issue" here I run 2 servers in a very closed environment, basically it is only one fileserver, the 2nd does snapshots and backups etc That server is configured as standalone and knows only ~6 local users. No ADS, no domain membership. Think of a separated department in a company which has to be as disconnected from the company's IT as possible. The users there wrote themselves a batch-script that connects their network shares, it contains cleartext passwords ... bad Now they had a security audit and we should get rid of that batch file, sure. I consider setting up an ADC for that one server overkill. And I wonder where they would keep their passwords then, it wouldn't change that. And connecting to the company's AD isn't wanted because that would allow the "upstream IT" access to the protected server. How do other admins solve that? I'd appreciate any clever suggestions or examples. greets, Stefan
Hi Stefan! On 10.09.2018 08:35, Stefan G. Weichinger via samba wrote:> > Greetings samba-users > > another "design issue" here > > I run 2 servers in a very closed environment, basically it is only one > fileserver, the 2nd does snapshots and backups etc > > That server is configured as standalone and knows only ~6 local users. > No ADS, no domain membership.AD sounds also senseful for this.> > Think of a separated department in a company which has to be as > disconnected from the company's IT as possible.For this, you could take roaming profiles for offline use. Here the files were copied to the local machine cache and used, if no (or only a slow) network connection is available. Alternativly, you could use a "RODC" (Read only Domain Controller, a mirror of the AD) locally in the another office. As a third solution, you could use the RODC only for authorization, not for file server services, but normally a slow connection in the desert should be sufficient for authorization purposes.> The users there wrote themselves a batch-script that connects their > network shares, it contains cleartext passwords ... badYes, really bad!> > Now they had a security audit and we should get rid of that batch > file, sure.Good decision.> > I consider setting up an ADC for that one server overkill. And I > wonder where they would keep their passwords then, it wouldn't change > that.A small explanation for this question: If a Windows-machine is authorized on an AD, you can configure the network-fileserver without passwords. With the login password, the clients will get a so called "granting ticket" from the AD, which can be used to mount a network directory to the machines without additional password entries, all secure encoded.> And connecting to the company's AD isn't wanted because that would > allow the "upstream IT" access to the protected server.This isnt really clear to me. What exactly is the apprehension?> > How do other admins solve that? > I'd appreciate any clever suggestions or examples.Hth, Oliver
On Mon, 10 Sep 2018 08:35:38 +0200 "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote:> > Greetings samba-users > > another "design issue" here > > I run 2 servers in a very closed environment, basically it is only > one fileserver, the 2nd does snapshots and backups etc > > That server is configured as standalone and knows only ~6 local > users. No ADS, no domain membership. > > Think of a separated department in a company which has to be as > disconnected from the company's IT as possible. > > The users there wrote themselves a batch-script that connects their > network shares, it contains cleartext passwords ... bad > > Now they had a security audit and we should get rid of that batch > file, sure. > > I consider setting up an ADC for that one server overkill. And I > wonder where they would keep their passwords then, it wouldn't change > that. > > And connecting to the company's AD isn't wanted because that would > allow the "upstream IT" access to the protected server. > > How do other admins solve that? > I'd appreciate any clever suggestions or examples. > > greets, Stefan >Hi Stefan, I would set up a small AD domain, one DC, and turn the two original servers into Unix domain members and then use kerberos. I cannot think of any other way of not using passwords. Rowland
Am 10.09.18 um 11:12 schrieb Rowland Penny via samba:> Hi Stefan, I would set up a small AD domain, one DC, and turn the two > original servers into Unix domain members and then use kerberos. > > I cannot think of any other way of not using passwords.I won't get a third server for doing so. It could be a VM or container, though. For now we discussed simply editing the batchfile to not contain the passwords and the users have to enter their (strong) pw at connection time. Maybe set "/persistent: no" as well. This would improve things, no readable passwords on the client anymore.
Am 10.09.18 um 10:06 schrieb Oliver Rath via samba:> For this, you could take roaming profiles for offline use. Here the > files were copied to the local machine cache and used, if no (or only a > slow) network connection is available. Alternativly, you could use a > "RODC" (Read only Domain Controller, a mirror of the AD) locally in the > another office. As a third solution, you could use the RODC only for > authorization, not for file server services, but normally a slow > connection in the desert should be sufficient for authorization purposes.I am not sure if I understand completely or if I described the requirements accordingly. The department uses Thin Clients to access (a) the company networks/servers and (b) its own protected LAN (behind a firewall run by me) with some specific servers and VMs. So the thinclients are primarily domain members in the domain "BigFatCompany" and would have to be members in the domain "ProtectedServers" as well. I think that second ADS complicates everything, at least in relation to the rather small benefits. We don't want to set up any trust between two domains or so. We don't trust that bigger environment ;-)>> The users there wrote themselves a batch-script that connects their >> network shares, it contains cleartext passwords ... bad > Yes, really bad! >> >> Now they had a security audit and we should get rid of that batch >> file, sure. > Good decision.As mentioned in my other reply, a first thought is to simply edit the batchfiles and remove the password -> enter at run time.>> I consider setting up an ADC for that one server overkill. And I >> wonder where they would keep their passwords then, it wouldn't change >> that. > > A small explanation for this question: If a Windows-machine is > authorized on an AD, you can configure the network-fileserver without > passwords. With the login password, the clients will get a so called > "granting ticket" from the AD, which can be used to mount a network > directory to the machines without additional password entries, all > secure encoded.Sounds good, but sounds like we would have to trust the bigger AD. We want to keep all the upstream IT out of our boxes (but on the other hand have to comply to the overall security standards).
Am 10.09.18 um 11:12 schrieb Rowland Penny via samba:> Hi Stefan, I would set up a small AD domain, one DC, and turn the two > original servers into Unix domain members and then use kerberos.How would "use kerberos" look like from the client's view?