Security & Active Directory Options Bonus update: Ghost computers on network

Thanatos

So, my supervisor today asked me to devise a plan in case they ever have to fire someone under unpleasant circumstances again. I'm the IT guy, in an XP SP2/3 environment, with a single Windows Server 2003 server. We have VPN enabled. Obviously, we can disable the account via Active Directory, but what if the person is currently logged in? One of our contracted IT-People (I'm the only in-house IT guy) recommended PSExec, which, based on what limited reading I did, sounds like witchcraft, but could be just what we're looking for. What's the best way to deal with blocking their access to VPN (assuming that they're logged in at home, and don't log out, allowing the disabling of the user account to take effect)? Is there a way to force-logoff specific users from the domain (rather than specific computers) using Active Directory? Is there anything else I'm likely missing? And is there a good guide to basic uses of Active Directory online somewhere (I already know the basic basics of creating new users and disabling/deleting old ones, but something a little beyond that)?

Djeet

Particulars will vary depending upon how your VPN is setup. If the VPN uses certificates for authentication then I'd revoke his certificate (Certification Authority MMC or snap-in), disable his AD account (also probably reset his password and remove him from all groups), and then boot his remote access connection if he's logged on (Routing and Remote Access MMC or snap-in). If VPN is user account plus secret then I'd do the same (skipping the cert revocation). If VPN is a separate appliance/device then once you've completed the AD operations it would need to be configured to not let him in anymore. If you're using Internet Security and Acceleration Server 2000/2004 (might be if you're using SBS 2000/2003) you can use ISA management console to disconnect his VPN connection.

Then move on to check out AD for users I don't recognize starting in the administrative groups, and after that check out any machines to which he had administrative access. If he had admin access to Exchange I'd check to see if any mailboxes had been configured to forward emails.

PSExec is probably a good program; I haven't used it, but I've used a few other utilities written by that author. It seems more geared to remotely executing commands. Though it looks like it could be blocked by AV/malware/spyware-prevention software.

3lwap0

Thanatos - I would seriously look into PStools.

http://technet.microsoft.com/en-us/sysinternals/bb897541.aspx

That's a good one for forcing users to shutdown/logoff, once you've killed their VPN session. It can even lock a workstation right in front of a user. If you wanted a more custom solution, you could write a script that will disable a account in AD, and then force a shutdown. PStools is robust, and inelegant at the best of times, but we use it in my shop, and it works.

Thanatos

So, I've been messing around with PSTools, but I can't get it to work. I give it the right computer name, it tries to run on the wrong computer, and just gives me "Error opening HKEY_USERS for <computer name>. Unable to query resource logons." Is it likely our virus protection blocking it? Or am I doing something wrong? I'm doing "psusersloggedon <computer name>" from the command prompt. I even tried it with the full address (i.e. "<computer name>.domain.net") and the same thing happens.

Djeet

If you are giving it the right computer name, and the commands are running on the wrong computer, that sounds like a name resolution issue (e.g. there´s a stale entry in DNS such that requests to computername.domain.net are going to the wrong IP). If you go to the command prompt and do ¨nslookup computername.domain.net¨and compare to ïpconfig¨run at the command line on the target computer, do the IP´s match up?

underdonk

I think you're going in the wrong direction looking for an automated tool to do this.

In the case of separations (unpleasant or otherwise), it's generally more important to have a formalized procedure with an accompanying checklist detailing what equipment to recover, what accounts to disable, what systems to check to ensure that all potentially active sessions are closed (and if sessions are still open, close them manually and verify that they are closed), etc. You should really be thinking about this more from an operational aspect rather than a technical aspect, IMO.

From a technical aspect, though, if you've enabled IPSec and IP forwarding to provide VPN services on that Windows server, there should be an MMC snap-in (most likely "IP Security Monitor") that will allow you to view currently active sessions. There is also most likely an associated right-click -> disconnect session context menu/option that you could use (under "Security Associations" either under Quick Mode or Main Mode depending on how things are setup) to kill their VPN session. I am more familiar with Cisco and Nortel VPN solutions, though, so don't take that as fact.

Hope this helps.

Thanatos

underdonk wrote: »

I think you're going in the wrong direction looking for an automated tool to do this.

