Joe,
I agree, it would be impossible to block all avenues, but I
don't think that would be necessary. The users we are concerned with are
inexperienced students (hence the need for the class) who, as students will
often do, find it easier to logon with a communal account than with their own
(the latter requires they remember their password, which is a new experience for
many of them - we get between 450 and 600 requests a week to reset passwords
because a lot of students can't remember what password they set the
previous day). We are trying to prevent them from using the communal user
everywhere except on the 250 lab computers, especially because they are not
authorized to use any other system on campus until they complete the
class.
I like the idea of using a logon script. That
might be doable, as all the machines in the lab have the same prefix. And
while I can't speak for others, I for one would be very interested to get a copy
of the tool/script you described.
Thank
you for the assistance.
David Aragon
Use a logon script.
Nothing you do can
prevent all mechanisms that could be used to use the ID (i.e. runas or
look-a-likes, net use /user, etc) and the fact
that you are targeting one single ID says to me logon script for that one
ID. Have it look for something on the machine or the machine name itself and
if it doesn't find it, it immediately logs back off.
I actually wrote a Quick Logoff tool back in like
2001 (called qlogoff) that is specifically for getting people logged off of a
machine quickly if they shouldn't be there. I used it for logon scripts used
by domain admin IDs, anytime they tried to log onto workstations interactively
they got booted right back off. Obviously it could be overridden since they
were DAs but it served as a gentle reminder of proper use of the ID. I wanted
to expand it to trying to interactively log onto any machine that wasn't a DC.
If I ran an environment in the future with the RODCs and had delegated the
ability to administrate one of the RODCs to a local admin I certainly would
make sure domain admins couldn't log into those machines interactively. I
would prevent the attempt even but no way to do that without dorking with the
GINA and if someone really wants to mess you up, they have already replaced
the GINA.
So anyway, the tool determines the OS type, if it is
NT based it will gracefully exit with a EQX_LOGOFF|EQX_FORCE so there is no
monkeying around and if it is Win9x it will be less nice and find the
main explorer instance and kill it hanging the
workstation.
If there is interest in that, I could be convinced to
post it up on the website.
joe
Thank you for the suggestions.
We had originally considered a GPO (and ultimately
may have to go back that direction) but had dismissed the idea due (in large
part) to the socio-political structure we have (who would have believed a
university could be so political, I know I didn't). Each OU represents a
separate college or major organization which enjoys a kind of
autonomy. They manage the GPO's and computer activities within
their OU, users are centrally managed. In order to implement a GPO that
might affect an OU, we end up needing to get their permission (odd, I know,
but it was a compromise worked out over several years worth of
negotiations (which, by the way, are still on going) with the different
colleges, unions, and organizations involved in an effort to unify services
and provide platform independent IdM (Identity Management) and single
sign-on for the staff, faculty, and students across the campus). I was
hoping for something less invasive, which is why I had tried the "Log On To"
method.
Come to think of it, I need to check when they (and who
"they" are that) added politician to my job description, but that's a
different issue for another time.
Thank you again for the suggestions, they are
appreciated.
David Aragon
I agree that GPO is the route to take. There is too much work
keying in what workstations an account can log into. I placed all lab
machines and lab accounts into a single OU and apply GPO.
ASB wrote:
One option is to deny Logon access to this account via User Rights on
machines outside the lab.
Configure with GPO.
-ASB
FAST, CHEAP, SECURE: Pick Any TWO
http://www.ultratech-llc.com/KB/
On 11/3/05, David Aragon <[EMAIL PROTECTED]> wrote:
Background:
We are a fair sized university. Before any students can use any of the
computing resources on campus they have to demonstrate a level of knowledge
or take a class (3 hours a week for 16 weeks) on basic computing skills
(this class also covers how to use the various pieces of software available
to them in the regular computing labs across campus).
The lab we use consists of about 250 workstations. There are usually three
full classes run each semester. To simplify things, we have created a
communal user for use within the lab. This carries with it certain security
risks we are trying to minimize. One thing we wanted to do was to limit the
use of this communal user to the systems within the lab. That is, we don't
want this user object to be able to log on to any other system within the
university (1 domain, 1 site, approx 8000 systems across 18 OU's).
Problem:
The "Log On To" setting in the user object seems to be limited to 64 NetBIOS
names and 1024 bytes of information.
Does anyone have any ideas? I'm sure I've just overlooked something basic.
Thank you in advance for your comments and suggestions.
David Aragon
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx List FAQ
: http://www.activedir.org/ListFAQ.aspx List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
|