Disabling "Save to FTP" on OFFICE 2000?

[Javier J]

Hi all!!

Am trying to find a way to disable the "save to ftp location" feature
found in the "save as" Dialog on OFFICE 2000 Apps. I've done some
testing using Gropu Policy, but the "disable custom item" on the UI only
works for the items on the "main" meu bars and such. This "feature" is
just part of a drop-down box on the main program.

I guess there has to be a way to prevent users from saving to FTP, but I
just can't figure out how to do it. Any and all help would be more than
appreciated.

Thanks a lot

Javier J

 

[Lanwench [MVP - Exchange]]

Hi all!!

Am trying to find a way to disable the "save to ftp location" feature
found in the "save as" Dialog on OFFICE 2000 Apps. I've done some
testing using Gropu Policy, but the "disable custom item" on the UI
only works for the items on the "main" meu bars and such. This
"feature" is just part of a drop-down box on the main program.

I guess there has to be a way to prevent users from saving to FTP,
but I just can't figure out how to do it. Any and all help would be
more than appreciated.

Thanks a lot

Javier J

Not sure.
Perhaps an OT reply:

Where's the ftp server you're afraid they'll save to? A workaround might be
to block the appropriate outbound TCP/UDP ports in your firewall, so that
users cannot use ftp to external servers at all. If you have an internal FTP
server, don't allow anonymous FTP.

 

[Gyorgy Moldova [MCSE, MVP]]

The easiest solution is to disable the FTP ports on the firewall.

hth,
g

--
Gyorgy Moldova, MCSE+I

MVP: Office System

E-mail: (e-mail address removed)
Blog: http://dracosbro.slytherin.hu

 

[Javier Jarava]

The problem is, I'm trying to prevent the users from connecting to *any*
FTP server, even those that might exist within the firewall...

The client is a *big* org where there is a mix of Windows and Unix
servers (~2000 users, 14 DCs, several NT PDCs, 30+ Linux/Unix Servers).
These group of users handle information that should _not_ leave their
PCs, but it's quite likely that they know some user/Pwd to some internal
FTP server, or the might know somebody who can provide it...

What I'd like to know is, how can I _disable_ the save-to-ftp or
open-from-ftp support _in_ windows, if possible, instead of having to
install yet another piece of software on the computer that has to be
administered and cared for.

 

[Javier Jarava]

The problem is, I'm not afraid of their connectig to an *specific* FTP
server. There are several linux servers inside the firewall (and plenty
of Windows ones, too), so there are potentially quite a number of FTP
servers out there. Not only that, but there is quite a big number of
people with Domain Admins privileges (or the "Adminitrator" password).

And, of course, the number of those who are local administrators of
their computer is big (and only grows, it never goes down). So they
could use (for example), VMWARE to install a linux server on a VM, and
they'd have a FTP server to connect to.

Those are (some) of the reasons I'd like to be able to disable
"explorer-like-ftp" from a number of computers...

I really hope there is some way to disalbe it "elegantly" that is not
"get a fork on the lan card"

Thanks a lot for any and all help you might offer..

Javier J

 

[Lanwench [MVP - Exchange]]

The problem is, I'm not afraid of their connectig to an *specific* FTP
server. There are several linux servers inside the firewall (and
plenty of Windows ones, too), so there are potentially quite a number
of FTP servers out there.

Do they permit anonymous FTP? Who manages these servers?

Not only that, but there is quite a big
number of people with Domain Admins privileges (or the "Adminitrator"
password).

Well, that's not a very good thing, is it.

And, of course, the number of those who are local administrators of
their computer is big (and only grows, it never goes down).

Why on earth is this permitted??

So they
could use (for example), VMWARE to install a linux server on a VM, and
they'd have a FTP server to connect to.

Those are (some) of the reasons I'd like to be able to disable
"explorer-like-ftp" from a number of computers...

I really hope there is some way to disalbe it "elegantly" that is not
"get a fork on the lan card"

Thanks a lot for any and all help you might offer..

"There are seldom good technological solutions to behavioral problems" - Ed
Crowley.

Sorry I don't have any further help to offer - I just think you're trying to
shovel snow during a blizzard.

 

[Javier J]

Hi!

Thanks for a great response to my question...

I answer your points below...

Do they permit anonymous FTP? Who manages these servers?

That's the problem. It only takes one user who is "Local Administrator"
of her computer and a copy of VMWARE to have as many servers as you
wish, with the policies you want.... I'm going to suggest to the client
that they start using Kerberos to avoid the "rogue laptop" problem (as
not all "new" computers would be on the domain), but that means quite a
lot of work on the integration front...

