Categoría: Windows 2008 R2

Hola a todos,

En la entrada de hoy no es que vaya a reinventar la rueda ni mucho menos, pero desde hace años veo cierta confusión a la hora de identificar los distintos grupos de AD, sus funcionalidades, y su alcance.

image

 

Existen muchas referencias en la Web, y en el sitio de Microsoft, sobre los grupos, pero casi nunca queda muy claro, además hay que leer bastante para tener perfectamente clara la manera de trabajar con los grupos de seguridad, las buenas prácticas a la hora de anidarlos, y sobre todo como utilizarlos en entornos de múltiples dominios, y o con relaciones de confianza.

Hoy me quiero centrar sobre todo en la parte relativa a los entornos con relación de confianza, en distintos dominios o Forests.

Casi todas las semanas recibo alguna consulta ya sea a través del Blog, Twitter, o de algún compañero o amigo, relacionada con que tipo de grupos usar para dar acceso a Dominio A en Dominio B, o en periodos de Coexistencia en migraciones de usuarios complejas, donde queremos que un usuario acceda a los recursos de un dominio distinto.

La información que podemos encontrar por la web se resume en este cuadro:

 Groups

Lo más importante es entender la funcionalidad de los grupos, en la tabla de arriba que la he sacado de Microsoft, y es la típica tabla donde nos explican que es, que hace, y los posibles miembros de cada grupo, no queda muy claro en muchas ocasiones si un grupo admite miembros de otro Forest, o solo de otros usuarios de Dominios distintos al suyo, pero dentro de su mismo Forest. A parte de los nombres que con el nombre de los grupos casi nadie sabe su finalidad.

Domain Local: La finalidad de este grupo es acceder a recursos de su propio Dominio, por eso es Dominio Local. Por lo tanto ya tenemos claro que un grupo de dominio local solo puede dar acceso a objetos de su propio dominio.

Global Group: Por el contrario los grupos de dominio Global se conciben para dar acceso a recursos dentro de cualquier dominio de su Forest, o incluso en dominios o forest con relación de confianza.

Universal Groups: Para dar acceso a cualquier recurso dentro del mismo Forest, o Forest de confianza.

Una vez aclarada la finalidad, ahora hay que entender cuales son los posibles miembros … porque claro, ojala todo fuera tan sencillo como entender la finalidad de cada grupo, además debemos conocer que usuarios, y grupos admite cada uno de ellos.

Entornos de Coexistencia, relaciones de confianza, y acceso entre forests, y Bosques de recursos.

Centrándome ya en el origen de esta entrada, me gustaría analizar detalladamente las situaciones que vivimos, y las necesidades que se nos presentan en entornos con relación de confianza, periodos de Coexistencia mientras vivimos una migración de AD entre entornos, o simplemente cuando instalamos un Forest de recursos, y debemos implementar un modelo de delegación, o de acceso a los recursos.

Voy a dar por hecho que ya hemos llegado a esta situación, que ya hemos establecido conectividad entre los distintos Dominios, relación de confianza, etc., y que por necesidades del proyecto, del servicio, o porque se ha definido así en la arquitectura o diseño del entorno, debemos dar acceso a recursos de nuestro dominio, a identidades (usuarios) de dominios externos.

Pongamos que tenemos como dominio destino donde residen los recursos a acceder contoso.com, y como dominios de origen bank.com y datum.es. Desde los dominios origen nos solicitan tener acceso a una granja de servidores llamada SW1.

Este tipo de situaciones se suelen solventar de dos posibles vías, la primera a mi modo de entender no es correcta, y la segunda si:

  • Dando acceso directamente en el recurso de contoso.com a usuario origen, Grupo Universal, o Grupo Global origen. Desgraciadamente en muchas ocasiones, y motivado por las prisas se da acceso directamente a los objetos de origen en SW1, sin crear en contoso ningún tipo de grupo que controle esta delegación de permisos. Esto a la larga es un gran error, ya que no controlamos quien tiene acceso, y con el tiempo se olvida que alguien dio acceso de manera local a SW1.

