jueves, 29 de julio de 2010

Transposición por columnas


El mensaje es puesto en escrito en filas hacia fuera otra vez de una columna de longitud fija, y después leída por la columna, y las columnas se eligen en una cierta orden revuelta. La longitud de las filas y la permutación de las columnas son definidas generalmente por una palabra clave. Por ejemplo, la palabra CEBRAS está de longitud 6 (así que las filas esté de la longitud 6), y la permutación es definida por el orden alfabético de las letras en la palabra clave. En este caso, la orden sería “6 3 2 4 1 5”.
En una cifra acolumnada regular de la transposición, cualquier espacio de repuesto se llena de anula; en una cifra acolumnada irregular de la transposición, los espacios se dejan en blanco. Finalmente, el mensaje se lee apagado en columnas, en la orden especificada por la palabra clave. Por ejemplo, suponga que utilizamos la palabra clave CEBRAS y el mensaje NOS DESCUBREN. HUYA INMEDIATAMENTE. En una transposición acolumnada regular, escribimos esto en la rejilla como:

6 3 2 4 1 5


W E A R E D


I S C O V E


R E D F L E


E A T O N C


E Q K J E.U.

El abastecimiento de cinco anula (QKJEU) en el extremo. El texto cifrado entonces se lee apagado como:

EVLNE ACDTK ESEAQ ROFOJ DEECU WIREE

Para descifrarlo, el recipiente tiene que resolver las longitudes de la columna dividiendo la longitud de mensaje por la longitud dominante. Entonces él puede escribir el mensaje hacia fuera en columnas otra vez, después reordena las columnas reforming la palabra clave.

Cifrado Cesar

En criptografía, el cifrado César, también conocido como cifrado por desplazamiento, código de César o desplazamiento de César, es una de las técnicas de codificación más simples y más usadas. Es un tipo de cifrado por sustitución en el que una letra en el texto original es reemplazada por otra letra que se encuentra un número fijo de posiciones más adelante en el alfabeto. Por ejemplo, con un desplazamiento de 3, la A sería sustituida por la D (situada 3 lugares a la derecha de la A ), la B sería reemplazada por la E, etc. Este método debe su nombre a Julio César, que lo usaba para comunicarse con sus generales.
El cifrado César muchas veces puede formar parte de sistemas más complejos de codificación, como el cifrado Vigenère, e incluso tiene aplicación en el sistema ROT13. Como todos los cifrados de sustitución alfabética simple, el cifrado César se descifra con facilidad y en la práctica no ofrece mucha seguridad en la comunicación.

Ejemplo

La transformación se puede representar alineando dos alfabetos; el alfabeto cifrado es un alfabeto normal que está desplazado un número determinado de posiciones hacia la izquierda o la derecha. Por ejemplo, aquí el cifrado César está usando un desplazamiento de seis espacios hacia la derecha:

Texto original:   ABCDEFGHIJKLMNÑOPQRSTUVWXYZ
Texto codificado: GHIJKLMNÑOPQRSTUVWXYZABCDEF

Para codificar un mensaje, simplemente se debe buscar cada letra de la línea del texto original y escribir la letra correspondiente en la línea codificada. Para decodificarlo se debe hacer lo contrario.

Texto original:   ESE CADI OE
Texto codificado: FTF DBEJ PF

La codificación también se puede representar usando aritmética modular, transformando las letras en números, de acuerdo al esquema A = 0, B = 1,..., Z = 26.La codificación de la letra x con un desplazamiento n puede ser descrita matemáticamente como:
E_n(x) = x + n \mod {27}.
La decodificación se hace de manera similar:
D_n(x) = x - n \mod {27}.

Seguridad en las redes: ENCRIPTACION

SEGURIDAD EN LA RED
SEGURIDAD DE LOS DATOS
Tipos
1- Del dato en si
CERTIFICADO DIGITAL:
Archivo que contiene información relativa a nuestra persona de carácter confidencial, su misión es autentificar la operación telemática de la persona que lo maneja.
• ALGORITMOS (HISTORIA):
1. Julio Cesar: x posiciones atrás o adelante en el abecedario
2. Transposición de columnas: se usa un algoritmo + mensaje + clave a usar
CLAVE no puede contener letras repetidas.
Cada letra de la clave representa unas columnas y el mensaje se completa rellenando éstas.
Se ordenan las letras de la clave alfabéticamente y se entrega el mensaje así: MSXSAENOSVLTOSIAAE
Para el des encriptado, se divide el mensaje en grupos iguales a la cantidad de letras que tiene el mensaje y se divide entre el numero de letras que tiene la clave. Ahora ordenamos alfabéticamente los grupos y se asignan a su letra correspondiente.
3. DES (Data Encriptation Standard)
Se llama simétrica cuando se usa la misma clave para encriptar y desencriptar.

A->0->0000


Z->2

A medida que se va usando se va permutando la clave y se va realizando por bloques por implicar que una letra se convierte en 4 dígitos.

Pasos para crear un mensaje encriptado:
(a) H O L A
| | | |
0111 1110 1011 0000
A->0->0000
B->1->0001
C->2->0010
D->3->0011
E->4->0100
F->5->0101
G->6->0110
H->7->0111
I->8->1000
J->9->1001
K->10->1010
L->11->1011
M->12->1100
N->13->1101
O->14->1110
P->15->1111
(b) Dividir el mensaje en bloques iguales [01111110] [10110000]
(c) Una vez dividido hacer tantos algoritmos como bloques resulten
(d) Permutación inicial [10111101] [00110010]
(e) Troceamos en izquierda y derecha [1011] [1101] [0011] [0010]
(f) Empieza la encriptación I0 D0
I1=D0
D1=I0 XOR (D0 XOR K0) XOR (0+1=1 0+0=0 1+1=0) XNOR (0+1=0 0+0=1 1+1=1)
K=1100

I1=D0 ->1101
D1=I0 XOR (D0 XOR K0) 1011 XOR (XOR 1100 y 1101 ->0001) ->1010
I1 D1
MENSAJE ENCRIPTADO 1101 1010 ->10011011 DESHACIENDO LA PERMUTACION INICIAL

