SRI. Solución Tema 4.

Servidores Web 1

Se partirá de la configuración de red siguiente:

a. Los equipos están en la red 192.168.1.0/24 (Se supone que dicha red es a la que pertenece los
equipos de vuestra casa. Si no fuera ésta, usar la red apropiada.)
b. La MV Linux pertenecerá a la red anterior con IP 192.168.1.Y3, con puerta de enlace la de vuestro
router-modem de casa y tierra como nombre de host. Sustituye el valor de Y con el número de
puesto habitual de clase. Por ejemplo si la red de casa es 192.168.1.0/24 y usas el puesto 7 en clase,
la IP de la MV Linux sería 192.168.1.73.
c. La MV Windows Server se denominará marte, tendrá como IP 192.168.1.Y4 y como puerta de
enlace la de vuestro router-modem de casa.
d. La MV Linux (tierra) será un servidor DNS y tendrá autoridad sobre el dominio sistema.sol. De igual
forma actuará como servidor maestro y tendrá autoridad sobre la zona de resolución inversa de la red
192.168.1.0/24. Por lo tanto el servidor DNS del dominio será tierra.sistema.sol.
e. Los nombres de los equipos y su IP serán:
mercurio.sistema.sol 192.168.1.Y1 (host imaginario)
venus.sistema.sol 192.168.1.Y2 (host imaginario)
tierra.sistema.sol 192.168.1.Y3 (máquina virtual Linux)
marte.sistema.sol 192.168.1.Y4 (máquina virtual Windows Server)

f. Las dos MVs usarán como servidor DNS el instalado en tierra y añadirán el sufijo sistema.sol a los
nombres de dominio no FDQN.
g. Probar con el comando nslookup desde las dos MVs que los nombres de dominio se resuelven
adecuadamente. Si el servicio DNS no funciona, no se puede seguir con los ejercicios…

1. Realizar y configurar alojamiento virtual por nombres de 2 sitios web en Apache

sobre Linux.

Se quiere crear y habilitar dos servidores web para los dominios apolo.sistema.sol y soyuz.sistema.sol
alojados en el host tierra.sistema.sol. Las características de éstos dos dominios se detallarán en la
lista de pasos que se deberán realizar.

1. Configurar el servidor DNS para que resuelva los nombres apolo.sistema.sol y soyuz.sistema.sol
como alias de tierra.sistema.sol.

Se debe añadir dos RR de tipo CNAME al archivo de registros de recursos de la zona sistema.sol
apolo.sistema.sol. IN CNAME tierra.sistema.sol.
soyuz.sistema.sol. IN CNAME tierra.sistema.sol.

2. A continuación probar mediante nslookup o dig que ambos nombres de dominio se resuelven
adecuadamente.
alumno@tierra:~$ nslookup apolo.sistema.sol
Server: 192.168.1.103
Address: 192.168.1.103#53

apolo.sistema.sol canonical name = tierra.sistema.sol.

Name: tierra.sistema.sol
Address: 192.168.1.103

alumno@tierra:~$ nslookup soyuz.sistema.sol

Server: 192.168.1.103
Address: 192.168.1.103#53

soyuz.sistema.sol canonical name = tierra.sistema.sol.

Name: tierra.sistema.sol
Address: 192.168.1.103

3. Crear los directorios raíz de cada uno de los servidores. Por ejemplo pudieran ser /var/www/apolo
y /var/www/soyuz.
a) Añadir a cada uno de los directorios anteriores respectivamente un archivo de nombre
apolo.html e soyuz.html con el contenido en HTML que se desee.
b) Al directorio /var/www/apolo añadirle dos archivos de texto (apolo1.txt y apolo2.txt)
c) Al directorio /var/www/soyuz añadirle dos archivos de texto (soyuz1.txt y soyuz2.txt)

IES Zaidín Vergeles de Granada. Departamento de Informática.

2 SRI. Solución Tema 4. Servidores Web

4. Crear con Apache los dos servidores virtuales web para los dos dominios. Cada servidor virtual
usará un fichero de configuración diferente de nombres webapolo.conf y websoyuz.conf alojados en
el directorio /etc/apache2/sites-available.
Características a cumplir en ambos servidores:

a) Podrán acceder todos los usuarios.