grupodn

  • Creando en contoso.com un grupo Domain Local, con los permisos necesarios sobre la granja SW1 (la forma de dar los permisos, o accesos es indiferente), el grupo podría llamarse DL_SW1_DATUM. Ahora faltaría hacer miembros de ese grupo domain local a los usuarios o grupos de datum. En teoría habrá cierta comunicación entre datum y contoso, y se habrá definido que se genere un grupo nuevo en Datum con los usuarios que deben tener acceso a SW1, ese grupo puede ser Global o Universal. Este es el método correcto ya que nosotros controlamos a través de grupos de seguridad los accesos a nuestra granja SW1, además la nomenclatura lo deja claro haciendo mención al dominio de origen, luego se podría incluir en la nomenclatura alguna mención al tipo de acceso, pero eso ya entra en la forma de trabajar, y en los modelos de administración de cada organización, a mi me gusta crear grupos en base a roles, y tipos de permisos.

GroupsD

Resumiendo un poco, los únicos grupos que admiten miembros de otros Forests (bosques) son los Domain Local Groups. En esta imagen he intentado resumir que el único grupo que admite miembros de otros bosques es Domain local, y los que se pueden usar para anidar en Domain Local de otros forests son Universales y Globales.

Groups_Mem

Un saludo

Daniel Graciá

Hola a todos,

Recientemente he recibido varias consultas relacionadas con un problema a la hora de configurar un fondo de escritorio mediante GPO a máquinas Windows 8, y Windows 8.1.

En los foros de Microsoft TechNet también he contestado últimamente a consultas relacionadas con este problema.

https://social.technet.microsoft.com/Forums/es-ES/8ef62cfb-2922-42f0-a5de-4e38db72daa4/gpo-wallpaper-windows-8-y-81?forum=wsgpes

 

PROBLEMA:

Cuando desplegamos por medio de GPO un fondo de escritorio para equipos Windows 8, y WIndows 8.1, los equipos cliente procesan dicha GPO, pero aparece un fondo de pantalla negro, que no es el que hemos definido en la configuración de la GPO. Es muy frustrante pues es un comportamiento totalmente anómalo, los pasos siempre son los mismos, revisión de la GPO, que se aplique sobre la OU que debe, que el fondo de pantalla, en su ruta de red esté accesible para los usuarios que deben tenerlo, que se procese la GPO, en resumen se de administradores que han intentado durante días encontrar el fallo… Pero … ¿está el fallo en la GPO?

 

 

CAUSA:

Bien, en este punto no está muy clara la causa, pero sí que se sabe que hay un tipo de problema con sistemas Windows 7, 8, y 8.1 con esta configuración por GPO, no es algo que suceda en el 100% de los casos, pero en organizaciones con cientos de equipos basados en estos sistemas operativos es frustrante ver como no somos capaces de configurar algo tan básico, y sencillo como un fondo de escritorio corporativo.

Buscando información por la Technet, y otras fuentes, hay un sin fin de entradas relacionadas con este problema, y podemos encontrar muchas soluciones, demasiadas.

El problema está relacionado con una entrada del registry en los equipos cliente, dicha entrada es la siguiente HKEY_CURRENT_USER\Control Panel\Desktop\ Debe existir un registro del tipo REG_SZ llamado WallPaper que apunta a la ruta del wallpaper.

En los equipos afectados por el problema del fondo de pantalla en negro pueden suceder varias cosas:

  • No existe dicha entrada.
  • Existe pero hace mención a un fichero de fondo de pantalla que no es el que hemos definido, y la GPO no puede actualizar dicha información.

 

 

SOLUCION:

La solución que he encontrado, y ha funcionado en todos los casos es la siguiente:

1. Creamos la GPO que aplica el Wallpaper que deseamos sea el fondo de pantalla de los equipos. La configuración de la GPO en mi caso es básica solo quiero que una imagen que tengo en una unidad de red accesible en modo lectura por los usuarios que deben tener acceso, se configure como fondo de pantalla, para ello llamamos a la GPO Wallpaper_Corporativo, la editamos y vamos hasta la ruta donde se encuentra la configuración del Wallpaper, la ruta es la siguiente User Configuration > Policies > Administrative Templates > Desktop > Desktop

2015-02-18_10-15-30

Antes de aplicar la GPO sobre el usuario en cuestión vemos que fondo de escritorio tiene su PC sin la GPO.