1001 1011
J L

[0011] [0010]
I1=D0 ->0010
D1=I0 XOR (D0 XOR K0) D1=0011 XOR (0010 XOR 1100->1110) ->1101
K=1100
MENSAJE ENCRIPTADO 0010 1101 ->01101100 DESHACIENDO LA PERMUTACION INICIAL

0110 1100
G M
Pasos para desencriptar
(a) Permutar I1 y D1
1001 1011
11011010
K=1100
(b) D0=I1 ->1101
I0= D1 XNOR (D0 XNOR K0)-> 1010 XNOR (XNOR 1101 y 1100 ->1110) ->1011

10111101

(c) Permutamos finalmente

0111 1110
H O

(d) Permutar I1 y D1
0110 1100
0010 1101
K=1100
(e) D0=I1 ->0010
I0= D1 XNOR (D0 XNOR K0)-> 1101 XNOR (XNOR 0010 y 1100 ->0001) ->0011
00110010

(f) Permutamos finalmente

1011 0000
L A

4. RSA
Método de encriptación asimétrico porque utiliza distintas claves para realizar la encriptación y desencriptacion.
Las distintas claves que se usan para encriptar y desencriptar se llaman clave pública y clave privada.
La clave publica es para encriptar y la privada para desencriptar (llamadas E y D).
El proceso de comunicación es el siguiente:
El emisor encripta el mensaje con la clave publica del receptor lo desencripta con su clave privada.
Se trabaja con números primos.
Características de métodos de encriptación:
I. Autentificación. Comprobación de la ID de una persona.
II. Confidencialidad. Es la propiedad de la información por la que se garantiza que esta accesible únicamente a personal autorizado a acceder a dicha información.
III. Integridad. Que la información llegue al destino igual que la original.
IV. Disponibilidad. Que sea accesible, listo para encriptarlo siempre.
Proceso de creación de un algoritmo:
- Partimos de 2 números primos (p,q)
- n=p*q
- Ф (n)= (p-1)*(q-1)
- e*d mod Ф (n)=1 e y d no pueden ser iguales
Formulas:
• encriptar C=M(e) mod n A=1
• desencriptar M=C(d) mod n Ñ=15
Z=27
C (cifrado) M (mensaje)
*M(e) -> M elevado a “e”

Ej. creación algoritmo y encriptación/desencriptacion
ALGORITMO
P=3 Q=11
N=3*11=33
Ф (n)=2*10=20
e*d mod 20=1 ->3*7
C pública (7,33) e,n
C privada (3,33) d,n
CIFRADO
C=M(e) mod n -> B 2(7) mod 33= 29 -> B
E 5(7) mod 33= 14 -> N
A 1(7) mod 33= 1 -> A
DESENCRIPTADO
M=C(d) mod n -> B 29(3) mod 33= 2 -> B
-> N 14(3) mod 33= 5 -> E
-> A 1(3) mod 33= 1 -> A

Ej. 2 3 5 7
n=65 11 13 17 19
p*q=n 23 29
13*5=n
Ф (n)=12*4=48
e*d mod 48=1 -> 5,29

***Técnica: para hallar e y d sumar Ф (n) + resto
y buscar primos que lo dividan, si no hay,
multiplicar por 2,3 hasta hallar un número
que pueda ser divisible por 2 números
C pública (29.65) e,n
C privada (5.65) d,n

HASH
Función que resume una totalidad de datos en un carácter (ej. letra DNI)
Internamente opera con una tabla que lleva asociadas por grupos las combinaciones a sus letras correspondientes.
La encriptación comprueba confidencialidad y disponibilidad del mensaje y la firma, integridad y autentificación.
La misión de la firma es aplicar al mensaje una función HASH.

Para firmar:
Este carácter HASH, se encripta con la clave privada del emisor, así el receptor, al desencriptar con la clave publica del emisor (que si es conocida), sabe la ID de quien lo envía inequívocamente.
Pasos Mensaje cifrado y firmado:
- HASH a M
- ENC M
- ENC CARACT. HASH (con C.priv Emisor)
- Enviar E+HASH ENC
- DES E
- DES HASH ENC (con C.pub emisor)
- HASH M = [DES HASH ENC (con C.pub emisor)]

by ViJeNTe, BaDMan & erEddydWerba

miércoles, 7 de julio de 2010

Guía de instalación y configuración del Protocolo DHCP para Windows Server 2008

¿Qué es el protocolo DHCP?

El protocolo DHCP (Dynamic Host Configuration Protocol, o protocolo de configuración dinámica de host), es un protocolo de red que permite a los nodos de una red IP obtener sus parámetros de configuración automáticamente.

Este protocolo nos permitirá, asignar una dirección IP única a cada máquina que se conecte al servidor, y cuando ésta máquina deje de usar esta IP, quedará libre para cualquier otra máquina que acceda al dominio del servidor. Nos informa concretamente, qué máquina ha tenido asignada cierta dirección IP, cuánto tiempo la ha tenido, y a qué otras máquinas se les ha asignado posteriormente.


Dentro del servicio del protocolo DHCP, podemos configurar de hasta tres maneras distintas nuestro servidor DHCP:

  1. Asignación manual o estática: Asigna una dirección IP a una máquina determinada. Se suele utilizar cuando se quiere controlar la asignación de dirección IP a cada cliente, y evitar la intrusión de clientes no identificados.
  2. Asignación automática: Asigna una dirección IP de forma permanente a una máquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta que el cliente la libera. Se suele utilizar cuando el número de clientes no varía demasiado.
  3. Asignación dinámica: El único método que permite la reutilización dinámica de las direcciones IP. El administrador de la red determina un rango de direcciones IP, cada máquina conectada a la red está configurada para solicitar su dirección IP al servidor cuando la tarjeta de interfaz de red se inicializa. El procedimiento usa un concepto muy simple en un intervalo de tiempo controlable. Esto facilita la instalación de nuevas máquinas clientes a la red.
