Logmein Ignition Error 4320

Error 4320 Operator or Administrator has refused the request

 

Hamachi es una solución muy usada por Gamers y privados que desean tener los privilegios de una VPN en casa, trabajo y amigos.

 

Pero aunque los CISCOfans denigran de sus servicios, la verdad es que Logmein usa en sus transferencias de datos protocolos de alta seguridad que no dejan nada que desear.

 

Ademas, algunas soluciones como Ignition, presentan Apps para integrar PDAs y Smartphones con systemas Android y Mac.

 

En nuestra Red, adicional al las MPLS usamos Servicios de Hamachi Pro para comunicar rapidamente a usuarios con cualquier Systema Operativo y aparato.

 

Logmein parace ser una empresa donde todo fue realizado y todo listo esta, donde cada problema esta documentado y el soporte brilla por su ausencia. La verdad es que casi nunca lo necesitas, aunque cuando lo necesites puedes esperar algunos dias hasta recibir alguna respuesta. El caso que me ocupa actualmente es el siguiente.

 

Mi jefe se antojó de mi acceso remoto al Terminal Server en mi Android Tablet ya que él tiene una igual. Claro con gusto! pensé: Instalé  Ignition App, logeé al jefe i voalá :( grrrrrr... ERR 4320 como en la foto:

 

Rapidamente tras preguntar a mr. goo conseguí esta ayuda
http://help.logmein.com/SelfServiceKnowledgeRenderer?type=FAQ&id=kA030000000DGDrCAO&search=1&kw=4320

y esta
http://help.logmein.com/SelfServiceKnowledgeRenderer?type=Documentation&id=kA1a0000000siUoCAI&search=1&kw=4320

y esta otra
http://help.logmein.com/SelfServiceKnowledgeRenderer?type=Documentation&id=kA1a0000000siUTCAY&search=1&kw=4320

En Cristiano:

1. logeate en la página de configuración de logmein online con tu cuenta logmein
2. ve al INICIO
3. ve al Equipo con el que tienes el problema y en la flecha derecha elige CONFIGURACION
4. Logeate con una cuenta administrativa
5. Opcion 11.-Configuraciones --> Seguridad --> Acceso de Usuario (benutzerzugriffssteuerung) --> Ver detalles --> click en el usuario o agregar si no esta en la lista
6. dar al usuario los derechos: logearse, y accesso remoto (1 y 9 R)
7. Aceptar
8. Probar de nuevo desde el Androide o Mac

Mucho exito!

Perfil temporal al cargar usuario

Nuestra empresa utiliza perfiles guardados en Servidor y un RDS Server en el cual estan algunas aplicaciones especiales y unas licencias para MS-Office. De vez en cuando, los usuarios se quejan de que sus iconos en el escritorio desaparecen, que sus favoritos no estan en favoritos, o que configuran todo diariamente y que al dia siguiente tienen que volver a hacerlo, además de la ya desde Windows XP bien conocido problema "logeando con perfil temporal" o "usuario se esta cargando" que dura una eternidad.

Parece que nadie sabe a ciencia cierta porque o de adonde viene el problema, aunque parece depender del tiempo que la cuenta lleva activa, de la computadora que carga el perfil, del usuario en sí, y de la velocidad de la red.

El problema tambien se puede presentar cuando el usuario no tiene los suficientes derechos para acceder a su carpeta, lo cual no debería pasar si configuramos el perfil en la pestana de Active Directory para perfil de usuario, porque es el mismo usario que crea su perfil con su primer logeo. Pero por el contrario, si el administrador pone en los perfiles una carpeta manualmente, es muy posible que los derechos esten errados.

Si hay problemas en la red o no hay coneccion con el servidor, es tambien muy lógico que el pc cree su propio perfil temporal al no poder acceder al guardado en el servidor. asi como si el perfil o alguno de sus Archivos es gigantescamente grande pues son mas datos a transferir, o si el usuario se logea por primera vez en una computadora (pues no hay nada local pre-guardado), en fin: hay Muchas posibilidades.

Pero cuando Estas razones no son la razon, y el problema se hace crónico, es saludable revisar el perfil de usuario y el registro de las computadoras que reportan error al cargar el perfil. Sobretodo en la clave del registro de Windows :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

pues aqui encontramos todas las cuentas de usuarios y sus respectivas direcciones de perfil.

donde en el ejemplo de arriba vemos a un usuario con roaming Profil y en el de abajo uno con local Profil: en el roaming tenemos una clave llamada CentralProfile que apunta a una Carpeta de Red y una clave llamada ProfileImagePath que apunta a la carpeta donde se sincronizan los archivos localmente para agregar Performance a la carga Futura, por lo que el primer logeo en una PC será siempre mas lento que los subsiguientes.

Aqui es de cuidar que:
CentralProfile apunte a la carpeta compartida de los usuarios, la misma dirección que aparece en la pestana de perfil en Active Directory
y ProfileImagePath apunte a C:\Users\Username

También se debe constatar de que en ninguna de Estas dos carpetas exista algo como TMP.dominio
001.dominio o TEMP que podrían ser causa de problemas.

RIS o ahora WDS instalacion

Despues de unas dos semanas de trabajo liviano
(esto es instalar, probar configuracion, cambiar, probar, apagar y tomarse un café o ir a dormir) tengo el gusto de presentarle mis experiencias con una instalacion por RIS (Remote Installation Services) o como ahora se llama WDS (Windows Deployements Services mas cool el nombre no?)

Primero que nada debo describirles mi Entorno:

- Un servidor con Windows Server 2003 Standard,
- un Router FritzBox 7xxx
- una maquina virtual dentro de mi laptop y con VMWare Player
- una vieja Laptop Thinkpad R60 (para prevenir errores con la configuracion de red VMWare

para no dar largas latas, aqui les van unos screenshots:

VIP: el DHCP, la configuracion no es igual cuando el DHCP esta fuera del servidor RIS, en mi caso DHCP y RIS/WDS estan en el mismo server

Migracion de una maquina Virtual de un VMWare Server Esxi a otro

Migracion de una maquina Virtual de un VMWare Server Esxi a otro

Bueno, normalmente prefiero el trabajo duro: entro en el el servidor virtual con vSphere Client, busco el Disco donde esta la máquina virtual y uso Subir o Bajar (download / Upload) la carpeta completa y la pongo en una Carpeta de red. Luego entro en el Segundo servidor (Objetivo) y repito el procedimiento con Subir desde la Carpeta de red. Luego exporto o monto el Disco duro y todo va bien.

Hoy se me dio un caso fortuito (como todos los dias): un mensaje de error no me permitió subir ni bajar nada. Googlear el mensaje no dio mucho resultado asi que tuve que pensar en otra(s) alternativas...

Lo primero que se me ocurrio fue darle acceso al Esxi Server a una Carpeta compartida, que estarría montada como otra del servidor. Para esto es necesario habilitar el servicio NFS que permite que los servidores de archivos de Windows puedan hablar con los de UNIX.

Habilité el Servicio, Compartí la carpeta y corrí a probarla en mi EsXi. Nada, otro mensaje de error. Al googlear, encontre que habian complejas configuraciones del Active Directory que deberian dar accesso a los usuarios del Servidor Virtual, autentificaciones de Kerberos, bla, bla, bla...

Cuando hago algo de it busco dos caminos: 1.- Profundo, lento y seguro, como el copiar archivos y montan en servidor, o el que me deje tiempo para llegar a la casa antes de las seis; un camino conocido que ya he probado anteriormente pero que se me antoja demasiado facil, esta vez solo el segundo fue caminando...

Se trata de vm Standalone Converter. La primera vez que lo usé fue para migrar la misma máquina virtual, un servidor der Terminales, desde Virtual Server 2 hasta EsXi 4. Recuerdo que aquella vez sólo pude installar el Converter dentro de la VM y mandarla, bastante elegantemente con la ip, usuario y contrasena al nuevo servidor.

Como esta vez todos los caminillos se me estaban cerrando, opté nuevamente por esta opción que aquella vez me obligó a reactivar unas licencias de unos programas que copian alguna identificacion que no se les escapa en la virtualizacion.

conectar dos DC sobre la tecnologia de hamachi logmein

Servidor Principal: DC1                                                             

Servidor que va a ser conectado: DC2

      

c/u tiene 2 tarjetas por lo menos: la física y la hamachi

la fisica debe tener su ip4 normal

la hamachi debe apuntar el dns serve al host: 127.0.0.1

cada dc debe tener entradas en el archivo host asi:

xx.xxx.xxx.xxx dc1

xx.xxx.xxx.xxx dc2

y yo para mejorar la recursividad y resolucion de nombres agrego tambien:

xx.xxx.xxx.xxx dc1.dominio.local

xx.xxx.xxx.xxx dc2.dominio.local

en las propiedades de la targeta de red hamachi, coloca en segundo lugar la ip de DC1, y si tienens otros servidores DC puedes agregarlos en lista en AVANZADO --> DNS

en este punto me tope con el problema:

Fue realmente fastidioso, que habia realizado el mismo procedimiento en otros servidores con windows idioma aleman y este problema no se habia presentado. Despues de probar y reprobar, mirar foros y volver a probar die con una solucion en las paginas de microsoft:

1.- buscar HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ldap\

2.- agregar la entrada de cadena con el nombre IPv4LoopbackAlternative y el valor 127.0.0.2

3.- reiniciar y funciona, son las increibles cosas de MS.

Bueno, la cosa es que funciona. Con este cambio pude logear el servidor en el dominio  a traves del servicio de hamachi.

Por costumbre, y para dividir posibles problemas, primero agrego DNS y luego ejecuto DCPROMO para convertir el servidor en DC. Aqui se encuentran varios problemas derivados de la ip hamachi, y el servidor DNS local que no resuelve estas direcciones. Como estaba preparando este servidor para otro lugar no tenia mucho sentido agregar registros al servidor dns local, asi que lo elimine de la lista de dns de las dos tarjetas y puse las dos hamachi-ips de los dos servidores DNS remotos que tenian direcciones. Esto funciono de maravilla hasta este ultimo mensaje

aunque la conexion con el dominio lejano, parecia funcionar de maravillas,  pues el servidor se logeo en el dominio y cada usuario podia logearse con su nombre y contrasena, el Active Directory seguia teniendo problemas. Uno, ya viejo conocido, era el RPC que parecía no encontrar.

Ya había tenido este problema otras veces y lamentaba no saber donde estaría el screenshot con la solución. El mensaje me daba una idea... network not exist... entonces cambié -otra vez las ip de los dns en la cartilla de las tarjetas de red quitando las ip locales y dejando solo las hamachi. Funcionó, pasó esta etapa.

instalar el servidor

instalar hamachi

configurar tarjetas de red:

- LAN1 : dns = router

- LAN2 (hamachi) = dns = remote dns hamachi ip

cambiar el registro por si el lookback bromea

------- al final mi red se ve asi

la tarjeta fisica:

la tarjeta hamachi:

donde las dos ip de abajo son las de hamachi en los servidores remotos

--- Un parentesis mas : --- antes de logear el servidor en el dominio he agregado el rol de DNS y he creado una zona stub para midominio.com.stub no se la verdad si esto ha servido de algo, pero me supongo que ayuda a mejorar la resolucion de nombres. Importante tambien -aunque pueda no parecerlo es que tras cada cambio estuve haciendo reboots. Aunque parezca una estupidez, tuvo mejores resultados la instalacion y configuracion con reboots que la directa

Demas esta decir que ambos servidores deben esta completamente uptodate, porque sino van apareciendo muchos errores que al estar actualizados no aparecen.

------------------------------------------------------------------------------------------------

Referencias:

http://www.stevensnet.com/Pages/Blogs/Blog_view.aspx?articleid=427

http://support.microsoft.com/kb/2619880/en-us

http://www.help-net.net/Docs/Routers%20-%20VPN%20-%20Security/Hamachi%20(VPN)/How%20to%20Configure%20Hamachi%20for%20AD%20Replicating.pdf

-----------------------------------------------------------------------------------------------------

Activar el acceso remoto sin tener acceso remoto (por registro)

Problema: He configurado un servidor en el que olvidé el acceso remoto, y que tiene acceso solo por red pero no tiene consola, ni monitor, ni teclado, y el acceso para instalarlos es dificil

Solución:
1.- Ejecutar "regedit"
2.- Archivo --> Conectar a Registro remoto
3.- Escribir el nombre de la máquina: workgroup\maquina o dominio\maquina --> OK
4- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
5- Clave  fDenyTSConnections en valor uno, cambiar a 0

- Esto me había funcionado siempre con xp, hasta que tuve que probar con windows 7 y me tope con el siguiernte mensaje:

Pero esto parece arriesgado y poco seguro, asi que tiene que complicarse la cosa, y ahora hacer lo mismo cuesta un poco mas.

Primero que nada en Windows7 sera necesario el programa de SystemInternals, PsExe

¿Quién borro esa carpeta? Cómo descubrir a culpable

Los Archivos compartidos no son sólo una Cosa práctica sino que estan usados ampliamente en grandes y pequenas empresas. Gracias a las Copias de Sombra o Shadowscopy podemos reestablecer fácilmente los archivos de Estas carpetas.

Pero que pasa, si repetidamente se pierden carpetas y archivos compartidos? Recuperamos estos repetidamente, pero en algun momento estamos hasta la coronilla del asunto y nos preguntamos : Quien esta haciendo esto? es menso, descuidado o saboteador? y cuando buscamos alguna pista nos topamos con que nuestro servidor no tiene idea y nadie nos puede decir quien es el culpable

Por suerte, no todo esta perdido, aunque en los primeros intentos se perdieron todas las pistas, si vuelve a suceder, sólo tenemos que configurar la trampa para nuesto saboteador...

Se trata de la Politica Local de Auditoría. Yo diría que se obtiene en dos grandes capítulos, o hasta en tres:

1.- Configurar la Auditoria en las Carpetas
2.- Activar la GP Local "Auditoria"
3.- Filtrar los contenidos (pues la DATA de resultados es enorme)

1.- Configurar la Auditoria en las Carpetas
Con el Explorador de Archivos de Windows ir hasta la carpeta, abrir las Propiedades --> Seguridad --> Avanzadas --> Auditoria --> Trabajar --> Agregar --> Aqui agregar el grupo a auditar --> Auditoria para la "Carpeta" --> Marcar las casillas "Borrar" y "Borrar contenido de la carpeta --> Aceptar, aceptar, aceptar.

2.- Activar la GP Local "Auditoria "
Ejecutar gpedit.msc como administrador.
Buscar "Configuración de Equipo --> Configuración de Windows -->  Configuración de Seguridad -->  Directivas locales - Directiva de Auditoría"  y habilitar "Auditar el acceso a objetos"

3.- Filtrar los contenidos
Ahora la cantidad de protocolos sera enorme, para encontrar la informacion que necesitamos, deberemos crear un filtro, que bien podemos guardar para proximas ocasiones:
3.1.- en nuestros protocolos de Windows (alem. ereignisanzeige) --> Vista (Filtro)definida por usuario --> crear nueva -->

Los ID de resultados se pueden obviar, pues al tratarse de protocolos de seguridad en la categoria Sistema de archivos (dateisystem) nos aparecerán todo lo referente a esto. Si aun son muchos, podemos agregar IDs, donde 4663 es borrar propiamente dicho (aceptar despues de la pregunta "desea borrar?") y 4660 es mandar a borrar. También se puede encontrar informacion valiosa tras auditar el evento logon y logoff que son los 4624 y 4634

Herramienta recomendada: LogParser para bajar en...
 http://www.microsoft.com/en-us/download/details.aspx?id=24659

Un buen documento (en ingles) de MIchael Firsov pero bastante mas profundo...
http://michaelfirsov.wordpress.com/2012/03/20/windows-audit-part-3-tracing-file-deletions/

Espero que le sirva de ayuda a alguien -un "me gusta" o un "plus" + no seria mala recompensa-