Es muy común que los administradores de Exchange no se involucren mucho con Outlook y viceversa, pero hay un atributo que realmente no podemos dejar pasar por alto, es el legacyExchangeDN.
La arquitectura original de Exchange utilizaba nombres distinguidos para cada objeto en el directorio, los cuales se forman con los nombres y ruta de los contenedores del objeto, esto era un poco rígido, lo cual llevaba a cierta complejidad y poca flexibilidad en su manejo. Por ejemplo, no se podía cambiar el nombre de un sitio en Exchange 5.5 o mover objetos entre contenedores, a menos que se eliminara el objeto para así obtener el nuevo nombre distinguido o distinguishedName.
Esto llevó a que los desarrolladores fueran más cautelosos al hacer la transición o integración de Exchange a Active Directory; este continúa utilizando nombres distinguidos pero no son el identificador primario, esta función la han tomado los GUIDs (Global Unique Identifier). El cual no varía sin importar la cantidad de modificaciones que se hagan al distinguishedName.
No obstante Exchange aún tiene partes de código que utilizan el distinguishedName para funcionar apropiadamente, razón por la cual surge una necesidad de un atributo que nos de esta compatibilidad, acá es cuando el legacyExchangeDN entra en juego.
Veamos a este atributo como "el nombre viejo" de un objeto en Exchange o bien como un identificador MAPI pues todo cliente MAPI pueden utilizar el legacyExchangeDN para hacer referencia a objetos.
De hecho usted puede responder correos usando una dirección en dicho formato ya que Active Directory responderá a la consulta ejecutada por el transport engine y resolverá la dirección apropiadamente, además este atributo está indexado para así agilizar los tiempos de respuesta.
Ahora bien, donde vemos el legacyExchangeDN en acción... pues cada vez que respondemos un correo y el destinatario está en la lista de direcciones de uso frecuente (Outlook Autocomplete o Automatic Name Resolution). Aunque normalmente lo único que vemos es la última parte de este, la cual casi siempre es igual al mailNickname peeero realmente es el legacyExchangeDN lo que esta ahí.
Por lo cual al migrar buzones entre organizaciones debemos recordar esto para no afectar el ruteo de correos, esto pues los clientes Outlook seguirán enviando correos a la dirección antigua, esto desde luego únicamente con destinatarios internos pues con los externos usa el ReturnPath que es una dirección SMTP.
Si usted es de esos incrédulos pues puede usar el MDB Viewer Utility (MDBVu32) para abrir su buzón de correo y mirar un mail enviado por un usuario interno, específicamente en la propiedad PR_SENDER_EMAIL_ADDRESS. Ahora si me cree? A bueno!
Y bien, si por alguna razón como la creación de una nueva Organización de Exchange o el movimiento de buzones entre organizaciones debemos modificar el legacyExchangeDN y deseamos preservar el ruteo pues tomando el legacyExchangeDN y agregándolo como una dirección X500 lo lograremos, algo como:
adfind -b DC=daemonroot,DC=com -f "(&(objectClass=user)(objectClass=person)(legacyExchangeDN=*)(!(objectClass=computer)))" legacyExchangeDN -adcsv admod proxyAddresses::X500:{{legacyExchangeDN}} -unsafeQué pasa si simplemente modificamos el legacyExchangeDN, pues vamos a tener NDRs por cada respuesta a un mail con el valor antiguo o por cada correo enviado a destinatarios que están el AutoComplete y pues al menos yo no quiero recibir todas esas quejas...
January 21, 2010
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, 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!
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!
December 07, 2009
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!
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!
November 16, 2009
Server 2008 R2 / Exchange 2010 p2
Pues bien, la instalación de los mailbox servers a terminado sin problema alguno, solo un par de cosas por resaltar, los requisitos de instalación, para simplificarnos podemos cumplirlos corriendo estos comandos de PoS:
•Import-Module ServerManager
•Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth, Web-Digest-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
•Set-Service NetTcpPortSharing -StartupType Automatic
Algo que me a fascinado es que ya no se depende del bendito servicio de Windows Cluster, para los que lo sufrimos esto es una gloria, no más “cluadmin .” Ahora Exchange se encarga de hacer la magia del failover.
Otro aspecto es que, durante la instalación del primer CAS se establece el nombre de Internet de tu organización, esto te pre-configura los URLs externos, lo cual realmente era una tarea lenta y tediosa en 2007, en donde realmente era muy simple comerter algun error.
Por otro lado, e estado instruyéndome en el tema en una manera más formal, les comparto un poco de las consideraciones a tomar en una implementación de Exchange 2010.
Si se puede pasar de Exchange 2003 a Exchange 2010, lo único necesario es expandir el esquema, además el modo funcional del bosque deba de ser 2003 y al menos contar con un servidor 2003 SP2 que funcione como GC en cada sitio donde se va a implementar Exchange. El modo operacional de la organización debe de ser Nativo.
RODC/ROGC no son soportados por E14! Esto como sabemos solo está disponible a partir de Windows Server 2008.
Si se va a hacer un upgrade desde 2007 también se requiere extender el esquema, igual se necesita tener SP2 instalado.
El CAS de E14 se puede usar como front-end con 2003 y 2007! Genial esto…
En un caso de migración de 2007 se deben de mantener los Hub Transport Servers, esto pues el HUB 2010 no puede comunicarse con mailbox servers en 2007.
Existen dos métodos para moverse a E14, -por migración, el cual te permite mover datos desde otras organizaciones o bien desde aplicaciones de mensajería de terceros (sigamos matando a Lotus Domino…) o bien por transición, la cual se efectúa cuando movemos datos entre nuestra misma organización.
Así rápidamente les comento algunas de las múltiples mejoras en el área de almacenaje.
Coalesced I/O. En Exchange Server 2010, ESE combina múltiples operaciones de I/O para crea una única operación, lo cual al final son menos I/Os, disminuyendo así la frecuencia de operaciones al disco, lo cual alarga su vida y nos da un mayor rendimiento general. Ligado a esto tenemos también que estas operaciones ahora manejan una mayor cantidad de datos.
También el viejo proceso de Online Defragmentation ha cambiado ya que este afectaba negativamente el rendimiento del servidor y sus dispositivos de almacenaje. Ahora el ESE contiene un nuevo evento llamado Defragmentation Manager, el cual monitorea la base de datos e identifica cuales B-Tress (método de almacenaje del ESE) necesitan ser desfragmentados, una vez identificados el mantenimiento se lleva a cabo en el background cuando la actividad en el servidor es menor, eliminando así el impacto mencionado anteriormente.
Realmente cuando me metí en Exchange 2007 note un gran salto tecnológico y en mi humilde opinión también agregaron cosillas que ofrecía la competencia y lo mejor es que las mejoraron, pero ahora veo un salto aun mayor, un producto más maduro y amistoso con el administrador, esperare con ansias mi primer implementación real!
Tambien pueden referirse al Exchange Deployment Assistant, esta herramienta les ayudará con su implementación, por ahora solo disponible de 2003 a 2010.
•Import-Module ServerManager
•Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth, Web-Digest-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
•Set-Service NetTcpPortSharing -StartupType Automatic
Algo que me a fascinado es que ya no se depende del bendito servicio de Windows Cluster, para los que lo sufrimos esto es una gloria, no más “cluadmin .” Ahora Exchange se encarga de hacer la magia del failover.
Otro aspecto es que, durante la instalación del primer CAS se establece el nombre de Internet de tu organización, esto te pre-configura los URLs externos, lo cual realmente era una tarea lenta y tediosa en 2007, en donde realmente era muy simple comerter algun error.
Por otro lado, e estado instruyéndome en el tema en una manera más formal, les comparto un poco de las consideraciones a tomar en una implementación de Exchange 2010.
Si se puede pasar de Exchange 2003 a Exchange 2010, lo único necesario es expandir el esquema, además el modo funcional del bosque deba de ser 2003 y al menos contar con un servidor 2003 SP2 que funcione como GC en cada sitio donde se va a implementar Exchange. El modo operacional de la organización debe de ser Nativo.
RODC/ROGC no son soportados por E14! Esto como sabemos solo está disponible a partir de Windows Server 2008.
Si se va a hacer un upgrade desde 2007 también se requiere extender el esquema, igual se necesita tener SP2 instalado.
El CAS de E14 se puede usar como front-end con 2003 y 2007! Genial esto…
En un caso de migración de 2007 se deben de mantener los Hub Transport Servers, esto pues el HUB 2010 no puede comunicarse con mailbox servers en 2007.
Existen dos métodos para moverse a E14, -por migración, el cual te permite mover datos desde otras organizaciones o bien desde aplicaciones de mensajería de terceros (sigamos matando a Lotus Domino…) o bien por transición, la cual se efectúa cuando movemos datos entre nuestra misma organización.
Así rápidamente les comento algunas de las múltiples mejoras en el área de almacenaje.
Coalesced I/O. En Exchange Server 2010, ESE combina múltiples operaciones de I/O para crea una única operación, lo cual al final son menos I/Os, disminuyendo así la frecuencia de operaciones al disco, lo cual alarga su vida y nos da un mayor rendimiento general. Ligado a esto tenemos también que estas operaciones ahora manejan una mayor cantidad de datos.
También el viejo proceso de Online Defragmentation ha cambiado ya que este afectaba negativamente el rendimiento del servidor y sus dispositivos de almacenaje. Ahora el ESE contiene un nuevo evento llamado Defragmentation Manager, el cual monitorea la base de datos e identifica cuales B-Tress (método de almacenaje del ESE) necesitan ser desfragmentados, una vez identificados el mantenimiento se lleva a cabo en el background cuando la actividad en el servidor es menor, eliminando así el impacto mencionado anteriormente.
Realmente cuando me metí en Exchange 2007 note un gran salto tecnológico y en mi humilde opinión también agregaron cosillas que ofrecía la competencia y lo mejor es que las mejoraron, pero ahora veo un salto aun mayor, un producto más maduro y amistoso con el administrador, esperare con ansias mi primer implementación real!
Tambien pueden referirse al Exchange Deployment Assistant, esta herramienta les ayudará con su implementación, por ahora solo disponible de 2003 a 2010.
~D~
November 14, 2009
Y dónde está???
Alguna vez les ha pasado que llegan a ver un ambiente y no encuentran algo… por ejemplo el grupo de Enterprise Admins?! Y lo mejor, cuando preguntan te ven como si tuvieras 3 ojos!!!
Desafortunadamente es muy común que los informáticos hagamos cosas y no las documentemos… o bien, algunos documentamos vía email y la gente simplemente no lee los correos… desgraciados…
Ok, mantengámonos en lo expuesto anteriormente ya que es algo muy común, manos a la obra, a resolverlo.
Existe una categoría especial de entidades predefinidas controladas por el sistema interno de seguridad de Windows, estas existen en todos los equipos, aunque varían ligeramente según la versión del sistema operativo; no importa si es un equipo en un workgroup o en un dominio, siempre encontraremos algunos de los llamados Well Know Security Principals, como son por ejemplo el grupo Everyone, Creator Owner, Administrators.
Estos son simple y sencillamente necesarios para el funcionamiento de nuestro sistema, además no podemos crear nuestros propios Well Know Security Principals.
Ok y que hacen estas entidades, básicamente tienen ciertos privilegios ya predeterminados, cuadnos pertenecemos a uno de estos grupos simplificando (mucho-mucho) estos agregan un SID a nuestro token de acceso, lo cual nos dará ciertos derechos muchas veces elevados. Esto del SID y token entonces me lleva a mencionar ciertos puntos, el SID o Security Identifier es como lo que los ticos conocemos como el número de cedula o identificación (DNI), en este caso esa cédula es un conjunto de valores alfanumérico que nos identifica, debo resaltar que el hecho de renombrar un objeto no significa que el SID cambie, así como cambiarnos de nombre no varía nuestro número de identificación (por lo cual esta técnica no me sirve para evadir mis deudas :-[ que mal).
Entonces para hacer una historia larga corta pensemos que al iniciar sesión se crea un token, el cual contiene nuestro SID y los SIDs de los grupos a los que pertenecemos, con esto el sistema sabe quién es y a que grupos de seguridad pertenece esa entidad y así puede honrar los permisos adecuados. Realmente eso es un tema mucho más complejo que esto, pero hoy Sábado no creo que mi esposa quiera que pase toda la noche en la computadora escribiendo, así que luego ahondamos en todas esas maravillas de la seguridad.
Habiendo dicho esto entendemos que el SID del Well Know Security Principal se suma al nuestro y así se dan ciertos permisos, algo como “mi número de identificación + el número de identificación de los Domain Admins = daemonRoot es Domain Admin = peligro!”
Bien, pero como mencione anteriormente algún sonajas renombro alguno de estos grupos y ahora no sabemos donde están entonces vamos a rastrearlos. ¿Cómo?! Pero ya les di la clave, por el identificador!
El identificador de un objeto en Active Directory está compuesto por una parte que identifica el dominio y otra a la entidad en si, esto es llamado el RID o Identificador Relativo. Recurramos a unas herramientas para que esto sea comprensible de forma sencilla.
ADFind http://joeware.net/freetools/tools/adfind/index.htm es la primer herramienta, luego necesitaremos otra que nos de el displayName del objeto que buscamos, el SidToName http://joeware.net/freetools/tools/sidtoname/index.htm .
El primer paso es ejecutar este comando en al consola adfind –f “objectClass=domain” –samdc objectSID este nos va a dar el SID del domino, que es algo como S-1-5-21-3922922491-1485192142-2417811997.
Ahora bien, para saber cómo están formado los SIDs de los Well Know Security Principals podemos consultar el KB 243330.
Entonces el siguiente paso es ejecutar este otro comando en la consola sidtoname S-1-5-21-3922922491-1485192142-2417811997-519 el cual nos va a dar el displayName del grupo llamado Enterprise Admins o talvez queramos probar con el -512 que pertenece a los Domain Admins <:0 br="">Si lo analizan un poco, esa tendencia que tenemos de renombrar la cuenta Administror “por seguridad” pues no lo es tanto, ya que el SID del Administrator siempre va a ser S-1-5-21-(SID del dominio)-500… lero-lero ^_^ !
Espero estas gotas de información les sean útiles, si alguien gusta discutir más a fondo algún tema, pues bienvenido! Realmente trato de expresarme y explicar las cosas de una forma simple y sencilla pero di… cada cabeza es un mundo, hasta pronto!
~D~
Desafortunadamente es muy común que los informáticos hagamos cosas y no las documentemos… o bien, algunos documentamos vía email y la gente simplemente no lee los correos… desgraciados…
Ok, mantengámonos en lo expuesto anteriormente ya que es algo muy común, manos a la obra, a resolverlo.
Existe una categoría especial de entidades predefinidas controladas por el sistema interno de seguridad de Windows, estas existen en todos los equipos, aunque varían ligeramente según la versión del sistema operativo; no importa si es un equipo en un workgroup o en un dominio, siempre encontraremos algunos de los llamados Well Know Security Principals, como son por ejemplo el grupo Everyone, Creator Owner, Administrators.
Estos son simple y sencillamente necesarios para el funcionamiento de nuestro sistema, además no podemos crear nuestros propios Well Know Security Principals.
Ok y que hacen estas entidades, básicamente tienen ciertos privilegios ya predeterminados, cuadnos pertenecemos a uno de estos grupos simplificando (mucho-mucho) estos agregan un SID a nuestro token de acceso, lo cual nos dará ciertos derechos muchas veces elevados. Esto del SID y token entonces me lleva a mencionar ciertos puntos, el SID o Security Identifier es como lo que los ticos conocemos como el número de cedula o identificación (DNI), en este caso esa cédula es un conjunto de valores alfanumérico que nos identifica, debo resaltar que el hecho de renombrar un objeto no significa que el SID cambie, así como cambiarnos de nombre no varía nuestro número de identificación (por lo cual esta técnica no me sirve para evadir mis deudas :-[ que mal).
Entonces para hacer una historia larga corta pensemos que al iniciar sesión se crea un token, el cual contiene nuestro SID y los SIDs de los grupos a los que pertenecemos, con esto el sistema sabe quién es y a que grupos de seguridad pertenece esa entidad y así puede honrar los permisos adecuados. Realmente eso es un tema mucho más complejo que esto, pero hoy Sábado no creo que mi esposa quiera que pase toda la noche en la computadora escribiendo, así que luego ahondamos en todas esas maravillas de la seguridad.
Habiendo dicho esto entendemos que el SID del Well Know Security Principal se suma al nuestro y así se dan ciertos permisos, algo como “mi número de identificación + el número de identificación de los Domain Admins = daemonRoot es Domain Admin = peligro!”
Bien, pero como mencione anteriormente algún sonajas renombro alguno de estos grupos y ahora no sabemos donde están entonces vamos a rastrearlos. ¿Cómo?! Pero ya les di la clave, por el identificador!
El identificador de un objeto en Active Directory está compuesto por una parte que identifica el dominio y otra a la entidad en si, esto es llamado el RID o Identificador Relativo. Recurramos a unas herramientas para que esto sea comprensible de forma sencilla.
ADFind http://joeware.net/freetools/tools/adfind/index.htm es la primer herramienta, luego necesitaremos otra que nos de el displayName del objeto que buscamos, el SidToName http://joeware.net/freetools/tools/sidtoname/index.htm .
El primer paso es ejecutar este comando en al consola adfind –f “objectClass=domain” –samdc objectSID este nos va a dar el SID del domino, que es algo como S-1-5-21-3922922491-1485192142-2417811997.
Ahora bien, para saber cómo están formado los SIDs de los Well Know Security Principals podemos consultar el KB 243330.
Entonces el siguiente paso es ejecutar este otro comando en la consola sidtoname S-1-5-21-3922922491-1485192142-2417811997-519 el cual nos va a dar el displayName del grupo llamado Enterprise Admins o talvez queramos probar con el -512 que pertenece a los Domain Admins <:0 br="">Si lo analizan un poco, esa tendencia que tenemos de renombrar la cuenta Administror “por seguridad” pues no lo es tanto, ya que el SID del Administrator siempre va a ser S-1-5-21-(SID del dominio)-500… lero-lero ^_^ !
Espero estas gotas de información les sean útiles, si alguien gusta discutir más a fondo algún tema, pues bienvenido! Realmente trato de expresarme y explicar las cosas de una forma simple y sencilla pero di… cada cabeza es un mundo, hasta pronto!
~D~
November 12, 2009
Server 2008 R2 / Exchange 2010.
Como podrán imaginar e estado esperando con mucha emoción el lanzamiento de Exchange 2010... hace un par de días mi buzón de correo corporativo fue migrado al ambiente de pruebas y ahora pues lo mejor "hágalo usted mismo!"
El día de ayer inicié la tarde de actualizar un poco mi ambiente de pruebas... para lo cual instalaré Windows Server 2008 R2 Enterprise con Exchange 2010 Enterprise.
Les describo un poco el ambiente... lo que tengo es una maquina con un AMD Phenom X3 2.3Ghz, 8GBs RAM 800Mhz y dos discos SATA de 500GB... Espero Colacho me traiga una con 2 procesadores y mas slots de memoria, acepto donaciones!
El host como les dije es un Server 2008 R2, DC/GC, DNS, WINS, CA, Exchange 2010 CAS y HT.
Este tiene dos maquinas virtuales, mismo sistema operativo y además DC/GC, DNS, WINS y próximamente Exchange 2010 MBX.
La instalación del sistema operativo no varia mucho, realmente sí es mas rápido que la versión anterior, ningún controlador me dio problema alguno...
Ciertamente todo fue muy bien, hasta que intente agregar la segunda maquina al dominio.
Como sabemos el Windows Firewall utiliza perfiles y pues algún parámetro en el perfil de domino no me permitía una buena comunicación con equipos que no están en el domino, realmente podía desde el cliente en el workgroup hacer ping, nslookup, nltest y otros, mas no podía mapear unidades de red ni agregar la maquina al dominio.
Llegue a pensar en problemas de resolución de nombres, configuración de las redes virtuales... también culpe al pobre Symantec... y como vemos era sencillo, claro, encontrar esto no lo fue tanto.
En fin, habiliten todo tipo de conexiones en el perfil de domino del Windows Firewall, agreguen el o los equipos al dominio y luego vuelvan a la configuración recomendada.
Ok perfecto, ahora tenía 3 controladores hablando entre sí felizmente... ahora vamos con Exchange!
Acá tampoco cambió mucho el proceso de instalación, lo primero el Setup.com /PrepareAD /OrganizationName. En mi cabecita dije, para tener más recursos disponibles voy a detener las maquinas virtuales mientras hacia esto, luego las inicio y listo, de por si el Schema Master es la maquina física o sea que pipa soy... pues no, parte de los chequeos preliminares que el instalador hace son buscar problemas de replicación, de existir la instalación no procede.
El error dice algo así como "The server side error is: 0x21a2 The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner".
Listo, maquinas virtuales arriba, NTDS reciclado*, repadmin /replsummary no muestra problema alguno.... después de unos minutos el proceso termina... ahora el Setup.com /PrepareSchema.
*Funny fact… algo que es una bendición en 2008 es que se puede reinicar el servicio de Active Directory ( net stop ntds o sc \\host stop ntds ) eso te va a quitar unas cuantas reiniciadas de sistema a lo largo de la vida… algo más curioso es que en 2000/2003 si navegan a HKLM\SYSTEM\CurrentControlSet\Services verán que el NTDS esta ahí solo que no podemos manipularlo; para mí que algún developer por estar chateando dejo eso a medias y no fue sino hasta 2008 que lo arreglaron... no sean hipócritas, también les a pasado!
Si son curiosos antes de correr esto podrían hacer lo siguiente, via ADSIEdit conéctense a la partición de Configuration... y naveguen al contenedor de llamado Services.
Acá encontraran aquellos servicios que se prestan en nuestro bosque, noten que digo bosque, pues otros como LCS/OCS se almacenan en la partición de dominio y no en la de configuración, esto pues la última es compartida por todos los DCs de nuestro bosque. También como parte del ejercicio podrían revisar el snap-in del Active Directory Schema ( el cual aparece al correr el comando regsvr32 schmmgmt.dll)... acá si revisan el contenedor de atributos, notaran que los atributos msExch* no están presentes...
Esto les da una breve idea de lo que los comandos anteriores hacen, ok ahora después de correr el Setup.com revisen de nuevo.
Bueno, manos a la obra a instalar Exchange!
Una de las cosas que más me gusta de 2007 es que los binarios son guardados en el disco local, por lo cual si pones tu disco de Exchange guindando en el retrovisor de tu carro y el sol lo daña, no hay problema!
Ok, si van a instalar la función de Client Access van a necesitar esto http://go.microsoft.com/fwlink/?LinkId=123380 así que mejor de una y evitarse la regañada.
Por ahí también puede que les salga un error que habla del NetTcpPortSharing... Dios nunca había escuchado de eso... claro Daniel sea inteligente y corra un sc query findstr /I "net" eso le va a dar la respuesta, pues... no! Acá es cuando me voy con solo los 500 mil pesos en ¿Quien quiere ser millonario? :(
Para solucionar esto debemos correr este comando de PowerShell o PoS Set-Service NetTcpPortSharing -StartupType Automatic y listo! https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/net-tcp-port-sharing
El set up continuará sin problema alguno.
¡Ah! como disfruté cuando saludé a mi servidorcito...
220 nemesis.daemonroot.com Microsoft ESMTP MAIL Service ready at Thu,
12 Nov 2009 22:49:13 -0600
ehlo daemonroot.com
250-nemesis.daemonroot.com Hello [::1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
Ok a este punto ya tengo mis DCs... y un CAS/HUB... mañana espero seguir con la parte de los Mailbox servers, espero estas líneas les ayuden en algo... hasta pronto!El día de ayer inicié la tarde de actualizar un poco mi ambiente de pruebas... para lo cual instalaré Windows Server 2008 R2 Enterprise con Exchange 2010 Enterprise.
Les describo un poco el ambiente... lo que tengo es una maquina con un AMD Phenom X3 2.3Ghz, 8GBs RAM 800Mhz y dos discos SATA de 500GB... Espero Colacho me traiga una con 2 procesadores y mas slots de memoria, acepto donaciones!
El host como les dije es un Server 2008 R2, DC/GC, DNS, WINS, CA, Exchange 2010 CAS y HT.
Este tiene dos maquinas virtuales, mismo sistema operativo y además DC/GC, DNS, WINS y próximamente Exchange 2010 MBX.
La instalación del sistema operativo no varia mucho, realmente sí es mas rápido que la versión anterior, ningún controlador me dio problema alguno...
Ciertamente todo fue muy bien, hasta que intente agregar la segunda maquina al dominio.
Como sabemos el Windows Firewall utiliza perfiles y pues algún parámetro en el perfil de domino no me permitía una buena comunicación con equipos que no están en el domino, realmente podía desde el cliente en el workgroup hacer ping, nslookup, nltest y otros, mas no podía mapear unidades de red ni agregar la maquina al dominio.
Llegue a pensar en problemas de resolución de nombres, configuración de las redes virtuales... también culpe al pobre Symantec... y como vemos era sencillo, claro, encontrar esto no lo fue tanto.
En fin, habiliten todo tipo de conexiones en el perfil de domino del Windows Firewall, agreguen el o los equipos al dominio y luego vuelvan a la configuración recomendada.
Ok perfecto, ahora tenía 3 controladores hablando entre sí felizmente... ahora vamos con Exchange!
Acá tampoco cambió mucho el proceso de instalación, lo primero el Setup.com /PrepareAD /OrganizationName. En mi cabecita dije, para tener más recursos disponibles voy a detener las maquinas virtuales mientras hacia esto, luego las inicio y listo, de por si el Schema Master es la maquina física o sea que pipa soy... pues no, parte de los chequeos preliminares que el instalador hace son buscar problemas de replicación, de existir la instalación no procede.
El error dice algo así como "The server side error is: 0x21a2 The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner".
Listo, maquinas virtuales arriba, NTDS reciclado*, repadmin /replsummary no muestra problema alguno.... después de unos minutos el proceso termina... ahora el Setup.com /PrepareSchema.
*Funny fact… algo que es una bendición en 2008 es que se puede reinicar el servicio de Active Directory ( net stop ntds o sc \\host stop ntds ) eso te va a quitar unas cuantas reiniciadas de sistema a lo largo de la vida… algo más curioso es que en 2000/2003 si navegan a HKLM\SYSTEM\CurrentControlSet\Services verán que el NTDS esta ahí solo que no podemos manipularlo; para mí que algún developer por estar chateando dejo eso a medias y no fue sino hasta 2008 que lo arreglaron... no sean hipócritas, también les a pasado!
Si son curiosos antes de correr esto podrían hacer lo siguiente, via ADSIEdit conéctense a la partición de Configuration... y naveguen al contenedor de llamado Services.
Acá encontraran aquellos servicios que se prestan en nuestro bosque, noten que digo bosque, pues otros como LCS/OCS se almacenan en la partición de dominio y no en la de configuración, esto pues la última es compartida por todos los DCs de nuestro bosque. También como parte del ejercicio podrían revisar el snap-in del Active Directory Schema ( el cual aparece al correr el comando regsvr32 schmmgmt.dll)... acá si revisan el contenedor de atributos, notaran que los atributos msExch* no están presentes...
Esto les da una breve idea de lo que los comandos anteriores hacen, ok ahora después de correr el Setup.com revisen de nuevo.
Bueno, manos a la obra a instalar Exchange!
Una de las cosas que más me gusta de 2007 es que los binarios son guardados en el disco local, por lo cual si pones tu disco de Exchange guindando en el retrovisor de tu carro y el sol lo daña, no hay problema!
Ok, si van a instalar la función de Client Access van a necesitar esto http://go.microsoft.com/fwlink/?LinkId=123380 así que mejor de una y evitarse la regañada.
Por ahí también puede que les salga un error que habla del NetTcpPortSharing... Dios nunca había escuchado de eso... claro Daniel sea inteligente y corra un sc query findstr /I "net" eso le va a dar la respuesta, pues... no! Acá es cuando me voy con solo los 500 mil pesos en ¿Quien quiere ser millonario? :(
Para solucionar esto debemos correr este comando de PowerShell o PoS Set-Service NetTcpPortSharing -StartupType Automatic y listo! https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/net-tcp-port-sharing
El set up continuará sin problema alguno.
¡Ah! como disfruté cuando saludé a mi servidorcito...
220 nemesis.daemonroot.com Microsoft ESMTP MAIL Service ready at Thu,
12 Nov 2009 22:49:13 -0600
ehlo daemonroot.com
250-nemesis.daemonroot.com Hello [::1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
P.D si ustedes tienen un chip que decodifica IPv6, los envidio, yo no... asi que talvez esto les sea útil http://support.microsoft.com/default.aspx/kb/929852
virgen del blog...
Ok ok... aquí un fan más de la tecnología, amante de la consola...
Realmente me gusta escribir y por los últimos años e mantenido una pequeña lista de distribución de correo a la cual contantemente bombardeo con noticias, trucos y mis vivencias, razones por las cuales me decidido a crear un blog para poder así llegar a más personas y tal vez poder ser de ayuda con mis humildes aportes...
Acá voy!
Realmente me gusta escribir y por los últimos años e mantenido una pequeña lista de distribución de correo a la cual contantemente bombardeo con noticias, trucos y mis vivencias, razones por las cuales me decidido a crear un blog para poder así llegar a más personas y tal vez poder ser de ayuda con mis humildes aportes...
Acá voy!
Subscribe to:
Posts (Atom)