Una vez definida la función del protocolo DHCP, vamos a proceder a instalarlo mediante el Asistente que nos provee Windows Server 2008:

En primer lugar, vamos a pinchar en Inicio, localizamos la carpeta herramientas administrativas, y pinchamos en Administración del servidor.


Una vez accedamos, con el botón derecho sobre Funciones, seleccionamos Añadir funciones.


Si es nuestra primera vez, nos aparecerá un mensaje de información sobre la instalación de funciones en Windows Server 2008, presionamos Siguiente, y seleccionamos la función Servidor DHCP, y pinchamos de nuevo en Siguiente.


Nos aparecerá una pantalla de información, continuaremos pinchando en Siguiente


En este momento, vemos como el asistente nos muestra la dirección IP de nuestro servidor, la seleccionamos y continuamos.


Una vez aquí, configuramos con nuestro nombre de dominio, y la dirección de red del servidor, y presionamos en Siguiente.


En esta sección, el asistente nos preguntará si deseamos configurar el servidor WINS, en este caso omitiremos este paso, seleccionamos la primera opción, y pinchamos en Siguiente.


En este paso, procederemos a configurar el rango de direcciones IP que asignará nuestro servidor DHCP, pinchamos en la opcion Añadir.


Aquí asignaremos el nombre del servidor, la primera dirección IP del rango, la última del mismo rango, la máscara de subred (mucho ojo en este paso, porque el propio asistente puede hacernos la pirula y asignar una máscara de subred errónea). Asignamos también la puerta de enlace, y en la última opción, dejamos la predefinida.

A continuación el asistente nos mostrará el rango de IP que hemos configurado.


En esta ocasión, el asistente nos brindará con la opción de seleccionar entre las opciones de configurar el modo sin estado DHCPv6, en el cual seleccionaremos la segunda opción, ya que omitiremos la instalación de esta configuración.


En este momento, indicaremos el usuario para aplicar los cambios, y seleccionaremos la primera opción para dar los permisos al usuario actual (en nuestro caso, seria \SERVIDOR\Administrador\).



Finalmente, el asistente nos mostrará un resumen, con la configuración que hemos preparado. Para iniciar la instalación, procedemos a presionar el botón Instalar.


Una vez acabada la instalación, Windows nos mostrará si la instalación fue correcta, o si ocurrió alguna incidencia durante la mísma.



Finalizando la instalación del protocolo DHCP en el servidor, confirmamos accediendo de nuevo desde Inicio, Herramientas Administrativas, Administrador del sistema, buscaremos dentro del servidor, la nueva función Servidor DHCP.


Una vez configurado nuestro servidor, nos vamos a nuestra máquina cliente, y cambiaremos en la tarjeta de red la configuración de la dirección IP, nos aseguraremos de que este señalada la primera opción, Obtener dirección IP automáticamente, y presionamos en Aceptar.

Realizado este paso, nos vamos a detalles de la tarjeta de red, y debería aparecer(después de unos segundos) en dirección IP el texto Asignada por DHCP.

Ya hemos acabado de configurar tanto nuestro servidor tanto como nuestro cliente, espero que este tutorial os haya ayudado en la mayor medida posible.

Fuente: http://www.geronet.com.ar/

Saludos.

lunes, 5 de julio de 2010

PROTOCOLO DNS

¿Que es y que utilidad tiene?.

Es un protocolo de alto nivel, es decir trabaja en el nivel de aplicacion independientemente del tipo de arquitectura usado ya sea tpc/ip OSI u otro.



Este protocolo nace de la necesidad de hacer mas fácil para los usuarios trabajen con direcciones de transporte (direccion IP mas número de puerto).



En el año 1983 Paul Mockapetris consciente de la dificultad sobre todo de trabajar con direcciones numericas, debido a la dificultad de recordar, propuso este protocolo que se encarga de convertir direcciones formadas por cadenas de caracteres ASCII como por ejemplo (www.google.com) en direcciones binarias de transporte.



Para administrar las direcciones de dominio se opto por una clasificacion jerarquica de nombres.



Una direccion esta formada por una cadena de caracteres que se divide en varios nombres separados por puntos.



En el primer nivel encontramos los nombres genéricos que son de dos tipos: genericos y de pais, del tipo:
"com, org, es, uk, etc". Junto a estos aparecen los de segundo nivel y asi sucesivamente ordenandose de derecha a izquierda.






  3º       2º     1º







La informacion relativa a la organizacion interna de los dominios se distribuye en los servidores DNS de la red.

Esta informacion almacenada constituye una zona, que esta definida por un conjunto de dominios y subdominios.



Estas zonas se guardan como una base de datos en determinados servidores DNS, desde donde es posible administrar los dominios definidos en ella.



Por lo tanto, si queremos definir una zona y administrarla para una red concreta, debe de existir al menos un servidor DNS que guarda la informacion de configuracion de esta.



Si no se define una zona concreta, los servidores DNS existentes en la red funcionaban como cache, es decir simplemente una tabla local de tamaño fijo que almacena correspondencias ya resueltas que se van eliminando conforme se quedan anticuadas.



Este servidor se limita a recibir peticiones de los equipos y buscar en su cache para ver si los puede resolver, si no los puede resolver, reenvia esas solicitudes a otros servidores DNS conocidos.



La base de datos de una zona se almacena en un servidor DNS primario de forma que todos los dominios se gestionan desde el equipo.



Lo conveniente seria configurar uno o mas servidores DNS secundarios que se encarguen de mantener copias actualizadas de la informacion de la zona, de forma que en caso de fallo en el servidor DNS primario se pueden seguir resolviendo las direcciones de forma normal.



En la practica, el protocolo DNS se define por los estandares RFC 1034 y 1035.



Donde se define como esta implementado este protocolo y como funciona realmente.



Se utiliza una base de datos distribuida por la red de ordenadores llamados servidores DNS, que almacenan tablas de correspondencias entre direcciones de nombre de dominio y direcciones IP.










viernes, 2 de julio de 2010

CONFIGURACIÓN DNS EN WINDOWS SERVER 2008

