Lista de proyectos vacía en Project Center (Project Server 2013)

Llevo varios días con este bug (creo) y por lo visto he encontrado la solución.

Escenario:

  • SharePoint 2016
  • Project 2013 con permisos en modo SharePoint
  • Casi todo configurado con valores por defecto

Depués de jugar con los permisos del site de Project me dejaron de aparecer los proyectos en Project Center. Es decir, me aparecía el listado en blanco. Si agregaba mi usuario a Administradores del site de Project me volvían a aparecer.

Probé con muchos cambios diferentes sin mucho éxito, hasta que ayer, por casualidad agregué una tarea nueva a cada proyecto.

Por arte de mágia ahora sí me aparecen los proyectos 😀

No encontré nada en la web sobre esto, así que supongo que es un bug.

Python ignora el parámetro –proxy al intentar usar pip

No se tanto de Python como para ponerme a buscar en que parte del código está esto, pero si tienes un proxy configurado en Internet Explorer e intentas usar pip install python va a coger el párametro HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer e ignorar lo que pongas despues de –proxy.

Por ejemplo, si ejecutas pip install -–proxy=usuario:pass@proxy:8080, pero en Internet Explorer tienes configurado el proxy2:8000. Python va a ignorar el proxy:8080 e intentar salir por proxy2:8000.

Para resolver esto simplemente deshabilita el proxy de Internet Explorer mientras ejecutas pip install o algo que requiera otro proxy.

Error “Anti-Malware Engine Offline” en Deep Security Manager 9.5

Si te aparece este error en la consola del Deep Security Manager y esta solución no te funciona, prueba reiniciando la DSVA.

  1. Abre la consola de DSVA en el cliente de vSphere
  2. Presiona Alt+F2 para que aparezca el prompt de login
  3. Introduce el usuario dsva y su contraseña (por defecto es dsva)
  4. Ejecuta el comando sudo reboot (te va a pedir que introduzcas la contraseña nuevamente)

The WSMan client cannot process the request. Proxy is not supported under HTTP transport

Este error me estaba apareciendo al intentar abrir la consola de Exchange en mi nueva máquina de Windows 10.

Da casi vergüenza admitirlo, pero se me olvidó desactivar el proxy de WinHTTP después de desplegar la imágen 🙂

Solo hay que abrir una consola con permisos administrativos y ejecutar:

netsh winhttp reset proxy

Error Lync – 0x800B0110 The certificate is not valid for the requested usage

Este ha sido uno de los errores mas ráros que he visto desde que estoy trabajando en IT… Y mira que he visto cosas raras.

Estás el lunes por la mañana de lo más tranquilo en tu mesa cuando de repente empieza a decirte la gente que la federación del Lync no va, que no pueden hablar con gente de otras empresas. Abres tu cliente de Lync y efectivamente, todos los contactos externos aparecen con “Presencia Desconocida”.

Entras en el servidor de Edge y revisas el log…

error certificate usage

What? O_o

Vas al certificado en cuestión y efectivamente, el propósito Server Authentication (Proves your identity to a remote computer) ha desaparecido del certificado.

cert bad

Revisas otro servidor que tiene instalado el mismo certificado y el propósito si está

cert good

¿Eh? ¿Qué pasa aquí?

Se habrá corrompido el certificado de alguna forma. Lo eliminas y lo vuelves a importar. Nada, sigue fallando.

Sigues revisando el resto de los logs. No hay errores.

Te paras un momento a pensar. ¿Y si el problema está en la entidad certificadora? ¿Quién firmó este certificado?

Resulta que este certificado esta firmado por Symantec Class 3 Secure Server CA – G4, que a su vez está firmada por VeriSign Class 3 Public Primary Certification Authority – G5, que a su vez está firmada por VeriSign Class 3 Public Primary CA. (¿A que PKI mola?)

Empiezas a revisar cada uno de los certificados de la cadena y te fijas de que ninguno tiene el proposito de Server Authentication. Aquí pasó algo raro, muy raro.

cert chain bad

Revisas como está esto en el otro servidor.

cert chain good

El certificado está firmado por Symantec Class 3 Secure Server CA – G4, que a su vez está firmada por VeriSign. ¡AJÁ!

La CA Symantec Class 3 Secure Server CA – G4 está cross-signed (firmado cruzado) por varias CA, dentro de ellas VeriSign y VeriSign Class 3 Public Primary Certification Authority – G5. La CA VeriSign está habilitada para unos propósitos y la CA VeriSign Class 3 Public Primary CA (que es la que firma VeriSign Class 3 Public Primary Certification Authority – G5) está habilitada para otros y NO incluye Server Authentication. (¿A que PKI mola MUCHO?)

code signing

Pero… ¿Y cómo es que antes si funcionaba?

