December 19, 2009

El mito del adminSDHolder...

Existe en todos los dominios y constantemente está en acción pero muchos lo ignoramos, es el adminSDHolder.
La definición técnica de dicho objeto la podemos encontrar en http://support.microsoft.com/kb/232199, básicamente lo que este hace es asegurarse que ningún security principal tenga altos derechos sobre otro que pertenezca a alguno de los grupos por defecto como Domain Admins, Account Operators u otros o, humanamente que Pedrito no le pueda cambiar la contraseña a Juanito, quien es el administrador del dominio, esto para dar un simple ejemplo.
Y dónde lo vemos, con el lindo ADSIEdit, en el contenedor System, por ejemplo CN=System,DC=bla-bla,DC=com.
Ahora bien, como lo vemos en accion? Pensemos en un escenario súper común, intentas migrar el buzón de correo de uno de tus compañeros y no lo logras, el error que se te muestra es relacionado a permisos en Active Directory pero tus permisos aparentan estar bien.
Si miras detenidamente el objeto, en la sección Avanzada, dentro de la etiqueta de Seguridad notaras que la herencia de permisos para dicho objeto esta deshabilitada, la podríamos habilitar pero en la próxima corrida del adminSDHolder los valores serán sobre-escritos.
En muchos casos con hacer esto tan simple podremos continuar nuestras tareas.
Ahora bien, casos de la vida real, en muchas empresas diferentes personas han realizado tareas técnicas en algún momento y luego dejaron esto de lado, muy comúnmente sus membresías no son ajustadas o bien lo hacen pero el adminSDHolder sigue monitoreando/afectando dichos objetos.
Entonces como sabe el adminSDHolder que debe auditar un objeto? Esto lo hace por medio del atributo adminCount. Lo más normal es que este no tenga valor alguno, pero en las cuentas protegidas verán que el valor es de 1.
Por razones de diseño este bit no se desactiva al remover las membresías. O sea que aunque yo remueva a mis antiguos administradores de los grupos privilegiados, cambiando asi sus permisos, el adminSDHolder continuara monitoreando dichos objetos y cambiando su ACL según sea necesario.
Los insto a hacer una rápida revisión de su ambiente, para determinar cuántas cuentas protegidas tienen en su ambiente!
adfind -f "(&(objectClass=user)(adminCount=1)(!(objectClass=computer)))" sAMAccountname memberOf
Esto les dará un listado de las cuentas de usuario protegidas por el adminSDHolder y la lista de grupos a que pertenezcan.
Cómo removerlo? Pues con ADSIEdit borren ese 1 del adminCount, luego busquen en objeto en ADUC, clic derecho Properties / Security / Advanced y denle clic en Restore Defaults. Bingo!
Hasta el 2010!

December 07, 2009

Y mis Public Folders??? (decomision Exchange 2003)

Cuando movemos nuestra organizacion a Exchange 2007 parte del proceso es mover las carpeta publicas o public folders (PFs para simplificarnos).
Recordemos que Outlook 2003 e inferiores necesitan de las carpetas del sistema para obtener las libretas de direcciones, calendarizacion y otras, las cuales estan dentro de la jerarquia de PFs.
Por ahi existen buenos articulos sobre el proceso adecuado de decomision de Exchange 2003, no obstante me e encontrado varias veces con este escenario: al remover el grupo administrativo de Exchange 2003 las conexiones de Outlook 2003 e inferiores fallan, lo mas comun es ver un mensaje de error que se refiere a un bloqueo/restriccion a esta version de Outlook; aunque estos pueden variar ligeramente pero normalmente hacen referencia a los PFs o la version del cliente.
De hecho al tratar de revisar el estado de los PFs no podremos, debido a una inconsistencia que causamos nosotros mismos.
Basicamente la jerarquia de PFs no existe, a pesar de que los datos fueron migrados el sistema no sabe como estos se organizan, por lo cual no estan disponibles para los clientes.
Para solucionarlo debemos utilizar la herramienta ADSIEdit ( I love ADSIEdit).
1- En la particion de Configuration navegar al contenedor de Exchange, el cual como sabemos se encuentra dentro del de Services.
2- Click derecho sobre el grupo administrativo de Exchange 2007 "Exchange Administrative Group (FYDIBOHF23SPDLT)".
3- Seleccionar New Object/msExchPublicFolderTreeContainer y llamarlo "Folder Hierarchies".
4- Dentro de este crear un objecto tipo msExchPFTree llamado "Public Folders", dandole el valor "1" a su atributo llamado msExchPFTreeType. Cuidado, si no hacemos esto Exchange ignorara que este es un arbol MAPI!
Ahora necesitamos darle un valor al atributo msExchOwningPFTreeBL, como vemos este es un atributo BackList por lo cual no podemos editarlo directamente, razon por la que deberemos hacer lo siguiente para cada almacen de PFs que tengamos.
1- Copiar el distinguishedName del objeto "Public Folders" que recientemente creamos.
2- Navegar al Storage Group que contenga el Public Folder Store para el servidor a reparar, click derecho sobre el objeto tipo msExchPublicMDB y copiar el valor del paso 1 en el atributo msExchOwningPFTree.
3- Reiniciar el servicio msExchangeIS.
Una vez que el servicio este arriba podremos manipular las popiedas del PF y los clientes legacy podran conectarse!