Aquí teneis un pequeño tutorial que nos ayudara a configurar un servidor DNS en nuestro servidor:

Pasos para crear un perfil obligatorio con Windows Server 2008

Para crear un perfil obligatorio, lo primero que hemos de hacer es crear un usuario en nuestro dominio. Para ello en el servidor haremos clic en el boton Inicio > Ejecutar y escribiremos "dsa.msc" (Usuario y equipos de Active Directory) y en la barra izquierda del explorador haremos con el boton derecho en "Users" y elegiremos Nuevo > Usuario.



En segundo lugar iniciaremos sesión en una estación de trabajo del dominio con la cuenta del dominio que hemos creado, modificando en dicha sesión el entorno de trabajo; posteriormente cerraremos sesión y nos autenticaremos en la misma máquina como un administrador del dominio (NO el administrador de la máquina local).


Una vez autenticados como el administrador del dominio, iremos a la opción Sistema dentro de Panel de Control; una vez allí pulsaremos sobre la pestaña Opciones Avanzadas > Perfiles de Usuario > Configuración y seleccionamos el perfil Caiman\jonnymelavo tal y como vemos en la siguiente imagen:


El siguiente paso consistirá en pulsar sobre el botón Copiar a, indicando como ruta de destino donde esta una carpeta Perfiles (la cual debe estar compartida y con la seguridad activada). Como se muestra en la imagen file://theboss/Perfiles/Jonny



Además en dicha ventana pulsaremos sobre el botón Cambiar para especificar que el perfil puede ser utilizado por el usuario Todos, tecleando dicho usuario en la caja de texto destinada a tal defecto, tal y como vemos en la siguiente ventana. Finalmente pulsamos sobre el botón Aceptar.


De vuelta de la pantalla anterior ya aparecerán especificados los usuarios a los que les estará permitido usar dicho perfil; pulsamos sobre el botón Aceptar para concluir este apartado.

Una vez completado el proceso anterior forzaremos a que el perfil sea obligatorio, tenemos que acceder a la carpeta Jonny y renombrar el fichero oculto "NTUSER.DAT" a "NTUSER.MAN".

miércoles, 30 de junio de 2010

Tomar posesión de un perfil Móvil creado en nuestra carpeta “Perfiles” del Servidor

Cuando clicamos sobre la carpeta del usuario nos sale un aviso de no tener permiso de acceso, pulsamos continuar


Ahora pulsamos sobre ficha de Seguridad

Se abren las Propiedades de Seguridad y nos advierte que para continuar debemos ser un usuario administrativo con permiso para ver las propiedades

Pulsamos en Opciones Avanzadas

En configuración avanzada pulsamos Continuar

Nos saldrá que no se puede mostrar el propietario actual. Bien, nosotros elegimos como propietario a administradores (Dominio\Administradores) y marcamos la casilla Reemplazar propietario en subcontenedores y objetos y pulsamos Aceptar

Nos saldrá este cartel, lo leemos y damos Si
Lo mismo con este otro le damos Aceptar a este y al resto de ventanas que estén abiertas.

Ahora si abrimos la carpeta perfiles y le damos al usuario Menganito vemos que nos abre todo su árbol de carpetas de perfil Móvil, pero el propio usuario no tendrá permiso para entrar en la carpeta como consecuencia de haber tomado posesión sobre ella los administradores (Dominio\Administradores). Tendremos que darle ahora permisos al propio usuario.

Pulsamos sobre la carpeta del usuario con el botón derecho en Propiedades y abrimos la pestaña de Seguridad. Aparecerá solo administradores (Dominio\Administradores), como dueño de la carpeta, pulsamos Editar
Ahora pulsamos Agregar y le damos posesión también al propio Usuario y al SYSTEM, con control total sobre la carpeta, y solo queda pulsar Aceptar ......


Aportado por Domingo Sánchez Solís.

lunes, 28 de junio de 2010

DISEÑO EFICAZ DE UNIDADES ORGANIZATIVAS

No subestime la importancia, y la complejidad, del diseño de una buena estructura de unidad organizativa (OU). 
    Los departamentos de TI, con frecuencia, adoptan una u otra dirección:bien ponen demasiado énfasis en la estructura de la unidad organizativa, o bien se olvidan de la misma. 
   Cualquiera que sea la dirección adoptada, ambas pueden provocar problemas con el modelo de Active Directory®.
   Poner demasiado énfasis en la estructura de la unidad organizativa resta importancia a otras áreas de diseño de Active Directory, como la planeación de la topología del sitio o la consideración del tamaño del controlador de dominio. 
   Por otro lado, al reducir la prioridad de planeación de la unidad organizativa, la directiva de grupo y la delegación se ven afectadas.
Una de las excusas es que la estructura de la unidad organizativa es flexible y puede cambiarse posteriormente si no es la adecuada. 
   Es verdad que la estructura de la unidad organizativa es flexible. No obstante, los administradores descubren, con frecuencia, que ese cambio posterior de estructura de la unidad organizativa es más complicado de lo que habían pensado en un principio. Es también verdad que se pueden agregar nuevas unidades organizativas, pero las anteriores no son fáciles de eliminar.
   Una estructura de unidad organizativa mal planeada tiende a cobrar vida propia. Si se crea un objeto nuevo en el directorio y el administrador no sabe en qué lugar de la unidad organizativa colocar el objeto, creará una nueva unidad organizativa, o bien colocará el objeto en un lugar al que no pertenezca. Ambos escenarios presentan sus propios peligros inherentes. La creación de una nueva unidad organizativa es sencilla, pero realizar un seguimiento de la misma es bastante complicado a la larga. La creación desorganizada de una unidad organizativa contribuye a una estructura de unidad organizativa caótica y es fácil permitir la acumulación de valores no documentados en el directorio. Por otro lado, si agrega un objeto a una unidad organizativa existente a la que no pertenezca realmente, el objeto nuevo puede recibir directivas que no debería recibir o los permisos del objeto podrían delegarse en usuarios imprevistos.
   Al diseñar estructuras de unidad organizativa, debe tener en mente una ecuación básica: sencillez + adaptabilidad = sostenibilidad. Si el diseño es demasiado sencillo, puede que no sea adaptable y, por lo tanto, tendrá que cambiarse con demasiada frecuencia. Si el diseño es demasiado adaptable, todo quedará dividido en secciones, lo cual aportará demasiada complejidad.
    Hay tres principios clave referidos a la directiva de grupo, la delegación y la administración de objetos que pueden ayudarle a adoptar una correcta decisión de diseño. Estos principios pueden resumirse en tres preguntas que debe realizarse a sí mismo y que le ayudarán a garantizar que la estructura de la unidad organizativa que está creando superará el paso del tiempo y los cambios de la organización:
  1. ¿Es necesaria la creación de esta unidad organizativa de manera que se pueda aplicar a la misma un objeto de directiva de grupo (GPO, Group Policy Object) exclusivo?
  2. ¿Es necesario que un grupo particular de administradores tenga permisos para los objetos de esta unidad organizativa?
  3. ¿Facilitará esta nueva unidad organizativa la administración de los objetos existentes dentro de la misma?
