Any way to detect a wireless connection and limit it?

[google]

Hello,
I am working on an Acc2003 app for my company. In the interest of
reducing chances of corruption due to unstable network connectivity, I
would like to either prevent users from running it through a wireless
connection, or limit their use to read-only. I have absolutely no idea
if this is possible, and if so, how. Is there any way from within
Access to get the list of routers they are connecting through?
Ideally, I'd like to keep a list of "accepted router names", pop up a
message telling them the database isn't supported through their current
connection, and direct them to use the thin client option (then, of
course, kill the app). Seems like this would be a good security
measure too, as it would prevent someone from copying the files and
taking them elsewhere to try to hack in to.

Any ideas?

Thanks!

 

[TC]

I don't see how you'd expect that to work. It's like saying, "When a
person knocks on my office door, I want to know if they came to the
building via a taxi, or a bus". No can do - because by the time that
they knock on your office door, the taxi or bus is long gone, and it's
too late to look out the window & see how they came!

I think you're going about this task the wrong way around. 99% of users
don't care *how* the software works - as long as it works. So, start
the app via a small script file that checks the user's PC has a copy of
the FE; downloads a copy if appropriate; then starts the FE. So it all
works automagically. Why then would a user spoend time trying to find a
different way to start the application? Using his wireless connection,
or anything else?

HTH,
TC (MVP Access)
http://tc2.atspace.com

 

[Arvin Meyer [MVP]]

There are several ways that you can limit connections. You will need a
dedicated database server for many of them. On the Access side, there isn't
much you can do without directly limiting users or workstations. You might
look to one of the networking newsgroups for answers involving the network.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

 

[Tim Marshall]

There are several ways that you can limit connections. You will need a
dedicated database server for many of them. On the Access side, there isn't

I write Access FEs for our Oracle systems and this is how the Oracle
DBAs accomplish preventing wireless access to the databases.

From my perspective, this is actually a very irritating limitation and
we're looking at getting our own Oracle server to avoid this wireless
limitation. It's incredibly limiting to be able to cart a laptop into a
meeting somewhere and be unable to generate reports and graphs on
various aspects of our operation or to be able to use hand held devices
to transmit information to workers who might be inside a boiler or
something.

Then again, the C/S nature of Oracle and, I would guess, MS SQL, makes
wireless type communications less fraught with danger?

 

[TC]

I write Access FEs for our Oracle systems and this is how the Oracle
DBAs accomplish preventing wireless access to the databases.

Tim, I don't understand. How do your Oracle DBAs prevent wireless
access to what databases?

Cheers,
TC (MVP Access)
http://tc2.atspace.com

 

[google]

""When a
person knocks on my office door, I want to know if they came to the
building via a taxi, or a bus". No can do - because by the time that
they knock on your office door, the taxi or bus is long gone, and it's
too late to look out the window & see how they came!"

I'm not quite sure I follow your analogy. When they start the
application, I'm already doing some security checks, and kicking them
out if, for example, they aren't logged in to the network under the ID
that matches the Access user ID. *IF* I could do something similar to
a tracert and find the hops to the server, there's no reason I couldn't
do the same thing here. It'd be before they got to the point where
they would be editing any tables, which is the main concern. Even if
the wireless connection flaked out during the brief amount of time it
took them to read the "sorry, you must use the thin client from this
connection" message, I don't see how any corruption would be caused
since they wouldn't have any tables open for editing.

"So, start
the app via a small script file that checks the user's PC has a copy of

the FE; downloads a copy if appropriate; then starts the FE."

I'm already doing that, but I don't understand what that has to do with
whether or not they are connected wirelessly. The script does the
check, copies the file, and opens the DB regardless of how they are
connected (I'm using Tony Toews' Auto FE Updater, FWIW). If that is
the appropriate place to do the check, that is fine with me, but I'm
still clueless on how to figure out how they are connected, or if it
can even be done.

"Why then would a user spoend time trying to find a
different way to start the application? Using his wireless connection,
or anything else?"

It's easy enough to tell people "use the TC if you're connected
wirelessly", it's another thing to get them to remember that. If
there's a way to seemlessly use that method instead when connected
wirelessly, then all the better.

 

[google]

"this is actually a very irritating limitation and
we're looking at getting our own Oracle server to avoid this wireless
limitation. It's incredibly limiting to be able to cart a laptop into
a
meeting somewhere and be unable to ..."
Yes, I agree that not having the limitation at all would be ideal, but
for us, a CS setup isn't an alternative. Our HQ is very restrictive on
what we can put on our network. I can use spare workstations to host
remote sessions for remote and wireless users to use the DB, But
putting another server on the system (much less getting licenses for
one), is not something I can do. But the fact remains that wireless
connections do provide a less robust connection, and therefore the
chances of curruption from a wireless client is higher than that via
wired. Therefore, I'm considering workarounds to reduce this chance.
I'd even be happy with (or even prefer), the ability to allow them to
connect wirelessly, but keep them in read only mode. But I have no
clue as to how to detect how they are connected. To mirror TC's
question, how are you detecting that in your network?

Thanks!

 

[TC]

Yes, on reflection, I think that I have missed the point entirely.

Is this it: From within the code that is running in a front-end
database on the user's PC, you want to know if their connection to the
*back end* database, on some other PC, is via a wireless network
connection (as opposed to a wired connection)?