b) Cuando se produzca un error del tipo 403 se enviará el mensaje “No tiene permiso de acceso”.
c) Cuando se produzca un error del tipo 404 se enviará la página notfound.html que deberá
almacenarse en una carpeta denominada messages ubicada en los directorios raíz de cada uno
de los servidores. El contenido de la página presentará el mensaje personalizado “Recurso no
encontrado en apolo.sistema.sol” o bien el mensaje “Recurso no encontrado en soyuz.sistema.sol”
dependiendo del cual sea el sitio en el cual el recurso solicitado no existe.
d) Cada servidor tendrá sus propios archivos de logs de errores y accesos ubicados en el
directorio messages del servidor web correspondiente.

5. En el caso de que no se solicite ningún recurso en concreto,

a) el servidor para el dominio apolo.sistema.sol mostrará un listado del directorio raíz del sitio.
b) el servidor para el dominio soyuz.sistema.sol mostrará el mensaje de error 403 que se
personalizó en el punto anterior.

// Archivo /etc/apache2/sites-available/webapolo.conf
<VirtualHost *:80>
ServerName apolo.sistema.sol
DocumentRoot /var/www/apolo
ErrorDocument 403 "No tiene permisos de acceso"
ErrorDocument 404 /messages/notfound.html

<Directory /var/www/apolo>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

ErrorLog /messages/apolo.error.log
LogLevel warn
CustomLog /messages/apolo.access.log combined
</VirtualHost>

// Archivo /etc/apache2/sites-available/websoyuz.conf
<VirtualHost *:80>
ServerName soyuz.sistema.sol
DocumentRoot /var/www/soyuz
ErrorDocument 403 "No tiene permisos de acceso"
ErrorDocument 404 /messages/notfound.html

<Directory /var/www/soyuz>
Options FollowSymLinks
AllowOverride None
Require all granted
</Directory>

ErrorLog /messages/soyuz.error.log
LogLevel warn
CustomLog /messages/soyuz.access.log combined
</VirtualHost>

6. Habilita los dos servidores virtuales, y reinicia el servicio Apache comprobando que no hay
errores.
$sudo a2ensite webapolo.conf
$sudo a2ensite websoyuz.conf
$sudo systemctl restart apache2

7. Accede con el navegador a los siguientes nombres de dominio:

a) apolo.sistema.sol (debe aparecer un listado con los archivos del sitio web)
b) apolo.sistema.sol/apolo.html (debe aparecer el contenido del archivo apolo.html)

IES Zaidín Vergeles de Granada. Departamento de Informática.

 SRI. Solución Tema 4. Servidores Web 3

c) apolo.sistema.sol/index.html (debe aparecer “Recurso no encontrado en apolo.sistema.sol”)

d) apolo.sistema.sol/messages/notfound.html (debe aparecer “Recurso no encontrado en
apolo.sistema.sol”)
e) soyuz.sistema.sol (debe aparecer el mensaje “no tiene permiso de acceso”)
f) soyuz.sistema.sol/soyuz.html (debe aparecer el contenido del archivo soyuz.html)
g) soyuz.sistema.sol/index.html (debe aparecer “Recurso no encontrado en soyuz.sistema.sol”)
h) soyuz.sistema.sol/messages (debe aparecer el mansaje “no tiene permiso de acceso”)

2. Realizar y configurar el alojamiento virtual de un sitio web en Apache sobre

Linux usando autentificación HTTP Digest para dicho sitio.
Cuando Apache recibe una petición para un sitio web comprueba que esta petición esté autorizada, de
forma que sólo los usuarios autorizados puedan acceder al sitio. En concreto realiza tres pasos:

a. Autenticación. Comprueba la identidad del usuario mediante un nombre y contraseña, a ver si

coinciden dichos credenciales con los almacenados en su base de datos. Básicamente existen dos
métodos de autenticación HTTP: básico y digest.
b. Autorización. Posteriormente el servidor comprueba si el usuario previamente validado tiene
autorización a la información solicitada. Apache gestiona estas autorizaciones mediante
directivas en la sección <Directory>.
c. Control de acceso. Por último se establece y controla los equipos que tienen acceso a un recurso
independientemente del usuario que accede. Apache gestiona el control de acceso mediante las
directivas en las secciones <Directory>, <Files> y <Location>.

