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, cómo lo vemos en acción? 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 notarés 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.
Un caso 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, cómo 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 así 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?!
adfind -f "(&(objectClass=user)(adminCount=1)(!(objectClass=computer)))" sAMAccountname memberOfEsto 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!

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

Cuando movemos nuestra organización a Exchange 2007 parte del proceso es mover las carpetas públicas o public folders (PFs para simplificarnos).
Recordemos que Outlook 2003 e inferiores necesitan de las carpetas del sistema para obtener las libretas de direcciones, calendarización y otras, las cuales están dentro de la jerarquía de PFs.
Por ahí existen buenos artículos sobre el proceso adecuado de decomisión 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 más común es ver un mensaje de error que se refiere a un bloqueo/restricción a esta versión de Outlook; aunque estos pueden variar ligeramente pero normalmente hacen referencia a los PFs o la versión del cliente.
De hecho al tratar de revisar el estado de los PFs no podremos, debido a una inconsistencia que causamos nosotros mismos.
Básicamente la jerarquía de PFs no existe, a pesar de que los datos fueron migrados el sistema no sabe como estos se organizan, por lo cual no están disponibles para los clientes.
Para solucionarlo debemos utilizar la herramienta ADSIEdit ( I love ADSIEdit).
1- En la partición de Configuration navegar al contenedor de Exchange, el cual como sabemos se encuentra dentro del llamado Services.
2- Clic 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", dándole el valor "1" a su atributo llamado msExchPFTreeType. Cuidado, si no hacemos esto Exchange ignorará 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, razón 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, clic 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 podrán conectarse!