Si la respuesta a cualquiera de estas preguntas es "sí", con toda probabilidad debería crear la unidad organizativa. Si la respuesta a estas tres preguntas es "no", debe volver a plantearse el diseño y determinar si un diseño distinto podría generar una opción más apropiada. Pero antes de entrar en detalles y mostrarle cómo aplicar estos principios, debo explicar en primer lugar por qué estos principios son importantes.

Principio 1: directiva de grupo
   El primer principio de diseño de unidades organizativas consiste en tener en cuenta los objetos de directiva de grupo que se aplicarán a una unidad organizativa. Un GPO le permite configurar opciones para los usuarios y equipos de una manera aplicable. Puede definir varios GPO en Active Directory y aplicarlos a un dominio completo, a varias unidades organizativas o, incluso, a los sitios del dominio. Los GPO se dividen en dos categorías: uno para los usuarios y otro para los equipos.
Tanto las directivas de equipo como las de usuario pueden definirse en el mismo GPO. La sección Configuración de usuario del GPO define, en su mayor parte, la experiencia que tendrá el usuario una vez haya iniciado sesión. Estos tipos de configuración existen también en la sección Configuración del equipo, pero esta sección contiene, asimismo, más configuraciones relacionadas con la seguridad del equipo, por ejemplo, quién puede iniciar sesión en él de forma local o cómo se cifran los datos.
Estos son algunos de los aspectos básicos que hay que tener en cuenta a la hora de definir unidades organizativas para que sean compatibles con los GPO. En primer lugar, sólo porque las directivas de usuario y de equipo puedan definirse en el mismo GPO, no significa que sea buena idea colocar los objetos de usuario y equipo en la misma unidad organizativa. Combinar ambos objetos en el mismo GPO dificulta la solución de problemas en la aplicación de GPO. Esto se hace muy evidente si tiene habilitada una directiva de bucle invertido.
En segundo lugar, muchas personas olvidan que puede aplicar los GPO a nivel de sitio y, por lo tanto, diseñar sus estructuras de unidad organizativa para modelar la estructura del sitio según los objetivos de la aplicación de GPO. Éste es un modelo común de diseño de unidad organizativa, conocido como modelo geográfico. En un instante hablaré sobre el mismo. Sería negligente por mi parte no reconocer que el modelo geográfico tiene su lugar en el diseño de unidades organizativas, pero como verá más adelante, no creo que esa aplicación de GPO deba ser la razón principal para implementar este modelo.
Además, al pensar en la estructura de unidad organizativa en términos de GPO, el objetivo debe ser eliminar la complejidad. Asegúrese de que la unidad organizativa se agrega al flujo de herencia de GPO. Si su unidad organizativa contiene servidores que requieran la misma directiva que otros servidores, considere la colocación de estos objetos de equipo bajo una unidad organizativa Servidores más amplia, así como la creación de varias unidades organizativas para diferentes tipos de servidor bajo la unidad organizativa Servidores (consulte la Figura 1). 
Esto puede simplificar la aplicación de directivas, puesto que cada objeto de equipo en las unidades organizativas inferiores obtendrá la directiva de la unidad organizativa Servidores así como cualquier otra directiva que sea específica para ese tipo específico de servidor.
Figura 1 Creación de varias unidades organizativas para distintos tipos de servidor (Hacer clic en la imagen para ampliarla)
Otro aspecto básico consiste en asegurarse de que no se crean o vinculan de forma innecesaria varios GPO. Con un GPO, puede crear una directiva y aplicarla a varias unidades organizativas. En ocasiones esto es útil, pero también puede causar daños. Si tiene que cambiar una configuración de GPO y dispone de un sistema extremadamente complejo de GPO vinculados, podría aplicar por accidente un cambio a los objetos equivocados. Cuantos más vínculos cree, más complicado será definir el ámbito de una directiva. Igualmente, debe evitar la creación de directivas adicionales con la misma configuración que otras directivas. Si tiene que hacer esto con frecuencia, considere la modificación de su estructura de unidad organizativa para aplicar un nuevo modelo de herencia de GPO.
   Y, por último, debe crear casi siempre una nueva unidad organizativa para los objetos de usuario y los de equipo. De forma predeterminada, los objetos de usuario y de equipo se colocan en contenedores, lo cual no le permite vincular los GPO directamente a los mismos. Los GPO se pueden aplicar a los contenedores para usuarios y equipos desde el dominio, pero a menos que bloquee la herencia en otro sitio, estas directivas se aplicarán a cada usuario y equipo del dominio. En Windows Server® 2003, puede usar las herramientas rediruser.exe y redircomp.exe para cambiar la ubicación predeterminada de los objetos de usuario y de los objetos de equipo a la unidad organizativa que creó para los mismos.