Teniendo en cuenta lo anterior, se quiere añadir un nuevo servidor virtual para un nuevo dominio
discovery.sistema.sol usando como directorio raíz /var/www/transbordador. El sitio usará autentificación
tipo HTTP Digest de forma que sólo el usuario commander podrá acceder a dicho sitio web.

Los pasos a seguir serían:

1. Configurar el servidor DNS para que resuelva el nombre discovery.sistema.sol
2. Crear el directorio /var/www/transbordador como sitio raíz del sitio web conteniendo un archivo
hello.html con un mensaje de bienvenida para el sitio web.
3. Habilitar el módulo auth_digest. Mediante el comando a2enmod nombre_modulo
$ sudo a2enmod auth_digest
Enabling module auth_digest.
Run '/etc/init.d/apache2 restart' to activate new configuration!

4. Para la autentificación Digest hay que crear un archivo accesible por Apache en el que se
guardarán los usuarios, grupos y contraseñas. Para ello se usa el comando htdigest de la forma:
$ sudo htdigest -c /etc/apache2/archivo_de_claves grupo_de_usuarios usuario

Con la opción –c se permite la creación de un archivo de claves (archivo_de_claves); con

grupo_de_usuarios indicamos el grupo o ámbito al que pertenece el usuario; y con usuario el
nombre de un usuario que se va a añadir al archivo de claves. (Si se quisiera posteriormente
añadir más usuarios, se repite la orden pero sin la opción -c ya que el archivo con las claves ya
ha sido creado…). Al ejecutar el comando se pedirá una clave para el usuario.
En nuestro caso crearemos el archivo de claves de nombre claves-digest, añadiendo el usuario
commander al grupo_de_usuarios o ámbito astronauts. (Luego veremos que el grupo o ámbito
debe coincidir con el dado en la directiva AuthName que usaremos en la configuración del sitio).

$ sudo htdigest -c /etc/apache2/claves-digest astronauts commander

Adding password for commander in realm astronauts.
New password:
Re-type new password:

5. Examina el archivo claves-digest. Debe contener una línea como la siguiente:

$ cat /etc/apache2/claves-digest
commander:astronauts:19c426e5b25e9bd568eaa17b5f0a6503

IES Zaidín Vergeles de Granada. Departamento de Informática.

4 SRI. Solución Tema 4. Servidores Web

6. Crea un servidor virtual web para el dominio discovery.sistema.sol. Se usará un fichero de

configuración de nombre webtransbordador.conf.

En la sección <Directory> del servidor virtual, añadir a las directivas habituales, las siguientes:

AuthType Digest
AuthName "astronauts"
AuthUserFile "/etc/apache2/claves-digest"
Require user commander

#El archivo deberá tener una configuración similar a la siguiente

<VirtualHost *:80>
ServerName discovery.sistema.sol
DocumentRoot /var/www/transbordador

<Directory /var/www/transbordador>
Options Indexes FollowSymLinks
DirectoryIndex hello.html
AllowOverride None

AuthType Digest
AuthName "astronauts"
AuthUserFile "/etc/apache2/claves-digest"
Require user commander
</Directory>
</VirtualHost>

7. Habilita el servidor virtual y luego reinicia el servicio Apache.

$sudo a2ensite webtransbordador.conf
$sudo systemctl restart apache2

8. Desde el navegador web accede al sitio web con su URL. Se presentará una ventana de
autentificación como la siguiente donde teclear los credenciales del usuario, para luego
presentarse el contenido del archivo hello.html.

3. Uso de directorios virtuales en servidores web.

Cambia la configuración del sitio apolo.sistema.sol para crear un directorio virtual de forma que
cuando en el navegador usemos como URL http://apolo.sistema.sol/satelites, obtengamos el documento
default.html que previamente se habrá creado en el directorio /home/alumno/satelites/. Además sólo se
podrá acceder desde el equipo marte.

// Archivo /etc/apache2/sites-available/webapolo
<VirtualHost *:80>
ServerName apolo.sistema.sol
DocumentRoot /var/www/apolo
ErrorDocument 403 "No tiene permisos de acceso"
ErrorDocument 404 /messages/notfound.html

