RE: [ActiveDir] Limiting User Logon to Specific Machines

[joe]

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 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/