In the case of separations (unpleasant or otherwise), it's generally more important to have a formalized procedure with an accompanying checklist detailing what equipment to recover, what accounts to disable, what systems to check to ensure that all potentially active sessions are closed (and if sessions are still open, close them manually and verify that they are closed), etc. You should really be thinking about this more from an operational aspect rather than a technical aspect, IMO.

Right, odds are we're just going to ask the person to go into a meeting room or office without knowing they're about to be fired, and have someone nearby log them off of their computer while they're in there. Disabling their account/changing their password via Active Directory is a no-brainer. These are just contingencies my boss would like to have in place in case doing that isn't possible.

underdonk wrote: »

From a technical aspect, though, if you've enabled IPSec and IP forwarding to provide VPN services on that Windows server, there should be an MMC snap-in (most likely "IP Security Monitor") that will allow you to view currently active sessions. There is also most likely an associated right-click -> disconnect session context menu/option that you could use (under "Security Associations" either under Quick Mode or Main Mode depending on how things are setup) to kill their VPN session. I am more familiar with Cisco and Nortel VPN solutions, though, so don't take that as fact.

Hope this helps.

I'm not sure what our VPN is, but I'll definitely ask (I haven't been working here very long, and thus far, our VPN has worked without problem, so I haven't had reason to familiarize myself with it yet).

rfalias

Is it your hardware they are using to VPN with from home?
VB Scripts can do this, given it's your hardware and you know the administrator credentials.

underdonk

Thanatos wrote: »

Right, odds are we're just going to ask the person to go into a meeting room or office without knowing they're about to be fired, and have someone nearby log them off of their computer while they're in there. Disabling their account/changing their password via Active Directory is a no-brainer. These are just contingencies my boss would like to have in place in case doing that isn't possible.

Ah, good times.

Also, don't revoke any user- or machine-specific certificates associated with the user or his/her equipment as a previous poster mentioned, unless you're sure that you specifically have the EFS DRA certificates issued correctly and have tested the "recovery" of encrypted data with said certificate. With your PKI (most likely) only being accessibly internally, it's generally an acceptable risk (regarding not revoking the certs) as the user's access has been disabled and others within the company (hopefully) know the user has been let go. Revoke the certificates when you delete the account rather then when you disable it.

Thanatos

underdonk wrote: »

Thanatos wrote: »

Right, odds are we're just going to ask the person to go into a meeting room or office without knowing they're about to be fired, and have someone nearby log them off of their computer while they're in there. Disabling their account/changing their password via Active Directory is a no-brainer. These are just contingencies my boss would like to have in place in case doing that isn't possible.

Ah, good times.

Also, don't revoke any user- or machine-specific certificates associated with the user or his/her equipment as a previous poster mentioned, unless you're sure that you specifically have the EFS DRA certificates issued correctly and have tested the "recovery" of encrypted data with said certificate. With your PKI (most likely) only being accessibly internally, it's generally an acceptable risk (regarding not revoking the certs) as the user's access has been disabled and others within the company (hopefully) know the user has been let go. Revoke the certificates when you delete the account rather then when you disable it.

Unless someone is putting a fair amount of work into concealing their knowhow, I have the most technical aptitude of anyone working at this office by a significant amount, and I have no idea what you just said. So, I think we're safe. :P

Djeet

I was assuming a Windows PKI, in which you can unrevoke a certificate, provided the reason for cert revocation is "Certificate Hold"; if your PKI does not provide for this then you shouldn't revoke the cert unless you're ready for it to be gone. Although disabling the AD account or resetting the password and then booting the remote access connection should be sufficient to prevent him logging on again via remote access.

Edit: Which I suppose I could have said in the earlier post.

Thanatos

Djeet wrote: »

If you are giving it the right computer name, and the commands are running on the wrong computer, that sounds like a name resolution issue (e.g. there´s a stale entry in DNS such that requests to computername.domain.net are going to the wrong IP). If you go to the command prompt and do ¨nslookup computername.domain.net¨and compare to ïpconfig¨run at the command line on the target computer, do the IP´s match up?

Just did this. The IPs match up.

underdonk

Thanatos wrote: »

Unless someone is putting a fair amount of work into concealing their knowhow, I have the most technical aptitude of anyone working at this office by a significant amount, and I have no idea what you just said. So, I think we're safe. :P

Gotcha.