<Directory /var/www/apolo>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

IES Zaidín Vergeles de Granada. Departamento de Informática.

 SRI. Solución Tema 4. Servidores Web 5

#Configuración para acceso al directorio virtual

Alias /satelites /home/alumno/satelites

<Directory /home/alumno/satelites>
DirectoryIndex default.html
Options Indexes FollowSymLinks
AllowOverride None
Require ip 192.168.1.Y4
</Directory>

ErrorLog /var/www/apolo/messages/apolo.error.log
LogLevel warn
CustomLog /var/www/apolo/messages/apolo.access.log combined

</VirtualHost>

4. Uso del archivo .htaccess.

Modifica el directorio virtual anterior de forma que el propio usuario alumno pueda decidir cuál será
el archivo por defecto a servir (por ejemplo otroindex.html) y desde qué equipos se podrá acceder a
dicho directorio virtual (por ejemplo desde los equipos de la red local). Pasos:
a) El administrador debe cambiar la configuración del directorio a servir para que se puedan
establecer ciertas directivas usando el archivo .htaccess. Para ello en la sección <Directory>
correspondiente al directorio a servir, se indicará mediante la directiva AllowOverride las directivas
que se podrán usar en dentro del archivo .htaccess. En particular se necesita el poder usar
directivas de indexado de directorios y directivas de autentificación.

#NUEVA Configuración para acceso al directorio virtual

Alias /satelites /home/alumno/satelites

<Directory /home/alumno/satelites>
AllowOverride Indexes AuthConfig
</Directory>

b) A continuación hay que reiniciar el servicio para que los cambios se registren
c) El usuario alumno deberá crear el archivo /home/alumno/satelites/.htaccess con las directivas
necesarias para la nueva configuración que desea para el directorio /home/alumno/satelites. Por
ejemplo:
# El archivo a servir será ahora "otroindex.html"
DirectoryIndex otroindex.html
# Sólo los usuarios de la red 192.168.1.0/24 podrá acceder al directorio virtual
Require ip 192.168.1.0/24

5. Configuración de servidores virtuales por IP y puerto.

- Cambiar la configuración del ejercicio 1º de forma que los dos servidores virtuales por nombre
que se crearon, se cambiarán por dos servidores virtuales por IP y por puerto.
- Para ello se necesitan 2 interfaces de red. La interfaz de red que ya se tenía mantendrá la IP. La
segunda interfaz habrá que añadirla configurando la MV Linux (tierra) con VirtualBox, y una
vez iniciada la máquina, se definirá su IP, máscara, etc.
- El primer servidor virtual escuchará por la primera interfaz y puerto 8081; el segundo servidor
virtual escuchará por la segunda interfaz y puerto 8082.

a) Para que el equipo tierra disponga de dos interfaces de red, desde el menú de configuración de la
máquina virtual Linux de VirtualBox añadir otra interfaz de red en modo puente. Al iniciar la
MV se dispondrá de otra interfaz de red la cual se configurará con la IP 192.168.1.Y5/24.
b) En el archivo de zona del dominio sistema.sol hay que hacer corresponder cada IP con cada uno
de los nombre de dominio de los servidores web. Así por ejemplo la IP 192.168.1.Y3 se
mantendrá con el nombre apolo.sistema.sol; y para la nueva IP 192.168.1.Y5 se le añade un
registro tipo A que la asocie al dominio soyuz.sistema.sol. (Evidentemente el registro CNAME del
dominio soyuz.sistema.sol como alias de tierra.sistema.sol habría que eliminarlo de la zona).
c) Reinicia el servidor DNS y comprueba con nslookup que se resuelven los dos nombres de
dominio (apolo.sistema.sol y soyuz.sistema.sol) cada uno con su IP correspondiente.

IES Zaidín Vergeles de Granada. Departamento de Informática.

6 SRI. Solución Tema 4. Servidores Web

alumno@tierra:~$ nslookup soyuz.sistema.sol

Server: 192.168.1.103
Address: 192.168.1.103#53

Name: soyuz.sistema.sol
Address: 192.168.1.105