2015-02-18_10-10-56

2. Una vez creada la GPO, la vinculamos a la OU donde se encuentra el usuario sobre el que queremos que se aplique. En mi caso utilizo una OU donde se encuentra el usuario sobre el que quiero se aplique el fondo de pantalla.

2015-02-18_10-49-15

3. Ahora accedemos a un PC con dicho usuario que es TEST1, si el fondo de pantalla aparece negro hay que seguir estos pasos:

  1. Crear una GPO para crear una clave de registry, a la que daremos la ruta del fondo de pantalla.

2015-02-18_10-59-19

  1. Vincularla también sobre la OU donde se encuentran los usuarios que queremos tengan ese fondo.
  2. Reiniciamos el PC, y en el siguiente reinicio aparecerá el fondo que hemos definido.

2015-02-18_11-01-51

En ocasiones tampoco funciona creando la clave del registry, por lo que primero debemos definir que se elimine la clave del registry que hace mención al Wallpaper, y luego crearla de nuevo con la GPO.

Como he dicho no sucede en todos los equipos, pero cuando ocurre genera muchos problemas.

Salu2!

Daniel Graciá

Hola a tod@s!

Navegando me he encontrado con una pequeña joya, la guía de supervivencia de Hyper-V!!

Está publicada en la wiki, y tras echarle un ojo me ha encantado todo el trabajo que hay recogiendo información, fuentes, enlaces … para aquellos que buscan un punto en concreto, los que tenéis unas horas libres y os apetece refrescar conocimientos, o porque queréis empezar en el mundillo de la virtualización con Hyper-V es perfecto.

 

Aquí tenéis el enlace: Hyper-V Survival Guide

microsoft-hyper-v-logo

 

Espero que la disfrutéis … eso si con calma, que la cantidad de información recabada es inmensa.

 

DGM

Primera entrada del 2014!

Como sabemos los Sufijos de User Principal Name (UPN) son la parte del UPN que comienza por símbolo @.

De tal manera que por ejemplo en el UPN DaniGracia@contoso.com, el sufijo UPN es el nombre de dominio contoso.com.

Los UPN hacen posible que los usuarios se autentiquen en el dominio usando una cuenta que incluya el nombre de sus dominios, sería algo parecido a una dirección de correo, tal y como hemos visto en el ejemplo anterior, y es algo fácil de recordar, aunque resulta muy útil en entornos complejos o bosques con múltiples dominios, donde los usuarios pueden autenticarse en diferentes dominios, y no deben usar diferentes credenciales, o estar pendientes sobre que dominio de la organización deben hacer la autenticación.

Veamos un ejemplo supongamos que el usuario Dani Gracia tiene una cuenta de usuario en el dominio sistemas.contoso.com, pero quiere iniciar sesión en un equipo que pertenece al dominio portatiles.contoso.com, lo más sencillo sería iniciar sesión usando el UPN de Dani Gracia que en este caso sería danigracia@contoso.com, estoy seguro que muchos dirían en la pantalla de inicio de sesión seleccionamos el dominio sistemas.contoso.com, o también escribiriamos Sistemas\DaniGracia … pero lo cierto es que lo más rápido y funcional en estos casos es escribir el UPN del usuario.

Alguno se preguntará … pero por qué en el UPN no he puesto DaniGracia@sistemas.contoso.com ?  Es sencillo, por defecto todos los usuarios tienen como sufijo UPN el nombre del dominio raíz, y el de su propio dominio, incluso si sus cuentas pertenecen a dominios hijo.

Hay una manera fácil de configurar los sufijos UPN alternativos que pueden utilizar los usuarios del dominio o bosque. Desde la consola de Directorio Activo de Relaciones de Confianza, tenemos la posibilidad de añadir o eliminar los sufijos UPN alternativos.

image

Estos sufijos alternativos aparecerán en las propiedades de directorio activo de usuario.

Otras utilidades de los Sufijos Alternativos:

Más info sobre los UPN

http://technet.microsoft.com/en-us/library/cc772007.aspx

 

DGM

Hola buenas tardes,

En breves publicaré una guia muy interesante de como sacar partido a esta nueva funcionalidad de la Release 2 de 2008.

