Error de Kerbauth al iniciar EMS – Exchange 2016/2013

Hola amigos,

Recientemente me contactaron debido a un problema que se presentaba en un ambiente al momento de cargar Exchange Management Shell [EMS],  Este error se presenta para Exchange 2016/2013/2010.  Que como bien sabemos también es conocido como el Poderoso Exchangiiiiiiiii.

El error inicial indicaba lo siguiente:

«Connecting to remote server failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid»

Tuvimos que cargar el PS Snapin de Exchange directametne en Windows Powershell. Pueden cargar los PS Snapins de Exchange mediante los siguientes comandos:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin [Exchange 2007]
add-pssnapin microsoft.exchange.management.powershell.e2010 [Exchange 2010]
add-pssnapin microsoft.exchange.management.powershell.Snapin [Exchange 2013]

Detecte que no existía un directorio virtual de Powershell visible en IIS, sin embargo Exchange lo detectaba, así que procedí a recrear el directorio virtual de PowerShell con los comandos:

Get-PowershellVirtualDirectory | Remove-PowershellVirtualDirectory

New-PowerShellVirtualDirectory -Name PowerShell

Una vez creado el directorio virtual, EMS seguia mostrando el error:

«Connecting to remote server failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid»

Despues de realizar las validaciones basicas (pre-requisitos instalados, configuraciones del directorio virtual, eventvwr, los servicios, la caracteristica de WinRM etc) me percate que dentro de IIS->Powershell->modules, el modulo de Kerbauth se mostraba sin ruta y listado como administrado en lugar de nativo. Así que procedi a quitar el modulo y volver a configurarlo como modulo nativo

Al intentar configurar el modulo nativo desde el VD de Powershell; Kerbauth no estaba presente. Se valido que el modulo no estuviera cargado directamente en Default Web Site.

Las siguientes verdades aplican para kerbauth.dll

1. Kerbauth = Kerberos authentication
2. Remote Powershell utiliza Kerberos para autenticar al usuario que esta conectandose
3. Kerbauth debe ser registrado directamente en el directorio virtual de PowerShell ( No en Default Web site) como modulo nativo y no heredado (administrado)

Debido a que no habia referencia hacia kerbauth.dll, el siguiente error comenzó a reflejarse en la consola de EMS:

«Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (nombre del servidor) returned an ‘access denied’ error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basicauthentication and provide user name and password. Possible authentication mechanisms reported by server: Negotiate»

El problema entonces resulto ser que no habia entrada de kerbauth en IIS y por ende no podia ser registrado correctamente. Para solucionar este problema, se realizo lo siguiente:

1.. Ir a la carpeta de inetsrv y abrir el archivo de configuración de aplicación:

C:\Windows\System32\inetsrv\config\applicationHost.config

2. Ir a <globalModules>

3.  Agregar la ruta del modulo (Podria ser tambien la situación que solo tengan que cambiar la ruta, en mi escenario particular, el modulo no estaba)

<add name=»kerbauth» image=»C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll»/>

OJO: Dependiendo la instalación de Exchange que realizaron (donde instalaron los binarios)  kerbauth.dll podría estar en una ruta diferente. Pueden validar la ruta de su instalación mediante: GCM exsetup |%{$_.Fileversioninfo}

4. Registrar el modulo en IIS. Ir a IIS->Default Web site>Powershell->Modules->Configure Native Modules->Seleccionar Kerbauth

5. Ejecutar IISRESET

Una vez realizado esto: EMS cargo sin problemas, recomiendo que de igual manera validen:

1.  Que las rutas de WSMan y Kerbauth reflejen la ruta completa «C:\Windows\…» y no variables como  %ExchangeInstallPath%. Ya que muchas veces durante la reinstalación se les cambia el drive
2. Que Kerbauth se muestre como un modulo nativo y no como administrado
3. Que el directorio virtual de Powershell  tenga SSL deshabilitado
4. Que los pre-requisitos estén instalados
5. Que WinRM este configurado
6. Que los Application pools esten iniciados
7. Que el sitio de IIS este iniciado

!Enhorabuena! Han aprendido a solucionar algunos errores relacionados al modulo nativo de Kerbauth para Exchange Server 2016/2013/2010. Coman una galleta y dense una palmada en la espalda, se lo han ganado

Por Geovany Acevedo

Coman frutas y verduras