d) Ahora en el archivo ports.conf deberemos indicar para cada IP, el puerto de escucha de la forma
Listen IP:puerto.
// archivo /etc/apache2/ports.conf
…
Listen 192.168.1.Y3:8081
Listen 192.168.1.Y5:8082

e) A continuación se modifican las directivas <VirtualHost *:80> de cada uno de los dos servidores
virtuales de forma que se indiquen la IP concreta y el puerto de cada servidor de la forma
<VirtualHost IP:puerto>
<VirtualHost 192.168.1.Y3:8081>
…
</VirtualHost>

<VirtualHost 192.168.1.Y5:8082>
…
</VirtualHost>

f) Reinicia el servicio Apache y accede a cada uno de los servidores usando en la URL del
navegador la IP y el puerto.
g) Ahora accede a cada uno de los servidores usando en la URL del navegador el nombre de
dominio y el puerto.

6. Uso de servidores web seguros.

Se quiere añadir un nuevo servidor virtual seguro mediante el uso de un certificado de servidor
autofirmado para un nuevo dominio webseg.sistema.sol usando como directorio raíz /var/www/webseg.

Los pasos a seguir serían:

1. Configurar el servidor DNS para que resuelva el nombre webseg.sistema.sol. Comprobar que el
nombre de dominio se resuelve adecuadamente.
2. Instalar el paquete OpenSSL.
$sudo apt-get install openssl.
3. Comprobar que el servicio Apache está configurado para escuchar por el puerto 443. y que el
puerto está a la escucha
$cat /etc/apache2/ports.conf
$netstat –ltn
4. Crear el directorio raíz del sitio y guardar en su interior el archivo a servir por defecto (por
ejemplo sitioseg.html). El archivo contendrá un mensaje de bienvenida para el sitio web.
5. Comprobar que el módulo que da soporte para SSL/TLS está activado
$ls -l /etc/apache2/mods-enabled

6. En el archivo de configuración de dicho módulo (ssl.conf), deshabilita el soporte para SSLv.3

SSLProtocol all -SSLv3
7. Crear un certificado autofirmado que guardaremos por ejemplo en /etc/apache2/ssl (crear antes el
subdirectorio ssl si no existiera…)
$ sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/cer-sistema.pem
8. Crear en /etc/apache2/sites-available el archivo de configuración del servidor, al cual le podríamos
llamar por ejemplo webseg.conf

# Archivo /etc/apache2/sites-available/webseg.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName webseg.sistema.sol

IES Zaidín Vergeles de Granada. Departamento de Informática.

 SRI. Solución Tema 4. Servidores Web 7

DocumentRoot /var/www/webseg
<Directory /var/www/webseg>
SSLRequireSSL
DirectoryIndex sitioseg.html
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

ErrorLog ${APACHE_LOG_DIR}/webseg.error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/webse.access.log combined

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/cer-sistema.pem
</VirtualHost>
</IfModule>

9. Habilitar el servidor web seguro y reiniciar el servicio.

$ sudo a2ensite webseg.conf
$ sudo systemctl restart apache2.service

10. Para probar el servidor web debemos usar el protocolo HTTPS en la URL del navegador. de la
forma https://webseg.sistema.sol y aceptar el certificado autofirmado.

7. Servicio WebDAV en IIS.

WebDAV (Web-based Distributed Authoring and Versioning) es un conjunto de extensiones al
protocolo HTTP que permite a los usuarios editar y gestionar de forma colaborativa los archivos
ubicados en un servidor web remoto.
Para ampliar conocimientos sobre el servicio visitar https://es.wikipedia.org/wiki/WebDAV.
Generalmente cuando queremos subir o actualizar los ficheros a servir de nuestro servidor web
empleamos el servicio FTP o el servicio SSH. Pero con WebDAV tenemos algunas ventajas:
 WebDAV usa el puerto 80, el mismo que HTTP para el acceso web, con lo que no necesitaremos
abrir puertos extra.
 WebDAV sólo permite a un único usuario la modificación de un fichero en un momento dado,
mientras permite su lectura al resto. Lo que permite el bloqueo de ficheros mientras están siendo
modificados.
 WebDAV permite la edición de los ficheros directamente en el servidor sin necesidad de