Principio 2: delegación
Es importante que cree la estructura de la unidad organizativa de una manera que sea coherente con la forma de delegar permisos en el dominio. Tenga presente que al delegar permisos en Active Directory, los cambios de permiso se llevan a cabo sólo en el objeto. Así pues, si ofreciera a un usuario control total sobre un objeto de equipo particular, esa persona podría modificar los atributos del objeto, pero carecería de privilegios de administrador en el propio equipo.
Estos son algunos de los procedimientos recomendados referentes a la delegación a la hora de diseñar una estructura de unidad organizativa:
Diseño con herencia de permisos Por ejemplo, digamos que desea que los administradores del nivel 1 puedan cambiar la contraseña de la mayoría de las cuentas. Los administradores no deben tener la capacidad de restablecer las contraseñas de un grupo especial de usuarios, sin embargo, los primeros deben tener la capacidad de cambiar los nombres para mostrar de dichas cuentas.
    Aquí cuenta con dos opciones. La primera, podría crear dos unidades organizativas paralelas independientes y separar los usuarios especiales de los usuarios normales. Esto significa, sin embargo, que si desea cambiar las opciones de delegación de todos los usuarios, tiene que cambiar estos permisos en dos sitios independientes. Por otra parte, esto contradice la práctica de no vincular innecesariamente varias directivas (consulte la Figura 2)
Figura 2 Mantenimiento de dos unidades organizativas paralelas independientes (Hacer clic en la imagen para ampliarla)

   La segunda opción consiste en crear una unidad organizativa anidada y en configurar una denegación explícita de permiso en la unidad organizativa que contenga usuarios especiales. Cualquier experto en delegación le dirá que denegar de forma explícita no es lo más adecuado, pero en este caso, necesita seleccionar, de los dos males, el mejor (consulte la Figura 3). Puede, por una parte, duplicar o mantener la configuración en dos unidades organizativas independientes o bien puede configurar una denegación explícita en una de las unidades organizativas. El hecho de denegar de forma explícita es, a largo plazo, la mejor decisión.
Figura 3 Uso de la denegación explícita (Hacer clic en la imagen para ampliarla)

Preste atención a AdminSDHolder.
    Este ejemplo funciona bastante bien a menos que los usuarios especiales pertenezcan todos a uno de los grupos de administradores (Administradores de dominio, Administradores de esquema, Administradores de empresa o Administradores) puesto que los permisos para las cuentas en estos grupos se administran de manera distinta. Básicamente lo que no desea es proporcionar a alguien de forma accidental permisos a una cuenta de administrador.
Si crea una unidad organizativa independiente para administradores, observará que los permisos que les delega siguen desapareciendo. Esto se debe a AdminSDHolder, que es un contenedor especial que aplica su lista de control de acceso a cada cuenta de administrador en un intervalo especificado. Como consecuencia, cualquier cambio de delegación que realice en una cuenta de administrador no será válido si los cambios no se aplican también al contenedor AdminSDHolder. Por lo tanto, no debería separar las cuentas de administrador de otras cuentas con el objeto de llevar a cabo una delegación. Es preferible, no obstante, separar las cuentas de administrador a efectos de la directiva de grupo. Esto es especialmente cierto en Windows Server 2008, donde puede tener varias directivas de contraseña.

Principio 3: administración de objetos
   La unidad organizativa debe facilitar la administración de los objetos. Agrupar los objetos en la misma unidad organizativa puede, a menudo, facilitar la realización de cambios globales. El complemento Usuarios y equipos de Active Directory le permite editar ciertos atributos en una selección de varios objetos. Así pues, si tiene que cambiar un atributo con regularidad en un grupo de objetos, es más fácil hacerlo si todos se encuentran en la misma unidad organizativa.
   Esto es también especialmente útil si va a llevar a cabo actualizaciones con un script. Los lenguajes de scripting facilitan en gran medida la enumeración de todos los objetos de una unidad organizativa y la administración de los mismos de uno en uno. La otra opción consiste en buscar y modificar cada objeto individualmente. Simplemente el hecho de colocar los objetos en la misma unidad organizativa para la administración puede, en ocasiones, ahorrarle horas de trabajo innecesario cada semana.
   Otra manera de ayudar en la administración de objetos consiste en separar los objetos en diferentes unidades organizativas según su tipo. La creación de una unidad organizativa independiente para objetos de impresora o recursos compartidos publicados garantiza que esos objetos no tengan que ser eliminados cuando lleve a cabo la administración en otros objetos de la unidad organizativa. Esta práctica es equivalente a la de no agrupar cuentas de usuario y de equipo en la misma unidad organizativa.

ELECCIÓN DE UN MODELO
   Ahora que he tratado los principios del diseño de las unidades organizativas, puedo centrarme en algunos modelos de diseño comunes. Tenga en cuenta que hay muchos más modelos de los que puedo tratar aquí y que no está limitado a trabajar con las restricciones de un solo modelo. Puede tomar fragmentos de cada uno y crear su propio modelo híbrido dirigido a sus necesidades particulares.
Prácticamente cualquier modelo puede ser satisfactorio a pequeña escala, pero cuando la empresa crece, su capacidad para mantener la administración del entorno decrece. Por tanto, asegúrese de que, en primer lugar, prueba su modelo en un entorno de laboratorio adecuado. Y recuerde que aunque las estructuras de las unidades organizativas pueden, en un principio, cambiarse fácilmente, son más difíciles de cambiar cuanto más tiempo lleven funcionando.

El modelo superficial
   El modelo superficial toma su nombre del hecho de que se mantiene prácticamente plano. En este modelo, unas pocas unidades organizativas de alto nivel contienen la mayoría de los objetos (consulte la Figura 4). Este modelo se ejercita en su mayor parte en empresas más pequeñas en las que hay una pequeña tienda de TI, no hay muchas divisiones diferentes ni los empleados tienden a ejercer funciones distintas. Recomiendo, normalmente, no subir por encima de las 10 subunidades organizativas, aunque Microsoft sugiere un límite de 15 subunidades organizativas antes de que se materialicen problemas de rendimiento.
Figura 4 El modelo superficial cuenta con unas pocas unidades organizativas de alto nivel que contienen la mayoría de los objetos (Hacer clic en la imagen para ampliarla)