Existe algo llamado Automatic Root Certificates Update, es un componente de Windows que actualiza automáticamente el listado de certificados raíz de un equipo y sus propósitos. En los logs de Windows queda registrado bajo el source CAPI2

capi update

Como se puede ver en la imagen, durante la madrugada se actualizó el certificado de VeriSign Class 3 Public Primary CA y supongo que ahí fue cuando se le eliminó el propósito de Server Authentication.

Pero… ¿Y por qué en el otro servidor no falló?

Como puse arriba, la CA VeriSign Class 3 Public Primary Certification Authority – G5 tiene un firmado cruzado. En el servidor que seguía funcionando correctamente SI estaba instalado el certifcado de VeriSign por lo que el certificado de Lync Edge Services tenía un camino que validara su propósito de Server Autentication. En el servidor donde falló, el certificado de VeriSign no estaba instalado, por lo que el certificado final parecía inválido. El tema se resolvió instalando los certificados nuevos de Symantec en el servidor de Edge.

No quiero saber nada de PKI por un tiempo… 🙂

Exportar listado de permisos de buzones de Enterprise Vault

Aquí dejo una consulta de SQL muy útil que exporta todos los permisos asignados a todos los buzones dentro de Enterprise Vault.

El flujo de la consulta es más o menos este:

  1. Chequea si existe la función para convertir SID de texto a binary. Si existe la elimina.
  2. Crea la función para convertir SID de texto a binary
  3. Saca el listado de permisos
  4. Elimina la función creada en el paso 2

Viene genial para saber hacer auditoría de los buzones o para saber si hay que notificar a alguien antes de eliminar un buzón cualquiera.

La consulta la saqué de este video que por alguna razón el autor no la puso en los comentarios.

MDT 2013 para Lite-Touch no permite usar IP estática

Al iniciar un equipo con MDT 2013, si seleccionas la opción de configurar una IP estática te darás cuenta de que te aparece el siguiente error:

error mdt 1

Es un bug del MDT 2013 que aún no han solucionado. Por fortuna el workaround es muy sencillo. Solo tienes que pulsar F8 e introducir los siguientes comandos:


netsh interface ip set address "Ethernet" static IP MASCARA GATEWAY

netsh interface ip add dns "Ethernet" DNS

Una vez introducidos los comandos puedes continuar el despliegue o captura como siempre.

Referencia

Configuración de NXLog y Logstash para archivo Netlogon.log

En la entrada anterior explicaba cómo habilitar el debug log del servicio Netlogon para poder ver los enventos de logon usando NTLM en los controladores de dominio. Para analizar estos logs de forma más fácil podemos enviarlos a ELK usando NXLog.

NXLog es un forwarder de logs multiplataforma, no necesita Java y más liviano que el Logstash.

Los archivos de configuración del NXLog y Logstash para enviar los eventos de netlogon.log a ELK los puedes decargar desde aquí.

La instalación de ELK es bastante sencilla, yo usé la guía de Digital Ocean.

Habilitar logging de netlogon sólo para eventos de Logon

Si tienes habilitada la auditoría de eventos de logon en tus controladores de dominio probablemente te hayas dado cuenta de que solamente quedan registrados los eventos de Kerberos.

Si tienes un proxy en el que los usuarios se autentican con NTLM usando una cuenta de dominio verás que estos eventos no quedan registrados en el visor de eventos del controlador de dominio. Si embargo, sí quedarían en el propio proxy si este tiene habilitada la auditoría de eventos de logon.

Para poder ver estos inicios de sesión tienes que tener habilitado el debug logging en los controladores de dominio. Habilitar esto es muy fácil y lo indica claramente en este KB de Microsoft. El problema es que si sigues los pasos de este KB vas a ver en el log muchos más eventos de los que seguramente te interesan.

Si solamente quieres que se registren los eventos de Logon tienes que ejecutar el siguiente comando en todos tus controladores de dominio:

nltest /DBFlag:0x20000004

Después de que ejecutes ese comando vas a ver los registros de inicio de sesión en el archivo C:\Windows\Debug\netlogon.log. Este archivo lo puedes enviar a tu sistema de centralización de logs para un posterior analísis.

Para desactivar el registro de estos eventos basta con ejecutar el siguiente comando:

nltest /DBFlag:0x0

Exportar tracking log de Exchange a CSV

Aquí os dejo un script muy sencillo que exporta el tracking log de Exchange a formato CSV, que es mucho más facil de inspeccionar en Excel.

La diferencia de este script con otros es que los campos como Recipients y RecipientStatus están completamente expandidos. Si exportas el resultado de Get-MessageTrackingLog directamente a Export-Csv estos campos aparecen como System.String[].

Para ejecutarlo solo tenéis que cambiar los parámetros inicio y fin.

exportarTrackingLog