Acceso Remoto al SMM 1.2

CONTENIDO DEL DOCUMENTO
1
ACCESO REMOTO AL SERVIDOR DE MENSAJERÍA MOVISTAR 1.2.
1.1
DEPENDENCIAS MÍNIMAS DE UNA APLICACIÓN CLIENTE DEL SMM.
1.1.1 DATOS PARA EL SERVIDOR DE CORREO MOVISTAR. VERSIÓN 1.2.
Dependencias del fichero DatosSCM.dll.
ATL Module for Windows
Microsoft C++ Runtime Library
Microsoft C Runtime Library
1.1.2 SERVIDOR DE CORREO MOVISTAR. VERSIÓN 1.2.
1.1.3 INFORMACIÓN DE REGISTRO ADICIONAL.
1.2
SEGURIDAD EN EL ACCESO REMOTO AL SERVIDOR DE MENSAJERÍA MOVISTAR.
1.2.1 CONFIGURACIÓN DE LA SEGURIDAD COM DE UN PROCESO.
1.2.2 CONFIGURACIÓN DE LA SEGURIDAD DE ACCESO EN EL SMM.
1.2.3 CONFIGURACIÓN DE LA SEGURIDAD DE INICIO O ACTIVACIÓN.
1
Acceso remoto al Servidor de Mensajería MoviStar 1.2.
Este documento explica los procedimientos básicos a seguir para que una aplicación cliente del
Servidor de Mensajería MoviStar (SMM) se pueda ejecutar de forma remota en un equipo
distinto del equipo en el que reside el SMM.
Cualquier aplicación desarrollada en el entorno Windows tiene una serie de dependencias de
ficheros externos que en la mayoría de los casos se tratan de ficheros DLL (Librerías de enlace
dinámico). Las DLL son ficheros de código ejecutable que cualquier aplicación puede utilizar y
que residen normalmente en un área común y bien conocido del disco duro. De esta forma
cualquier aplicación que necesite utilizar alguna operación ya implementada en una DLL tan
solo tendrá que cargar en memoria dicha DLL y ejecutar la operación requerida. Este sistema
de enlace dinámico optimiza los recursos del equipo al permitir que varias aplicaciones que
utilizan la misma DLL compartan el mismo código al tener la DLL cargada en memoria una
sola vez.
Muchos de los ficheros de los que depende una aplicación de Windows requieren que exista
cierta información adicional asociada a dichos ficheros. Esta información reside en una base de
datos jerárquica del sistema operativo conocida como el registro de Windows.
Las aplicaciones normalmente se distribuyen en paquetes de instalación que se encargan de
comprobar que el equipo dispone de los ficheros necesarios e instalarlos en caso contrario, así
como comprobar que existe la información de registro adecuada y actualizarla en caso
necesario.
Una aplicación cliente del SMM tiene una serie de dependencias de ficheros y cierta
información de registro que el paquete de instalación de dicha aplicación debería comprobar o
actualizar en caso necesario. Hay que observar que se podrían tener más dependencias según el
tipo de aplicación desarrollada, pero que serían totalmente ajenas al uso de los servicios
proporcionados por el SMM.
1.1
Dependencias mínimas de una aplicación cliente del SMM.
En este apartado se describen con detalle todos los ficheros de los que como mínimo depende
un cliente del SMM solo por el hecho de ser cliente de este.
IMPORTANTE
Si la aplicación cliente se utiliza en un equipo en el que ya está instalado el SMM, no será
necesario comprobar las dependencias ya que es el propio SMM el que ya se ha encargado
de configurar e instalar en el equipo todo lo necesitan los clientes, aun en el caso de que la
aplicación se conecte al SMM de otro equipo remoto en lugar de hacerlo al SMM del
equipo local.
Si la aplicación cliente se ejecuta en un equipo en el que no está instalado el SMM, la
instalación de dicha aplicación deberá asegurarse de que están bien instaladas todas las
dependencias y en caso necesario instalarlas por si mismo.
En este documento se describen todos los ficheros de los que depende una aplicación cliente
del SMM y la información necesaria para su instalación. Existen herramientas de creación de
paquetes de instalación que o son capaces de detectar todas las dependencias necesarias o son
capaces de detectar toda la información asociada a cada uno de los ficheros de los que depende
la aplicación.
En el caso de desarrollar la aplicación en Visual Basic existe la herramienta ‘Asistente para
empaquetado y distribución’ que se encarga de realizar esta tarea de la misma manera que lo
hace para cualquier componente OCX o referencia externa que se esté utilizando en la
aplicación.
Un paquete de instalación bien construido deberá comprobar que existen los ficheros mínimos
necesarios para la ejecución de la aplicación e instalarlos en caso de que no existan.
Independientemente de si el paquete de instalación añade o actualiza ficheros de uso
compartido la instalación deberá incrementar un contador que el sistema asocia a cada fichero
compartido. De esta forma los ficheros comunes solamente se eliminan o se desinstalan del
sistema cuando se elimina la última aplicación que utiliza dichos ficheros.
El sistema mantiene un contador para cada fichero compartido bajo la siguiente clave del
registro:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs]
En esta clave se listan todos los nombres de ficheros con su ruta completa en el disco duro y el
número de referencias actual. Un paquete de instalación bien construido debe comprobar si el
fichero que quiere añadir o eliminar existe en esta lista y eliminar dicho fichero cuando su
contador llega a cero.
Para más información relacionada con la creación de instalaciones se puede recurrir a la
documentación de la herramienta utilizada para de creación de la instalación o a la propia
documentación técnica de Windows.
1.1.1 Datos para el Servidor de Correo MoviStar. Versión 1.2.
DatosSCM.dll
Este fichero es un servidor COM In-Process que contiene una serie de objetos COM que tanto
la aplicación cliente como el SMM utilizarán para intercambiar todos los datos o información
que necesiten.
Al tratarse de un servidor de objetos COM lleva asociada toda la información de registro que
requiere cualquier servidor COM.
Para instalar de forma correcta esta DLL habrá que copiarla a la máquina de destino y escribir
toda la información asociada en el registro.
La mayoría de las herramientas de creación de paquetes de instalación son capaces de extraer la
información de registro asociada a un servidor COM In-Process. En cualquier caso en
Windows existe la herramienta regsvr32 que sirve para instalar o desinstalar DLLs de este tipo.
En este caso basta con ejecutar ‘regsvr32 DatosSCM.dll’ para instalarla y ‘regsvr32 /u
DatosSCM.dll’ para desinstalarla.
Dependencias del fichero DatosSCM.dll.
El servidor COM In-Process DatosSCM.dll a su vez hace uso de una serie de funcionalidades
contenidas en librerías de uso general. Un paquete de instalación que añade en el sistema el
servidor DatosSCM.dll debe asegurarse de la presencia de dichas librerías.
Los ficheros de los que depende DatosSCM.dll son de uso general, es decir, no son propios del
SMM. Otras aplicaciones totalmente independientes del SMM podrían hacer uso de ellas. Por
tanto dichos ficheros deben instalarse en el directorio del sistema de Window.
El nombre del directorio del sistema depende de la versión de Windows y de las opciones
elegidas durante la instalación del sistema operativo. La instalación debe tener esto en cuenta y
obtener dicha información realizando las llamadas apropiadas al sistema operativo.
La configuración por defecto del sistema operativo suele establecer la siguiente configuración
para el directorio del sistema:
Windows 95, Windows 98:
C:\Windows\System
Windows NT, Windows 2000:
C:\Winnt\System32
Como se ha mencionado anteriormente la instalación debe pedir al sistema operativo la
ubicación de actual de dicho directorio.
ATL Module for Windows
Atl.dll
Este fichero contiene un servidor COM In-process así como varias funciones de uso general. Al
tratarse de un servidor COM, el fichero lleva información de registro asociada que debe
añadirse al sistema de la misma forma que se ha explicado para el servidor DatosSCM.dll.
Microsoft C++ Runtime Library
Msvcp60.dll
Fichero con funciones de uso general.
Microsoft C Runtime Library
Msvcrt.dll
Fichero con funciones de uso general.
1.1.2 Servidor de Correo MoviStar. Versión 1.2.
ServidorCorreoMoviStar.tlb
Este fichero es la librería de tipos que contiene la descripción de todos los objetos del SMM
que son accesibles desde los clientes. Las librerías de tipos no contienen código ejecutable que
pueda utilizar una aplicación, pero cumplen dos funciones básicas. En primer lugar permiten
realizar de forma trasparente para los clientes todas las tareas de bajo nivel relacionadas con la
comunicación remota, la correcta activación de los métodos y el paso correcto de parámetros al
servidor SMM remoto. En segundo lugar permiten que clientes desarrollados en lenguajes
interpretados como Visual Basic puedan importar y manejar todos los tipos y objetos definidos
en el SMM.
Al igual que la DLL anterior las librerías de tipos llevan asociada toda la información de
registro que necesitan los tipos y objetos que describe. Para instalar de forma correcta un TLB
hay que copiar el fichero en la máquina de destino y escribir en el registro toda la información
asociada.
Como en el caso de las DLLs la mayoría de las herramientas de creación de instalaciones son
capaces de extraer la información de registro asociada a un TLB o como mínimo son capaces
de instalarlas correctamente utilizando la función de auto registro que tienen estos ficheros.
Las librerías de tipos soportan auto registro o auto instalación de si mismas al igual que las
DLLs. Desafortunadamente Windows no tiene ninguna herramienta propia del sistema que
realice esta operación como sucede con regsvr32.
Por tanto si se quiere instalar la librería de tipos sin utilizar ninguna herramienta de creación de
instalaciones habrá que implementar un pequeño ejecutable que registre la TLB utilizando unas
pocas funciones de la API Win32 que realizan dicha tarea.
NOTA IMPORTANTE
El núcleo del Servidor de Mensajería MoviStar es el fichero ServidorCorreoMoviStar.exe,
la librería de tipos ServidorCorreoMoviStar.tlb es una parte fundamental para el
funcionamiento del servidor, así como lo son el resto de los componentes del SMM.
Para el caso de un cliente remoto ejecutándose en un equipo distinto del equipo en el que
reside el SMM no sirve para nada distribuir ServidorCorreoMoviStar.exe, ya que el código
del servidor se estará ejecutando en la máquina en la que reside el servidor. El cliente solo
necesita la librería de tipos para saber como comunicarse con el equipo remoto. El equipo
en el que reside el cliente no tiene todos los componentes del SMM y ni los usa ni los
podría usar (excepto DatosSCM.dll, que es necesario para poder manejar los datos que
intercambian el cliente y el servidor).
1.1.3 Información de registro adicional.
Si una aplicación cliente se instala en un equipo que no dispone del SMM de forma local, la
aplicación deberá acceder al servidor COM Out-Of-Process ServidorCorreoMoviStar.exe de
otro equipo de la red.
Si el equipo local tiene instalada la librería de tipos ServidorCorreoMoviStar.tlb la aplicación
cliente puede utilizar de forma remota todos los objetos del servidor. Pero existe cierta
información mínima de registro asociada normalmente al fichero ServidorCorreoMoviStar.exe
que debe existir en el equipo local. Esta información de registro es necesaria para que la
aplicación cliente pueda activar o inicializar de forma remota el objeto principal de la
aplicación, ‘ScmAplicacion’ o ’ServidorCorreoMoviStar.Aplicacion’. Esta información de
registro también puede tener asociada el nombre o la dirección del equipo remoto por defecto
en el que se realizará la activación o conexión inicial con el SMM.
La
información
mínima
necesaria
está
documentada
en
el
fichero
‘ServidorCorreoMoviStar.reg’ . Este fichero está escrito en el formato utilizado por el editor
del registro ‘regedit’ de Windows. Por tanto puede añadirse toda esta información
directamente con dicha herramienta. Como en los casos anteriores la mejor solución es que la
instalación creada para la aplicación cliente compruebe dicha información y la añada de forma
apropiada en caso de no existir.
El contenido de ‘ServidorCorreoMoviStar.reg’ es el siguiente:
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}]
@="ScmAplicacion"
"AppID"="{F31F54C4-056C-11D3-99C1-949C42F88A32}"
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\Implemented
Categories]
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\Implemented
Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\Implemented
Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B3200C0DFEE7D51}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\TypeLib]
@="{3FFD7B55-C514-11D3-9B32-00C0DFEE7D51}"
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\Version]
@="1.0"
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}\ProgID]
@="ServidorCorreoMoviStar.Aplicacion.1"
[HKEY_CLASSES_ROOT\CLSID\{3FFD7B62-C514-11D3-9B3200C0DFEE7D51}\VersionIndependentProgID]
@="ServidorCorreoMoviStar.Aplicacion"
[HKEY_CLASSES_ROOT\ServidorCorreoMoviStar.Aplicacion.1]
@="ScmAplicacion"
[HKEY_CLASSES_ROOT\ServidorCorreoMoviStar.Aplicacion.1\CLSID]
@="{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}"
[HKEY_CLASSES_ROOT\ServidorCorreoMoviStar.Aplicacion]
@="ScmAplicacion"
[HKEY_CLASSES_ROOT\ServidorCorreoMoviStar.Aplicacion\CLSID]
@="{3FFD7B62-C514-11D3-9B32-00C0DFEE7D51}"
[HKEY_CLASSES_ROOT\ServidorCorreoMoviStar.Aplicacion\CurVer]
@="ServidorCorreoMoviStar.Aplicacion.1"
[HKEY_CLASSES_ROOT\AppID\{F31F54C4-056C-11D3-99C1-949C42F88A32}]
@="ServidorCorreoMoviStar"
"RemoteServerName"="[REMOTESERVERNAME]"
El valor “RemoteServerName” asociado al AppID es opcional y puede contener cualquier
cadena de texto que identifique un equipo en la red, según el protocolo de comunicación
utilizado. Puede tener el nombre de un equipo o una dirección IP en caso de que la red tenga
instalado el protocolo TCP/IP.
Las aplicaciones clientes pueden indicar explícitamente el nombre del equipo en el que desean
realizar la activación del objeto ‘ScmAplicacion’. En caso de que una aplicación cliente no
indique explícitamente el nombre del equipo, el sistema utiliza automáticamente el equipo
indicado en dicho valor del registro. En el caso de que “RemoteServerName” no exista o
contenga una cadena vacía, si la aplicación no indica un nombre de equipo, la activación se
intentará realizar en la máquina local. Por lo tanto dicha activación fallará si el equipo no tiene
instalado el SMM.
1.2
Seguridad en el acceso remoto al Servidor de Mensajería MoviStar.
En este apartado se explican los temas relacionados con la seguridad o la autentificación de
usuarios que puede realizar el SMM cuando se utiliza de forma remota.
Cuando se accede a un servidor COM de forma remota desde otro equipo de la red pueden
entrar en juego ciertos mecanismos para que el SMM pueda autentificar la identidad de un
usuario de la red y controlar el acceso permitiendo o denegado la utilización de los servicios
proporcionados a ciertos usuarios. Todos estos mecanismos son los que se conocen como la
Seguridad DCOM.
Cuando se ejecuta un servidor COM Out-Of-Process o se ejecuta una aplicación cliente que
utiliza los objetos COM de un servidor, siempre se establece la configuración de seguridad que
utilizará por defecto la aplicación para todos los accesos a objetos COM.
Esta configuración de seguridad siempre se establece explícita o implícitamente para cada
aplicación y una sola vez durante la vida del proceso. En caso de que una aplicación no
establezca por si misma las configuraciones de seguridad, el sistema se encarga de realizarlo
por si solo cuando se produce la primera conexión con el servidor en caso de una aplicación
cliente o cuando se produce el primer acceso externo en caso de un servidor.
Para establecer la configuración de forma implícita el sistema utiliza cierta información
contenida en el registro de Windows. En general no conviene que una aplicación dependa de
esta configuración automática ya que la información que utiliza el sistema para establecer esta
seguridad por defecto se encuentra algo dispersa en el registro de Windows y puede depender
de la versión de Windows utilizada o del Service Pack instalado en el caso de WinNT. Por
tanto la mejor solución es que la aplicación establezca la configuración de la seguridad de
forma explicita.
1.2.1 Configuración de la Seguridad COM de un proceso.
Una aplicación que quiere establecer la configuración de seguridad por si misma debe realizar
una llamada a la función de Win32 ‘CoInitializeSecurity’. Esta función se puede utilizar una
sola vez en la aplicación, y además debe ser utilizada antes de cualquier operación de conexión
o acceso a un objeto COM. En caso de que la aplicación no utilice dicha función o que la
intente utilizar demasiado tarde, el propio sistema la llamará automáticamente utilizando cierta
información guardada en el registro de Windows para establecer los parámetros que necesita.
El prototipo de la función en lenguaje C es el siguiente:
HRESULT CoInitializeSecurity(
PSECURITY_DESCRIPTOR pVoid,
//Points to security descriptor
LONG cAuthSvc,
//Count of entries in asAuthSvc
SOLE_AUTHENTICATION_SERVICE * asAuthSvc,
//Array of names to register
void * pReserved1,
//Reserved for future use
DWORD dwAuthnLevel,
//The default authentication level
// for proxies
DWORD dwImpLevel,
//The default impersonation level
// for proxies
SOLE_AUTHENTICATION_LIST * pAuthList,
//Authentication information for
// each authentication service
DWORD dwCapabilities,
//Additional client and/or
// server-side capabilities
void * pReserved3
//Reserved for future use
);
El parámetro más importante de la función es ‘dwAuthnLevel’. Este parámetro indica si el
servidor obligará a que el usuario que intenta acceder a los objetos tenga que ser autentificado o
no. En caso de requerir autentificación el servidor puede establecer distintos niveles según el
grado de seguridad que se quiere conseguir.
Para una aplicación cliente este parámetro establece el nivel de autentificación que dicho
cliente quiere utilizar al acceder a los objetos del servidor.
Por lo tanto cuando una aplicación cliente desea utilizar un objeto del servidor el nivel de
autentificación utilizado en la llamada remota será el más riguroso de los dos, entre el nivel que
permite el servidor y el nivel que quiere utilizar la aplicación cliente.
Por autentificación se entiende que el servidor deberá comprobar que el usuario de la aplicación
cliente es quien dice ser y que su clave es correcta. La aplicación cliente utiliza generalmente el
usuario que inició la sesión de red (login) en la máquina en la que se ejecuta el cliente junto con
la clave de dicho usuario en cada acceso a los objetos del servidor.
La forma en la que el servidor autentifica al usuario depende de la configuración de red
establecida. Es decir, si la red está dividida en grupos de trabajo, en dominios NT, etc.
Si la configuración de seguridad finalmente requiere que el servidor autentifique al usuario en
los accesos, dicho servidor puede establecer con la llamada a ‘CoInitializeSecurity’ la lista de
usuarios a los que se permite o se deniega el acceso.
Si la configuración de seguridad finalmente no requiere que el servidor autentifique a los
usuarios en los accesos, se realizará lo que se denomina un acceso anónimo, y cualquier
usuario de la red podrá acceder al servidor.
Para mas información relacionada con la configuración de la seguridad en las aplicaciones
COM se puede recurrir a la documentación técnica de Windows.
1.2.2 Configuración de la seguridad de acceso en el SMM.
El Servidor de Mensajería MoviStar configura su seguridad para permitir un acceso anónimo
desde cualquier aplicación cliente de la red. Por tanto el SMM no requiere la autentificación
de los usuarios de las aplicaciones clientes.
Como se ha explicado anteriormente la aplicación cliente puede informar al servidor de que
desea que autentifique a sus usuarios. En este caso el servidor realizará la autentificación ya
que el cliente establece una configuración mas rigurosa que la del servidor. Por tanto la
aplicación cliente podría obtener un error de acceso denegado por parte del servidor, aunque
este permita un acceso anónimo.
Si una aplicación cliente no llama explícitamente a la función ‘CoInitializeSecurity’ lo
realizará automáticamente el sistema utilizando, generalmente, la siguiente configuración
almacenada en el registro (a no ser que la aplicación tenga registrada de forma correcta un
AppID y la versión de Windows utilizada permita el uso del AppID para establecer el nivel de
autentificación por defecto):
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
“LegacyAuthenticationLevel”= default_authentication_level
Si nunca se ha modificado este valor, el sistema configurará la seguridad en los clientes para
que pidan al servidor que autentifique sus usuarios.
Esta configuración establece el nivel de autentificación que usarán todas las aplicaciones
ejecutadas en el equipo que no establecen su nivel de autentificación de forma explicita
llamando a la función ‘CoInitializeSecurity’.
Por tanto una aplicación cliente del SMM deberá desactivar esta configuración para que el
acceso al servidor se realice de forma anónima. Según lo explicado en apartados anteriores se
puede deducir fácilmente que existen varias formas de realizar esta tarea.
Modificando la configuración de autentificación por defecto del sistema:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
”LegacyAuthenticationLevel”=”1”
Esto establece que todas las aplicaciones ejecutadas en ese equipo que no usan la función
‘CoInitializeSecurity’ establecerán por defecto una configuración de acceso anónimo.
Esta solución tiene el problema de que la configuración de la seguridad depende de la
configuración por defecto del sistema. Esta configuración se puede volver a cambiar en
cualquier momento y por tanto las aplicaciones que dependen de dicho valor podrían dejar de
funcionar.
La mejor solución es que la aplicación llame explícitamente a ‘CoInitializeSecurity’ para
desactivar por si mismas la autentificación y realizar un acceso anónimo al servidor.
El Ejemplo de uso remoto del SMM en Visual Basic utiliza esta solución y muestra como se
puede llamar a dicha función para desactivar la autentificación de los usuarios.
NOTA
En ciertas versiones de Windows existe la herramienta DCOMCNFG que permite
establecer las configuraciones de seguridad por defecto del sistema, así como otras
características relacionadas con las aplicaciones COM.
IMPORTANTE
Desactivar la autentificación de usuarios en la aplicación cliente es necesario para que los
clientes se conecten al SMM sin pedirle a este que autentifique los usuarios y por tanto
tener un acceso anónimo.
También es importante el hecho de que el servidor lanza eventos al cliente para realizar
ciertas notificaciones. Cuando el servidor lanza un evento al cliente, los papeles están
intercambiados. El SMM actúa como cliente y el cliente actúa como servidor. Por tanto si
el cliente no ha establecido un nivel de acceso anónimo, podría darse el caso de que el
SMM no pudiera enviar los eventos al cliente y obtener un error de acceso denegado.
1.2.3 Configuración de la seguridad de inicio o activación.
Si el SMM ya se está ejecutando en un equipo de la red cualquier cliente remoto se puede
conectar directamente al servidor utilizando la configuración de acceso anónimo establecida
por SMM y establecida por la propia aplicación cliente tal y como se ha descrito anteriormente.
Si un cliente remoto intenta conectarse al SMM en un equipo en el que aún no se está
ejecutando el servidor, el sistema será capaz de encontrar el fichero adecuado y arrancar el
SMM. Pero en este caso como el SMM aun no está arrancado, no ha podido establecer ninguna
configuración relativa a la seguridad.
Para situaciones en las que el servidor todavía no se está ejecutando, Windows establece otra
serie de configuraciones conocidas como seguridad de inicio o activación. En esta
configuración se especifican los usuarios que pueden realizar el arranque remoto del SMM,
independientemente de la configuración de seguridad relativa al acceso y la conexión.
Estas configuraciones siempre se guardan en el registro de Windows ya que tienen que estar
disponibles antes del arranque del servidor. Pueden ser modificadas mediante la herramienta de
administración DCOMCNFG.
La instalación del SMM configura el servidor de forma automática para que cualquier usuario
de la red pueda arrancar, iniciar o activar el SMM de forma remota. Esta configuración por
defecto se puede cambiar posteriormente con las herramientas y conocimientos adecuados.
Al configurarse de esta forma el SMM, los clientes no tendrán ningún problema relativo a este
aspecto de la seguridad y no se requerirá ningún trabajo adicional por parte ellos.
Windows 95 no permite en ningún caso un inicio o arranque remoto de un servidor COM
instalado en este sistema por parte de clientes remotos. Si el SMM se quiere utilizar en
Windows 95 como un servidor de red, habrá que asegurarse de que el SMM está arrancado de
forma manual antes de que cualquier cliente pueda conectarse.
NOTA
La configuración optima para utilizar el SMM como servidor de red es instalarlo en una
máquina con Windows NT o Windows 2000 y configurarlo para funcionar como un
Servicio del Sistema, que es la configuración por defecto cuando se instala en alguno de
esos sistemas. Esto permite utilizar todas las funcionalidades incluidas en el Servidor de
Mensajería MoviStar.