bajarlos previamente al cliente de un modo totalmente transparente para el usuario.
1. Instalación de WebDAV en IIS.
Para instalar el servicio WebDAV partimos de Herramientas administrativas -> Administrador
del servidor y desde el Panel activamos el enlace de Agregar roles y características. Pulsamos
repetidamente Siguiente hasta que el asistente presenta la pantalla de Seleccionar roles de
servidor. En la lista de roles buscamos el rol Servidor web (IIS) y pulsamos en el botón
triangular para desplegar los roles asociados. Desplegamos el grupo Servidor Web y volvemos a
desplegar el grupo Características HTTP comunes. A continuación marcamos el rol Publicación
en WebDAV. Pulsamos seguidamente el botón Siguiente y finalizamos con el botón Instalar.
2. Creación de un sitio web con acceso WebDAV.
Si el sitio web ya existe, podremos obviar estos pasos. Si no existe, lo creamos:
Desde la consola de Administración de IIS y con el elemento Sitios seleccionado, hacemos click
con el botón derecho del ratón y elegimos Agregar sitio web… Esta operación presenta una
ventana en donde deberemos completar los siguientes datos:
 Nombre del sitio: PruebaWebDAV
 Ruta de acceso física: C:\CarpetaWD
 Dirección IP del servidor: Pondremos la IP de nuestro servidor Windows.
 Nombre de hosts: wd.aula.izv (Como siempre, un servidor DNS o la tabla de hosts debe
resolver este nombre con la IP del servidor.)

IES Zaidín Vergeles de Granada. Departamento de Informática.

8 SRI. Solución Tema 4. Servidores Web

 Finalizamos pulsado Aceptar.

 Creamos en C:\CarpetaWD un archivo index.html con cualquier contenido para servir.
 Probar que el sitio web está disponible mediante un navegador web usando la URL
wd.aula.izv.
3. Establecimiento de una Regla de Autorización para WebDAV.
En este paso añadiremos una regla de autorización para que sólo el usuario Administrador del
equipo servidor pueda editar el contenido de este sitio web. (Como se podrá comprobar
podríamos habilitar a otros usuarios). Para ello:
 Desde la consola de Administración de IIS, seleccionamos del panel izquierdo el sitio
creado (PruebaWebDAV). En el panel central hacemos click en Reglas de creación de
WebDAV y a continuación en el panel derecho pulsamos en Agregar regla de creación...
 En la regla a crear permitiremos el acceso a todo el contenido del sitio. En usuarios
especificados escribimos Administrador; y en permisos marcamos leer, origen y escribir.
Terminamos con Aceptar.
 Por último, en el panel derecho pulsamos en Habilitar WebDAV.
4. Establecimiento del sistema de autentificación al sitio web.
 Por defecto todos los sitios web tiene habilitada la autentificación anónima, es decir
cualquier usuario puede acceder al sitio web; pero necesitamos mecanismos de
autentificación más estrictos para poder modificar el contenido de un sitio web. Para
habilitar otros tipos de autentificación, debemos agregarlos a IIS. En este caso agregaremos
los roles Autentificación de Windows y Autorización para URL.
 Para ello desde Administrador del servidor y desde el Panel activamos el enlace de Agregar
roles y características. Pulsamos repetidamente Siguiente hasta que el asistente presenta la
pantalla de Seleccionar roles de servidor. En la lista de roles buscamos el rol Servidor web
(IIS) y pulsamos en el botón triangular para desplegar los roles asociados. Desplegamos el
grupo Servidor Web y volvemos a desplegar el grupo Seguridad. A continuación marcamos
los roles Autentificación de Windows y Autorización para URL. Pulsamos seguidamente el
botón Siguiente y finalizamos con el botón Instalar. (Se pueden usar otros mecanismos de
autentificación como puede ser básica, certificados de cliente, texto implícita, etc.).
 Reiniciamos el administrador de IIS para que los cambios surjan efecto.
 Agregado el rol de Autentificación de Windows vamos a habilitar este tipo de autentificación
para el sitio web. Para ello seleccionamos en el panel izquierdo el sitio web
(PruebaWebDAV) y pulsamos en Autentificación del panel central. Seleccionamos
Autentificación Windows y pulsamos Habilitar del panel derecho.
 En panel central pulsamos en Reglas de autorización. Debemos comprobar que existe una
