Interesting challenge (for me at least)

Mark Stinson markstinson at gmail.com
Thu Feb 25 17:33:20 CST 2010


I have to agree with and acknowledge the other replies. To solve a
mgmt issue with a technical solution doesn't always fly.

Given that the Domain Admin could reset the user's password and log
onto the account, you may need to break away from his area of control
- AD share technology. You may have to set up a SSL webdav server,
sftp, nfs share, etc only the power user can have r/w access to.

One of the easiest solutions would be webdav, using LAMP stack on an
SELinux enabled host.
* Windows has built-in webdav mounting
* The webserver could use AD/LDAP auth'ing or other ACL for just r/o
access, while giving rights in a /etc/httpd/conf.d/custom-webdav.conf
to a specific user name.   - NOTE: if you use MS's AD/LDAP there's
some funny business surrounding it. read up on it.

You could set up a Windows Host with standard file sharing or the
webdav setup that's not managed by the AD Domain. Then you could use a
Windows Filesharing, IIS or XAMPP solution.

No matter what poison pill you choose, you're still going to have the
issue of backups, access to those backups, etc. :-)

Later, M.
---
Mark A. Stinson


On Thu, Feb 25, 2010 at 12:00 PM,  <kclug-request at kclug.org> wrote:
> Send KCLUG mailing list submissions to
>        kclug at kclug.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://kclug.org/mailman/listinfo/kclug
> or, via email, send a message with subject or body 'help' to
>        kclug-request at kclug.org
>
> You can reach the person managing the list at
>        kclug-owner at kclug.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of KCLUG digest..."
>
>
> Today's Topics:
>
>   1. Interesting challenge (for me at least) (Haworth, Michael A.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 25 Feb 2010 11:16:40 -0600
> From: "Haworth, Michael A." <Michael_Haworth at pas-technologies.com>
> To: "KCLUG (E-mail)" <kclug at kclug.org>
> Subject: Interesting challenge (for me at least)
> Message-ID:
>        <0446F51E8649E844BD140D357024A9A30B1E502842 at SAL9000.PASTECH.PRV>
> Content-Type: text/plain; charset="us-ascii"
>
> This is most likely pretty elementary, but I wanted to bounce it off of some people that know more than me and can point out any flaws in my very weary logic before I do a concept presentation to my bosses:
>
> I have a folder that has to be available on the network (currently Windows with AD), but must be protected from unauthorized access (including access by Domain Admins). Here is what I think a valid solution could be:
>
>
> 1.       Build up a CentOS box.
>
> 2.       Install and configure SAMBA to allow for sharing to windows computers.
>
> 3.       Create a SAMBA share for the required folder (and sort out auto-mount in case of a reboot).
>
> 4.       create two accounts - one to allow for Read/Write access to the shared folder and one to allow for Read-only access
>
> 5.       Issue the account credentials to the manager of the folder (in this case, out Export Compliance Officer) and then allow it to be that persons problem to manage who knows the credentials.
>
> I see this as a low stress, low cost, quick, and above all - easy - way to deal with a potential compliance issue. The reason that we can not simply use Active Directory to restrict access is that one of our Domain Admins is a foreign national - if we were to place a 'deny access' on the folder, he could remove it if he wished - and getting rid of AD or Windows is not an option ATM, but it is still in process.
>
> Any help from the list is greatly appreciated,
> Michael Haworth<mailto:michael_haworth at pas-technologies.com>
> Enterprise Systems Support Manager
> PAS Technologies Inc.
> D: (816) 556-5157
> M: (816) 585-1033
> F: (816) 556-5189
>
>
> ________________________________
> CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://kclug.org/pipermail/kclug/attachments/20100225/dc9f23ac/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> KCLUG mailing list
> KCLUG at kclug.org
> http://kclug.org/mailman/listinfo/kclug
>
> End of KCLUG Digest, Vol 67, Issue 6
> ************************************
>


More information about the KCLUG mailing list