It is easy, using code within the FE database, to get the full
pathfilenam of the back-end database. Presumeably, that pathfilename
will be a UNC path (//server//share// or whatever it is), or a mapped
drive letter (X:/blah). Perhaps, given that UNC path, or mapped drive
letter, there's a win32 API which would tell you something about the
relevant transport layer.

If so, this would be a win32 question, not an Access one. "Given a UNC
path, or mapped drive letter, how do I determine whether there is a
wireless network connection to the end-point defined by that UNC path
or mapped drive letter?"

Yes? No?

TC (MVP Access)
http://tc2.atspace.com

 

[google]

"From within the code that is running in a front-end
database on the user's PC, you want to know if their connection to the
*back end* database, on some other PC, is via a wireless network
connection (as opposed to a wired connection)? "

Yes, that's exactly it. Sorry I wasn't more clear in the beginning.

"If so, this would be a win32 question, not an Access one."

Yes, but I'm hoping someone here would have already found a way. If
someone explains it in terms of VB, I can generally digest it. But I
fear I may not know how to apply what I may learn if given an answer
that pertains more to the inner workings of Windows. ;-) Through some
searching, I've found a couple other posts in the Access newsgroups
with similar questions, but they tend to stray off into discussions of
how instable wireless connections are, without addressing how to
prevent them from happening. :-/

 

[TC]

Ok, then I would definitely try asking in
comp.os.ms-windows.programmer.win32, for example. It's definitely a
win32 programming question, not so much an Access one. If someone gives
you an answer there, using win32 API programming calls, we can probably
translated that answer into Access VBA.

HTH,
TC (MVP Access)
http://tc2.atspace.com

 

[Tim Marshall]

clue as to how to detect how they are connected. To mirror TC's
question, how are you detecting that in your network?

I have no idea. I will ask our Oracle security manager and hopefully
have a response for you by Monday or Tuesday.

 

[Albert D.Kallal]

It's incredibly limiting to be able to cart a laptop into a meeting

somewhere and be unable to generate reports and graphs on various aspects
of our operation or to be able to use hand held devices to transmit
information to workers who might be inside a boiler or something.

Then again, the C/S nature of Oracle and, I would guess, MS SQL, makes
wireless type communications less fraught with danger?

Oracle is not going to be any different then using sql server. The last 3
versions of access have shipped with a free edition of sql server. So, out
of the box, you can achieve the same reliability using ms-access as sql
server, or oracle for that matter.

So, it is the file-share that you don't want going over the wireless
connection. IF you don't want to use the free edition of sql server from MS,
then you can consider using remote desktop...as windows 2000 server or later
will allow two free and simultaneous desktop connections without any
additional cost....

So, between remote desktop, and the several free editions of sql server from
MS...you have ample choices here to eliminate the file share....

By the way, if you are wondering WHY a broken connection will damage a file
share..but not sql server...you can read the following article of mine....

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

 

[Arvin Meyer [MVP]]

One possibility is to segregate connections by machine name or username and
dump them out the moment they connect. Tou can capture user name with:

http://www.mvps.org/access/api/api0008.htm

and machine name with:

http://www.mvps.org/access/api/api0009.htm

Have a startup form check the user or machine and Exit if it's on a list.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

 

[google]

Thanks Arvin,
While I'm already using the machine name and user name for some of my
security checks, they won't help me here. Pretty much anyone who would
connect wirelessly would be doing that from their laptop which would be
hardwired when they are in their offices. If I had a user who was
wireless only, I wouldn't give them access to the database to start
with. The ones I'm concerned with are the users who connect normally
through a wired connection in their office, then carry their laptops
into a conference room without thinking about the fact that they
shouldn't be using the database if they have switched to a wireless
connection.

I have taken TC's suggestion of posting in the Win32 group... hopefully
something good will come out of that.

 

[lesperancer]

what about redirecting the IPCONFIG command to a text file
and parsing it out

Windows IP Configuration


Ethernet adapter Local Area Connection:

Media State . . . . . . . . . . . : Media disconnected

Ethernet adapter Wireless Network Connection:

Connection-specific DNS Suffix . : xxx
IP Address. . . . . . . . . . . . : xx.xx.xx.xx
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : xx.xx.xx.xx

 

[Tim Marshall]

Tim, I don't understand. How do your Oracle DBAs prevent wireless
access to what databases?

Hi TC and others,

Sorry I'm later with this than I intended. This is from one of our DBAs
on the subject of options they see available for preventing wireless
access. Note that the initial paragraph is talking about access to the
database, not MS Access:

*********************

As a general rule, there are three levels at which one can potentially
implement access controls: at the network level, at the host level, or
at the individual application level.

When I say 'network level', think hardware firewall or router. Whether
that's a large enterprise model (CheckPoint, PIX), or a small SOHO one
(D-Link, Linksys, etc), the concept is the same: traffic gets policed
between your network - which typically contains more than one machine
- versus the rest of the world.

When I say 'host level', think software firewall. Desktop-wise, think
XP's Windows firewall; linux-wise, think iptables; server 2003-wise,
think its built-in firewall. Protects one host from the rest of the
world - including anything else that may be on the same network segment.

When I say 'application level', that means the application itself has
some means of IP-based access control built into it. Less common than
either of the above, the best example would probably be Apache, which
has long supported 'allow' and 'deny' directives which allow you to
specify which remote hosts are permitted to connect. Differs from a
host-based firewall in that it polices connections to that application
and that application alone.

I know next to nothing about JET - more specifically, whether or not it
supports application layer access controls of the type just described.

If it doesn't, and those posters are trying to protect a single or small
number of JET servers, a host-based firewall would probably be the best
way to go. A good excuse to upgrade to 2003, if they're currently running
2000 or (gasp!) NT, else they'll have to buy one third-party.

If they have numerous JET servers to protect, and their network is
partitioned in such a way that they're all in a VLAN by themselves,
then a single network layer firewall might be prefered (as opposed
to having to maintain multiple host-based firewalls).

As you can see, there are multiple ways, each with pluses and minuses.
What one uses in any given instance will be a function of budget and
available know-how to implement and support it, among other things.