Just for your edification, an Encrypting File System (EFS) (http://en.wikipedia.org/wiki/Encrypting_File_System and http://technet.microsoft.com/en-us/library/cc875821.aspx) certificate (specifically) is issued to a user to allow them to encrypt and decrypt files. Within the domain or local system, you can define a Data Recovery Agent (DRA). A DRA role is assigned to an account (typically the administrator account) that holds a recovery certificate that can decrypt any encrypted file within scope (domain or local). If this DRA is not defined, and a recovery certificate not issued, any file encrypted by the person you fired will not be able to be decrypted if you revoke their certificate. Given the situation, this could be a very bad thing, obviously. This has nothing to do with your original question, but rather details why it's a bad idea to revoke certificates immediately, as a previous poster noted you should do. Again, certificates should be revoked when a user's account is deleted and not disabled, in the event of a separation, and you shouldn't delete their account for some time (generally 30 days is given as common guidance).

Djeet wrote: »

I was assuming a Windows PKI, in which you can unrevoke a certificate, provided the reason for cert revocation is "Certificate Hold"; if your PKI does not provide for this then you shouldn't revoke the cert unless you're ready for it to be gone. Although disabling the AD account or resetting the password and then booting the remote access connection should be sufficient to prevent him logging on again via remote access.

Interesting, I'm going to have to test this out as it relates to EFS and see what it breaks. Being able to "unrevoke" a certificate is a funny concept. It seems akin to being able to "unamputate" a limb.

Thanatos

Thanatos wrote: »

Djeet wrote: »

If you are giving it the right computer name, and the commands are running on the wrong computer, that sounds like a name resolution issue (e.g. there´s a stale entry in DNS such that requests to computername.domain.net are going to the wrong IP). If you go to the command prompt and do ¨nslookup computername.domain.net¨and compare to ïpconfig¨run at the command line on the target computer, do the IP´s match up?

Just did this. The IPs match up.

I also tried running psloggedin directed at the computer it's misdirecting to, and it gives me the same error message. "Error opening HKEY_USERS for <computer name>. Unable to query resource logons."

Thanatos

underdonk wrote: »

Thanatos wrote: »

Unless someone is putting a fair amount of work into concealing their knowhow, I have the most technical aptitude of anyone working at this office by a significant amount, and I have no idea what you just said. So, I think we're safe. :P

Gotcha.

Just for your edification, an Encrypting File System (EFS) (http://en.wikipedia.org/wiki/Encrypting_File_System and http://technet.microsoft.com/en-us/library/cc875821.aspx) certificate (specifically) is issued to a user to allow them to encrypt and decrypt files. Within the domain or local system, you can define a Data Recovery Agent (DRA). A DRA role is assigned to an account (typically the administrator account) that holds a recovery certificate that can decrypt any encrypted file within scope (domain or local). If this DRA is not defined, and a recovery certificate not issued, any file encrypted by the person you fired will not be able to be decrypted if you revoke their certificate. Given the situation, this could be a very bad thing, obviously. This has nothing to do with your original question, but rather details why it's a bad idea to revoke certificates immediately, as a previous poster noted you should do. Again, certificates should be revoked when a user's account is deleted and not disabled, in the event of a separation, and you shouldn't delete their account for some time (generally 30 days is given as common guidance).

Yeah, we generally hang onto accounts for at least a week (in the case of a user who was only here a couple of days) and up to 60+ days, though like I said, I disable the account, change the password, and remove them from all groups as soon as they're gone.

Djeet

I have had, on occasion, psshutdown not work and I was never satisfied as to why. Just tried it on a remote xp pro machine and this syntax worked "psshutdown \\hostname.domainname.net -u username -p password -r -t 30". This syntax throws a dialog to the loacl user that says I'm rebooting your machine and kicks off a 30 second timer.

Waiting for reboot to see if it works by IP, which would bypass any name resolution strangeness.

Erandus

Just aim it at the IP address instead of the PC name. PSShutdown will recognize it in place of the fqdn (pcname.domain.whatever).

EDIT: If you're feeling saucy, I might suggest something like ChrisControl. It will attempt to remote to the PC via Remote Desktop, and if that fails, it will remotely deploy VNC and then connect a remote session to the PC. There's an option in VNC that will allow you to blank the local monitor of the machine and stop accepting input from the keyboard and mouse. You'd then be free to shut the PC down.

Djeet

underdonk wrote: »

Djeet wrote: »

I was assuming a Windows PKI, in which you can unrevoke a certificate, provided the reason for cert revocation is "Certificate Hold"; if your PKI does not provide for this then you shouldn't revoke the cert unless you're ready for it to be gone. Although disabling the AD account or resetting the password and then booting the remote access connection should be sufficient to prevent him logging on again via remote access.

Interesting, I'm going to have to test this out as it relates to EFS and see what it breaks. Being able to "unrevoke" a certificate is a funny concept. It seems akin to being able to "unamputate" a limb.

Let me know if it breaks EFS. We use a third party app for encryption, not EFS; though some users have decided to use full drive encryption provided by the laptop vendor on their own. I've only played with unrevoking w/r/to smartcard or certificate logon.

Thanatos

Trying the IP address was the first thing I thought of, and that didn't work, either.

C'mon, guys, I'm not that retarded.

Erandus

Thanatos wrote: »

Trying the IP address was the first thing I thought of, and that didn't work, either.

C'mon, guys, I'm not that retarded.

I never like to assume.

See the next suggestion in my edit above. Dont know if it's something you want to look into.

Out of curiosity, can you browse into the \\pcname\C$ share of the target machine?

Is the windows firewall on?

Thanatos

Interestingly, psloggedon works for a couple of other computers on the network, but not the one I'm trying to get it to work with. No firewall.

Thanatos

Okay, it suddenly started working. That's weird.

Thanatos

Seriously, the programmers of these programs need to be burned at the stake. This is witchcraft. Also, awesome.

Djeet

I couldn't get good output from psloggedon to a target machine until I authenticated a connection to it (e.g. \\computername.domainname.net\c$). It looks like it's trying to open the registry on the target machine, so it's not surprising that that would require authentication, if that's what's happening. The psshutdown command lets you specify authentication via syntax.

Thanatos

Do PSTools work on computers which are using VPN to remotely connect to a network? Because I'm getting info on a computer that isn't physically here with psloggedon.

Also, I have another problem: our IT company seems to think we have three computers that we don't. Two of them even have IPs (like, I can nslookup them). They're the ones that psloggedin seems to hang on. Is it possible that those are printers or something, or do we have ghost computers connected to our network?

underdonk

Thanatos wrote: »

Do PSTools work on computers which are using VPN to remotely connect to a network? Because I'm getting info on a computer that isn't physically here with psloggedon.

Depending on how things are setup on the VPN server and the endpoints you're connecting too, yes, they could. It certainly sounds like everything is setup to allow it.

Thanatos wrote: »

Also, I have another problem: our IT company seems to think we have three computers that we don't. Two of them even have IPs (like, I can nslookup them). They're the ones that psloggedin seems to hang on. Is it possible that those are printers or something, or do we have ghost computers connected to our network?

They could be printers, or a Windows/Unix box without NetBIOS running or a host-based firewall running. Are they on the same subnet as your workstation? If so, ping each of the IP addresses you can't identify. Open a command prompt and type "arp -a". Find the MAC address associated with the IP addresses you just pinged. Go to http://www.coffer.com/mac_find/ and type in the MAC addresses. This will help you at least identify the hardware platform; if it comes back as MAC addresses assigned to Lexmark or <insert your printer manufacturer here> than you at least have an idea of what the device is.

Thanatos

underdonk wrote: »

Thanatos wrote: »

Do PSTools work on computers which are using VPN to remotely connect to a network? Because I'm getting info on a computer that isn't physically here with psloggedon.

Depending on how things are setup on the VPN server and the endpoints you're connecting too, yes, they could. It certainly sounds like everything is setup to allow it.

Thanatos wrote: »

Also, I have another problem: our IT company seems to think we have three computers that we don't. Two of them even have IPs (like, I can nslookup them). They're the ones that psloggedin seems to hang on. Is it possible that those are printers or something, or do we have ghost computers connected to our network?

They could be printers, or a Windows/Unix box without NetBIOS running or a host-based firewall running. Are they on the same subnet as your workstation? If so, ping each of the IP addresses you can't identify. Open a command prompt and type "arp -a". Find the MAC address associated with the IP addresses you just pinged. Go to http://www.coffer.com/mac_find/ and type in the MAC addresses. This will help you at least identify the hardware platform; if it comes back as MAC addresses assigned to Lexmark or <insert your printer manufacturer here> than you at least have an idea of what the device is.

Yeah, I don't think they're printers.

I figured out that one of them is just a PC with Windows Firewall up.