regla que permita al usuario Administrador el acceso al sitio. (Por defecto hay una regla para
Todos los usuarios, la cual incluye al usuario Administrador).
 Finalmente para que los cambios surjan efecto en el sitio web debemos reiniciar el sitio.
5. Conexión al sitio con un cliente WebDAV Windows usando los credenciales de la cuenta de
Administrador.
 Para establecer la conexión necesitamos un cliente WebDAV llamado WebDAV Redirector.
En las versiones Windows de escritorio (Vista, Windows 7, Windows 8, Windows 10) el
cliente ya viene instalado, pero en las versiones Windows Server no lo está. El siguiente
paso por lo tanto es opcional, dependiendo del cliente.
 Si usamos como cliente una versión de Windows Server 2012, la manera de instalar el
WebDAV Redirector es agregando la característica Experiencia de escritorio disponible
desde Administrador del servidor ->Infraestructura e interfaces de usuario. (Esta
característica añade aplicaciones típicas de los sistemas Windows de escritorio, como puede
ser el reproductor Windows Media, los temas de escritorio etc.) Una vez instalada, habrá
que reiniciar el servidor y comprobar que el servicio cliente está en ejecución. Para ello ir a
Herramientas Administrativas -> Servicios -> Cliente Web y comprobar que está iniciado.

IES Zaidín Vergeles de Granada. Departamento de Informática.

 SRI. Solución Tema 4. Servidores Web 9

 Para realizar la conexión desde un cliente, se mapea el sitio web que dispone de WebDAV
con una unidad de red. Esto podemos hacerlo mediante una consola de comandos o usando
un asistente.
- En el primer caso desde, la consola escribimos
C:\Users\carlos>net use * http://wd.aula.izv
Escriba el nombre de usuario para "wd.aula.izv": Administrador
Escriba la contraseña para wd.aula.izv:
C:\Users\carlos>
La unidad Z: está conectada a http://wd.aula.izv.
Se ha completado el comando correctamente.
C:\Users\carlos>z:
Z:\>dir
El volumen de la unidad Z no tiene etiqueta.
Directorio de Z:\
22/11/2016 17:02 <DIR> .
22/11/2016 17:02 <DIR> ..
22/11/2016 17:06 <DIR> Datos
21/11/2016 18:48 25 index.html
1 archivos 25 bytes
3 dirs 196.663.373.824 bytes libres

- En el caso de querer usar el asistente, podemos hacerlo pulsando en el botón Equipo del
escritorio, y activando Conectar con una unidad de red de la barra superior. En la
ventana seleccionamos la letra de unidad que queramos, escribimos en Carpeta
http://wd.aula.izv y marcamos la casilla Conectar con otras credenciales para poder
teclear luego el nombre del usuario (Administrador) y sus contraseña.
Al realizarse la conexión, nos aparecerá en la ventana del explorador de archivos, una nueva
unidad de red mapeada a la conexión WebDAV del sitio web. Por ejemplo DavWWWRoot
(\\wd.aula.izv)(Z:)
6. Conexión al sitio con otros clientes WebDAV.
En la configuración de WebDAV usamos anteriormente el sistema de autentificación de
Windows (NTLM), pero este método no es soportado por muchos clientes. Para hacer más
compatible la conexión podríamos deshabilitar este tipo de autentificación, e instalar y habilitar
el Rol de autentificación básica.
Este tipo de autentificación es bastante vulnerable (usa la codificación base64), por lo que se
recomienda usarla cuando el sitio web sólo sea accesible mediante HTTPS para que la
información se transmita cifrada.
- WinSCP es una aplicación para Windows que actúa como cliente para diversos protocolos,
entre ellos WebDAV. Puede usarse tanto para conexiones HTTP como HTTPS. No soporta la
autentificación tipo Windows, pero si el tipo básica.
- Para realizar la conexión desde un cliente Linux, podemos usar la opción Conectarse con un
servidor del explorador de archivos nautilus. En la ventana debemos completar el cuadro de
Dirección del servidor con dav://wd.aula.izv o davs://wd.aula.izv si usa una conexión HTTPS.
No soporta la autentificación tipo Windows, pero si el tipo básica.

IES Zaidín Vergeles de Granada. Departamento de Informática.