RemoteApp se licencia por usuario (basado en el servicio que se est\u00e1 desplegado y el n\u00famero de usuarios asignado a la implementaci\u00f3n). No necesita CAL de RDS o una garant\u00eda de software, y RDS se encarga de toda la infraestructura de RDS. Todo RDS le pide es:<\/p>\n
- \n
- \nUna plantilla sysprepped que puede ser utilizado por Azure para desplegar los anfitriones de la sesi\u00f3n para que<\/div>\n<\/li>\n
- \n
Azure AD se rellena con las cuentas de usuario que ser\u00e1n asignados a la colecci\u00f3n de RemoteApp<\/div>\n<\/li>\n<\/ul>\nEn casi todos los escenarios que he estado involucrado, los clientes han optado por una implementaci\u00f3n de RemoteApp que usa Active Directory en conjunci\u00f3n con AD Azure:<\/p>\n
- \n
- \nLos usuarios se registran en RemoteApp a trav\u00e9s de Azure AD para obtener acceso a las aplicaciones publicadas.<\/div>\n<\/li>\n
- \n
Cuando un usuario inicia sesi\u00f3n en su primera solicitud, que el usuario haya iniciado sesi\u00f3n en Active Directory a trav\u00e9s de un controlador de dominio que ejecuta como una m\u00e1quina virtual Azure. Group Policy configures the user experience. Directiva de grupo configura la experiencia del usuario.<\/div>\n<\/li>\n- \n
Los anfitriones de la sesi\u00f3n RemoteApp tambi\u00e9n son miembros del dominio (a trav\u00e9s de los controladores de dominio) y son controlados por la directiva de grupo.<\/div>\n<\/li>\n<\/ol>\nY aqu\u00ed est\u00e1 la trampa: Es necesario ejecutar los controladores de dominio (idealmente, al menos dos) como m\u00e1quinas virtuales en Azure para la configuraci\u00f3n anterior. A pesar de que probablemente son m\u00e1quinas ligeras, la suma del coste es mal – sobre todo cuando el cliente pregunta por qu\u00e9 tienen que utilizar dos Directorios Activos (controladores de dominio Azure AD) y.<\/p>\n
Azure AD Domain Services<\/h4>\n
Microsoft se dio cuenta de que muchos clientes est\u00e1n buscando para desplegar servicios, nuevo o viejo, en Azure que se basan en los Servicios de dominio, tales como la directiva de grupo, LDAP, y as\u00ed sucesivamente. Estas son cosas que Azure AD simplemente no puede hacer. Por lo que Microsoft puso en marcha una vista previa de los Servicios de dominio de AD Azure que ofrece muchos de los servicios que ofrece el legado AD. El objetivo aqu\u00ed es dejar que nosotros tenemos un dominio en Azure sin desplegar los DC en Azure (nota me dijo, "en azul").<\/p>\n
Al implementar Azure AD Servicios de dominio, usted:<\/p>\n
- \n
- Verificar el FQDN de su dominio en el mismo recinto <\/li>\n
- Habilitar los Servicios de dominio en el dominio de AD Azure <\/li>\n
- Conectar los Servicios de dominio de AD Azure a un VNet – que consumir\u00e1 2 direcciones IP para utilizar como servidores DNS en la VNet <\/li>\n
- Opcionalmente podemos utilizar Azure AD Conect para sincronizar cuentas de usuario desde DCs on-premises en Azure AD <\/li>\n<\/ul>\n
![\"AzureRemoteApp00[1]\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2016\/UsodeRemoteAppconlosServiciosdedominiode_B305\/AzureRemoteApp001_thumb.png\" "\\"AzureRemoteApp00[1]\\"")
<\/a> Una colecci\u00f3n de RemoteApp puede residir en el mismo VNet como m\u00e1quinas virtuales [Cr\u00e9dito de la imagen: Aidan Finn]<\/p>\nAzure AD Domain Services con RemoteApp<\/h2>\n
Antes de seguir leyendo, recuerda que los Servicios de dominio de AD Azure es en la vista previa. No van a haber problemas, as\u00ed que est\u00e9 preparado para ellos. En esta soluci\u00f3n, usted:<\/p>\n
- \n
- \nContinuar\u00e1 funcionando controladores de dominio en el mismo recinto. Aqu\u00ed es donde usted contin\u00faa haciendo la mayor parte de su administraci\u00f3n de usuarios.<\/div>\n<\/li>\n
- \n
Sincronizar AD on-premises con Azure AD.<\/div>\n<\/li>\n- \n
Usar Azure AD para autenticar a los usuarios de la aplicaci\u00f3n a distancia (como antes).<\/div>\n<\/li>\n- \n
Servicios de dominio de AD tienen Azure autenticar los anfitriones de la sesi\u00f3n RemoteApp en un VNet com\u00fan.<\/div>\n<\/li>\n- \n
Utilizar los Servicios de dominio de AD Azure para autenticar a los usuarios cuando se inscriban en los anfitriones de la sesi\u00f3n RemoteApp.<\/div>\n<\/li>\n<\/ul>\n![\"AzureRemoteApp01[1]\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2016\/UsodeRemoteAppconlosServiciosdedominiode_B305\/AzureRemoteApp011_thumb.png\" "\\"AzureRemoteApp01[1]\\"")
<\/a>
usuarios de autenticaci\u00f3n RemoteApp con los Servicios de dominio de AD Azure
[Cr\u00e9dito de la imagen: Microsoft]<\/p>\nHay algunas notas de Microsoft:<\/p>\n
- \n
- \nServicios de dominio de AD Azure es un dominio diferente a su dominio on-premises (local). Ellos comparten un nombre de dominio y cuentas de usuario est\u00e1n sincronizados entre ellos, pero esto no es un entorno h\u00edbrido donde su dominio se extendi\u00f3 a Azure utilizando los controladores de dominio virtuales, y AD Sitios y Servicios.<\/div>\n<\/li>\n
- \n
Se puede utilizar tanto "h\u00edbrido" o usuarios sincronizados y "solo" en la nube Azure usuarios en AD DS. Pero s\u00f3lo se puede utilizar con los usuarios sincronizados RemoteApp en este momento.<\/div>\n<\/li>\n- \n
No hay confianza entre Azure AD DS y el dominio local. Esto significa que un usuario las indicaciones en RemoteApp no \u200b\u200bpueden utilizar un cliente para el acceso en locales de recursos a trav\u00e9s de una conexi\u00f3n de red de sitio a sitio.<\/div>\n<\/li>\n<\/ul>\n - \n
- \n
- \n
- \n
- \n
![\"AzureRemoteApp00[1]\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2016\/UsodeRemoteAppconlosServiciosdedominiode_B305\/AzureRemoteApp001.png\" "\\"AzureRemoteApp00[1]\\"")
<\/a> Una colecci\u00f3n de RemoteApp puede residir en el mismo VNet como m\u00e1quinas virtuales [Cr\u00e9dito de la imagen: Aidan Finn]<\/p>\n