GSNW depende de otra característica de compatibilidad con NetWare de Windows Server: el protocolo de transporte compatible IPX/SPX/NetBIOS (abreviado como NWLink). NWLink es una implementación de los protocolos de transporte de Intercambio de paquetes entre redes (Internetwork Packet Exchange, IPX), de Intercambio secuencial de paquetes (Sequenced Packet Exchange, SPX) y NetBIOS utilizados por las redes de NetWare. Las implementaciones de estos protocolos por Microsoft pueden coexistir sin problemas con otros protocolos en el mismo adaptador de red.
El principal inconveniente de utilizar GSNW es que resulta más difícil personalizar la seguridad para cada usuario en los recursos de NetWare. Cada perfil de usuario debe utilizar una unidad compartida diferente de la puerta de enlace y, en consecuencia, una letra de unidad diferente, lo que limita el número de unidades compartidas que pueden crearse. Además, dado que Windows 2000 Server debe traducir cada bloque de mensajes del servidor (Server Message Bloclr, SMB) al Protocolo del núcleo de NetWare (NetWare Core Protocol, NCP), y viceversa, el uso de GSNW puede resultar realmente más lento que hacer que se instale el software en cada uno de los clientes.
La sobrecarga por la traducción se reduce enormemente al comunicarse mediante TCP/IP con los servidores basados en NetWare 5.
Aunque las primeras versiones de Novell NetWare soportaban TCP/IP, las implementaciones de Microsoft y de Novell de este protocolo no fueron compatibles hasta NetWare 5. En consecuencia, Windows 2000 Server necesita NWLink para comunicarse con los servidores de NetWare 4.x y de versiones anteriores. Si se establece comunicación con servidores de NetWare 5, no hace falta instalar el protocolo NWLink antes de instalar GSNW
También se pueden establecer en el servidor de NetWare una o varias unidades compartidas para que las utilicen los clientes de Windows 2000. Hay que pulsar Agregar en el cuadro de diálogo Configurar puerta de enlace para que aparezca el cuadro de diálogo Nuevo recurso compartido.
Una vez creada la nueva unidad compartida, hay que pulsar el botón Permisos para especificar los usuarios y grupos de Windows 2000 que tienen acceso al recurso y sus derechos en el mismo. Hay que establecer estos mismos derechos en cualquier unidad compartida de Windows 2000 Server.
Para ejecutar utilidades administrativas NDS en Windows 2000 Professional, hay que utilizar el software cliente de NetWare.
Windows 2000 Server soporta muchas utilidades de NetWare que se pueden
utilizar para gestionar la red de NetWare desde una computadora que ejecute
Windows 2000 Workstation o Windows 2000 Server. (Puede que algunas de las
utilidades necesiten archivos adicionales que se proporcionan con Windows 2000
Server o con NetWare, como se estudia en el apartado siguiente).
Las siguientes utilidades basadas en MS-DOS trabajan con Windows 2000:
| Chkvol | Help | Rconsole | Settts |
| Colorpal | Listdir | Remove | slist |
| Dspace | Map | Revoke | syscon |
| Fconsole | Ncopy | Rights | Tlist |
| Filer | Ndir | Security | Userlist |
| Flag | Pconsole | Send | Volinfo |
| Flagdir | Psc | Session | Whoami |
| Grant | Pstat | Setpass |
La orden Net Use de Windows 2000 Server o el Explorador de Microsoft Windows realizan las mismas funciones que las órdenes de NetWare Attach, Login y Logout. La orden Net Use también es parecida a la orden Capture para impresión cuando las aplicaciones basadas en MSDOS y en Windows deben imprimir en un puerto concreto. Además, se puede utilizar el Asistente para agregar impresoras para conectarse a las colas de impresión de NetWare. La orden Net Use también se puede utilizar para conectarse a volúmenes a impresoras de árboles NDS o de servidores de NetWare basados en vinculación. La orden Net View de Windows 2000 Server realiza las mismas funciones que la utilidad Slist de NetWare.
Muchas aplicaciones que funcionan con NetWare se ejecutarán en Windows 2000 Server mediante GSNW igual que si se estuvieran ejecutando en una computadora cliente de NetWare. No obstante, no están soportadas todas las aplicaciones que funcionan con NetWare. Muchas aplicaciones necesitan archivos especiales que se proporcionan con NetWare o con Windows 2000 Server.
Muchas aplicaciones antiguas de 16 bits que funcionan con NetWare necesitan el archivo Nwipxspx.dll proporcionado por Novell¡. El archivo forma parte de la instalación cliente estándar de Novell¡. Hay que buscarlo y copiarlo en la carpeta \SystemRoot\System32 de la máquina en la que se vayan a utilizar las aplicaciones de NetWare.
Puede que las aplicaciones que funcionan con NetWare que utilizan la API de NetWare para enviar y recibir paquetes del Protocolo del núcleo de NetWare (NetWare Core Protocol, NCP) necesiten Netware.drv y Nwnetapi.dll o, para versiones de NetWare más recientes, Nwcalls.dll. Netware.drv debería instalarse en la carpeta\SystemRoot\System32 al instalar GSNW Si se copia alguno de estos archivos en la computadora que ejecuta Windows 2000 Server o se modifica el camino de búsqueda durante la sesión de trabajo de Windows 2000 Server abierta, hay que cerrar la sesión y volver a abrirla para que las modificaciones tengan efecto.
Para obtener los archivos de NetWare necesarios, hay que comprobar con el administrador de la red de NetWare o con el representante local de Novell si se hallan disponibles de modo local los últimos archivos clientes. O bien se pueden obtener en Internet en ftp.novell.com. Novell también envía revisiones de su software cliente de NetWare y de los controladores en CompuServe en http://www.compuserve.com/computing/subs/Novelldown.asp.
Una vez que se conoce todo lo necesario sobre el acceso a los recursos de Novell NetWare desde un entorno y una red basados en Windows 2000, hay que averiguar la otra parte de la historia: el modo de tener acceso a los recursos de Windows 2000 Server desde los clientes y servidores de NetWare. Microsoft proporciona un paquete de complementos independiente denominado Microsoft Services for NetWare (servicios de Microsoft para NetWare), que consiste en Servicios de archivo a impresión para NetWare (File and Print Services for NetWare, FPNW) y Gestor de servicios de directorio para NetWare (Directory Service Manager for NetWare, DSMN).
FPNW permite a los administradores de NetWare 4.x y anteriores (exclusivamente en modo de emulación de vinculación) integrar Windows 2000 Server en su red de NetWare. Emula un servidor de NetWare, lo que permite al servidor de Windows 2000 que ejecute este servicio integrarse en la red basada en NetWare existente sin modificaciones en los clientes de NetWare. Los clientes de NetWare no saben que están teniendo acceso a un servidor de Windows 2000 habilitado para FPNW
Los administradores que trabajen con redes mediante la vinculación de NetWare
(versión 4.x y anteriores) pueden tener problemas, ya que tienen que gestionar
cada servidor y sus usuarios independientemente del resto de los servidores.
Pero, mediante el uso de Windows 2000 y de DSMN, pueden gestionar varios
entornos mientras sólo mantienen una única cuenta de usuario y su contraseña
asociada por cada usuario final de la red.
Los administradores simplifican la
labor del control de los entornos mixtos de Windows 2000 y de NetWare utilizando
el Active Directory de Windows 2000. DSMN copia las cuentas de usuario de
NetWare en el Active Directory y propaga cualquier cambio hacia el servidor de
NetWare, todo ello sin necesidad de instalar ningún tipo de software en los
servidores de NetWare.
Una vez configurados Windows 2000 Server y la red para tener acceso a los recursos basados en NetWare, la decisión más importante que hay que tomar es la elección de los servicios clientes. Se puede escoger instalar servicios clientes para cada cliente de la red o simplificar las cosas instalando GSNW. Las tablas muestran algunas condiciones que puede tener la red y la mejor opción de servicio o de cliente en cada caso. La realidad es que indudablemente habrá que escoger una opción menos que perfecta, pero estas tablas pueden proporcionar un punto de partida.
|
Elección entre servicios clientes y servicios de pasarela | ||
| Situación | Servicio de pasarela | Servicio cliente |
| Los directorios raíz de los usuarios se hallan en el servidor de NetWare. | X | |
| Los directorios raíz de los usuarios se hallan en el servidor de Windows 2000. | X | |
| Las aplicaciones se hallan en el servidor de Windows 2000. | X | |
| Las aplicaciones se hallan en un servidor de NetWare y las utilizan todos los usuarios. | X | |
| Las aplicaciones se hallan en un servidor de NetWare, pero su acceso está restringido a determinados grupos. | X | |
| Los usuarios sólo necesitan acceso a las impresoras basadas en NetWare. | X | |
| Los usuarios necesitan acceso a archivos del servidor NetWare compartidos entre gran número de usuarios. | X | |
| Los usuarios necesitan acceso a archivos del servidor de NetWare restringidos a un usuario o grupo. | X | |
| Los usuarios se hallan más cómodos utilizando utilidades y comandos de NetWare que de Windows 2000 Server. | X | |
| Los usuarios están más acostumbrados con las utilidades y los comandos de Windows 2000 Server que con los de NetWare. | X | |
|
Elección entre clientes Novell y Microsoft | ||
| Situación | Cliente de Novell | Cliente de Microsoft |
| El cliente se ejecuta en una plataforma que no es Intel (por ejemplo, Alpha). | X | |
| Se necesitan las aplicaciones basadas en NetWare heredadas. | X | |
| En la red se utilizan los servicios de Windows 95/98 igualitarios para compartir en la red. | X | |
| En la red se utiliza Microsoft FPNW | X | |
| El cliente tiene recursos limitados (por ejemplo, espacio de disco duro y memoria). | X | |
|
Comparación entre los atributos de archivo de Windows y de NetWare | |
| Atributos de los archivos de Windows | Atributos de los archivos de NetWare |
| A (Archivo) | A |
| S (Sistema) | Sy |
| H (Oculto) | H |
| R (Sólo lectura) | Ro, Di (Inhibir borrado), Ri (Inhibir cambio de nombre) |
Al utilizar GSNW los atributos de los archivos de NetWare no son exactamente iguales que los de Windows 2000 Server. GSNW no soporta los siguientes atributos de archivo de NetWare:
Cuando se copia un archivo desde un cliente de red de Microsoft al servidor de archivos de NetWare mediante GSNW, se conservan los atributos de archivo Ro, A, Sy y H.
Cuando se utiliza un servidor de Windows 2000 que ejecuta GSNW para obtener acceso directo a los servidores de NetWare, se pueden utilizar las utilidades de NetWare, como Filer y Rights, para definir los atributos no soportados por GSNW.
La informática empresarial implica inevitablemente trabajar a interconectarse con gran variedad de entornos y de sistemas operativos. Uno de los sistemas operativos alternativos más extendidos con el trabajan los usuarios de Microsoft Windows 2000 es UNIX -en todas sus diversas formas-. Por sí mismo Windows 2000 tienen herramientas básicas de conectividad que le permiten funcionar en la misma red con los servidores de UNIX. Otros complementos de Microsoft y de otros fabricantes ayudan a UNIX y a Windows 2000 a trabajar juntos prácticamente sin problemas, de modo que los administradores de sistemas de ambos entornos puedan proporcionar a sus usuarios un acceso completo a los recursos del otro entorno de manera casi transparente.
Una de las diferencias más importantes y generalizadas entre Windows 2000 y UNIX es el modo en que tratan los permisos y la seguridad. Estas diferencias son sutiles y suelen llevar al usuario incauto a realizar suposiciones falsas.
Un listado de archivos UNIX puede tener el siguiente aspecto:
-rwxr-x-x 2 charlie dba 2579 Aug 30 15:49 resize
Este listado indica prácticamente todo lo que hace falta saber acerca de la seguridad y de los permisos del archivo examinado. Se empezará por el extremo izquierdo de la línea y se avanzará para ver lo que hay, lo que significa y su comparación con Windows 2000.
El primer guión (-) indica que este listado no es un directorio. Si lo fuera, aparecería una «d» en su lugar. UNIX trata los directorios meramente como otros archivos, aunque especiales, y los permisos tienen un significado ligeramente diferente cuando hacen referencia a un directorio y a un archivo. En breve se tratarán los permisos para los directorios, pero de momento se seguirá con los archivos normales.
Los tres caracteres siguientes corresponden a los permisos del propietario del archivo, que puede ser distinto de su creador original, ya que UNIX permite a los usuarios « dar» archivos a otros usuarios. La « r» indica que el propietario tiene derecho a leer el archivo; la « w» significa que puede escribir en él, borrarlo o modificarlo de cualquier otra manera; y la « x» permite al propietario del archivo ejecutar el programa.
En Windows 2000 el sistema operativo decide si un programa es ejecutable basándose en el nombre del archivo. Si el nombre del archivo tiene una extensión .COM, .EXE, .BAT o .CMD, puede ejecutarse siempre que el usuario tenga los permisos correspondientes. En UNIX no hay ninguna asociación entre la extensión y la ejecutabilidad del archivo (de hecho, la mayor parte de los archivos UNIX no tiene ninguna extensión). Lo único que determina si un archivo es ejecutable es su permiso. Por tanto, aunque la convención en un sistema dado pueda ser denominar siempre a las secuencias de comandos de la interfaz de comandos (el equivalente UNIX de los archivos por lotes) con un nombre que acabe en .sh o .ksh, esto no tiene significado real. El archivo debe recibir el permiso de ejecución para poder ejecutarlo.
Los caracteres quinto, sexto y séptimo corresponden a los permisos de los miembros del mismo grupo del propietario del archivo. La < r> significa que los miembros del grupo pueden leer el archivo (o llevar a cabo acciones que lo dejen intacto, como copiarlo); el guión indica que no tienen permiso para escribir en él, borrarlo ni modificarlo de ninguna otra manera; la < x> les concede la capacidad de ejecutar el programa.
Finalmente, los últimos tres caracteres del primer grupo corresponden a los permisos del resto de usuarios. El guión inicial indica que esos usuarios no tienen derecho a leer el archivo ni a examinar su contenido de ninguna manera, ni tampoco tienen permiso para copiar el archivo. El segundo guión indica que no tienen permiso para cambiar, modificar, ni borrar el archivo y, finalmente, la última <x> indica que pueden ejecutar el archivo, si ello no exige leerlo.
UNIX sólo tiene tres permisos básicos: lectura, escritura y ejecución.
- Lectura El derecho a leer un archivo o mostrar su contenido. El derecho a hacer una copia del archivo. Para los directorios, el derecho a mostrar el contenido del directorio.
- Escritura El derecho a alterar el contenido de un archivo. Para los directorios, el derecho a crear archivos y subdirectorios. Si se tiene permiso de escritura para un directorio, se tiene el derecho a borrar archivos del directorio aunque se carezca del permiso de escritura para el archivo, si también se tiene permiso de lectura o de ejecución para el directorio.
- Ejecución El derecho a ejecutar el archivo. Incluso el propietario del archivo necesita este permiso para ejecutarlo. Para los directorios, el derecho a modificarlos o a ejecutar archivos del directorio. La posesión de este permiso para un directorio, sin embargo, no concede permiso para mostrar su contenido, por lo que puede que se sea capaz de ejecutar un archivo sin poder ver que se halla ahí.
El siguiente carácter, el número < 2> , indica que hay dos vínculos duros con el archivo. Un vínculo duro concede otro nombre al mismo archivo. Sigue habiendo un único archivo real guardado en el disco duro, pero hay dos entradas de directorio que apuntan a ese archivo. No hay límites prácticos al número de vínculos duros que puede haber con un mismo archivo, pero todos los vínculos con el archivo deben estar en el mismo sistema de archivos.
Los dos grupos siguientes del listado son el propietario, « charlie» , y el grupo del archivo, « dba». Aunque suelen ser los nombres del usuario y del grupo, también podrían ser un número si el usuario o el grupo del archivo no tuvieran una cuenta en el sistema.
A continuación aparece el tamaño del archivo (2579 bytes, en este caso), la fecha y la hora en que se creó el archivo o se modificó por última vez y el nombre del archivo: realmente, la entrada de directorio del archivo que se corresponde con este vínculo duro con el archivo. Obsérvese que ningún vínculo tiene preferencia sobre los demás. No hay nada significativo en cuanto al nombre que aparezca primero; todos se tratan por igual. Y el borrado de un vínculo no borra el archivo, sólo esa referencia al mismo. El resto de las versiones del archivo siguen existiendo.
UNIX soporta tanto vínculos duros como vínculos simbólicos. Los vínculos simbólicos son similares a los accesos directos de Windows 2000, pero con algunas diferencias. La diferencia más importante es que en UNIX, cuando se tiene acceso al vínculo simbólico, en realidad se tiene acceso al archivo al que apunta, no al propio vínculo. Por ejemplo, si se edita un vínculo simbólico con un archivo de texto, en realidad se está editando el archivo de texto original. Con los accesos directos de Windows 2000 sólo se puede utilizar un vínculo para iniciar un archivo ejecutable o para abrir una carpeta.
Los vínculos simbólicos se diferencian de los vínculos duros en que el archivo real tiene preferencia sobre sus vínculos simbólicos. De hecho, el listado de un vínculo con el archivo resize deja claro que se trata de un vínculo simbólico, no de un vínculo duro:
lrwxrwxrwx 1 charlie dba 2579 Aug 30 15:49 resize -> /u/cpr/resize
Como puede verse, el listado no sólo comienza con la letra «l» en primer lugar, sino que muestra realmente el lugar al que apunta el vínculo. Se puede observar que los dos nombres de archivo son idénticos. Aunque esto no es imprescindible, se trata del uso más frecuente de los vínculos simbólicos: hacer que parezca que un archivo está en un lugar cuando realmente se halla en otro.
Otra característica de los vínculos simbólicos que los distingue de los vínculos duros es que pueden apuntar a otros sistemas de archivos a incluso máquinas. Se puede tener un vínculo simbólico que apunte a un archivo que resida en una computadora completamente diferente.
Si se copia un archivo sobre un vínculo simbólico, se romperá el vínculo. El nuevo archivo sustituirá al vínculo con el archivo. No obstante, el archivo original seguirá existiendo, lo que, como mínimo, hace que la duplicación de archivos resulte confusa.
Tradicionalmente UNIX divide el mundo únicamente en tres tipos de usuarios: el propietario del archivo, los miembros del grupo del propietario y el resto del mundo. Estos tres niveles de privilegios se conocen como propietario, grupo y otros. La mayor diferencia con Windows 2000 estriba en el segundo nivel de privilegios: el grupo.
En los sistemas UNIX con seguridad tradicional, cada usuario sólo está activo simultáneamente en un grupo. Cuando ese usuario crea un archivo, éste se crea con permisos para grupo basados estrictamente en el grupo actual del creador del archivo. Esta situación puede suponer complicaciones interesantes y sutiles al compararla con la metodología de Windows 2000. Si el inicio de sesión principal de un usuario es con uno de los grupos estándar, las cosas suelen transcurrir como se espera. Sin embargo, cuando un usuario pertenece a un grupo especializado con pertenencia restringida y crea archivos mientras ese grupo es el grupo activo, la capacidad de los usuarios ajenos al grupo para tener acceso al archivo puede quedar restringida.
Los usuarios que no son miembros activos del grupo que posee el archivo y que no son su propietario se hallan en el otro nivel de privilegios. Esta disposición es esencialmente igual que el grupo de Windows 2000 denominado Todos. Un usuario de la otra categoría no tiene más permiso para el acceso al archivo que el que tienen el resto de los usuarios.
En los estudios sobre seguridad de UNIX, hay que recordar un principio supremo: el usuario root (a veces denominado superusuario) tienen acceso a todo. En el mundo de Windows 2000 se puede definir fácilmente un archivo o un directorio de modo que ni siquiera los usuarios con privilegios administrativos tengan acceso a él sin cambiar su propiedad, pero en el mundo de UNIX esa restricción no existe. No sólo eso, sino que el superusuario puede incluso cambiar su identidad para tener la misma que un usuario dado.
Ahora que se comprenden las diferencias entre los modelos de seguridad de Windows 2000 y de UNIX, se examinará la manera en que son compatibles. Por un motivo, sin complementos adicionales, Windows 2000 coexiste razonablemente bien con los servidores de UNIX. El protocolo de red predeterminado para ambos sistemas operativos es ahora el mismo -TCP/IP-. Pueden compartir fácilmente DNS, DHCP y otros servicios. Y la mera conectividad entre Windows 2000 y UNIX puede tratarse mediante los clientes de FTP y de Telnet en las máquinas de Windows 2000.
Todas las versiones de Windows 2000 incluyen un cliente FTP sencillo de línea de comandos y pueden tratar FTP desde el Explorador de Microsoft Windows hasta cierto límite. El cliente de modo texto no proporciona ningún extra, pero debe resultar bastante cómodo para los usuarios de UNIX y funciona sin complicaciones. Quienes deseen un cliente FTP más gráfico y amistoso tienen una amplia variedad en la que elegir, incluidos algunos que son puro software gratuito o software de libre distribución. El preferido de los autores es WS FTP Pro de Ipswitch (http://www.ipswitch.com). Windows 2000 también incluye un servidor FTP completo como parte de la familia Internet Information Services (IIS). Con un cliente y un servidor FTP disponibles de origen resulta sencillo copiar archivos entre las máquinas UNIX y de Windows 2000 de la red.
Todas las versiones de Windows 2000 vienen con el nuevo cliente de Telnet de modo texto que se estrenó en SFU. El cliente de telnet semigráfico francamente horrible que se ha proporcionado desde Microsoft Windows 3 desaparece por fin. El nuevo cliente es más rápido, tiene mejores emulaciones de terminales y es realmente bastante bueno para la mayor parte de sus fines. Soporta ANSI (American National Standards Institute), incluido el color, VT52, VT100 y VTNT, una emulación especial que puede resultar útil al ejecutar aplicaciones de Windows 2000 de modo texto como Edit. Si ninguno de estos modos satisface las necesidades de emulación de terminales, hay disponibles excelentes clientes de telnet comerciales de otros fabricantes.
El modo de compartir archivos de red de Windows 2000 se basa en el mecanismo tradicional de Microsoft de los bloques de mensajes del servidor (Server Message Blocks, SMB). Los sistemas UNIX, por su parte, utilizan el Sistema de archivos de red (Network File System, NFS) -desarrollado originalmente por Sun Microsystems- para compartir los sistemas de archivos por la red.
Hasta la publicación de SFU solo se disponía de soluciones NFS de otros fabricantes para los sistemas Windows que necesitaban compartir recursos de archivos con los sistemas UNIX. La mayor parte de estas soluciones de otros fabricantes resultaban caras y problemáticas. El principal problema era su incapacidad para mantenerse al nivel de los service packs de Windows NT, que casi siempre parecían descomponer estas soluciones NFS. Además, estas soluciones tenían frecuentemente problemas significativos de rendimiento.
No obstante, varias soluciones UNIX potentes basadas en SMB abordan el problema del modo de compartir recursos de archivos entre Windows NT y UNIX. Estas soluciones SMB varían en coste desde la gratuidad hasta las más caras y soportan las redes nativas de Windows al nivel de grupo de trabajo o de dominio. Con la publicación de Windows 2000 sólo el tiempo podrá decir el modo en que estas soluciones logran mantenerse al nivel de los cambios en el modelo de seguridad de Windows 2000 respecto del modelo de Windows NT.
NFS se diseñó para ejecutarse como protocolo de difusión mediante el protocolo de datagramas de usuario (User Datagram Protocol, UDP). Este protocolo creaba problemas importantes de rendimiento y de tráfico de red para quienes pretendían implementar grandes cantidades de red NFS y hacía difícil compartir sistemas de archivos más allá de los límites de los enrutadores. Finalmente, el estándar del NFS se modificó para que soportara TCP para la red NFS y muchos clientes y servidores modernos soportan este mecanismo. No obstante, muchas implementaciones antiguas de NFS todavía en funcionamiento no soportan TCP, por lo que el mecanismo predeterminado para SFU y otras implementaciones de NFS en Windows 2000 es UDP
En conjunto, el rendimiento de las transferencias de archivos NFS hacia y desde el servidor de Windows 2000 es sustancialmente más baja que la de la mayor parte de las implementaciones SMB. Para entonos en los que se deben copiar habitualmente archivos grandes entre sistemas Windows 2000 y UNIX, es probable que NFS no sea una solución satisfactoria. No obstante, si las necesidades son principalmente de acceso transparente a los recursos UNIX residentes en servidores UNIX, NFS es la mejor opción. Proporciona un entorno completamente integrado para los usuarios de Windows 2000.
El principal problema que tienen los usuarios de SMB sobre UNIX es el modelo cambiante de seguridad de Windows 2000. Se utilizan dos mecanismos para tratar la seguridad con las soluciones de SMB sobre UNIX: la seguridad de nivel de grupo de trabajo y la seguridad de nivel de dominio de Windows NT 4.
La seguridad de grupo de trabajo sufre los mismos problemas que los grupos de trabajo en el entorno empresarial: resulta más difícil gestionar a medida que aumenta el número de usuarios y de máquinas, y tiene opciones limitadas para una verdadera gestión de la seguridad. No obstante, la seguridad de grupo de trabajo tiene realmente sentido en entonos más reducidos, donde resulta fácil de comprender y sencilla de configurar. Además, hay una buena ventaja de costes: en casi todas las plataformas de UNIX se dispone de un servidor SMB de software gratuito fácil de encontrar y bien implementado, denominado Samba. También se dispone de otros servidores SMB para grupos de trabajo que se pueden ejecutar en gran variedad de plataformas. Tienden a ser más parecidos a Windows y más sencillos de configurar y de administrar que Samba, que muestra su procedencia de código abierto.
También se pueden obtener servidores SMB de dominios Windows NT 4 de varios fabricantes de UNIX. Todos ellos se basan en el puerto inicial de AT&T para UNIX de la tecnología de servidores avanzados de Microsoft. Cada uno de ellos está limitado a ejecutarse en la plataforma para la que fue diseñado, y todos tienen pequeñas diferencias debido a que el puerto de AT&T necesitaba configurarse en la mayor parte de los casos. Todos los servidores SMB pueden ser tanto controladores del dominio principal como controladores del dominio de reserva en los dominios de Windows NT, pero todos ellos tienen problemas al trabajar con el nuevo modelo de seguridad de Windows 2000. Estos servidores, basados en el modelo de seguridad de Windows NT 4, por desgracia, obligan a permanecer en el modo mixto.
Los servidores de dominio SMB presentan una ventaja importante respecto de los servidores SMB de grupos de trabajo: para los usuarios y para los administradores de la red de Windows, todos tienen el mismo aspecto y comportamiento que los servidores auténticos de Windows NT 4. Para gestionarlos se utilizan las herramientas de administración usuales de Windows NT Server, y los servidores y las unidades compartidas tienen el mismo aspecto para los usuarios que los servidores de Windows NT, lo que elimina problemas de formación y de interfaces de usuario. Además, todos los servidores SMB tienen una ventaja respecto de las soluciones NFS: suelen ser significativamente más rápidos en las transferencias de archivos, especialmente al tratar archivos grandes.
Para simplificar la conexión y el trabajo con los sistemas UNIX, Microsoft publicó el paquete SFU que contiene todas las herramientas básicas para la interoperatividad entre Windows 2000 y UNIX. Estos productos incluyen NFS, telnet, la interfaz de comandos Korn de UNIX y utilidades, así como un demonio para sincronización de contraseñas. Antes de instalar SFU hace falta algo de formación respecto a la sincronización de las contraseñas. Luego se examinarán con mayor detalle los demás productos SFU.
La sincronización de contraseñas es una utilidad de sincronización de un solo sentido que permite administrar las contraseñas de los usuarios para Windows 2000 y para UNIX desde el servidor de Windows 2000. SFU incluye demonios precompilados para la sincronización de contraseñas (denominados en UNIX como demonios de contrato (sign-on) o SSOD) para tres de las principales versiones de UNIX: HP-UX, Sun OS y Digital UNIX. También incluye código fuente que, en teoría, permite compilarlo en cualquier otro sistema UNIX que pudiera hacer falta soportar. En realidad, sin embargo, si no se tiene alguno de los tres puertos proporcionados del demonio seguro, es probable que se descubra que la única opción viable es el método inseguro de la sincronización de contraseñas mediante rlogin.
Obviamente, el uso de rlogin tiene problemas de seguridad inherentes, ya que implica la transferencia por la red de contraseñas en texto claro, pero resulta relativamente sencillo de configurar y puede resultar suficiente en redes pequeñas adecuadamente protegidas de las influencias externas. Tampoco necesita software ni configuración adicionales y es básicamente independiente de las plataformas.
Los hosts de UNIX se organizan en vainas, con el método de sincronización de contraseñas gestionado vaina a vaina. Se pueden crear vainas nuevas, añadir hosts a las existentes o modificar el método de sincronización de una vaina mediante el Administrador del servicio de sincronización de contraseñas (Password Synchronization Service Administrator, psadmin.exe).
Cuando se crea una nueva vaina, se piden los hosts miembros de la vaina y la metodología de sincronización de las contraseñas que se utilizará en la vaina. Esto se puede cambiar más adelante. También se dispone de la opción de activar el inicio de sesión en modo informativo. De manera predeterminada sólo se registran los fallos, pero cuando se activa el activar el inicio de sesión en modo informativo, todas las acciones de sincronización se registran en el Visor de sucesos.
Aunque algunos entornos de UNIX no permiten el uso de rlogin, allí donde es una opción viable proporciona un mecanismo sencillo y fácil de configurar. Cuando la red se halla completamente aislada del mundo exterior por un cortafuego muy seguro (o cuando no hay conexión con el mundo exterior), se puede utilizar rlogin para gestionar la sincronización entre las máquinas de Windows 2000 y las de UNIX. Esta opción tiene la ventaja de no necesitar software adicional en los hosts de UNIX, ya que la mayor parte de las versiones de UNIX soportan rlogin.
Para configurar la sincronización de contraseñas mediante rlogin, hay que configurar antes los hosts remotos de UNIX para que soporten correctamente rlogin para la cuenta raíz: Esto exige la creación en el servidor de un archivo .rhosts. Este archivo .rhosts debe tener los permisos de modo que sólo root (o la cuenta autorizada a cambiar las contraseñas) pueda escribir en él, debe poseerlo root (o la cuenta alternativa mencionada) y residir en el directorio raíz de la cuenta root o de la cuenta alternativa. Debe contener un listado de la máquina en que se llevará a cabo el cambio de contraseñas -generalmente, un controlador del dominio-. El listado sólo debe tener el nombre abreviado de la máquina, no el nombre de dominio completo.
La configuración predeterminada para la sincronización mediante rlogin utiliza la cuenta root, espera un indicativo «#» y supone que la orden para cambiar las contraseñas es passwd. Si el entorno es diferente de éste se pueden modificar estos valores predeterminados mediante el Administrador del servicio de sincronización de contraseñas (Password Synchronization Service Administrator).
A diferencia de las cuentas de Windows 2000 y de Windows NT, que no diferencian entre mayúsculas y minúsculas, las cuentas de usuario de los sistemas UNIX sí lo hacen. Si ya se tienen cuentas de Windows 2000 que mezclan mayúsculas y minúsculas, es probable que se descubra que se emplea más tiempo y esfuerzo en alinear las cuentas que el que se ahorra a la larga. Pero si sólo se trata de añadir Windows 2000 a un entorno UNIX existente, se puede hacer que la sincronización de las cuentas y de las contraseñas sea sencilla y directa creando las cuentas de Windows 2000 correspondientes sólo en minúsculas desde el primer momento. Los nombres de visualización asociados con las cuentas pueden seguir mezclando mayúsculas y minúsculas; sólo tiene que estar completamente en minúsculas el nombre de la cuenta subyacente.
SFU facilita la sincronización segura de contraseñas mediante archivos binarios precompilados que se ejecutan como demonios en el servidor de UNIX, lo que le permite recibir las contraseñas cifradas enviadas por Windows 2000 y luego modificar la contraseña UNIX de la misma cuenta. No obstante, las advertencias sobre la distinción entre mayúsculas y minúsculas relativas a la sincronización mediante rlogin son igualmente aplicables a la sincronización segura.
Para instalar el demonio de sincronización de contraseñas, hay que copiar los archivos SSOD y ssod.config de la versión correspondiente del demonio seguro en la máquina UNIX que será objeto de la sincronización de contraseñas. Una ubicación de destino típica para estos archivos es /usr/local/etc, pero esto varía de sistema a sistema y no resulta fundamental. Si se utiliza FTP para copiar los archivos, hay que asegurarse de que se utiliza una transferencia binaria para evitar la corrupción de los archivos.
Una vez copiados los archivos en la máquina UNIX, hay que utilizar el mecanismo adecuado para instalarlos. Esto varía según la plataforma, pero puede incluir pkgadd a otros mecanismos de instalación. Hay que editar el archivo ssod.config facilitado para que refleje las ubicaciones de los archivos en el sistema y el tipo de sincronización correspondiente. Se soportan tanto NIS (Network Information Service, servicio de información de red) como /etc/passwd, al igual que la sombra de contraseñas.
El archivo ssod.config debe residir en el mismo directorio que el demonio. Una vez configurado, el demonio se puede iniciar manualmente o añadirlo al archivo de inicio correspondiente. Los mecanismos de inicio varían de plataforma a plataforma, pero pueden incluir /etc/rc.local y envoltura de la interfaz de comandos en un directorio /etc/rc2.d.
Cuando se crea la vaina UNIX y se selecciona Usar cifrado (Use Encryption), se abre el cuadro de diálogo Configuración de propagación segura (Secure Propagation Settings). Hay que abrir el número del puerto que se ha configurado en la parte UNIX y la clave secreta de cifrado seleccionada en el archivo ssod.config. Esta clave se utilizará para cifrar la contraseña antes de pasarla por la red.
Ahora ya se está preparado para instalar SFU. Para ello hay que seguir este procedimiento:
Una vez instalado SFU se puede examinar su configuración. SFU eran inicialmente varios productos diferentes de procedencias distintas unidos en un único paquete. Cada producto tiene una interfaz y un mecanismo de configuración diferentes y, en consecuencia, no tiene un aspecto coherente. Aun así, la funcionalidad se halla en cada componente y, generalmente, no depende de los otros integrantes del paquete. Los componentes básicos del producto (la mayor parte de los cuales ya se ha examinado brevemente) pueden clasificarse en alguna de las tres categorías siguientes:
El cliente y el servidor telnet proporcionan un excelente método para comunicarse entre las máquinas de Windows 2000 y las de UNIX. Pero los servicios de telnet también pueden ofrecer importantes ventajas en la administración diaria de las propias máquinas de Windows 2000. Al añadir un servicio telnet a los servidores de Windows 2000 se proporciona a los servidores una interfaz de línea de comandos sencilla y que sobrecarga poco el sistema que permite gestionar gran variedad de tareas administrativas desde un único sistema de escritorio e, incluso, mediante una línea telefónica lenta.
Tal y como se instala, el servidor de telnet funciona de manera óptima en la mayor parte de las instalaciones. Proporciona acceso desde cualquier servidor o estación de trabajo que tenga instalado un cliente de telnet y ofrece una interoperatividad mejorada en el ámbito de la empresa y una mejora en las posibilidades de gestión, incluso en entornos Windows 2000 puros. Acepta inicios de sesión de una gran variedad de clientes, incluidos el cliente telnet gráfico incluido con Windows NT y con Microsoft Windows 95/98 y gran variedad de clientes de terminal en modo texto de prácticamente todos los sistemas operativos. Además, puede cumplir los requisitos específicos del sitio para mejorar la seguridad, simplificar los inicios de sesión, etc.
NT LAN Manager: El servidor telnet de SFU soporta NT LAN Manager (NTLM) para la autenticación de los inicios de sesión de los clientes. NTLM autentica automáticamente al usuario con base en su inicio de sesión de Windows 2000, lo que proporciona una conexión transparente con el host mientras asegura que no se transfieran por la red contraseñas en texto claro. NTLM debe estar soportado tanto en el cliente como en el servidor, sin embargo, lo que hace que esta opción sólo sea viable entre máquinas de Windows, y no directamente con máquinas UNIX.
Al utilizar el inicio de sesión NTLM los usuarios quedan restringidos a las unidades locales de la máquina en la que han iniciado la sesión. Si necesitan asignar recursos de la red pueden hacerlo asignándolos directamente con su denominación completa. Por ejemplo:
net use g:\\servidor\unidad compartida\usuario:dominio\nombre de usuario
Administración: El servidor de telnet se administra mediante el programa tlntdmn.exe, que se instala de manera predeterminada en <SFU Root>\telnet y proporciona un menú de texto sencillo que se puede ejecutar prácticamente desde cualquier ventana de texto, incluido un inicio de sesión telnet remoto. Con el programa tlntadmn.exe se pueden mostrar los usuarios actuales, terminar un grupo de usuarios, mostrar (y modificar) los valores del registro para el servidor a iniciar y concluir el servicio. Entre los valores del registro que se pueden modificar están los siguientes:
Valores del registro: Se puede utilizar el programa de administración de telnet facilitado para editar los valores del registro para el servidor de telnet, o también se pueden editar manualmente utilizando regedit o regedt32. La subclave para el servidor de telnet es HKEY_ LOCAL MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0.
|
Valores del registro para el servidor de telnet | ||
| Clave del registro | Tipo | Valor predeterminado |
| AllowTrustedDomain | REG_DWORD | 0x00000001 |
| AltKeyMapping | REG_EXPAND_SZ | |
| DefaultDomain | REG_EXPAND_SZ | |
| DefaultShell | REG_ EXPAND_ SZ | %SystemRoot%\system32\,cmd.exe/q/k |
| LoginScript | REG_ EXPAND_ SZ | %SystemRoot%\system32Vogin.cmd |
| MaxConnections | REG_ DWORD | 0x0000003f (63) |
| MaxFailedLogins | REG_ DWORD | 0x00000003 |
| NTLM | REG_ DWORD | 0x00000002 (sólo NTLM) |
| TelnetPort | REG_ DWORD | 0x00000017 (23) |
| Termcap | REG_ DWORD | %SystemRoot%\system32\termcap |
Además, hay una subclave específica para el ajuste del rendimiento:
HKEY_LOCAL_MACHINE
\SOFTWARE
\MICROSOFT
\TelnetServer
\1.0
\Performance
\NumThreadsPerProcessor
El valor mínimo de este parámetro es 2 y el valor predeterminado es 10 (Ox0000000a). En la mayor parte de los entornos el valor predeterminado optimiza el rendimiento.
Aunque Windows 2000 viene con un típico cliente de telnet de modo gráfico, también incluye el nuevo cliente de telnet SFU de modo texto que proporciona barras de desplazamiento muy mejoradas y la posibilidad de autentificar el uso de contraseñas cifradas al conectarse a los servidores de telnet que soportan autenticación NTLM. Resulta a la vez más rápido y de mejor funcionamiento que el cliente de modo gráfico al que sustituye.
Además, el cliente de telnet proporciona emulaciones de terminales, incluyendo una emulación ANSI que soporta correctamente los colores al conectarse con servidores que también los soporten, como los que ejecutan la variante de UNIX de Santa Cruz Operation (SCO). También hay una nueva emulación VTNT que soporta características mejoradas en la conexión entre máquinas de Windows NT y de Windows 2000, incluida la posibilidad de ejecutar aplicaciones complejas de modo texto como edit.exe que no funcionan en emulaciones estándar de terminales.
La configuración de telnet se realiza desde el interior de una sesión de telnet "escapando" al indicativo de telnet. Hay que pulsar CTRL + el corchete derecho (]) para obtener el indicativo de telnet una vez iniciada una sesión. A partir de ese momento se pueden utilizar las opciones siguientes:
Si se conecta principalmente con sistemas UNIX, hay que definir TERM como ANSI y definir NTLM como desactivado (off), pero, si se conecta frecuentemente tanto con sistemas Windows NT como con sistemas UNIX, o si lo hace principalmente con sistemas Windows NT, se descubrirá que la emulación VTNT es una opción más adecuada y se seguirá utilizando ANSI al conectar con sistemas que no soporten VTNT.
SFU proporciona conectividad adicional de servicios de archivos además del cliente y del servidor FTP nativos de Windows 2000. La adición del cliente y del servidor NFS permite la conectividad nativa de modo que parezca natural tanto a los usuarios de UNIX como a los de Windows 2000.
Al utilizar el cliente de NFS integrado naturalmente se pueden asignar sistemas de archivos exportados de los servidores UNIX como si fueran unidades compartidas nativas de Windows 2000, usando el formato UNIX servidorIrecursoexportado o el formato Windows. Y el servidor NFS permite compartir los recursos de archivos con los sistemas UNIX o con otros clientes NFS, incluidos los clientes de Windows 2000. En primer lugar se examinará el cliente NFS.
Al instalar el cliente NFS, se añade un applet al Panel de Control para administrar los parámetros del cliente NFS. Hay que abrir el Panel de Control y pulsar dos veces Client for NFS (Cliente para NFS) para abrir la ventana Propiedades de Client for NFS. Los apartados siguientes detallan las opciones que se pueden seleccionar al administrar los parámetros del cliente NFS.
Authentication (Autentificación) Define las opciones de autenticación en función del tipo de sistema y de entorno UNIX con el que se está conectado. A continuación figuran varias opciones de la ficha Authentication (Autentificación):
También se dispone de estos otros parámetros:
Mount Options (opciones de montaje): La ventana Propiedades de Client for NFS permite especificar el tamaño de los búferes de lectura y de escritura (el valor predeterminado es 64 K), el intervalo de espera inicial, el número de intentos y si se deben utilizar montajes duros (hard) o en caliente (soft). A menos que se disponga de una buena razón para modificar estos valores, se deben dejar tal y como están. Resultan óptimos para las conexiones que los soportarán y, en caso necesario, retrocederán automáticamente.
En la ventana Propiedades de Client For NFS hay otros tres parámetros de montaje:
Permisos de acceso a archivo: Los permisos de acceso a los archivos para el cliente NFS ión para el usuario (propietario) del archivo, pero sólo Lectura y Ejecución para el grupo propietario y para los demás usuarios (lo que equivale a una umask de 022).
Filename Mapping (asignaciòn de nombres de archivo): Se puede asignar la manera en que se crean los nombres de archivo y el modo en que se asignan los nombres de archivo existentes entre el servidor NFS remoto y el cliente NFS. Las opciones de nombres de archivo que se crean desde el cliente son las siguientes:
Las opciones para la asignación de los nombres de archivo existentes son las siguientes:
En entonos mixtos en que los usuarios tengan acceso tanto a archivos de Windows como a archivos de UNIX, se descubrirá que definir la asignación de nombres de archivo de modo que los convierta automáticamente a minúsculas, pero que los compare ignorando el tipo de letra, causa el mínimo de molestias a ambas comunidades de usuarios.
Configuración de las LAN de NFS: Antes de que el cliente NFS pueda explorar la red de manera efectiva en búsqueda de sistemas de archivos exportados (compartidos), hay que configurar la LAN de NFS. Hay dos opciones para la configuración de la LAN de NFS: FavoriteLAN y LAN de difusión identificada. Se debe utilizar LAN de difusión para dividir la red en segmentos lógicos, limitar las difusiones únicamente a una parte concreta de la red y reducir el tráfico de red.
Se puede crear una única FavoriteLAN que incluya a los servidores NFS con los que se establezca conexión con mayor frecuencia. Estos servidores se identifican por su nombre o por su dirección IP, independientemente del segmento en que se encuentren. Utilizando una FavoriteLAN se limita la cantidad de tráfico de red de difusión y se acelera la conexión a los recursos preferidos. Para crear una FavoriteLAN y añadirle un servidor, hay que seguir el procedimiento siguiente:
La creación y uso de una LAN de difusión identificada es un proceso muy parecido al uso de FavoriteLAN, salvo en que hay que tener cierta información sobre el segmento de red en que reside la LAN de difusión. Para crear una LAN de difusión hay que seguir el siguiente procedimiento:
Vínculos simbólicos: Los vínculos simbólicos son un modo de que un archivo o directorio exista en una dirección física pero se pueda ver como existente en una o varias direcciones diferentes. Cuando un vínculo simbólico hace referencia a un archivo o a un directorio que es local en la máquina en que se ubica el vínculo, el cliente para NFS no necesita realizar ninguna actividad especial para seguirlo. Pero también se pueden crear vínculos simbólicos en servidores NFS que apunten a archivos o directorios que se hallen realmente en máquinas remotas.
Para resolver estos vínculos, el cliente para NFS debe tener un archivo de asignaciones que identifique la máquina real a la que apunta el vínculo. El archivo de asignaciones debe residir en la máquina cliente local, o estar ubicado de manera central en la red para su mejor administración. El archivo de asignaciones es un archivo de texto ASCII y tiene el formato siguiente:
# Las líneas que comienzan por un signo # son comentarios y se ignoran mnt \máquina\export
Hay que utilizar la ficha Symbolic Links (vínculos simbólicos) para definir las opciones.
De manera predeterminada, el cliente para NFS no resuelve ni muestra vínculos no resueltos. Tampoco permite la redenominación ni la eliminación de vínculos simbólicos. Sólo se deben activar las opciones Rename o Delete de los vínculos simbólicos si se comprenden plenamente las consecuencias de su redenominación y de su eliminación y se conoce el mecanismo o programa que las vaya a realizar. Si se elimina un vínculo simbólico y se sustituye por un archivo con el mismo nombre, dejará de ser un vínculo simbólico. Habrá dos archivos en el servidor NFS: el archivo original en su ubicación primitiva y el archivo sustituto en la ubicación del vínculo.
Conexión con una exportación NFS La conexión con una exportación NFS es igual que la conexión con cualquier recurso de sistemas de archivos compartidos de la red. Mediante el Explorador de Microsoft Windows se pueden hallar redes NFS además de las redes de Microsoft Windows y de cualesquiera otras redes que se hayan configurado en Mis sitios de red.
Si se desea conectar con un sistema de archivos NFS exportado, se puede utilizar la sintaxis estándar de Windows (\\servidor\recursocompartido) o la sintaxis estándar de UNIX (servidor:/recursocompartido). El uso de la sintaxis UNIX estándar resulta algo más rápido, ya que resuelve inmediatamente la sintaxis NFS nativa y evita la necesidad de buscar una unidad compartida convencional de Windows que tenga el mismo nombre.
También se pueden utilizar las órdenes Net Use de la línea de comandos pare conectar directamente con un recurso concreto si se conoce su ubicación. Por ejemplo, pare asignar la siguiente letra de unidad disponible al sistema de archivos exportado /home en served del servidor NFS, se puede utilizar cualquiera de las órdenes siguientes:
net use * server1:/home net use * \\server1\home
Se puede utilizar el servidor SFU NFS robusto pare proporcionar recursos de las máquinas de Windows 2000 a cualquier máquina de la red que soporte NFS. Incluso se podría utilizar pare exportar sistemas de archivos a otras máquinas de Windows 2000 que ejecuten el cliente SFU NFS, aunque se recomienda, en general, utilizar pare ello la red nativa de Windows 2000. Los apartados siguientes describen las opciones disponibles pare la configuración de NFS.
Unidades compartidas: Las unidades compartidas se crean mediante Server for NFS Configuration (Configuración del servidor pare NFS) del Panel de control. Se pueden compartir directorios individuales o toda una unidad. No se pueden compartir subdirectorios de recursos ya compartidos, dado que NFS no lo soporta, por lo que se deberán planificar las unidades compartidas pare asegurarse de que se comparte desde la altura del árbol que resulte necesaria. Cada letra de unidad se comparte como la parte superior de un sistema de archivos.
En el entorno UNIX todos los sistemas de archivos se ven como subdirectorios del sistema raíz. Como Windows 2000 carece de este concepto de sistema de archivos de raíz única, cada letra de unidad de disco se comparte como un sistema de archivos diferente. Las Letras de unidad de la forma "D:" se convierten a la sintaxis < /D/». Por tanto, la unidad compartida de la carpeta F:\UserHome es vista por los clientes NFS de la red como: /F/UserHome. Pare crear una unidad compartida NFS, hay que seguir el siguiente procedimiento:
Alias de las unidades NFS compartidas: Se pueden crear alias para las unidades NFS compartidas para hacer que las unidades NFS compartidas de Windows 2000 tengan un aspecto más parecido al que pueden esperar los usuarios de UNIX. Hay que tener en cuenta que los alias NFS necesitan un reinicio de la computadora para tener efecto, por lo que hay que crear primero todos los puntos compartidos y luego añadir todos los alias para reducir el número de reinicios necesarios. Para crear un alias, hay que seguir el procedimiento siguiente:
Grupos de Clientes: El servidor para NFS proporciona un mecanismo para la gestión de los permisos y las unidades compartidas por grupos de computadoras, conocido como grupos de clientes. Al crear grupos de clientes se pueden exportar (compartir) recursos de sistemas de archivos a grupos concretos de computadoras sin necesidad de especificar cada vez cada computadora por se parado. Esta capacidad también mejora la gestión y la administración al permitir la gestión de los miembros de cada grupo desde una misma ubicación.
Los cambios en la pertenencia a los grupos (y, por tanto, los permisos) se modifican de manera automática en cada recurso NFS que hace referencia a ese grupo de clientes. Para crear grupos de clientes, hay que seguir el procedimiento siguiente:
Bloqueo de archivos: Se puede activar el bloqueo de archivos para los clientes de NFS y para todo el sistema, con propagación local y por la red. De manera predeterminada, el bloqueo está desactivado, pero si se espera utilizar aplicaciones en montajes NFS que necesiten el bloqueo de archivos, puede que se desee activarlo. Todos los cambios en el bloqueo de archivos necesitan un reinicio de la máquina, por lo que hay que tenerlo en cuenta a la hora de la planificación.
Seguridad: Server for NFS Configuration utiliza entradas de control de acceso para simular los permisos típicos de los mundos UNIX y NFS. Sin embargo, se pueden inhibir ciertos comportamientos que suelen ser posibles en el conjunto de permisos de UNIX pero que no se aplican normalmente en Windows 2000 o Windows NT. Concretamente, se puede inhibir la posibilidad de los clientes NFS de denegar el acceso al propietario y al grupo poseedor de un archivo. También se pueden definir permisos para objetos para que coincidan más estrechamente con la manera en que Windows 2000 los gestiona seleccionando la opción Implicit Permissions (permisos implícitos) y escogiendo FULL Control (Group) [control completo (grupo)] y FULL Control (World) [control completo (todos)].
Los modelos de seguridad de UNIX y de Windows 2000 tienen conjuntos de permisos intrínsecamente diferentes. Cualquier intento de correlacionarlos constituye una mera aproximación.
Los usuarios de UNIX esperan una gran cantidad de utilidades de la línea de comandos que no existen en el mundo de Windows 2000. No obstante, SFU incluye un conjunto reducido de las utilidades UNIX más comunes basado en el Kit de herramientas de Mortice Kern Systems (MKS), incluida la interfaz de comandos Korn MKS para facilitar la posibilidad de compartir las secuencias de comandos. Si se necesita un conjunto completo de utilidades UNIX, un complemento de MKS (MKS Toolkit Services for UNIX Update Edition) proporciona el resto. del kit de herramientas de MKS y más de 200 utilidades UNIX.
Las utilidades SFU se agrupan en cuatro categorías principales: utilidades para archivos y directorios, utilidades de texto, utilidades de programación y utilidades relacionadas con la seguridad. En cada caso están disponibles las más importantes, pero, si se espera poder utilizar las secuencias de comandos del mundo UNIX en Windows 2000, puede que se considere que esta lista resulta insuficiente para cubrir las necesidades, a menos que se sea cuidadoso al elaborar la secuencia de comandos o que se aproveche la utilidad de programación Perl incluida para superar los límites de la interfaz de comandos Korn.
Utilidades para archivos y directorios Las utilidades del sistema de archivos incluidas en SFU son las siguientes:
Utilidades de texto: Las utilidades de texto incluidas en SFU son las siguientes:
Utilidades de programación Las utilidades de programación incluidas en SFU
son las si-
guientes:
Utilidades relacionadas con la Segurid8d Las utilidades de seguridad
incluidas en SFU son
las siguientes:
Tanto el kit de herramientas completo de MKS como el subsistema Interix incluyen un grupo de utilidades mucho más numeroso que las que se proporcionan con SFU. Interix también incluye su propia implementación de telnet (que, por desgracia, tiene licencias por usuario, lo que incrementa notablemente su coste). El kit de herramientas de MKS incluye varias utilidades gráficas, incluida una versión gráfica bastante buena de vi y otras varias utilidades que se prestan bastante bien a la implementación gráfica. Tanto MKS como Interix incluyen versiones que escriben en cinta o en disquete, como podría esperar cualquier administrador de UNIX.
Ningún estudio sobre la interoperatividad entre Windows y UNIX estaría completo sin abordar las diferencias entre sus interfaces de comandos. Resulta interesante que todavía nadie haya aportado una emulación de la interfaz de comandos cmd.exe de Windows NT/2000 a UNIX. Pero hay gran variedad de emulaciones y puertos de las interfaces de comandos de UNIX a Windows 2000, lo que está bien, ya que el usuario típico de UNIX no desea abandonar la interfaz de comandos completa Korn o POSIX para trabajar con las limitaciones de la interfaz de comandos de comandos de Windows.
Como ya se conoce, SFU proporciona una implementación excelente de la interfaz de comandos Korn de UNIX en Windows 2000. Se basa en la implementación de la interfaz de comandos Korn de MKS con las peculiaridades propias de esa implementación.
La interfaz de comandos Korn de MKS, tanto en SFU como directamente en MKS, obtiene la máxima acomodación al mundo de Windows 2000. No distingue entre mayúsculas y minúsculas e ignora totalmente la caja de la letra al comparar nombres de archivo, aunque al igual que NTFS lo conserva. Tampoco transforma la sintaxis de las letras de unidad de Windows 2000 en sistemas de archivos con raíz única, más propios de UNIX. Esto hace que resulte bastante cómodo para los usuarios de Windows 2000 que también, a veces, pasen algún tiempo en el entorno UNIX, pero lo hace algo menos cómodo para los usuarios de UNIX que tengan que pasar algún tiempo de manera ocasional en el indicativo de comandos de Windows 2000.
Las secuencias de comandos escritas para UNIX pueden pasarse con bastante facilidad a la interfaz de comandos Kom de MKS. Las funciones están soportadas, a incluso la comparación mediante corchetes dobles ([[]]) funciona como es de esperar. El mayor problema es el tratamiento de las letras de unidad y la confusión sintáctica resultante. Las entradas PATH se separan mediante punto y coma, en lugar de por dos puntos, para atenerse al requisito del uso de dos puntos detrás de las letras de unidad; en consecuencia, hay que reescribir las secuencias de comandos que pretenden dividir la instrucción PATH utilizando los dos puntos como separador de campos. Y las secuencias de comandos que deban trabajar tanto en sistemas UNIX como en sistemas de Windows 2000 deben escribirse con esta consideración presente (no resulta difícil, sólo es algo con lo que el usuario típico de UNIX no espera tener que trabajar).
Otro problema que tienen que abordar las secuencias de comandos es la carencia de un sistema de archivos con raíz común. Esto se enmascara mejor utilizando nombres de archivos y caminos completos en las variables y haciendo referencia a los caminos en función de las variables, en vez de hacerlo de modo explícito. Esto no supone un gran problema y tiende, en todo caso, a promover buenas prácticas de programación.
Aunque la interfaz de comandos Korn SFU (y el de MKS) no es más que otra interfaz de comandos que se ejecuta sobre el núcleo nativo de Windows 2000, algunos subsistemas POSIX completos también soportan UNIX en el nivel del núcleo. El mejor de ellos es, sin duda alguna, la implementación POSIX de Interix de Softway Systems, un subsistema que cumple completamente POSIX y se integra directamente en el núcleo de Windows 2000.
La interfaz de comandos POSIX de Interix utiliza el enfoque opuesto al utilizado por la interfaz de comandos Korn de MKS/SFU -no hace prácticamente ninguna concesión al mundo de Windows 2000 y, por el contrario, implementa en Windows 2000 un sistema de archivos con raíz que diferencia completamente entre mayúsculas y minúsculas-. En consecuencia, las secuencias de comandos escritas para UNIX se ejecutan exactamente de la manera esperada sin necesidad de cambios adicionales, al menos en teoría. No obstante, la distinción total entre mayúsculas y minúsculas causa un sinnúmero de problemas, y la ausencia de concesiones a la sintaxis de Windows 2000 implica que hay que recordar que los programas nativos de Windows 2000 tienen nombres como notepad.exe, no notepad.
Se pueden hallar soluciones a estos problemas, incluido el uso de un conjunto de utilidades cuya única misión es convertir los caminos y los tipos de letra de Windows 2000 a POSIX, y viceversa. No obstante, los problemas con el uso de secuencias de comandos de UNIX en ambos entornos son similares a los de la implementación MKS/SFU: hay que recordar las diferencias entre ambos entornos y escribir las secuencias de comandos de manera que puedan superarlas.