Ojo esta nueva funcionalidad solo está disponible en Bosques con nivel funcional 2008 R2. Pero merece la pena, ya que nos ofrece posibilidades de recuperación de objetos rápidamente.

 

 

Espero poder subirlo esta semana.

Saludos

Dani Gracia.

>Windows Server 2008 R2’s AppLocker feature allows additional policy configuration for software use on servers. IT pro Rick Vanover provides an overview of this enhanced functionality.

Windows Server 2008 R2’s AppLocker feature allows additional policy configuration for software use on servers. IT pro Rick Vanover provides an overview of this enhanced functionality.

Starting with Windows Server 2008 R2 for server platforms and Windows 7 for desktop platforms, the Software Restrictions policies functionality has been replaced with AppLocker. With AppLocker and Group Policy, you can define what files to prohibit from being executed; this can include scripts, installation files, and standard executables.

The management goodness of AppLocker is that it can be applied via Group Policy locally or via a domain-based GPO. AppLocker exists in the Computer Configuration section of Group Policy under Windows Settings | Security Settings | Application Control Policies. From there, the AppLocker configuration provides an enhanced Group Policy configuration as shown in Figure A.

Figure A

Click the image to enlarge.

Within this section of Group Policy, you can craft myriad individual configurations, including policies that permit or deny users or groups the ability to run a file, an installation, or a script. Further, you can set this with exceptions and apply it in a granular fashion in Active Directory. If you don’t want a full deny, you can configure AppLocker to only audit the iteration of an installation file, a script, or a standard executable.

The AppLocker feature is new to Windows Server 2008 R2 and will not apply to operating systems older than Windows Server 2008 R2 or Windows 7. For older OSs, you can apply Software Restriction Policies via a separate group policy object.]

Visit Microsoft’s site for more information about AppLocker.

Stay on top of the latest Windows Server 2003 and Windows Server 2008 tips and tricks with our free Windows Server newsletter, delivered each Wednesday. Automatically sign up today!

AppLocker is what I would use. I would create a directory that’s «acceptable» like c:GoodCommands and put all the stuff allowed to run in there. Then, use AppLocker to specify that c:GoodCommands is an acceptable place to run. AppLocker’s «brain» does the rest, and everything else is prevented.

 


>EL viernes 14/08/09 se puso a disposición de los Techneters la versión final de la nueva versión de Windows Server 2008, la R2.
Si que trae algunas mejoras que son dignas de ver, por ejemplo las relacionadas con Active Directory.

windows-2008-r2-active-directory-administrative-center2 Active Directory Domain Services in Windows Server 2008 R2 support a new forest functional level. I am not sure if all of the features described here require the R2 functional level. I will try to find out more about this issue soon. The better PowerShell support is probably the most important enhancement. However, my favorite new feature is the new Recycle Bin.

Powershell Cmdlets

They replace the current Active Directory command line tools. There are about 85 Active Directory-related PowerShell cmdlets

Active Directory Administrative Center

windows-server-2008-r2-ad-create-userThe Active Directory Administrative Center is a new task-oriented user interface for the Active Directory Services. You can perform similar tasks as with the Active Directory Users and Computers console (ADUC). It is based on the new PowerShell cmdlets and displays the PowerShell commands that correspond to the tasks performed with the GUI.

Recycle Bin

Accidently deleted Active Directory objects can be restored from the Recycle Bin. (Requires R2 functional level)

GA_googleFillSlot(«Content-Middle»);

Offline Domain Join

windows-2008-r2-djoin.exe Admins can automate the joining of a Windows 7 machine to a domain during deployment with an XML file. The target computer can be offline during the deployment process. The tool that is used to join the domain is djoin.exe.

Managed Service Accounts

If the password of an account that is used as identity for services is changed by an admin, the managed service account feature will update all services automatically. (Requires R2 functional level)

Authentication Assurance

Authentication Assurance provides an authentication mechanism that allows administrators to map specific certificates to security groups using certificate policies. Users logged on with a smart card, USB token, or some other type of certificate logon method can be distinguished in this way. This feature can be used to grant external users access to corporate resources using Active Directory Federated Services. (Requires R2 functional level)

Sander Berkouwer described the new Active Directory features in more detail.

A %d blogueros les gusta esto: