Universal Forwarder no envía logs al servidor de Splunk

Hoy estuve mas tiempo del que quería instalando el Forwarder de Splunk en un nuevo servidor. Aparentemente, en algún momento entre la versión 6.1 y 6.2.1 cambiaron las configuraciones por defecto.

Al ejecutar netstat el cliente aparecía conectado al servidor, sin embargo, no se estaban recibiendo los logs de [WinEventLog://Security].

El culpable es el inputs.conf de %ProgramFiles%\SplunkUniversalForwarder\etc\apps\Splunk_TA_windows\default\ que ahora viene con el parámetro index = wineventlog por defecto.

Para solucionarlo solo hay que poner en %ProgramFiles%\SplunkUniversalForwarder\etc\apps\Splunk_TA_windows\local\inputs.conf, debajo de [WinEventLog://Security] el parametro index = main (o el nombre de tu índice) y reiniciar el servicio SplunkForwarder

Active Directory, el atributo pwdLastSet y cómo extender tiempo de expiración de una contraseña

Hoy quiero hablar un poco sobre el atributo pwdLastSet y su importancia.

Este es uno de esos atributos que no se suele mirar mucho, pero que puede ser de mucha utilidad si se sabe usar.

Cada vez que cambiamos nuestra contraseña en Active Directory se modifica este atributo y se guarda el Time Stamp correspondiente a la fecha/hora de ese momento. Este valor solo puede ser asignado por SYSTEM, por lo que las únicas formas de cambiarlo son:

  1. Cambiando la contraseña
  2. Marcando la casilla el “El usuario debe cambiar la contraseña en el siguiente inicio de sesión”

Si pedimos que el usuario cambie contraseña en el próximo inicio de sesión el sistema cambia el valor de este atributo a 0.

pwdLastSet1

Si tenemos aplicada una política que pide que los usuarios cambien de contraseña a cada X días el sistema lo que hace es calcular si la contraseña está caducada en base a este atributo, restándole el valor al Time Stamp del momento en el que iniciamos sesión y convirtiendo este valor a días.

Teniendo en cuenta esto útlimo, aquí va el tip:

Supongamos tenemos una política que pide cambio cada 30 días, ahora imagina la siguiente situación.

El CEO se va de vacaciones cuando han pasado 29 días desde que cambió la contraseña. Al día siguiente te llama de emergencia porque el móvil no le sincroniza el correo o no se puede conectar a la VPN corporativa. ¿Cómo hacemos para extenderle el tiempo de caducidad de la contraseña sin cambiarla?

Tenemos tres posibilidades:

  1. Te da su contraseña y le das a cambiar contraseña poniendo la misma que tenía, violando seguramente la política de seguridad de la empresa.
  2. Editamos la cuenta del usuario marcando la casilla “La contraseña nunca expira”, violando nuevamente la política de seguridad.
  3. Le extiendes el tiempo de caducidad a la contraseña actual.

¿Cómo hacemos esto último? Muy facil, hay un tercer posible valor que le podemos asignar al atributo pwdLastSet. Si colocamos el valor -1 utilizando el editor de atributos del ADUC (Active Directory Users and Computers) el sistema convierte este número al Time Stamp actual, dándole a la contraseña otros 30 días de vigencia.

Un punto importante es que no le podemos asignar el valor -1 directamente. Primero hay que asignarle 0, guardar y salir de la cuenta, enterar nuevamente y cambiar el valor a -1. Esto lo podemos hacer más rápidamente con el siguiente script de Powershell.


$cuenta = "usuario del CEO"
Set-QADUser -Identity $cuenta -ObjectAttributes @{pwdLastSet='0'}
Set-QADUser -Identity $cuenta -ObjectAttributes @{pwdLastSet='-1'}

Referencia

Buscar por fecha en Outlook Web App (OWA)

Buscar en OWA correos entre determinadas fechas es menos intuitivo de lo esperado, por lo menos en Exchange 2010.

El problema está en que tenemos que utilizar las palabras clave en inglés y las fechas en formato americano, sin importar en cual idioma tenemos la interfaz de usuario.

Por ejemplo, si queremos buscar correos recibidos entre Junio del 2013 y Julio del 2015 tendríamos que colocar lo siguiente en la barra de busqueda de OWA:

received:06/01/2013..07/31/2014

Para los enviados tendríamos que colocar:

sent:06/01/2013..07/31/2014

Referencia

Administrar Active Directory con PowerShell y ActiveRoles Management Shell

La administración de Active Directory se ha hecho más sencilla con el paso de los años, se ha pasado por la interfaz ADUC (Active Directory Users and Computers), herramientas de línea de comando, el Centro de administración de Active Directory y en los últimos años los Snap-ins de PowerShell. Las interfaces gráficas son muy útiles para tareas puntulaes, tales como cambiar el nombre de un usuario, bloquear y desbloquear cuentas o mover PCs de una OU a otra. Sin embargo, para trabajos en lote es mejor utilizar scripts de PowerShell. El Snap-in de Active Directory incluído en las herramientas de RSAT de Windows 7 están bien, pero en mi opinión tiene fallos que dificultan su utilización. No quiero entrar en detalle, pero uno de estos fallos es que no muestra los Time Stamps de algunos campos en un formato legible y estos campos se utilizan mucho en los scripts.

Un sustituto de este Snap-in es el ActiveRoles Managemente Shell ofrecido de forma gratuita por DELL (antes Quest) desde hace algunos años. Lo puedes descargar desde aquí.

Algunos ejemplos de scripts que se pueden ejecutar con esta herramienta son los siguientes:

  • Listar usuarios con su última fecha de logon (la diferencia entre LastLogon y LastLogonTimeStamp para el próximo post)
    Get-QADUser -IncludedProperties LastLogonTimeStamp | Select-Object Name,ParentContainer,LastLogonTimeStamp
  • Listar usuarios deshabilitados
    Get-QADUser -Disabled:$true
  • Deshabilitar todas las cuentas de equipo que estén inactivas
    Get-QADComputer -Inactive | Disable-QADComputer
  • Exportar todos los usuarios de la OU Administración a un CSV delimitado por punto y coma
    Get-QADUser -SearchRoot "chorbo.es/Administracion" | Export-Csv -NoTypeInformation -Encoding UTF8 -Delimiter ";" UsuariosAdministracion.csv

Listar puntos de montaje en Windows

Los puntos de montaje, si bien son muy útiles algunos programas no los “entienden” y por lo tanto no los interpretan correctamente. En mi caso fue el VirusScan que no interpretaba las exclusiones correctamente.

La solución que ellos proponen es colocar la ruta verdadera en el listado de exclusiones. Para hacer esto necesitamos saber el GUID del volumén al que apunta el punto de montaje. Para saber este identificador ellos sugieren crear un fichero EICAR en la ruta a excluir y ver en los logs el GUID del volúmen. Esto para mí es bastante engorroso, es mucho más fácil ir a la linea de comandos y ejecutar la utilidad mountvol. Esta utilidad lista los puntos de montaje que tiene el sistema y a que volúmenes están apuntando.

Referencia

Error al instalar Distribution Point en SCCM 2012

Al intentar desplegar un punto de distribución me encontré con que la instalación fallaba con un error poco claro. En la pestaña de Distribution Point Configuration Status aparecía que la preparación del servidor había finalizado correctamente, sin embargo, al intentar distribuir el software del agente de SCCM la tarea fallaba. Después de forzar varias veces la distribución manualmente el error continuaba.

Revisando el log smsdpprov.log en el servidor de destino me encontré con lo siguiente:

sccm_dp

No se puede abrir el archivo D:\SCCMContentLib\DataLib\EAA00002.4.temp\ccmsetup.cab. Lógico, no se puede abrir un archivo que está en una unidad que ni siquiera existe. Este servidor no tiene unidad D:\. Entonces, ¿Por qué aparece esta ruta en los logs?

Uno de los problemas de las fusiones/separaciones de empresas es que muchas veces los proyectos quedan a medio completar y las tareas de separación no se realizan correctamente. En este caso en concreto, este servidor sí tenía una unidad D:\ y en algún momento fue un punto de distribución para otra instalación de SCCM. Sin embargo, antes de la separación entre las dos empresas no se eliminó este servidor de la jerarquía del SCCM, por lo que los antiguos valores continuaban en el registro.

Para solucionar este problema tuve que editar el registro de windows. La ruta en este caso fue HKLM\Software\Microsoft\SMS\DP. El valor problemático era ContentLibraryPath y tuve que cambiarlo de D:\SCCMContentLib a E:\SCCMContentLib.

sccm_dp2

Una vez hecho este cambio y forzada nuevamente la distribución de los archivos la tarea se ejecutó correctamente.

Error 0x80070660 (1632) al instalar Microsoft Visual C++ 2010 Redistributable (SCCM)

Hoy estaba preparando una máquina para hacer pruebas de despliegues de software con el SCCM 2012 R2 y me encontré con problemas apenas al iniciar. Creé una máquina virtual desde cero y le instalé Windows 7 Professional x64 con el Service Pack 1, la agregué al dominio y luego intenté instalarle el cliente de SCCM.

La instalación manual del cliente es muy fácil, solo tenía que copiar el archivo ccmsetup.exe al equipo y ejecutar el siguiente comando:

CCMSetup.exe /mp:MISERVIDOR /logon SMSSITECODE=AUTO

Sin embargo, pasados varios minutos me di cuenta de que el proceso ccmsetup.exe había finalizado y el agente todavía no estaba instalado.

Al abrir el fichero C:\Windows\ccmsetup\logs\ccmsetup.log vi que la instalación había fallado retornado el error 0x80070660. Este error es una “traducción” del error 1632.

ccmsetup

Si buscamos en la documentación de Microsoft qué significa este error veremos que hace referencia a la carpeta de archivos temporales, indicando que la unidad donde esta se encuentra puede estar llena o que el instalador no tiene permisos de escritura sobre la misma.

La carpeta de archivos temporales por lo general está en la ruta C:\Users\USUARIO\AppData\Local\Temp y en mi caso la unidad C:\ tenía espacio de sobra y los permisos eran correctos, así que el problema debía estar en otra parte.

Después de estar casi una hora revisando logs sin éxito decidí mirar en el log del instalador del Microsoft Visual C++ 2010 Redistributable. Este log se encuentra en la carpeta de archivos temporales con el nombre Microsoft Visual C++ 2010 x64 Redistributable Setup_FECHA_HORA.txt.

ccmsetup2

Como podéis ver en la captura, el log no dice mucho acerca de cual puede ser el origen del error. Sin embargo, este hace referencia a la carpeta C:\Windows\Installer. Intenté entrar a esta carpeta para ver si encontraba alguna pista sobre el origen del error y para mi sorpresa la carpeta no existía.

Creé la carpeta e intenté ejecutar la instalación nuevamente y esta vez concluyó exitosamente.

En resumen, el error fue causado porque, al ser una instalación nueva, el servicio de Windows Installer nunca se había ejecutado, por lo tanto la carpeta C:\Windows\Installer no había sido creada.

Instalar Agente de OfficeScan 11 de forma remota

Hace poco me tocó cambiar el antivirus corporativo a OfficeScan 11 y una de las cosas que tenía que resolver era como hacer el despliegue de los agentes de forma remota. El despliegue a través de la consola de OfficeScan requiere que el servicio de Registro Remoto esté habilitado en los equipos y en la mayoría de los nuestros está deshabilitado.

Después de evaluar varias alternarivas (scripts de logon, política de despliegue de software) me decanté por utilizar PsExec. Esta utilidad es parte del conjunto de PsTools desarrolladas por Mark Russinovich y nos permite principalmente ejecutar programas de forma remota. Para empezar a utilizar la herramienta solo hay que descargarla y extraerla en cualquier carpeta.

Para hacer la instalación del OfficeScan lo primero que hay que hacer es empaquetar el instalador, esto lo hacemos desde el propio servidor donde está instalada la consola. La herramienta para empaquetar es ClnPack.exe y en la instalación por defecto debería estar en C:\Program Files (x86)\Trend Micro\OfficeScan\PCCSRV\Admin\Utility\ClientPackager.

Ejecutamos la aplicación, marcamos la opción de Silent Installation para evitar que al usuario remoto le aparezca la ventana de instalación, luego especificamos un archivo de destino (Output File) y finalmente hacemos clic en Create:

Remote Install

Pasados unos segundos se creará un instalador en la carpeta que hallamos especificado anteriormente:

Remote Install 2

Este instalador tenemos que copiarlo a alguna carpeta compartida para que sea accesible por todos los equipos.

Abrimos una consola y nos situamos en el directorio donde hallamos extraído la herramienta PsExec. Para hacer la instalación ejecutamos el siguiente comando:

psexec -s \\equipoRemoto \\servidorFicheros\carpetaCompartida\MiInstalador.exe

Si no hay problemas de ningún tipo PsExec debería retornar un codigo de error 0:

Remote Install

Después de unos segundos la instalación se iniciará. Esto lo podemos confirmar abriendo el administrador de tareas del equipo remoto:

Remote Install 4

Dependiendo de las caracteristicas del equipo la instalación del agente puede tardar entre 10 y 30 minutos. Si hemos hecho todo bien, pasado este tiempo nos aparecerá el icono del agente de OfficeScan:

Remote Install 5