Si el encargado de recursos humanos es también el encargado de las nóminas, no tiene entonces sentido crear dos unidades organizativas independientes para ambos departamentos. En el modelo superficial, todos los objetos de usuario pueden agruparse en una unidad organizativa de gran tamaño para Cuentas o pueden mantenerse en el contenedor predeterminado Usuarios. Como mínimo, sus objetos de usuario deben separarse de sus objetos de equipo.
Para este modelo, recomiendo también que vaya un paso más allá y separe sus estaciones de trabajo de los servidores. A continuación, puede aplicar directivas de grupo diferentes sin tener que definir un GPO que use una consulta del Instrumental de administración de Windows® (WMI, Windows Management Instrumentation) para filtrar estaciones de trabajo o servidores.
Una de las ventajas de mantener la amplitud de su estructura de unidad organizativa, y no la profundidad, es que las búsquedas de Active Directory se ejecutarán más rápido. Normalmente recomiendo no sobrepasar las 10 subunidades organizativas. El control sobre los objetos no es muy preciso en este modelo, pero si va a administrar objetos en una pequeña empresa no necesitará ese control tan preciso. Además, este modelo sería difícil de usar correctamente en una empresa de gran tamaño, pero funciona muy bien en pequeñas empresas.
El modelo geográfico
En el modelo geográfico, debe crear unidades organizativas independientes para las distintas regiones geográficas. Este modelo es mucho mejor para las empresas que cuentan con departamentos de TI descentralizados pero que no desean incurrir en costos asociados con la administración de varios dominios (consulte la Figura 5).
Figura 5 El modelo geográfico separa las unidades organizativas por región geográfica (Hacer clic en la imagen para ampliarla)

Pongamos como ejemplo que tiene oficinas en Atlanta, Baltimore y Seattle. En el caso de que cada sitio administre sus propios usuarios y equipos, podría tratarse de una buena opción en términos de delegación. Pero, ¿qué ocurre si un usuario de Seattle vuela a Baltimore para realizar un curso y bloquea su cuenta? Los encargados de TI en Baltimore no podrán ayudar a este usuario si no se les han delegado permisos para obtener acceso a la cuenta del usuario. Si son las 8 de la mañana en Baltimore, son las 5 de la mañana en Seattle, lo que significa que el usuario puede tener que esperar horas antes de poder ponerse en contacto con alguien de la oficina de Seattle para obtener ayuda.
Algunas compañías globales usan un modelo denominado "Follow the sun" ("Siga el sol"), en el cual las llamadas al departamento de soporte técnico se enrutan a un sitio ubicado en una zona horaria en la que aún sea horario de oficina. Esto significa que la compañía no tiene por qué tener abierto el departamento de soporte técnico las 24 horas en cada una de las sucursales. Aún así puede proporcionar ayuda a los empleados, por ejemplo, desbloquear sus cuentas, en cualquier momento del día o de la noche.
Si éste es su modelo, la creación de unidades organizativas independientes basadas en la ubicación geográfica no es probablemente la mejor opción para sus necesidades operativas. Tendría que delegar los permisos independientes a cada departamento de soporte técnico regional para cada unidad organizativa de usuarios. Sin embargo, si sus ubicaciones cuentan con sus propios departamentos de TI, el modelo geográfico puede constituir un buen modelo para su organización.
El modelo geográfico es también difícil de eliminar en un solo dominio debido a su naturaleza de funcionamiento. Un dominio tiende a tener un modelo de seguridad diferente de otros dominios. Esto es más evidente si observa una aplicación a nivel de empresa, como Microsoft® Exchange.
El servidor Exchange Server de Atlanta puede tener distintas directivas de mensajes definidas, pero todos los Exchange Server de la empresa tienen, probablemente, los mismos GPO aplicados. Si éste fuera el caso, al poner Exchange Server en unidades organizativas independientes basadas en regiones provocaría el tener que vincular de manera innecesaria el mismo GPO a varias unidades organizativas. En términos de delegación, tiene que preguntar si los administradores de Exchange necesitan realmente permisos únicos a los objetos de equipo para los servidores Exchange Server. En la mayoría de los casos, la división de los objetos de equipo en unidades organizativas geográficas se lleva a cabo por la directiva de grupo, no por la delegación.
El modelo basado en tipos
El modelo basado en tipos clasifica los objetos según sus funciones (consulte la Figura 6). Al crear su último objeto de usuario, ¿lo hizo para una cuenta de usuario normal, una cuenta administrativa o una cuenta de servicio? En un modelo basado en tipos, cada uno de estos objetos se trata de manera diferente.
Figura 6 El modelo basado en tipos agrupa los objetos según sus funciones (Hacer clic en la imagen para ampliarla)

   En la mayoría de los casos, debe distinguir entre distintas clasificaciones de objetos de usuario para las directivas. Sus directivas se diferenciarán en su mayoría según el tipo de cuenta de usuario. Por ejemplo, el permitir a las personas iniciar sesión en un equipo con una cuenta de servicio es generalmente una práctica de negocio incorrecta. Las contraseñas de la cuenta de servicio se comparten, generalmente, entre muchos usuarios, por lo que si alguien inicia sesión con una cuenta de servicio, su identidad permanece anónima. En el caso de que ocurriera algo, tendría problemas para realizar un seguimiento del usuario que había iniciado sesión cuando se produjo el evento. En este ejemplo, debería establecer una directiva en las cuentas de servicio que evitara el inicio de sesión interactivo. Esto se adapta muy bien al modelo jerárquico mostrado en la Figura 3.
   Podría usar la herencia de GPO para obtener ventajas en este caso. Por ejemplo, podría tener una directiva Todos los usuarios referida a directivas implementadas para todos los objetos de usuario. Además, podría tener una directiva distinta e independiente para las cuentas de servicio, que dependa de la directiva Todos los usuarios. Este enfoque garantiza que sus cuentas de servicio tienen el mismo conjunto base de directivas que cualquier otra cuenta, así como las restricciones de inicio de sesión específicas.
