Ir al contenido principal

Formas de cerrar la sesion de un usuario Windows en remoto



   Recientemente he tenido que hacer limpieza de restos debido a la baja de un compañero administrador. Unos días después, mi script de chequeo de logs todavía me cantaba errores que podían estar relacionados con el uso de su cuenta de administrador. Lo mas probable es que hubiera sesiones remotas abiertas con su usuario (ya deshabilitado), desperdigadas por los servidores de la compañía. Para buscarlas, hay varias formas de hacerlo. A continuación, os muestro dos de ellas.


   THE OLD WAY, usar los comandos quser y logout

   Primero necesitamos ver que usuarios están logados en el servidor remoto y con que id de sesión para después, poder hacerles logof remotamente. Para ello, usaremos el comando quser de la siguiente forma:
Quser /server:servername
   Este comando devuelve la lista de usuarios logados en un equipo remoto, indicando el nombre, el id de la sesión, el estado y los tiempos de logon y de inactividad. Una vez que tengamos todos esos datos, podremos decidir a qué sesiones queremos cerrar y cuáles no. De las sesiones que queramos cerrar, apuntaremos su id de sesión y lo utilizaremos con el comando logoff de la siguiente forma:
Logoff sesionID /SERVER:servername [/V]


THE COOL NEW WAY, usar powershell

   Porque si, porque powershell es cool y nosotros queremos ser cool, ¿verdad? El problema de usar powershell, es que no hay una forma estándar de comprobar que usuarios hay logados en una maquina remota. Si, siempre podemos invocar quser desde powershell, ¿pero de verdad quieres pelearte parseando el texto de la salida? Personalmente prefiero usar otra técnica. Simplemente busco procesos “explorer.exe” (se crea uno por cada sesión local o remota que haya) y extraigo el nombre del usuario al que pertenece el proceso. Si, no muestra información del estado de la sesión, ni de la hora de inicio ni de cuanto tiempo lleva inactiva… Pero me vale para meterlo en un objeto y hacer algo muy muy Cool después. Pero primero vamos a echarle un vistazo a la función que utilizo:

function Get-LoggedOnUser

 {
     [CmdletBinding()]
     param
     (
         [Parameter(ValueFromPipeline)]
         [ValidateScript({Test-Connection -ComputerName $_.dnshostname -Quiet -Count 1})]
         [ValidateNotNullOrEmpty()]
         [Microsoft.ActiveDirectory.Management.ADComputer[]]$Computer
     )
     
     process{
        $output = @()
        $explorerprocesses = @(Get-WmiObject -ComputerName $Computer.DNSHostName -Query "Select * FROM Win32_Process WHERE Name='explorer.exe'" -ErrorAction SilentlyContinue)
        foreach($process in $explorerprocesses){ 
            $myObject = New-Object PSCustomObject
            $myObject | Add-Member -type NoteProperty -name ComputerName -Value ($Computer.DNSHostName)
            $myObject | Add-Member -type NoteProperty -name SessionUser -Value ($process.getowner().user)
            $myObject | Add-Member -type NoteProperty -name SessionUserDomain -Value ($process.getowner().domain)
            $myObject | Add-Member -type NoteProperty -name SessionId -Value ($process.sessionId)
            $output += $myObject
        }
        Return $output
     }
 }


   Como podéis ver, el código de esta función acepta objetos de tipo ADComputer a través del pipe y devuelve un objeto personalizado con la información de las sesiones de usuario abierta usando los procesos explorer.exe para ello.
   Esto nos permite hacer búsquedas de equipos en AD con el cmdlet get-adcomputer y redirigir la salida a nuestra funcion.
   Una vez que hemos hecho esto, pues ya podemos meterle el código que queramos al objeto devuelto, bien usando logoff, con una pssession, o lo que queramos. Por ejemplo:

Get-ADComputer -Filter 'OperatingSystem -like "Windows Server*"' | Get-LoggedOnUser

Comentarios

Entradas populares de este blog

Error id 12294, La base de datos SAM no pudo bloquear la cuenta de administrador...

Últimamente hemos estado teniendo un problema de esos que a todo administrador de sistemas le trae de cabeza... Al menos hasta que lo ha solucionado una vez. Para aquellos de vosotros que habéis llegado hasta aqui después de toparos con el en vuestro trabajo diario y no sabeis muy bien que hacer, voy a indicaros paso por paso como solucionarlo. El error consiste en el intento reptitivo de bloqueo de la cuenta de Administrador del dominio por parte de una maquina del dominio. Estos errores se generan en el registro de eventos de sistema con el id 12294 y con origen Directory-Services-SAM si es Windows 2008 o SAM si es Windows 2003 o anterior. El error en si no aunque parece grave, no debe preocuparnos tanto, ya que la cuenta de administrador de dominio nunca se bloquea. Lo que si nos molestara mas, es el hecho de que estos errores saturan nuestro log de eventos de sistema, así como el registro de seguridad del DC. El problema que nos encontramos cuando intentamos

Solucionar Error 8344 “Insufficient access rights to perform the operation.” En Azure AD connect

Ayer termine de instalar y configurar Azure AD connect. Para los que no lo sepáis, Azure AD connect es el programa que se utiliza para sincronizar objetos de tu directorio activo local con el directorio activo de azure. Podéis acceder a la estupenda documentación de Microsoft aquí. El caso es que después de terminar la configuración, estuve repasando que las primeras sincronizaciones fueran correctas cuando vi que aparecía una tarea con errores en Azure AD sync service. El fallo era el siguiente: Como podéis ver, esta tarea de export, que ya os voy diciendo que era una sincronización de contraseñas, falla por un problema de permisos. La verdad es que era un poco confuso, ya que había seguido la documentación de Microsoft para la implementación al pie de la letra y cumplido todos los prerrequisitos. ¿Se me escapaba algo? Al final, la respuesta era bastante sencilla. Este directorio activo no lo desplegué yo, así que hay algunas cosillas “heredadas”. Una de ellas es que una Unidad Organi

DNS y reenviadores condicionales...

Resulta que estamos migrando a Windows 2008 R2 para poder poner GPOs personalizadas por OU, y el otro día nos surgió un problemilla relacionado con los reenviadores condicionales del servicio DNS en 2008 (anteriormente, los teníamos en 2003 R2). Se nos paso configurar el reenvío de las peticiones de nuestro subdominio principal a nuestro dominio raíz, lo cual, teníamos hecho mediante el uso de reenviadores condicionales. Entramos en el nuevo servidor DNS para configurarlos y @_@ ¡¡no estaban!! Resulta que los amigos de Microsoft han cambiado las pestañas de opciones del servidor DNS y las han dejado así: Como podéis ver, el reenvío de peticiones basado en sufijo, ha desaparecido. Aparentemente solo se permite el reenvío global de peticiones, ¿no? Bueno, pues no, solo lo han cambiado de sitio. Con Windows 2003, cuando querías configurar el reenvío de peticiones DNS basado en dominio, tenias que hacerlo servidor por servidor, ya que la pestaña correspondiente, se encontraba dent