Well, that's not a very good thing, is it.

No, it isn't. But that's the way things are. I'm trying to reduce that
number to the minimum that is _really_ necesary, but that's a political
battle that it going to take quite long. And first of all, we have to
prove to the client that we know what we're talking about...

Why on earth is this permitted??

Many reasons, some of them are reasonable (for instance, they use some
legacy apps that won't run properly as non-Admin; yes, they should phase
them out or upgrade, but it's not that easy), but many of them not (ie,
it "cures" many of the user's problems when contacting support, so if a
user is on your hair all day long, they just make him a local admin, and
then the user has no problems with his software. Problem ""solved"").

In this, I have the support of their "systems" dept, who are quite fed
up with network scanners showing up, and similar "Niceties". But it's
not going to be an easy battle.

"There are seldom good technological solutions to behavioral problems" - Ed
Crowley.

How true. But we've been hired to try to plug the holes. Of course,
there is a point when we just say "not possible".... but we _have_ to
show that we've done our duties. Of course, if the proposed solution is
just too cumbersome or too restrictive, they could "take the easy way
out" and just start to limit users' rights and such... Even if that
means dealing with irate users

Sorry I don't have any further help to offer - I just think you're trying to
shovel snow during a blizzard.

Don't worry. Somebody sent me this link:
http://homepages.wmich.edu/~mchugha/w2kfirewall.htm
that shows the way... I agree with you on the "shoveling snow" alegory.
Thankfully, I only have to keep a tiny corner clean.. And then explain
_what_ should be done to try & clear the rest (or to explain why it's
not possible if they don't change their user behaviour).

Of course, first I have to "clear my corner", and that's when these
questions come in.

Thanks a lot for your time. Any further ideas will be more than
appreciated..

 

[Paul Adare]

microsoft.public.win2000.security news group, Javier J

Don't worry. Somebody sent me this link:
http://homepages.wmich.edu/~mchugha/w2kfirewall.htm
that shows the way...

Given the fact that the majority of the users are local admins, the
above will accomplish exactly nothing. Admin users can simply turn this
off.
I don't understand the specific concern about saving to FTP locations in
the first place. As others have pointed out, you can block access to
external FTP sites easily with any half decent firewall. Who cares if
they save to internally located FTP sites? Where's the risk? They could
just as easily save to a USB/Firewire device and walk out with the
files. Where's the additional risk involved in saving to an internal FTP
site?
Again, as others have pointed out, this seems to be a problem that
doesn't really have a good technical solution. This should be covered by
written and _enforced_ security and acceptable use policies. Any user
caught with VMWare on their systems will be disciplined. Any user caught
running an unauthorized FTP server will likewise be disciplined...

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Andrew Mitchell]

microsoft.public.win2000.security news group, Javier J


Given the fact that the majority of the users are local admins, the
above will accomplish exactly nothing. Admin users can simply turn this
off.

Not if it's applied through a group policy. A domain or OU based group policy
will over-ride a local policy.

If the user is a domain admin it's a different story.

 

[Javier J]

Hi!!

I know that with users being local admins, this would be of no use. And
re-reading my post, I see that I haven't made myself too clear. Sorry
for that.

The computers I want to secure will be placed in a separate OU, and the
users that will use them will _NOT_ be local admins. That's why I'm
investing time and effort researchin group policy, etc.

