none
Problemas creando un Directorio Virtual de OWA alterno con diferente tipo de autenticacion RRS feed

  • Pregunta

  • Tenemos Owa en Exchange 2013 con autenticacion FBA trabajando correctamente   https://mail.dominio.com/owa
    se necesita configurar un owavirtualdirectory adicional  con diferente tipo de autenticacion windows integrated a traves del puerto 80 con acceso solo  desde la LAN

    Para ello desde el IIS se ha creado un site nuevo llamado "Intranet"
    Y desde el EMC se procedio a crear los directorios virtuales a traves de los siguientes cmdlets:
    New-OwaVirtualDirectory -Server Name_Server -WebSiteName "Intranet"
    Set-OwaVirtualDirectory -identity "Name_Server\owa (Intranet)" -InternalUrl "http://correo.dominio.local/owa" -WindowsAuthentication $true -Basicauthentication $false -Formsauthentication $false

    New-ECPVirtualDirectory  -Server Name_Server -WebSiteName "Intranet"
    Set-ECPVirtualDirectory -identity "Name_Server\ecp (Intranet)" -InternalUrl "http://correo.dominio.local/ecp" -WindowsAuthentication $true -FormsAuthentication $false

    iisreset


    Luego de ello el acceso a  http://correo.dominio.local/owa es correcto con autenticacion integrated windows; pero el acceso al owa  por medio de fba https://mail.dominio.com/owa  se vuelve imposible, carga la pagina de logue, pero no valida las credenciales, aparentemente por temas de tipo de autenticacion
    Al revisar el tipo de autenticado por powershell esta correcto con FormsAuthentication en true, sin embargo pareciera q el Exchange no lo entendiera asi y hay que restaurar dichos permisos

    Por lo tanto realizo lo siguiente:

    Set-OwaVirtualDirectory -identity "Name_Server\owa (Default Web Site)" -FormsAuthentication $false
    Set-ecpVirtualDirectory -identity "Name_Server\ecp (Default Web Site)" -FormsAuthentication $true
    Set-OwaVirtualDirectory -identity "Name_Server\owa (Default Web Site)" -FormsAuthentication $false
    Set-ecpVirtualDirectory -identity "Name_Server\ecp (Default Web Site)" -FormsAuthentication $true
    luego iisreset

    y el acceso a https://mail.dominio.com/owa es ok .. pero  http://correo.dominio.local/owa   ya no autentica como windows integrated sino q magicamente realiza un redirect a https://correo.dominio.local/owa y es necesario ingresar credenciales para entrar el owa

    Gracias por la ayuda de antemano

    martes, 3 de junio de 2014 21:56

Respuestas

Todas las respuestas

  • Hola TNT,

    Mira este enlace, quizá te permita encontrar alguna pista para tu escenario:

    http://blogs.technet.com/b/exchange/archive/2011/01/17/configuring-multiple-owa-ecp-virtual-directories-on-exchange-2010-client-access-server.aspx

    Suerte!

    Saludos,


    Jesús Peñaranda| MCP,MCT,MCTS,MCITP,MCSA,MCSE

    • Propuesto como respuesta Uriel Almendra miércoles, 4 de junio de 2014 15:37
    • Marcado como respuesta Uriel Almendra martes, 10 de junio de 2014 22:45
    martes, 3 de junio de 2014 23:57
  • Gracias por tu respuesta Jesús,

    Actualmente  estamos en un periodo de coexistencia entre Exchange 2010 y Exchange 2013,  en Exchange 2010 estuvo funcionando correctamente, pero al realizar las configuraciones de forma idéntica en Exchange 2013 se presenta este escenario de "o funciona el principal o el alterno".

    El link que me brindas brinda la información para el escenario que comento, también pude revisarlo tratando de encontrar en la web alguna solución, sin embargo como te comento no pude solucionar este issue.

    Incluso probe como ahí indica  .... You must ensure that the Default Web Site is set to All Unassigned for IP, or problems will occur with PowerShell.

    Agregue una ip adicional y al site Intranet le asigne dicha ip , conservando en el Default Web site All Unassigned  con el mismo resultado insatisfactorio

    Las diferencias básicamente son

    Exchange 2010 SP3 Enterprise sobre Windows Server 2008 R2

    Exchange 2013 SP1 sobre Windows Server 2012 R2

    Gracias

    miércoles, 4 de junio de 2014 17:32
  • Hola TNT,

    Algo que se me ocurre probar es si la convivencia tiene que ver en este problema, si analizas el flujo de comunicación, en un entorno de CAS 2013 con CAS 2010, siempre se requiere este último para la comunicación con los buzones, es decir, el flujo va del CAS 2013 al 2010 para la búsqueda de buzones según el destino. Se me ocurre evaluar que pasa si esto se hace en un escenario de servidores solo Exchange 2013.

    Veamos los resultados.

    Saludos,


    Jesús Peñaranda| MCP,MCT,MCTS,MCITP,MCSA,MCSE

    jueves, 5 de junio de 2014 3:44
  • Hola Jesús,

    He probado con buzones en mailbox 2010 y también con buzones en mailbox 2013 con los mismos resultados, el problema es que estoy un poco frenado con la migración de buzones debido a este detalle faltante.

    Voy a levantar un lab de solo Exchange 2013 para evaluar este comportamiento

    Gracias

    jueves, 5 de junio de 2014 14:56
  • Hola Jesús, 

    Replique el mismo escenario en un ambiente de QA, con la misma metadata ,  resultado insatisfactorio

    Preparé un lab con solo 1 dc 2012 r2 y un Exchange 2013 sp1 multirole , con el mismo resultado , será algún bug de la versión sp1 de Exchange o del win 2012 R2 ???

    A alguien no le ha ocurrido algo similar?

    Saludos

    _TNT_

    viernes, 6 de junio de 2014 21:53
  • Hola _TNT,

    Como nos dimos cuenta después de las pruebas el problema parecía radicar efectivamente en la configuración del directorio virtual de OWA en el nuevo sitio y a reciclar el application pool de OWA desde el servidor FE y BE, debido al redireccionamiento proxy que hace el servidor CAS al Mailbox.

    :D


    Saludos cordiales | Exchange Trainer | MCDST-MCTS-MCITP-MCSA-MCT


    martes, 10 de junio de 2014 22:39