| Sun Java Enterprise System 2003Q4 Installation Guide |
Cap�tulo 12
Provisi�n y conceptos de esquemas para Messaging Server 6.0En este cap�tulo se describen las opciones de provisi�n para Messaging Server 6.0, as� como otros temas que le ayudar�n a comprender los conceptos y las tecnolog�as de esquema de Sun ONE LDAP Schema, v.2.
Este cap�tulo incluye los siguientes apartados:
�rbol de informaci�n de directorio (DIT) LDAP y Messaging ServerDIT constituye una forma de organizar las entradas LDAP en una estructura de �rbol con nodos que representan dominios, subdominios, usuarios y grupos. Las versiones anteriores de Messaging Server usaban una estructura de doble �rbol con un “�rbol DC” que conten�a nodos de dominio acompa�ados de todos los atributos de dominio pertinentes, y un “�rbol de organizaci�n”, que conten�a nodos de dominio acompa�ados de todos los atributos de usuarios y grupos. La parte superior de la Figura 12-1 ilustra este tipo de estructura DIT. El uso de esta estructura hac�a posible que varios nodos de �rbol DC hicieran referencia al mismo nodo de dominio del �rbol de organizaci�n gracias a los alias definidos en el �rbol DC.
Messaging Server 6.0 presenta una estructura de �rbol �nico, donde no hay �rbol DC. Adem�s, toda la informaci�n sobre los dominios se guarda en nodos de dominio en el �rbol de organizaci�n. El modelo de doble �rbol todav�a se admite, pero ha sufrido las modificaciones que se explican en “Opciones de Schema v.2: modos original o de compatibilidad”.
La parte inferior de la Figura 12-1 ilustra una estructura LDAP de �rbol �nico. El tratamiento de los alias es completamente diferente en la nueva estructura de �rbol �nico. Observe especialmente en la representaci�n de �rbol �nico el lugar en el que se ubica la informaci�n del dominio.
Figura 12-1 Modo original comparado con la estructura LDAP del modo de compatibilidad
Opciones de esquema para Messaging Server 6.0Las tres opciones de esquemas para Messaging Server 6.0 son:
Sun ONE LDAP Schema, v.2 en modo original
El modo predeterminado para las nuevas instalaciones de clientes donde no hay una aplicaci�n iPlanet™ Messaging Server instalada es Sun ONE LDAP Schema, v.2. Se da por hecho que Identity Server 6.1 se ha instalado antes de instalar Messaging Server 6.0.
Tambi�n puede elegir este modo si dispone de una instalaci�n existente de iPlanet Messaging Server, pero se requiere la migraci�n de la base de datos LDAP al dise�o de �rbol �nico.
Se proporciona una interfaz de l�nea de comandos para la provisi�n y la administraci�n. Tambi�n puede llevar a cabo provisiones LDAP.
Sun ONE LDAP Schema, v.2 en modo de compatibilidad
Puede elegir Sun ONE LDAP Schema v.2 en modo de compatibilidad como alternativa si dispone de una instalaci�n existente de iPlanet Messaging Server. Este modo no requiere la migraci�n al dise�o de �rbol �nico. Puede conservar su dise�o actual de doble �rbol. Tambi�n se da por hecho que Identity Server 6.1 se ha instalado antes de instalar Messaging Server 6.0.
Se proporciona una interfaz de l�nea de comandos para la provisi�n y la administraci�n. Tambi�n puede llevar a cabo provisiones LDAP.
Sun ONE LDAP Schema, v.1
Sun ONE LDAP Schema v.1 es el modo predeterminado para las nuevas instalaciones de clientes que no disponen de Identity Server. Sun ONE LDAP Schema v.1 requiere la instalaci�n de un dise�o LDAP de doble �rbol.
Los clientes que dispongan de una instalaci�n existente de iPlanet Messaging Server pueden optar por conservar Sun ONE LDAP Schema v.1, y continuar usando la interfaz gr�fica de usuario para la provisi�n y la administraci�n, o por usar la provisi�n LDAP.
Identificaci�n de las herramientas de provisi�n adecuadasUna vez que ha decidido el modelo de esquema que va a usar, el siguiente apartado describe las herramientas y la documentaci�n que debe usar.
Este apartado contiene la siguiente informaci�n:
Matriz de provisiones
En la Tabla 12-1 se proporciona una matriz que resume las opciones de esquemas, las herramientas de provisi�n que est�n disponibles y la documentaci�n que se debe usar para cada caso. En los apartados que siguen a la tabla se explican las opciones.
En la primera columna de esta tabla se le pregunta si dispone de una versi�n previa instalada de Messaging Server (iPlanet Messaging Server 5.0, 5.1 o 5.2) y, en la segunda, se le pregunta si Identity Server est� ya instalado o si lo instalar� antes de la provisi�n.
Tabla 12-1 Matriz de provisiones
�Est� instalado iPlanet Messaging Server (5.0, 5.1 o 5.2)?
�Est� instalado Identity Server?
Tipo de esquema instalado por Messaging Server 6.0
Herramientas de provisi�n
Consulte estos documentos
No
No
Sun ONE LDAP Schema, v.1 (predeterminado)
Delegated Administrator
iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
Provisi�n LDAP
iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
No
S�
Sun ONE LDAP Schema, v.2 en modo original (predeterminado)
User Management Utility (commadmin)
Sun ONE Messaging and Collaboration 1.0 User Management Utility Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
Provisi�n LDAP
Consulte el Cap�tulo 11, “Provisi�n de organizaciones y usuarios” de esta gu�a
S�
No
Sun ONE LDAP Schema, v.1
Delegated Administrator
iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
Provisi�n LDAP
iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
S�
S�
Sun ONE LDAP Schema, v.2 en el modo original o de compatibilidad (puede elegir el que desee)
User Management Utility (commadmin)
Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
Provisi�n LDAP
Consulte el Cap�tulo 11, “Provisi�n de organizaciones y usuarios” de esta gu�a
Determinaci�n del modelo de esquema
Si no dispone de una versi�n previa de Messaging Server e instal� en primer lugar Identity Server, la nueva instalaci�n de Messaging Server 6.0 instalar� autom�ticamente usando el modo original de Sun ONE LDAP Schema, v.2. Si no ha instalado Identity Server, entonces Messaging Server usar� Sun ONE LDAP Schema, v.1 de forma predeterminada.
Si dispone de una versi�n previa de Messaging Server y desea usar Sun ONE LDAP Schema, v.2, deber� optar entre las siguientes posibilidades:
En funci�n de la elecci�n que realice, se usar� una de las dos plantillas predeterminadas para las b�squedas LDAP:
Si desea obtener m�s informaci�n acerca de los dos modos de Sun ONE LDAP Schema, v.2, consulte “Opciones de Schema v.2: modos original o de compatibilidad”.
Herramientas de provisi�n que se deben usar
Para Sun ONE LDAP Schema, v.2, puede usar la utilidad de administraci�n de usuarios Sun ONE User Management Utility, (commadmin) o realizar una provisi�n LDAP escribiendo los registros LDIF directamente en LDAP.
Para Sun ONE LDAP Schema, v.1, puede usar iPlanet™ Delegated Administrator (administrador delegado) o realizar una provisi�n LDAP.
M�s informaci�n acerca de la provisi�n
Use esta gu�a para realizar provisiones LDAP para Sun ONE LDAP Schema, v.2 (tanto en modo original como en modo de compatibilidad). Consulte Cap�tulo 11, “Provisi�n de organizaciones y usuarios” para obtener m�s informaci�n. Para realizar provisiones LDAP para Sun ONE LDAP Schema, v.1, consulte iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).
Si desea usar la herramienta de provisi�n User Management Utility (utilidad de administraci�n de usuarios) para Sun ONE LDAP Schema, v.2, consulte Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10). Si desea usar la herramienta de provisi�n Delegated Administrator (administrador delegado) para Sun ONE LDAP Schema, v.l, consulte iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).
Opciones de Schema v.2: modos original o de compatibilidadPuede estructurar LDAP con Sun ONE Schema, v.2 de dos formas: modo original (recomendado), que usa s�lo el �rbol de organizaci�n, o el modo de compatibilidad (para obtener compatibilidad con versiones anteriores de productos basados en Sun ONE o en iPlanet), que usa tanto un �rbol DC (de componente de dominio) como un �rbol de organizaci�n. La provisi�n de LDAP depende del modelo elegido.
Antes de elegir los modos de Sun ONE Schema, v.2 que desea usar, consulte los siguientes temas:
�Por qu� cambi� la estructura LDAP?
Java Enterprise System introduce un cambio fundamental en la estructura de LDAP mediante la implementaci�n del �rbol �nico. Las dos ventajas principales de usar una estructura de �rbol �nico (modo original) son:
La estructura LDAP de �rbol �nico es bastante menos compleja que la de doble �rbol. Como se refleja en la siguiente figura, en la estructura de doble �rbol, algunos nodos hacen referencia directamente a un nodo del �rbol de organizaci�n (usando el atributo inetDomainBaseDN). Los otros nodos cuentan con alias que, en lugar de hacer una referencia directa al nodo del �rbol de organizaci�n, hacen referencia a otro nodo de �rbol DC, usando el atributo aliasedObjectName.
Figura 12-2 Alias de doble �rbol con aliasedDomainName y inetDomainBaseDN
En la figura anterior, sesta.com del �rbol DC hace referencia a siroe.com del �rbol DC usando aliasedObjectName, mientras que siroe.com hace referencia al nodo del mismo nombre del �rbol de organizaci�n, usando inetDomainBaseDN.
Adem�s, tal y como se muestra en la siguiente figura, puede haber uno o varios nodos en el �rbol DC usando inetDomainBaseDN para que haga referencia directamente al mismo nodo del �rbol de organizaci�n. En este caso, hizo falta el atributo inetCanonicalDomainName en uno de los nodos de �rbol DC para clarificar cu�l era el nombre de dominio “real”. Es decir, el dominio en el que reside realmente el correo y al que se debe encaminar.
Figura 12-3 Alias de doble �rbol con inetCanonicalDomainName
En comparaci�n, la nueva estructura LDAP es mucho m�s simple: una estructura de �rbol �nico contiene s�lo un �rbol de organizaci�n, tal y como se muestra en la Figura 12-4.
En la estructura de �rbol �nico, los nodos de dominio del �rbol de organizaci�n contienen todos los atributos de dominio que antes se encontraban en el �rbol DC. Cada nodo de dominio se identifica mediante la clase de objeto sunManagedOrganization y el atributo sunPreferredDomain, que contiene el nombre de dominio DNS. Un nodo de dominio tambi�n puede tener uno o varios atributos associatedDomain, que enumeran los nombres de alias por los que se conoce este dominio. Al contrario que en la estructura de doble �rbol, no hay nodos duplicados para los nombres de alias.
Figura 12-4 Alias de �rbol �nico con associatedDomain
Modo original: ventajas e inconvenientes
En las nuevas implementaciones de Messaging Server, la informaci�n LDAP se organiza usando una estructura sencilla del �rbol de informaci�n de directorio (DIT). En concreto, la estructura DIT sencilla de Messaging Server se denomina “�rbol de organizaci�n”. Contiene entradas de usuarios, grupos y dominios, as� como plantillas de b�squeda.
Ventajas de un DIT de �rbol �nico
La estructura DIT de �rbol �nico supone una ventaja en cuanto a la organizaci�n de los datos para obtener un control de acceso espec�fico para las empresas. Es decir, todas las organizaciones pueden tener un �rbol independiente en el DIT donde se ubican las entradas de grupo y de usuario. El acceso a dichos datos se puede restringir a los usuarios de esa parte concreta del �rbol. De esta forma, las aplicaciones pueden funcionar con seguridad.
Adem�s, para las nuevas implementaciones de Messaging Server 6.0, la estructura de �rbol �nico se ajusta mejor a las aplicaciones LDAP existentes de �rbol sencillo.
Inconvenientes del modo original
Con una estructura de doble �rbol, era posible tener dos nodos de dominio de �rbol DC que hicieran referencia al mismo nodo de dominio del �rbol de organizaci�n. Cada uno de los dominios de �rbol DC pod�a tener diferentes valores de atributos de encaminamiento. Esto permit�a diferentes procesos y encaminamientos de correo para el mismo dominio del �rbol de organizaci�n, en funci�n del alias de dominio que se especificara. Dado que este tipo de alias ya no es posible en una estructura de �rbol �nico, esta funci�n deja de estar presente.
La definici�n de alias se realiza ahora mediante el atributo associatedDomain y es similar al funcionamiento en modo de compatibilidad de los dominios de alias que cuentan con el atributo aliasedObjectName. Es decir, el dominio de alias no inclu�a atributos de encaminamiento de dominios, sino que se basaba en los atributos que acompa�an al dominio de alias (cuyo dn estaba incluido en el atributo aliasedObjectName), puesto que el encaminamiento de mensajes para el dominio de alias era id�ntico al dominio de alias.
Conversi�n al modo original
Si dispone de una instalaci�n de Sun ONE Schema, v.1 (estructura LDAP de doble �rbol) y desea convertirla al modo original, consulte la siguiente lista donde aparecen los cambios que se deben efectuar en el �rbol de organizaci�n.
- Agregue las clases de objetos sunISManagedOrganization y sunManagedOrganization, junto con sus atributos respectivos, a todos los nodos de dominio.
- Agregue la clase de objeto sunNameSpace a todos los nodos de dominio adecuados. (Consulte “Declaraci�n de espacios de nombres”.)
- Copie todos los atributos de dominio pertinentes del �rbol DC en los nodos correspondientes de dominio del �rbol de organizaci�n.
- “Comprima” todos los alias del �rbol DC en el atributo associatedDomain.
- Agregue instrucciones ACI a los nodos del �rbol de organizaci�n.
- Identity Server agrega plantillas de b�squeda global al nodo ra�z (basedn). Tambi�n puede proporcionar plantillas privadas de sustituci�n en los nodos individuales.
Para obtener informaci�n acerca de las clases de objetos y de los atributos, consulte Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).
Modo de compatibilidad: la estructura de doble �rbol se sigue utilizando
Messaging Server 6.0 admite todav�a la estructura de doble �rbol para las versiones anteriores de Messaging Server, en caso de que deba conservar esta estructura. Puede que sea necesario conservar la estructura LDAP de doble �rbol si dispone de otras aplicaciones que dependan de ella.
Si conserva la estructura de doble �rbol, Messaging Server usa una plantilla de b�squeda compatible con RFC 2247 para buscar entradas de usuario.
La migraci�n de Sun ONE Schema, v1 al modo de compatibilidad de Sun ONE Schema, v.2 requiere las siguientes circunstancias:
- El atributo inetDomainStatus debe copiarse desde los nodos de �rbol DC a los nodos correspondientes del �rbol de organizaci�n. (Cuando los dos nodos contengan inetDomainStatus, el estado hallado en el nodo del �rbol de organizaci�n prevalecer� con respecto al estado hallado en el nodo del �rbol DC.)
- La plantilla de b�squeda predeterminada de doble �rbol debe tener definido el atributo rfc2247Flag de forma que todas las aplicaciones que busquen LDAP sigan usando el �rbol DC para acceder a los nodos correctos del �rbol de organizaci�n, como en las versiones anteriores de Messaging Server.
- Todos los nodos del �rbol de organizaci�n deben tener los atributos y las clases de objeto de marcador de Identity Server adecuados.
- A cada nodo se le deben agregar las instrucciones ACI adecuadas para
Identity Server.- Las plantillas de b�squeda global para dominios, usuarios y grupos se encuentran en el nodo ra�z de Identity Server. No obstante, puede que sea necesario personalizar las b�squedas para ciertos nodos. Para realizar la personalizaci�n, debe agregar plantillas de sustituci�n a los nodos concretos.
Modelos de datos para los modos original y de compatibilidadEl modelo b�sico de datos de las clases de objetos de Sun ONE es ampliar los tipos de entradas LDAP (por ejemplo, usuario, grupo y dominio) creados por las clases de objetos principales superponi�ndolos con clases compartidas (clases de objetos que se pueden compartir entre varios servicios) y clases de objetos espec�ficas para servicios (clases espec�ficas para un cierto tipo de servidor).
Esta relaci�n se ilustra en las tablas que aparecen a continuaci�n. En el caso de LDAP en modo original con s�lo un �rbol de organizaci�n, consulte la siguiente tabla. Para LDAP con compatibilidad con un �rbol DC y un �rbol de organizaci�n, consulte la Tabla 12-3.
Consideremos el tipo de entradas de usuario como ejemplo para explicar los tipos de atributos que proporcionan las siguientes clases de objetos:
person Proporciona atributos para describir a una persona.
organizationalPerson Proporciona atributos para describir a una persona que pertenezca a una organizaci�n.
inetOrgPerson Proporciona atributos b�sicos de usuarios de Internet.
ipUser Incluye el atributo de la libreta de direcciones personal, la plantilla de clase de servicio y el DN de la cuenta de familia, seg�n proceda.
inetUser Representa una cuenta de usuario y se usa junto con inetMailUser y con ipUser para crear una cuenta de correo.
inetSubscriber Es una clase de objeto optativa que representa una cuenta de suscriptor. Proporciona el ID de cuenta y atributos de pregunta y respuesta.
inetMailUser Representa una cuenta de correo y proporciona gran parte de los atributos de cuenta de correo espec�ficos para el usuario.
inetLocalMailRecipient Representa a un destinatario de correo electr�nico local (dentro de la organizaci�n) mediante la especificaci�n de las direcciones de correo electr�nico del destinatario y la indicaci�n de la informaci�n de encaminamiento pertinente para el destinatario.
Declaraci�n de espacios de nombresLos espacios de nombres definen entidades de organizaciones en las que uno o varios atributos deben ser exclusivos en todas las entradas.
Para proveer una organizaci�n (normalmente, un dominio) para que sea un espacio de nombre, agregue la clase de objeto sunNameSpace a la entrada de la organizaci�n. Este hecho lo marca como espacio de nombre exclusivo, pero no habilita la funci�n de “exclusividad”. Es decir, la clase de objeto sunNameSpace por s� misma no altera el comportamiento del sistema.
Para habilitar la funci�n de exclusividad, debe agregar el atributo sunNameSpaceUniqueAttrs a la entrada de la organizaci�n. El atributo contiene el nombre de un atributo que se usa para distinguir las entradas exclusivas de esta organizaci�n. Se pueden usar varios atributos para la funci�n de exclusividad.
A�adir la funci�n de exclusividad a un dominio significa que ning�n �rbol del dominio se podr� declarar como espacio de nombre usando los mismos atributos.
La exclusividad la garantiza la herramienta de provisi�n de la utilidad de l�nea de comandos, commadmin, que no le permitir� agregar una entrada duplicada que infrinja la funci�n de exclusividad. No obstante, cuando provisione directamente con LDAP, deber� forzar la exclusividad personalmente. El comando LDAP, ldapmodify, no fuerza la exclusividad. Con �l, podr� incluir registros duplicados.
La exclusividad de atributos es una funci�n de Identity Server que usa
Messaging Server. Para que la base de datos LDAP pueda administrarse mediante Identity Server, debe proveer los datos de manera que se cumplan las restricciones de exclusividad impuestas por sunNameSpace y sunNameSpaceUniqueAttrs.
La siguiente figura muestra un ejemplo de dominios considerados como espacios de nombres.
Figura 12-5 Dominios como espacios de nombres
En la figura anterior hab�a tres dominios, cada uno de ellos con la clase de objeto sunNameSpace y el atributo sunNameSpaceUniqueAttrs definido en uid. Cada dominio es un espacio de nombre en el que dos entradas no pueden tener el mismo uid. Esto tambi�n posibilita que varios dominios tengan entradas con el mismo identificador exclusivo, sin infringir las restricciones de exclusividad de los dominios separados. Por ejemplo, los tres dominios tienen una entrada cuyo uid es jdoe. Esto es posible porque cada organizaci�n es un espacio de nombre separado. Para buscar un jdoe concreto en este ejemplo, la plantilla de b�squeda debe conocer el nombre de la organizaci�n (dominio).
Se pueden asignar atributos diferentes adicionales a cada dominio. Por ejemplo, los usuarios de un dominio pueden tener un valor exclusivo para telephoneNumber. De manera que, para este dominio, la entrada contar� adicionalmente con sunNameSpaceUniqueAttrs=telephoneNumber y, en ning�n caso, dos usuarios podr�n tener el mismo n�mero de tel�fono.
Superposici�n de espacios de nombres y el nodo ra�z
Aunque es posible superponer espacios de nombres con Sun ONE LDAP Schema v.2, no convierta el nodo ra�z en espacio de nombre.
Si prev� tener m�s de un dominio en su instalaci�n, no coloque el atributo sunNameSpaceUniqueAttrs en el nodo del sufijo ra�z (basedn en el ejemplo) porque a los dominios que pertenecen a la ra�z se les prohibir�a usar los atributos nombrados en la entrada ra�z debido a la aplicaci�n de las restricciones de exclusividad.
Por ejemplo, si tiene sunNameSpaceUniqueAttrs=uid en el nodo ra�z, ninguno de los dem�s dominios podr�n usar uid para forzar la exclusividad en el dominio.
Identity Server provisiona autom�ticamente el nodo ra�z con sunNameSpace, pero no agrega el atributo. Dado que la funci�n de exclusividad no est� habilitada sin la presencia de sunNameSpaceUniqueAttrs, el nodo ra�z no funciona como espacio de nombre a menos que agregue espec�ficamente el atributo.
Plantillas de b�squedaEste apartado explica el funcionamiento de las plantillas de b�squeda y el formato que tienen.
Nota
El formato para las plantillas de b�squeda est� sujeto a cambios. Debe administrarlas mediante Identity Server.
Visi�n general de las plantillas de b�squeda
Las plantillas son entradas especializadas del �rbol de organizaci�n. Messaging Server las usa para localizar entradas LDAP para dominios, usuarios y grupos de la siguiente forma:
- En el modo original, Messaging Server usa la plantilla BasicOrganizationSearch y realiza la b�squeda especificada usando el filtro de b�squeda que aparece en la plantilla.
- En el modo de compatibilidad, usando la plantilla BasicDomainSearch, Messaging Server busca las preferencias de rfc2247Flag. Si el indicador est� establecido en true, se omite el filtro de b�squeda y se usa el �rbol DC para buscar el nodo del �rbol de organizaci�n adecuado, como en las versiones anteriores de Messaging Server.
Existen dos tipos de plantillas de b�squeda:
Para obtener m�s informaci�n acerca de las clases de objetos y los atributos, consulte Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).
Formato de las plantillas de b�squeda
Las plantillas de b�squeda constan de los siguientes elementos:
Valor booleano (true o false) que indica si las aplicaciones deben usar el algoritmo RFC 2247 para construir el valor DN de la entrada LDAP para buscar en lugar de usar el filtro de b�squeda especificado. (Se trata de una compatibilidad retrospectiva con instalaciones existentes que cuenten con estructuras LDAP con modo de compatibilidad como, por ejemplo, las instalaciones de iPlanet Messaging Server 5.2.) Este elemento hace que el sistema busque en el �rbol DC un atributo inetDomainBaseDN coincidente que haga referencia al nodo de organizaci�n correcto en el �rbol de organizaci�n. Para obtener m�s informaci�n acerca de los �rboles DC, consulte iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).
Grupos (listas de correo)Los grupos, conocidos como “listas de correo” en Messaging Server, permiten a los usuarios de los servicios ponerse en contacto con usuarios de otros grupos sin tener que nombrarlos individualmente. En Messaging Server, esto se traduce en la posibilidad de enviar un correo electr�nico a varios buzones sin tener que escribir cada direcci�n por separado. Messaging Server admite listas de correo (grupos) din�micas y est�ticas. Cada tipo de lista tiene una entrada LDAP compatible con la clase de objeto inetMailGroup.
En el caso de las listas de correo est�ticas, los miembros de la lista se especifican directamente en la entrada LDAP del grupo. Para las listas de correo din�micas, los miembros se especifican usando un filtro de b�squeda LDAP (RFC-2254).
En los grupos din�micos se pueden realizar m�s divisiones: un grupo din�mico se puede asignar o filtrar. Adem�s, los tipos de grupos puede ser “abiertos” (es posible suscribirse) o “cerrados” (no es posible suscribirse). Una excepci�n es el grupo din�mico filtrado, que no puede ser abierto.
Puede resultar �til visualizar las diferentes combinaciones, tal y como se muestra en la tabla que aparece a continuaci�n:
Abierto/Cerrado
Est�tico
Din�mico, se puede asignar
Din�mico, filtrado
Abierto (es posible suscribirse)
S�
S�
No
Cerrado (no es posible suscribirse)
S�
S�
S�
Tipos de grupos
Existen tres tipos de grupos:
- Est�tico. Un grupo est�tico tiene una entrada LDAP que enumera todos los miembros, usando el atributo uniqueMember para los miembros internos y el atributo mgrpRFC822MailMember para los miembros externos.
- Din�mico, se puede asignar. La entrada LDAP de un grupo din�mico que se puede asignar contiene un filtro de b�squeda definido en el atributo mgrpDeliverTo. El atributo filtrado debe ser un atributo reconocido. El atributo reconocido predeterminado para Messaging Server es memberOf, un atributo que ahora es compatible con Identity Server, usando la clase de objeto inetAdmin.
Por ejemplo, para el grupo din�mico llamado HRStaff, el atributo mgrpDeliverTo deber�a tener el siguiente valor:
(&(objectclass=inetAdmin) (memberOf=cn=HRStaff, ou=Groups, o=sesta.com, o=basedn ))
Adem�s, la entrada de usuario de cada miembro deber�a contener las siguientes l�neas:
objectClass: inetAdmin
memberof: HRStaff
- Din�mico, filtrado. Al igual que los grupos din�micos que se pueden asignar, la entrada LDAP de un grupo din�mico filtrado contiene un filtro de b�squeda definido en el atributo mgrpDeliverTo. No obstante, en este caso, los miembros del grupo se pueden determinar mediante la filtraci�n de atributos (uno o varios). Por ejemplo, un filtro podr�a ser as�:
(&((objectclass=inetMailUser)(city=tokyo)&(objetclass=inetOrgPerson)(uid=jdoe)))
Por otra parte, los grupos est�ticos tambi�n pueden tener miembros din�micos con s�lo agregar el atributo mgrpDeliverTo a la entrada LDAP del grupo est�tico.
Cada tipo de grupo tiene su propia clase de objeto de Identity Server. En la siguiente tabla se enumeran los tipos de grupos y las clases de objetos de Identity Server que se usan para proveer a cada uno de ellos:
Nota
La clase de objeto iplanet-am-managed-group es la clase superior para las tres clases, pero su uso en una entrada LDAP de un grupo es optativo.
Grupos abiertos y cerrados
Los grupos abiertos son aquellos a los que puede suscribirse cualquier usuario. Si el atributo iplanet-am-group-subscribable est� presente en la entrada LDAP del grupo con el valor true, significa que el grupo est� abierto y que es posible suscribirse a �l. Se trata de un atributo optativo. Si el atributo no est� presente, se considera que el grupo est� cerrado, es decir, que no es posible suscribirse a �l. El atributo tambi�n puede tener el valor false, lo que significa que el grupo est� cerrado y que no es posible la suscripci�n.
Clase de servicio (CoS)El mecanismo avanzado de administraci�n de entradas de CoS le permite crear atributos virtuales que no est�n almacenados en las entradas. En lugar de ello, se generan mediante el mecanismo de CoS a medida que la entrada se env�a a la aplicaci�n cliente. Al igual que ocurre con los grupos y los roles, CoS se basa en las entradas de ayuda del directorio.
Los tres mecanismos disponibles son:
Classic CoS es el mecanismo recomendado para las clases de servicios de Messaging Server tal y como se describe en este apartado.
Puede obtener m�s informaci�n acerca de estos mecanismos avanzados de administraci�n de entradas en Sun ONE Directory Server 5.2 Administration Guide y en Sun ONE Directory Server 5.2 Reference Manual. Estos documentos se encuentran en el sitio Web de documentaci�n de Sun:
http://docs.sun.com/prod/s1dirsrv
CoS para Messaging Server
La funci�n CoS le permite crear un conjunto de funciones fijas y atributos con un nombre para aplicarlo a usuarios espec�ficos. Esta funci�n tambi�n hace posible crear una plantilla de atributos que se puede conferir mediante entradas de usuario con un atributo sencillo. Por ejemplo, si usted es un proveedor de servicios de Internet, puede crear dos niveles de servicios de correo, llamados MS1 y MS2, de la siguiente forma:
- La clase de servicio MS1 puede proporcionar a los usuarios servicios de correo IMAP, Secure IMAP, POP3 y HTTP (correo Web), as� como 5 gigabytes de espacio en disco para almacenar mensajes.
- La clase de servicio MS2 puede proporcionar servicios de correo POP3 junto con 5 megabytes de espacio en disco para almacenar mensajes.
Nota
Las solicitudes de b�squeda LDAP que contengan un filtro que haga referencia a un atributo definido por una clase de servicio no se atender�n. Por ejemplo, no es posible realizar una b�squeda satisfactoria en el atributo mailquota si mailquota s�lo est� definido en una plantilla de clase de servicio y no en las entradas de usuario. El servidor mostrar� un mensaje de error sobre la imposibilidad de atender la petici�n.
Esta limitaci�n y otras m�s aparecen en Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10), tal y como se indic� anteriormente.
Definici�n de CoS en Messaging Server
El proceso de adici�n de clases de servicio lleva consigo las siguientes operaciones:
- Habilitaci�n del complemento de la clase de servicio
El complemento de clase de servicio (CoS) se instala autom�ticamente con Directory Server. Para activarlo y, en consecuencia, habilitar las clases de servicio, es necesario modificar el archivo de configuraci�n SLAPD.
Para obtener informaci�n acerca de c�mo configurar el complemento de clase de servicio, consulte Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10).
- Reinicio de Directory Server
- Creaci�n del contenedor de CoS para las plantillas y las definiciones de CoS
- Creaci�n de un esquema de correo de CoS en el contenedor de CoS
Cada entrada de esquema de correo contiene los siguientes elementos:
- DN de entrada de esquema de correo de CoS (con ou:CoS).
- Clase de objeto que define la entrada de esquema de clase de servicio (objectClass:cosClassicDefinition).
- Atributo con varios valores que contiene �rboles (nombres de directorios) donde se almacenen las entradas de la plantilla de CoS para este esquema (cosTemplateDN).
- Atributo con varios valores que contiene un �rbol al que se aplica el esquema de CoS (cosTargetTree).
- Nombre del atributo usado para especificar la plantilla de CoS aplicada a una entrada de usuario (cosSpecifier:inetCOS).
- Atributos que se deben usar en una entrada de plantilla (atributo cosAttribute con varios valores).
- Creaci�n de un contenedor para las plantillas de CoS
- Creaci�n de las plantillas de CoS
- Asignaci�n de una clase de servicio a las entradas de usuario
Para crear una clase de servicio: ejemplo
En este ejemplo se considera que el complemento de CoS ya est� instalado y configurado y que Directory Server se est� ejecutando. Este ejemplo muestra la forma de crear un servicio de correo para dos clases de servicio, MS1 y MS2, en el dominio alojado sesta.com. Las dos clases de servicio tienen los siguientes objetivos:
- La clase de servicio MS1 proporcionar� a los usuarios servicios de correo IMAP, Secure IMAP, POP3 y HTTP (correo Web), as� como 5 gigabytes de espacio en disco para almacenar mensajes.
- La clase de servicio MS2 proporciona servicios de correo POP3 junto con 5 megabytes de espacio en disco para almacenar mensajes.
- Cree el contenedor para los esquemas y plantillas de CoS.
Esta entrada define el contenedor como organizationalUnit (ou).
El siguiente ejemplo de c�digo muestra la entrada LDIF para crear el contenedor de CoS:
- Cree un esquema de correo de CoS mediante la entrada LDIF de ejemplo que aparece a continuaci�n:
- Cree el contenedor para las plantillas del esquema de correo.
Use el siguiente ejemplo LDIF para crear el contenedor:
dn: ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn
changetype: modify
add: organizationalunit
ou: MailSchemeClasses
- Cree las plantillas de CoS.
Use el siguiente ejemplo LDIF para crear las dos entradas de plantilla para las plantillas MS1 y MS2.
dn: cn=MS2,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn
objectClass: top
objectClass: costemplate
objectClass: extensibleobject
objectClass: ldapsubentry
mailQuota: 5000000
mailAllowedServiceAccess +pop3:*
dn: cn=MS1,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn
objectClass: top
objectClass: costemplate
objectClass: extensibleobject
objectClass: ldapsubentry
mailQuota: 5000000000
mailAllowedServiceAccess +imap, imaps, pop3, http:*
- Agregue una clase de servicio a una entrada de usuario.
