How to control network shares on server and preserve permissions?

  • Thread starter Thread starter David
  • Start date Start date
D

David

Hello,

I'm trying to write a utility for a product that I have. The
product allows remote clients to access the server's database
via a shared drive. The problem I am trying to solve is the
sequence of events needed to record the settings for a shared
drive and then disable it. Later on, after performing a bit
of maintenance, I plan on sharing the drive again and
restoring all of the previous permisions.

I need some command line utilities or operating system APIs
that I can use to control the network shares and their
permissions. Ideally these utilities or APIs should be
consistant from Windows 2000 on.

I've found the Windows 2003 Resource Kit and the rmtshare
and chkshare utilities. These are good for XP and 2003.
I've not found a similar utility for Windows 2000.
NET SHARE is an unacceptable partial solution to the
problem, as I need to restore the exact configuration the
customer had on their system.

Thanks in advance for any leads to this information,

David
 
This is what web servers are for. Why reinvent the wheel especially since
you are missing some serious security issues with a "file share"
 
Hmm,..I may actually get to catch a programmer *before* he does
this....that's a good thing, not a bad thing,..and if you heed what I say it
will all work much better for you in the end.

Never, ever, ever, ever use Mapped Drives to access anything from an
application. It doesn't matter whether it is just files or is a DB. Use UNC
Paths,...no Mapped Drives!

Also if you use a Database Connection,...never, ever, ever,ever use a DSN.
Use a "DSN-Less" Connection. DSNs also most often use a Mapped Drive as
well, so they are "doubly-bad"

Aspin: ASP DSN-less - ASP tutorial, script, programming, code
http://www.aspin.com/home/tutorial/database/dbconn/dsnless

Connection Strings (See the ODBC DSN-Less section)
http://www.carlprothman.net/Default.aspx?tabid=81

If your Database is to work across a network never use Jet (Access), it
simply is not designed properly for that, it was designed as a local
single-user database...instead use, at a mimimum MSDE (its free), and can be
run anywhere that is reachable from the machine running the Application. It
will also allow those using your App to migrate the DB to the full SQL
Server and maintain all functionality,..and even gain functionality.

Mapped Drive letters and the old DSNs are thing thing of the past,...they
are nothing but trouble,..and using them is like rubbing two sticks together
to start a fire.

There are still a few Applications around here at our place that use this
old stuff and they are nothing but trouble.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
 
This is what web servers are for. Why reinvent the wheel especially since
you are missing some serious security issues with a "file share"
Click to expand...

This is legacy stuff that I don't have time to invent right now. I'm
just trying to keep it alive while more profitable adventures can be
pursued.

The medium term goal is to remove this concept from the inept programmers
that listened to the dark-side to begin with.

The shares are fairly well protected (not my idea of protected) under
2000 and above if maintained properly.

David
 
David said:
This is legacy stuff that I don't have time to invent right now. I'm
just trying to keep it alive while more profitable adventures can be
pursued.
Click to expand...

I understand...
The medium term goal is to remove this concept from the inept programmers
that listened to the dark-side to begin with.
Click to expand...

The shares are fairly well protected (not my idea of protected) under
2000 and above if maintained properly.
Click to expand...

I have confidence in NTFS permission if done properly, so I'm not worried
about security. But I don't know of any means to do it the way you were
asking about. In my other post it is the performance and dependability that
were my concerns.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------
 
David said:
This is legacy stuff that I don't have time to invent right now.
Click to expand...

It could be that reinventing it would be quicker and more dependable than
the time and hassle involved in comming up with a workaround that
"kinda-sorta-almost-works".

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------
 
Hello Phillip,

Hmm,..I may actually get to catch a programmer *before* he does
this....that's a good thing, not a bad thing,..and if you heed what I say it
will all work much better for you in the end.
Click to expand...

Agreed. This is bad stuff that came from bad programers to begin with.
However, I do need to add this "maintenance stuff" as a stop gap measure
to keep a few critical customers happy.
Never, ever, ever, ever use Mapped Drives to access anything from an
application. It doesn't matter whether it is just files or is a DB. Use UNC
Paths,...no Mapped Drives!
Click to expand...

Agreed. I've been reworking the entire dark-side-programmer-mess for
a while now. By that I mean anything derived from Microsoft examples
as the proper and acceptable way of doing things.

We support this as well.
Also if you use a Database Connection,...never, ever, ever,ever use a DSN.
Use a "DSN-Less" Connection. DSNs also most often use a Mapped Drive as
well, so they are "doubly-bad"
Click to expand...

