Laptop use in increasing amongst our users.
If a user is off-site, they cannot access our file servers directly using NCP or CIFS and have to deliberately choose to use a VPN or an alternative method like Filr or NetStorage.
Users expect their experience to be the same whether they are on or off site.
My idea is that the Novell Client will automatically detect that it cannot access the file server directly and would communicate with it using the Filr protocols instead.
This would show clear value for both the OES Client and OES itself.
Whilst this could be achieved by the OES client communicating directly with the Filr server, it would be advantageous if it could communicate with the Filr Client because cached files would be available to offline users.
by: Paul R. | over a year ago | Novell Client
Comments
I think this is going rather too far.
Better is to inform the user about a failure to connect, and perhaps reluctantly offer alternatives (which is product advertising), but do not automatically jump to such alternatives. Basically, Filr is but one way of communicating. It may not exist (or many do exist and then which to choose) nor be what the user intended to access, etc. Also, Filr requires either an active Filr client or an active web browser. Best to stick with what we have about notifying users about failed connections (which may be simply a mistyped credential).
Thanks,
Joe D.
Agreed on the need for something. Laptops don't play nice enough off network.
I like the idea of attaching a VPN to the side of the Novell client, so if:
1) It's on our corporate network, it connects directly.
2) If it's on another WLAN, it uses the VPN.
If we had this functionality, it'd have to take into account:
Zenworks DLU's etc, SLP, DNS, LDAP for contextless etc. which is why I think an auto-configured hidden VPN (openvpn as a service?) might make sense.
Thanks,
Simon
I think that the problem you describe is real, but I'm not sure that automatically switching over to Filr as a secondary access mechanism would be the best solution. Filr uses a different paradigm for file access than NCP or CIFS, so I have doubts that the transition between the two methods could be made truly automatic or transparent.
If Filr is able to meet all end-user needs, the better option might be just to use Filr for both local and remote access. If Filr isn't able to meet the needs of end users locally, then it probably couldn't do so remotely either if used in a transparent fail-over scheme.
Adding encryption, either through a VPN or by incorporating it directly into the file-access protocol (NCP/CIFS) and making sure that the performance of the protocol can deal appropriately with the higher latency involved in remote access is, to me, the better path forward for a seamless user experience.
Automatically invoking a VPN is another unwanted action. There can be more than one VPN, it would invisibly connect to one of possilibly many remote sites without the user being aware of it, and thus traffic would be sent to the VPN's remote site rather than to the expected host. That's a nasty form of deception if we are not careful, and a pain to manage. Thus, for least surprise just fail a connection as now, and inform users to use a Plan B if off site. This requires no code, just education.
After mulling the pros and cons of the situation it seems to me (as they say) the effort is of the kind where an access method may not be trusted if the originator is off site, and thus other access methods are called into play.
What trust could we place in the robustness of each method on that list, including the original NCP one? That is an open question of some import.
In the end this again boils down to
a) avoiding guessing of credentials (NCP ones in this case) and
b) avoiding receivers/protocols which are readily subverted.
NCP does have an intruder lockout counter which can help a lot! Other access methods may or often do not, and in the "not" cases we need to fall back upon log file entries which are noted by a helper and which impose IP blocks, say fail2ban or equivalent. Hopefully those "not" methods write log entries for authentication failures. We recall, an authentication failure counter needs to be kept somewhere and if the access application itself can not remember it across multiple fresh connections then we need an external helper (fail2ban et al) which can and which can impose blocks.
We still need to verify that a method is not easily subverted (thus think several times before using popular target ssh).
In parallel with this is my outstanding request to support SSL/TLS (with STARTTLS) for NCP connections. That would add a needed degree of shielding when using the Internet.
Once the above aspects are dealt with then the user problem of needing a variety of connection methods for places of origin nearly disappears for ordinary use (but not for very sensitive material). An additional benefit of such a solution would be the server system itself likely is stronger against intrusion and deception even if occuring on-site.
Various VPN vendor can allready provide you with an on-demande/(pre-logon & on-demande)/transtunnels solution for your question. iOS an MacOS have the ondemande feature allready a long time. In some cases access to vpn is restricted to the site you want to connect. That is where filr comes in handy.
I'm glad my idea has generated so much discussion. In a sense, I don't really mind what the technical solution is.
I just think the laptop user should not need to change their behaviour dependant on where they are.
I would also observe that the need for the laptop to appear to work the same what wherever the user is drives adoption of Dropbox, OneDrive, Box, Google Drive, iCloud etc.
I do agree that something needs to be fixed for issues like this to ensure a seamless experience for the end-user. However, rather than allowing the client to figure stuff out on its own, I think that this needs to be something that's somehow prescribed by the appropriate IT folks, eg., whether routing through a tunnel, proxy, some other service that's set up, etc. I don't know that doing the VPN route would be a viable solution other than prompting the end-user that they need to connect to one. But it might be nice if there was some sort of relay host that could be set up to route the traffic through a highly-encrypted tunnel, ideally over port 443 so that it will work in coffee shops, hotels, etc. where folks would frequently encounter issues like this.
An alternative solution would be to build out Filr so that the "novell client" as it's known now does what it does, but instead of going NCP, it always acts as an enhanced front-end for Filr. That way it could work, by default, the same way no matter where you're at.
The discussion does boil down to judging security of connections made from on site versus off site, couple with (in)conveniences thereof. This brings into focus what the original problem was about: secure access, with convenience, from both local and non-local places. In my view the actual problem is achieving secure access. Swapping comms methods is often just trading one for an even less well understood substitute.
The on/off site part has two components as well. One is whether we can trust on-site users more than those elsewhere, for which the sensible answer is "not really" except in rather sensitive circumstances. Second is inserting VPN access markedly broadens the concern to include access to most of a site rather to just a particular server. Often such broadened access is itself a serious concern, particularly if a user's machine has malware. A VPN silently redirecting a user's traffic to a local system is inherently an unwise idea, to put it mildly, and can become unmanageable in practice. Heads may roll if trouble results or if users (or the trade press) get wind of such trickery.
This takes us to the second component, asking how robust/strong/impervious is a login channel, of which there are a varity (NCP, SMB, Filr, NFS, SSH, HTTP etc and their server agents). My earlier comments suggested this is where the secure connectivity goal might be approached cheaply once and for all, independent of location, whether or not one blissfully trusts the locals more than pesky outsiders, with no supplementary comms applications, and without silent VPN trickery. If that were accomplished then all of our NCP nicities would remain intact independent of location and our on-site behaviour could be repeated from far away (firewall rules and common sense permitting).
The sensitive situations aspect covers a large range of concerns which are people and policy related. Those comms are kept under management lock&key for local good reasons.
My suggestions about the robustness aspect included using up to date SSL/TLS against eavesdroppers, blocking access upon exceeding authentication attempts, and testing the strength of the server side agents to withstand nefarious activities by the bad guys (local or remote).
The company ought to have a test suite at hand to deal with the nefarious part of things. Luckily NCP has proper intruder lockout, which is ahead of most comms applications. We can add server-side lockout helpers in many cases. What is not yet available are SSL/TLS for NCP, and reports about nefarious weaknesses in our standard applications.