RE: [ActiveDir] Limiting User Logon to Specific Machines

[Edwin]

Hello Everyone:   Why not make them stand alone machines?  These are in fact “learning play toys” for the “inexperienced user” therefore a domain is not necessarily required.   If it is possible, I would suggest isolating that room from your existing network and building an ADS machine.  I would make sure that the workstations support PXE before doing so.  The machines in the classroom would all then be configured to listen to PXE requests and have images pushed to them as needed.  Using this method would do a couple of things.   100% isolation from the existing domain leaving no possible risk to the rest of your network infrastructure. If the user were to somehow break something because you thought something was configured that should have denied access, you can simply push a new image at the machine with minimal effort.  You can also update your image so that you can update any new security changes you would like to implement. You will not have to waste the time and resources in your current environment managing workstations that are not a critical aspect of the entire network.   Another thing that I think is the most important is the fact that you have isolated the communal user from doing anything outside of the classroom.   If I were a student of the class taking entry level computer training sessions and had years of computer experience under my belt including several personally written virus I would be very upset and bored.  I would be finding a way to break something.  Add to that the fact that I know everyone is using a global user, therefore if I did anything malicious I could probably get away with it because it is not tied to my unique account ID.  I could do anything I wanted to with minimal risk to myself of getting caught.   If it were me and I were in this situation this is what I would do.  You could also expand upon this and create a new domain that has a specific purpose for this classroom environment.  The domain would have nothing to do with the rest of the network.  Then you can eliminate the communal user, still manage all workstations within the isolated domain and provide the highest level of security to the rest of the network.  You would also be under the protection of the ADS server should anything go bad to where you had to push out new images to the workstations.   My two cents, Edwin   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Aragon Sent: Thursday, November 03, 2005 8:39 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Limiting User Logon to Specific Machines   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   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, November 03, 2005 3:50 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Limiting User Logon to Specific Machines 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   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Aragon Sent: Thursday, November 03, 2005 6:10 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Limiting User Logon to Specific Machines 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     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Za Vue Sent: Thursday, November 03, 2005 10:11 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Limiting User Logon to Specific Machines 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 thecomputing resources on campus they have to demonstrate a level of knowledgeor 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 availableto them in the regular computing labs across campus). The lab we use consists of about 250 workstations.  There are usually threefull classes run each semester.  To simplify things, we have created acommunal user for use within the lab.  This carries with it certain securityrisks we are trying to minimize.  One thing we wanted to do was to limit theuse of this communal user to the systems within the lab.  That is, we don'twant this user object to be able to log on to any other system within theuniversity (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 NetBIOSnames 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.aspxList FAQ    : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/    List info   : http://www.activedir.org/List.aspxList FAQ    : http://www.activedir.org/ListFAQ.aspxList 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/