Already DSN-less.
Aspin: ASP DSN-less - ASP tutorial, script, programming, code
http://www.aspin.com/home/tutorial/database/dbconn/dsnless

Connection Strings (See the ODBC DSN-Less section)
http://www.carlprothman.net/Default.aspx?tabid=81
Click to expand...

I'll read up on these. Personally they don't fit the problem set.
This mess should never have had an SQL Database as part of the design.
If your Database is to work across a network never use Jet (Access), it
simply is not designed properly for that, it was designed as a local
single-user database...instead use, at a mimimum MSDE (its free), and can be
run anywhere that is reachable from the machine running the Application. It
will also allow those using your App to migrate the DB to the full SQL
Server and maintain all functionality,..and even gain functionality.
Click to expand...

Performance isn't a problem, we don't need it. MSDE looks okay, but is
still a potential hole that very security conscious customers hate.
There are still a few Applications around here at our place that use this
old stuff and they are nothing but trouble.
Click to expand...

The only problem here is an occasional customer that performs a few magic
incantations with the database editor (simple add/change/delete rows)
that grows the database uncontrollably. We have a new customer that
did sixty-seven edits and grew a 3MB Jet database to 1.7GB before it
got corrupted. The solution they need is still nearly nine months out.

I still need a solution for use today.

Since there may be decent developers lurking, I'll also mention that
I'm searching for someone to add to the staff to get this mess cleaned
up. So if you know of someone seeking a permanent development position
with a good amount of decent experience (senior level) give me a shout.
My real address is included below.

David [HUEY dot DLL at GTE dot NET]
 
It could be that reinventing it would be quicker and more dependable than
the time and hassle involved in comming up with a workaround that
"kinda-sorta-almost-works".
Click to expand...

The applications are fairly dependable (MTBF for most customers is years).

So far, the database compress and repair logic, coupled with stopping
and restarting the applications to allow the database to be overwritten
took about six hours time. Most customers have clients that access the
database over the shared drives so I need to cycle them as well.

I'm reading the links you provided earlier. Thank you. One of them
might be usable. All the database access code is in various C++ classes
and can easily be changed over to other technologies. However, there
are about a dozen cooperating applications/services to update all at
once so it will need ot wait for a major release and major validation.

Thank you for the help,

David
 
David said:
I'm reading the links you provided earlier. Thank you. One of them
might be usable. All the database access code is in various C++ classes
and can easily be changed over to other technologies. However, there
are about a dozen cooperating applications/services to update all at
once so it will need ot wait for a major release and major validation.
Click to expand...

Ok, well I hope it all works out. I don't know of anything other than what
I have said,..although it took me a while to fully understand the situation
and where you fit in to it. It sounds like you already have a pretty good
grip of the situation.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------
 
Ok, well I hope it all works out. I don't know of anything other than what
I have said,..although it took me a while to fully understand the situation
and where you fit in to it. It sounds like you already have a pretty good
grip of the situation.
Click to expand...

Thank you for the help Phillip,

My problem isn't so much determining what is a good way or poor way of doing
things, as it is trying to determine what Microsoft has or hs not created
and how to find out the information I'm looking for. I've only worked in the
Microsoft world for eight years and have several good local sources for most
information. There are just some concepts, like shared drives and such, that
appear to be well known from a UI perspective but that any other interface
has not been documented well.

I would have thought that having more documentation for APIs or command-line
tools would have been in demand by the administrators. My local domain
admins seem to be in the dark and the programmers far more aware of what
each generation had to offer.

Thank you,

David
 
David said:
I would have thought that having more documentation for APIs or command-line
tools would have been in demand by the administrators.
Click to expand...

I know I don't speak for all Administrators, and when I speak of them I am
more considering Network Engineers/Administators not simply general
Administrators but,...
Administrators for the most part dispise commandline tools. It is almost the
last thing in the world we want MS to invent. We want the funtionality that
would have been provided by those to just simply be in the interface to
begin with. A commandline tool is looked at as an "unfinished product" that
still needs to have the interface built. Automated tasks can done via Group
Policy, SMS, (maybe MOM),...but the functionality needs to be in the
interface of those things, not in some obscure commandline tool.
Administrators couldn't care less about APIs,...leave that to to
programmers.

The programmers are supposed to write the stuff (and do it correctly),...we
are supposed to use the stuff (and use it correctly).
My local domain admins seem to be in the dark and the programmers far more aware
of what each generation had to offer.
Click to expand...

I would not expect that to be anything other than exactly that.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------
 
Back
Top