Security Policy: MS servers (2003, 2008, 2012, ++) file transfer question.

Hi,
Thank you for any assistance you can provide.  

Q:  How can files be copied between MS servers with the below security requirements:
\\server111\c$\folder\file  -->  \\share$\folder\file   -->  \\server222\c$\folder\file

Main Goal: For MS servers (2003, 2008, 2012, ++), only Users with ADMIN permission Users are allowed on the c$ drive.  
IIS Developers are not given Admin permissions.  
Developers are given a specific GPO to allow only what is required for them to do their job with a higher then default User permissions, but lower then ADMIN permissions.  

With the following mostly related to, but not limited to, MS IIS web development process:  DEV   -->  Staging -->  Production  and the transfer of files between the 3 phases.  With DEV, Staging & Production environments having its own server instance.

My company has the following security requirements #1-5 below.

1.      No Local Shares (except for Users Home drives)
1.a.      This is for the purpose of preventing a Public server being mapped to a Private share.
2.  IIS Developers do not have Admin permissions
3.  RDP by Admin User not allowed
4.  share$ are accessed by Admin permission only
5.  No file transfer agent (FTP, SFTP, ect)
6.  Local Admin User is not allowed

Thanks, Scott
stepnharpAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

NVITEnd-user supportCommented:
> No Local Shares

Without creating a share, users can't see, and thus, copy files.
Dan McFaddenSystems EngineerCommented:
The security requirements are quite extreme and IMO overkill.

Typically "Public" accessible servers are placed on a DMZ subnet.  A network that exists between the Internet and your internal network.  In this scenario, the DMZ'ed servers should have no internal network access except over well defined and controlled ports.  If these were web servers, the access profile would be something like (not an exhaustive list):

From Internet to DMZ:
http (80/tcp) - allow anonymous  {web traffic}
https (443/tcp) - allow anonymous  {web traffic}
inbound smtp (25/tcp) - allow anonymous  {unknown inbound email traffic}
outbound smtp (25/tcp) - allow internal email server IPs  {your company outbound email traffic}

From Internet to internal network:
Deny All

From DMZ to internal:
Deny All
* this may need to be modified depending on your infrastructure, but it should be highly controlled

From internal network to DMZ:
http (80/tcp) - allow
https (443/tcp) - allow
ftp (20-21/tcp) - allow specific IPs
rdp (3389/tcp) - allow specific IPs
in & out smtp - allow to DMZ smtp relays

OK, I'm off my soap box, every company has their own reasons for security requirements.

Anyway, to your points"

1.  SysAdmins should work with a minimum of 2 accounts.

1) their regular day account. this account has no admin privileges!
2) their admin account.  this account is used for RDP or running process with a "Run as different user" functionality.  This account does not need an mailbox or user drives.
** this prevents your point 1a.
2. Developers do not need admin access to production servers.  This includes publish access to web applications.
3.  No RDP for Sysadmins is unbelievably restrictive.  I've never had this restriction in place in even the most secure of networks.  Management has to trust at least 1 sysadmin!
4. $ shares... access by only admins as expected
5. No file transfer agents... on the server side, ok.  But running an (S)FTP(S) Service on a server is a normal task.  No FTP traffic should be out of a server in a DMZ.
No file transfer protocols, means no file transfer.
BTW, http & https are essentially file transfer protocols!
6. "Local Admin User is not allowed"  is a bad policy.  If your domain connection is in some way disrupted and the local server will not recognize the cached domain credentials, you have no way of getting on to the machine until connectivity is restored.

To perform publishing of applications to web servers, with the above severe restrictions in place you could use 1 of the methods below.  Though they may stretch your company's secure policy.

1. Replication or synchronization software running as a service on a publisher device.  It would use the Admin share(s) to move files around.  Software packages use various file transfer methods.  OS copy, ftp, ftps, sftp, etc.  
2. Microsoft Web Deploy.  Only valid for IIS7+

Someway or another, you will have to enable a file transfer process with permission to Read, Write and Delete files on your servers.

Dan

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
stepnharpAuthor Commented:
Dan,  Thanks for your input.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft IIS Web Server

From novice to tech pro — start learning today.