We are setting up a citrix solution for co-workers from an external partner to access applications in our organisation. The question is if it's a bad idea to allow Citrix Client Drive mapping from a security perspective?
Does anyone know of any best practices?
We have no control over the state(of for example antivirus software) of the clients from where they connect or their network.
This is probably a question for the Citrix forums, but here are my 2 cents:
With Citrix XenApp you can granularly control which level of data exchange between the client (where the user sits) and the server (where applications are executed and data is stored) you want to allow. One extreme is to disable every form of exchange, including the clipboard. In such a scenario the only way users can copy data from the server is via screenshots.
The other extreme is to allow everything including clipboard and client drive mapping. In that case you can copy data to and fro, both via the clipboard and via the file system.
There is no best practice, you need to define which level of security you want and act accordingly. But beware: think of the users, too, and do not restrict them unnecessarily.
Related
Need to understand something related to Citrix XenApp and XenDesktop.
If I install a software (e.g. Paint.NET) on Citrix Server and publish it via XenApp and XenDesktop to set of users. My understanding is below,
Users who are accessing published application as XenApp; is a thin client application.
users who are accessing using XenDesktop; is a thick client application.
Is my understanding is correct? I googled a lot but still couldn't get a proper answer. I am very new to this Citrix world.
Can someone please explain me in laymen language?
I'm not sure these categories can really be cleanly applied to Citrix. Let me just explain in a nutshell how it works and you can be the judge yourself which of the (if either) it should be.
I have a farm of Citrix servers that I deploy WPF to. The servers are basically just Windows machines, so I can browse for files, upload, interact with the local file system in any way. The app itself to the Citrix server just like it was a personal computer. Citrix technology basically just transmits a picture of whatever apps each user has open on the server(s). It does this by the user installing a client (web browser plug-in), and all that comes across the wire is the compressed graphics info. There is no discernible lag, so it's basically just like I'm working directly from the server. I can't copy objects directly to my laptop from these web servers, because the OS I'm on there isn't really the same OS (although can browse through the network to my laptop and copy it that way very quickly).
That is Xenapp. I assume XenDesktop is the same as what we call 'Remote Desktop, but double-check me on that. This is what I use to log into a computer in the office from my home and control it. It works very much like the above except that, instead of logging into a server , it's used to log into a desktop PC.
Both technologies just transmit a (compressed) image, and both allow you to send keystrokes and mouse movements so that it's like you're working directly on that machine. As I understand it, Citrix is one of the few games in town with this kind of technology, and last I heard, even MS licensed it from them.
The typical usage is to install fat client apps on a Citrix farm so that they then become web/browser accessible from outside the work place. The apps are published on a gateway web site with links to the individual apps (although you can also browse through the file system and open that way). The only thing the user needs to have installed to do this is the Citrix client to decipher the visual stream. The client is free and lightweight.
So basically, I would say Citrix technology allows for fat clients to be installed on the Citrix server and then accessed like thin clients.
There are a few key differences between Citrix deployment and the way typical web app works. One is that the user has to actually close the app out, not just their local web browser , otherwise the app stays running on the Citrix server. By default that doesn't typically happen because from the Portal, a particular app will be published, so that only that particular app pops up on click of the link (not a desktop or Windows Explorer). So when the close the 'picture' of it running in the browser, they do so by closing the 'X' on the app. But if they're crafty, they're can disconnect the client from the server and leave it running. That can be handy if ones need to some work that shutting downt the laptop would otherwise close out (long-running datawarehouse pulls, etc). Another difference is that speed and performance are pretty much the same no matter the location of the user(at least with XenaPP). Normally, if you have a Wide Area Network, and you say, deploy an ASP.NET web page on web server in City A, the user in City B 1000 miles away may have a bit of a lag, since the web app may have to query a database server, then spit out some Javascript, that then gets consumed and ran on the client. With Citrix Xenapp, everything is occurring on the server in City A. In Citry B, the user is just getting a compressed picture stream. For this reason, it's better to avoid too fancy graphics, because they waste bandwidth and usually get autocompressed to look weird anyhow. But assuming that is done and the farm doesn't suck, performance will be appreciably the same in India or the Philipines or the United States for the same app. Another difference is that the data is inherently Sandboxed, and there are is no URL unless you decide to put the app on a web server and then have users access it through Citrix (which I've seen done in companies with sensitive data using offshore vendors because of the Sandboxing and speed benefits). But if you do that, you have to open the web app from within the Citrix portal and then you can run the browser on that server (you can't just put a link to that web app from the web). Finally--and maybe this is just where I work--but the load balancing seems to work a little differently than with web servers. Users tend to get thrown on the same server if they already have another app open. That can be handy for copying files, etc, but also means less balance in the load for particular servers at times, so that you typically don't want the overall average load to go high (need more servers).
Hopefully that helps explain it and give you an idea. Citrix just sends a picture of the wire that you can use to remote-control a machine. I would say it's kind of "both" on the thick or thin client question. Typically it is used to deploy Winforms, WPF or other 'fat client' technologies, and is largely unnecessary for technologies that already allow for thin clients (web apps). But sometimes web apps are pushed through there also, for various reasons.
I want to figure out how many users can ADFS 2.0 stand-alone server support. I mean load of the server. My customers said that it supports just 100 users (seems strange for a server and so simple operations) and they have 700 users at the same time.
So he recomended to have a federation farm instead of stand-alone server. But I prefere to check first.
So, can you share info about load limitations of stand-alon SSO server VS server farms?
Any docs, articles with numbers, experts ideas or so on...
We have standalone servers that support WAY more than 100 users - easily over 1000.
Not sure what the upper limit is?
A farm is only going to help if you have a load balancer in front of them
I also found an article about this problem.
The auther writes that they use 2 ADFS servers for 10 000 users.
And there is a calculator to get number of servers depending on the load and users
There is no such restriction and it solely depends on how often users login to your system.
We have few deployments of the adfs, one of them supports like 50000 users and only TWO servers are enough. I even suspect one would do however this is, as always, not a good idea to have just one server (at least two servers = failover, you wouldn't want the whole environment to be inaccessible just because your login server just died).
The idea would be then to start with two servers and monitor the infrastructure. Add other instances only when necessary.
We currently have POP3 mail accounts where I am and try as I might to convince my manager that we should be using hosted IMAP or Exchange he won't budge because of the cost. The staff are mostly out of office so there is no domain server here, however, we do have a dedicated server and I wondered whether I could use this to collect the mail and distribute it from there in some way.
Effectively what I'm trying to do is ensure mail is stored somewhere other than the end users machine because backups are user dependant at the moment. With hosted Exchange or Exchange on this server would be simple but my manager won't shell out for it. I have seen free mail servers called MailEnable and Axigen but unsure if they will do the job. Sorry if this seems like an easy or stupid question but never needed to do this before.
I am assuming due to the reference to Exchange that you are on Windows.
If you have an old box lying around that works, you could install linux on it and then choose from a number of different imap servers. Dovecot and Courier are both good choices and I have worked with them before.
You could use fetchmail to then pick up the mailboxes and then deliver to the imap boxes or get them deliver directly.
Setting up such a linux server for email was one of the first things I ever did on Linux. While initially daunting, once you get the hang of it, it is pretty straightforward and there are plenty of resources out there to help.
Ubuntu is probably the easiest to get used to. CentOs is also a reasonable choice.
You shouldn't be running your own server if you aren't willing to administer your own server, and they are not easy to configure if you don't know what you are doing (e.g., you mess up and you are exploited for spamming).
Look into a service like mailgun. In my application we are using them for forwarding to REST endpoints as well as onto another SMTP server.
Competitors that wound up not meeting my needs but may meet yours include Dyn, email yak, Sendgrid, etc. etc.
Why not just setup the mail clients to store their mail files on a standard network drive or share? I follow that this situation is pretty silly in your view - 100% because of the ridiculous constraints that you are being asked to work within: I would similarly find the solution I am suggesting ridiculous generally; but under the circumstances, it seems like a simple answer to your problem - replacing distributed mail storage and backup with centralized storage and backup.
Don't POP3 email clients have the option keep a copy on the server? Mine certainly does. See second tick box on the pic.
You can then periodically take a back up of all the emails from the server to stop it getting clogged up.
I have a VB6 app which is used by a large number of clients.
I need to allow the clients to be able to send emails to me. In the past I have done this using Microsoft MAPI controls. However, not all of them have an email client installed, since they use webmail instead.
Is there any other method anyone can recommend which would allow them to do this?
SMTP
You can use CDO for Windows to do this if we make a few assumptions:
Your users are all on Win2K or later.
The users will never be behind a firewall blocking SMTP or proxying all SMTP port use to a corporate server.
You have an SMTP server that you have an account you can let the user-mails be sent with.
You embed the server's address and account credentials in your program.
Sometimes using an SMTP server listening on an alternate port will address the second issue, but often such an alternate port is even more likely to be blocked.
SMTP is Dying
Abuse over time has made SMTP less and less viable for automated/assisted user contact. There are just too many variables involved in trying to open some sort of "clear channel" for SMTP communication as people work harder to fight spammers and such.
Today I would be much more likely to use either WebDAV or a Web Service for this. Both use HTTP/HTTPS which is more likely to get past firewalls and usually get by most proxy servers as well. WebDAV is often more "slippery" at this than Web Services, which more and more proxies are bocking. You can also use something more RESTful than SOAPy since the traffic "smells more like" user browsing to proxy servers.
WebDAV is a Clean Option
There are even free WebDAV providers offering 2GB of storage with a main and a guest user. The guest account can be given limited rights to various folders so some folders they might post your messages to, other folders they might get data from (read only folders), etc. For a paid account you can get more storage, additional users, etc.
This works well. You can even use the same hosting for program version files, new version code to be downloaded and installed, etc. All you need on your end is an aggregator program that scoops up user posted messages and deletes them using the main user/pw.
You still need to embed user credentials in your program, but it can be a simpler matter to change passwords over time. Just have the program fetch an info file with a new password and an effective date and have the program flip the "new" password to "current" once run on that date or after.
WebDAV support in Windows varies. From WinXP SP3 forward you can simply programmatically map a drive letter to a WebDAV share and then use regular file I/O statements against it, and unmap the letter when done. For more general use across even Win9x you can build a simple WebDAV client on top of XMLHTTPRequest or use a 3rd party library.
Web Services Have Higher Costs
Just to start with you have server-side code to write and maintain, and you have to use a specific kind of hosting. For example if you built it using PHP you need a PHP host, ASP an ASP host, ASP.Net an ASP.Net host, etc.
Web Services can also be more problematic in terms of versioning. If you later update your program to provide different information in these user contact posts you have to make another Web Service as well as changing both the application and the aggregator. Using WebDAV you can just make a "new format" folder on the server and have the new program post the data there in the new format. Your aggregator can simply pull from both folders and do any necessary reformatting into your new local database/message repository format.
This is merely an incremental additional effort though and a Web Service might be the way to go, even if it is just something written like an HTML Form GET/POST acceptor.
Although this question is for VBA you may find it of interest. Sending Emails using VBA without MAPI
I want "A" computer to responsible for execute the command, and "B" computer will send the command to "A" computer. I have some ideas on the implementation.
Way1:
The "A" computer have a while true loop to listen for "B" computer's command, when it is received, it execute.
Way2:
Using a FTP Server, that store information that about the command.
The "A" computer have a while true loop to check whether the "B" computer uploaded any new information about the command. if yes, reconstruct the command and execute. After executed, the file on FTP Server will be deleted. And store a copy the "A" computer.
Way3:
this is similar to way2, but using database to store. After the command is executed, it will made as executed.
What is your suggestion about these 3 ways? Is that secure enough?
A generic way: ssh and scp.
Reliable secure database specific: depends on the platform: Service Broker, Oracle AQ, MQSeries.
Not so good idea: write a socket program w/o knowing anything about security.
You're assuming a trust relationship without giving any clues as to how you know that the payload from computer A is benign. How do you plan to prevent computer A from sending a task that says "reformat your hard drive after plundering it for all bank accounts and passwords?
AKA write a socket listener on computer B and let computer A connect to it. No security here.
FTP just saves you from having to write the transport protocol.
Database for persistence instead of file store - nothing new here.
None of your options have any security, so it's hard to say which one is more secure. FTP requires that the user know the URL of your FTP server and, if you aren't allowing anonymous access, a username and password. That makes 2 more secure than 1. 2 and 3 are equally (in)secure.
All can work, but all are risky. I see little or no security here.
Without more details, all I can suggest for security is to use SSL.
Using FTP or a database server will just add needless complexity, potentially without gaining any real value.
If you want a secure solution, you will need to carefully describe your environment, risks, and attackers.
Are you afraid of spoofing? Denial of service? Information disclosure? Interception?
1 has nothing to do with security.
2 uses FTP and not FTPS? Anyone and their grandparents can sniff the username/password. Do not use.
3 depends on how securely you connect to the database --- on both ends. Also, how can you be sure what's inserted into the database if from your trustee?
What are you really implementing here? With all due respect, it sounds like you should pick up at least an introductory book on information security.
From your examples it seems that you aren't so much interested in securing against malicious attacks and bit manipulation but what you want is reliable delivery.
Have a look at a message queue solution, for example MSMQ.
It depends what kind of security you need.
if it is guaranteed delivery - anything way that makes the message stored and approve the storing before deletion will do.
if it's about the sender and the receiver id you should use certificates.
if it's about the line security - you should encrypt the message.
All things can be achieve using WCF if you're on the Microsoft world.
and there are other libraries if you're on the Linux world.
(you can use https post for example).