Este enfoque es adecuado también para la delegación, en la que usa la herencia de permisos en lugar de la herencia de GPO. Suponga que sus administradores del nivel 2 tienen la capacidad de restablecer las contraseñas para todas las cuentas excepto para las cuentas de los administradores del nivel 3. Con una estructura de unidad organizativa plana, tendría que delegar los permisos a cada unidad organizativa que contenga cuentas de usuario. Sin embargo, en un modelo basado en tipos con una estructura jerárquica, puede dar al grupo del nivel 2 permisos para "restablecer la contraseña" en la unidad organizativa Cuentas y, a continuación, en la unidad organizativa del nivel 3, podría simplemente no heredar los permisos o incluso configurar una denegación explícita para evitar que el nivel 2 restablezca la contraseña.
Esto funciona también correctamente para los objetos de equipo. Los servidores y las estaciones de trabajo pueden separarse permitiendo la aplicación de distintas directivas a los mismos. Entonces, los servidores pueden subdividirse en funciones (consulte la Figura 1). 
   En este diseño, es posible configurar una directiva de alto nivel en la unidad organizativa Servidores que afecte a todos los servidores y también configurar directivas individuales en cada unidad organizativa de nivel inferior.
    Por ejemplo, digamos que tiene una cuenta de servicio de Microsoft Operations Manager (MOM). Con este modelo por niveles, puede crear un GPO de MOM y aplicarlo a la unidad organizativa Servidores de MOM. Y, a continuación, dentro de ese GPO, puede otorgar derechos a la cuenta de servicio de MOM para iniciar sesión como un servicio. Esto sólo se aplicaría a los servidores MOM de esa unidad organizativa. Los servidores MOM obtendrán, no obstante, el GPO de Servidores de la unidad organizativa Servidores de nivel superior, pero también obtendrán el GPO de MOM especializado, que está vinculado en la unidad organizativa de MOM.
Documentación del diseño
   Puede ser muy gratificante diseñar una estructura de unidad organizativa que resista los numerosos cambios que se producen en un entorno de Active Directory. Pero necesita algún método para realizar el seguimiento de las características dinámicas de las unidades organizativas. Si no dispone de ningún método, podría perder rápidamente el control de su entorno. Cuando sea necesario un cambio y deba agregarse o eliminarse una unidad organizativa, debe saber exactamente qué hacer para garantizar que su modelo seguirá ciñéndose a su modelo de diseño, adhiriéndose a los tres principios fundamentales. Por esta razón debe contar con un diseño bien documentado.
Microsoft ofrece guías de documentación en el Kit de recursos de Windows Server. Estas guías son estupendas si su estructura es un marco sólido que no va a cambiar mucho en el futuro. Pero la mayoría de las organizaciones cuentan con una estructura muy dinámica que cambia con frecuencia. Así pues, les presento algunas sugerencias importantes para garantizar que su estructura de unidad organizativa esté bien documentada y pueda ser compatible con un entorno dinámico.
Asegúrese de que toda la información es relevante
  Creo firmemente en la documentación que persigue un objetivo. Demasiados documentos operativos cuentan con tanta información superflua que es difícil encontrar lo que realmente se busca. No se quede estancado en el proceso de documentación porque sí. ¿Necesita realmente incluir el número de objetos en cada unidad organizativa o cada Entrada de control de acceso (ACE, Access Control Entry) en la lista de control de acceso de la unidad organizativa? Para la documentación de la unidad organizativa, la información siguiente será generalmente suficiente:
  • Nombre de la unidad organizativa
  • Descripción breve
  • Quién la creó, o con quién hay que ponerse en contacto para obtener más información o cambios
  • Cuándo se creó
No dificulte las actualizaciones  
   Si, desafortunadamente, tiene que actualizar algún documento complejo de Microsoft Word, es más que probable que postergue la implementación de actualizaciones. No es un problema que se desvincule de implementar pequeños cambios si sabe que pronto contará con una gran cantidad de actualizaciones que llevar a cabo a la vez. Desafortunadamente, las personas a menudo se olvidan de estos pequeños cambios o simplemente siguen postergándolos, por lo que el trabajo nunca se termina. Por lo tanto, la actualización del documento debe ser muy sencilla para no desalentarse. En la mayoría de los casos, una sencilla hoja de cálculo de Microsoft Excel® con unas pocas columnas funcionará bien.
Realice comentarios sobre el propio objeto 
    Los objetos de la unidad organizativa tienen un atributo de descripción donde puede escribir sus comentarios. En lugar de escribir los comentarios en el documento de diseño, considere l escribirlos en el atributo de descripción, de manera que otros usuarios puedan deducir directamente para qué sirve la unidad organizativa. Si necesita incluir más detalles, escriba una breve descripción en el atributo de descripción e incluya más detalles en el documento de la unidad organizativa.
Automatice la documentación 
    Un script se puede escribir para volcar los contenidos de la estructura de la unidad organizativa en un archivo de texto, una hoja de cálculo de Excel o incluso un archivo HTML. Este script puede ejecutarse cada noche en una tarea programada. Esto puede ser muy útil si incluye comentarios en el campo de descripción de la unidad organizativa. A continuación, es sólo cuestión de volcar el atributo de descripción al archivo y obtendrá automáticamente una estructura de unidad organizativa completamente documentada que estará siempre actualizada. Si crea un archivo nuevo cada vez que se ejecuta el script, en vez de sobrescribir el documento existente, puede mantener un historial de los cambios a los que se ha sometido la unidad organizativa a lo largo del tiempo.
Desafortunadamente, la mayoría de los administradores no entienden la importancia de una buena documentación de estructura de unidad organizativa hasta que realmente la necesitan. Y para entonces, a las 3 de la mañana, es casi imposible resolver lo que otras unidades organizativas eliminaron por accidente sin llevar a cabo una restauración.
No espere hasta que le ocurra esto. Le recomiendo encarecidamente que sea previsor en este área y que comience de inmediato un documento de unidad organizativa y designe una persona responsable de actualizarlo. Por último, si sigue la regla de facilitar la actualización de la documentación, la tarea no supondrá ninguna complicación.

 FUENTE: http://technet.microsoft.com