We want to make sure (or at least, as sure as it's reasonably possible)
that the users won't be able to take the info off the computers "no
matter what". There is already a solution in place for the "local
device" problem: We're using "Secuware Security Framework" for local
security. Among other things, the software enables the domain admin to
set all the external devices on a computer as "encrypted", so all info
to/from them is encrypted. That takes care of the "portable USB Drive"
problem.

The issue is, we don't want the files from moving about, even within the
internal network. The reference to the number of local admins present is
to show that there is quite a number of people who might be able to save
the files to a CD/Pen Drive, or similarly make use of them. And when
users are Local Admins, the possibility of rogue FTP Servers exist, and
has to be taken into account.

The problem with "banning" VMWARE is that, first of all, the client has
1500+ employess in 6 (IIRC) buildings, and fairly old buildings at that,
so it's not easy to see who "uses" VMWARE. Remember, it only takes a few
minutes to do this. Of course, those who have rogue FTP servers will be
disciplined... when caught. Equally those who use VMWARE and shouldn't
be doing so.... But this is all after the fact, and we'd like to stop
the information from leaking in the first place

Hope this makes the situation clearar. Thanks for the time and your
opinions, and I look forward to any further input you care to offer.

 

[Javier J]

In the case of these "secured" PCs, one of the things we use Group
Policy for, is to control the members of the local Administrators group.

The only local admins are "Administrator"; "Domain Admins." and an
account for remote update and access (whose password is closely held).
I've already stated (and gotten a written confirmation) that if the
users are given local administrator privileges, we won't make any claims
about the proposed security solution...

Any more ideas?

Javier J

 

[Ken B]

If the computers are meant to be "secure" computers (containing confidential
info), you might consider taking them off the network, disabling the nic,
and making them standalone computers that are totally stand alone. Between
disabling the nic and usb ports, you won't have to worry about the "secure"
machines losing data. Oh yea, take out the floppy drive and cd rw if it has
one .

The only sucky downside to making a machine 'secure' in this manner is that
you've now dedicated a machine to being virtually (paradoxically) unusable
for normal work tasks--email, sharing files, etc.

:link plink::

Ken

 

[Lanwench [MVP - Exchange]]

Hi!

Thanks for a great response to my question...

I answer your points below...

Responses inline as well (although I see you've got plenty of other good
replies already)

That's the problem. It only takes one user who is "Local
Administrator" of her computer and a copy of VMWARE to have as many
servers as you wish, with the policies you want.... I'm going to
suggest to the client that they start using Kerberos to avoid the
"rogue laptop" problem (as not all "new" computers would be on the
domain), but that means quite a lot of work on the integration
front...

I agree with one of the other replies - to wit, this should be made an HR
issue.

No, it isn't. But that's the way things are. I'm trying to reduce that
number to the minimum that is _really_ necesary, but that's a
political battle that it going to take quite long. And first of all,
we have to prove to the client that we know what we're talking
about...

Is the client the one dictating that users should not have the ability to do
what they are currently doing?
If so, make them aware that you can pretty easily make this impossible by
tightening up security.
If the client doesn't care, then just charge them for every minute you spend
working on problems caused by users having too many privileges on the
network. And document everything out the yin-yang, in obsessive detail.

Many reasons, some of them are reasonable (for instance, they use some
legacy apps that won't run properly as non-Admin; yes, they should
phase them out or upgrade, but it's not that easy),

Another option: RegMon and FileMon from www.sysinternals.com - will help you
find out where these apps expect to be able to write to, so you can manually
open up what needs opening. Very handy utilities.

but many of them
not (ie, it "cures" many of the user's problems when contacting
support, so if a user is on your hair all day long, they just make
him a local admin, and then the user has no problems with his
software. Problem ""solved"").

Right. ;-)

In this, I have the support of their "systems" dept, who are quite fed
up with network scanners showing up, and similar "Niceties". But it's
not going to be an easy battle.


How true. But we've been hired to try to plug the holes. Of course,
there is a point when we just say "not possible".... but we _have_ to
show that we've done our duties. Of course, if the proposed solution
is just too cumbersome or too restrictive, they could "take the easy
way out" and just start to limit users' rights and such... Even if
that means dealing with irate users
Yep.

Don't worry. Somebody sent me this link:
http://homepages.wmich.edu/~mchugha/w2kfirewall.htm
that shows the way... I agree with you on the "shoveling snow"
alegory. Thankfully, I only have to keep a tiny corner clean.. And
then explain _what_ should be done to try & clear the rest (or to
explain why it's not possible if they don't change their user
behaviour).

Of course, first I have to "clear my corner", and that's when these
questions come in.

Thanks a lot for your time. Any further ideas will be more than
appreciated..

Wish I could help further - sounds like you have quite a job, there. I'm not
envious!

Javier J


Lanwench [MVP - Exchange] wrote:

Javier J wrote:


Hi all!!

Am trying to find a way to disable the "save to ftp location"
feature found in the "save as" Dialog on OFFICE 2000 Apps. I've
done some testing using Gropu Policy, but the "disable custom
item" on the UI only works for the items on the "main" meu bars
and such. This "feature" is just part of a drop-down box on the
main program.

I guess there has to be a way to prevent users from saving to FTP,
but I just can't figure out how to do it. Any and all help would
be more than appreciated.

Thanks a lot

Javier J


Not sure.
Perhaps an OT reply:

Where's the ftp server you're afraid they'll save to? A workaround
might be to block the appropriate outbound TCP/UDP ports in your
firewall, so that users cannot use ftp to external servers at all.
If you have an internal FTP server, don't allow anonymous FTP.