我是卡迁移对象类定义从OpenDS的到Active Directory。我已经成功迁移的部分的定义（可以读/写AD与我的Java应用程序） - 但现在我卡住了
I am stuck migrating object class definitions from OpenDS to Active Directory. I have already successfully migrated some definitions (and can read/write to AD with my Java application) - but now I'm stuck.
在我OpenDS的模式说明我有这样的事情：
In my OpenDS schema description I have something like this:
objectClasses: ( 1.3.6.1.4.1.99.2
NAME 'myNewClass'
SUP top STRUCTURAL
MUST ( myAttribute1 $ myAttribute2 $ myAttribute3 )
MAY someOtherAttribute
)
我翻译这这样的AD架构语法：
I translated this to the AD schema syntax like this:
# Class: myNewClass
dn: cn=myNewClass,cn=Schema,cn=Configuration,dc=X
changetype: add
objectClass: classSchema
governsID: 1.3.6.1.4.1.99.2
ldapDisplayName: myNewClass
adminDisplayName: myNewClass
objectClassCategory: 0
systemOnly: FALSE
# subclassOf: top
subclassOf: 2.5.6.0
# rdnAttId: myAttribute1
rdnAttId: 1.3.6.1.4.1.99.1
# mustContain: myAttribute2
mustContain: 1.3.6.1.4.1.99.2
# mustContain: myAttribute3
mustContain: 1.3.6.1.4.1.99.3
# mayContain: someOtherAttribute
mayContain: 1.3.6.1.4.1.99.4
# possSuperiors: organizationalUnit
possSuperiors: 2.5.6.5
# defaultObjectCategory: myNewClass
defaultObjectCategory: cn=myNewClass,cn=Schema,cn=Configuration,dc=X
但是，当我尝试写的类的对象myNewClass我得到这个异常：
But when I try to write an object of class myNewClass I get this exception:
javax.naming.InvalidNameException: "myAttribute1=Read+myAttribute2=Allow+myAttribute3=cn=someResource": [LDAP: error code 34 - 0000208F: LdapErr: DSID-0C090715, comment: Error processing name, data 0, v1db1 ];
我认为问题是rdnAttId，这似乎是在AD中必要的（而不是在OpenDS的）。我只能将它设置为一个值（所以我选择了myAttribute1），但它不应该是更像myAttribute1和myAttribute2和myAttribute3？
I assume the problem is rdnAttId, which seems to be essential in AD (and not in OpenDS). I can only set it to a single value (so I have chosen myAttribute1), but shouldn't it be more like myAttribute1 AND myAttribute2 AND myAttribute3?
做怎么办？
推荐答案
确定这里是一类建立一个LDIF的一个例子。你应该遵循我的意见。首先，你与微软Mananagement控制台创建它，那么你就使用LDIFDE.EXE，你清理你的LDIFDE，然后你可以将其导入在其他AD出口。
Ok here is an example of a LDIF with a class creation. You should have followed my advice. First you create it with Microsoft Mananagement Console, then you export it using LDIFDE.EXE, you clean your LDIFDE and then you are able to import it in an other AD.
dn: CN=SlxOeuvre,CN=Schema,CN=Configuration,DC=XXXX
changetype: add
objectClass: top
objectClass: classSchema
cn: SlxOeuvre
distinguishedName: CN=SlxOeuvre,CN=Schema,CN=Configuration,DC=XXXX
instanceType: 4
possSuperiors: organizationalUnit
subClassOf: top
governsID: 1.3.6.1.4.1.10558.2.2.1
mustContain: SlxTitre
mayContain: SlxChapitres
mayContain: SlxEditeur
mayContain: SlxGenre
mayContain: SlxLangue
mayContain: SlxPages
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: SlxOeuvre
objectClassCategory: 1
lDAPDisplayName: SlxOeuvre
name: SlxOeuvre
systemOnly: FALSE
在活动目录 rDNAttID 是使用以创建相对可分辨名称属性的名称。论观点的理论框架点，你可以选择你想要的。在实际操作来看我比 CN 。从来用户别的
In Active-Directory rDNAttID is the name of the attribute that is use to create the Relative Distinguished Name. On the theorical point of view you can choose the one you want. On the practical point of view I never user anything else than CN.
编辑：
在创建你的属性，是carreful重新加载你架构，以便让他们可以创建类。这里是换向器：
Once created your attributes, be carreful to reload you Schema in order to have them available to create the class. Here is the commutator :
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
编辑：
Edited :
随着DN是 CN = myNewClass，CN =架构，CN =配置，DC = X 必须添加CN到TNE属性DN： CN：myNewClass （t指定应该automaticaly添加）
As your DN is cn=myNewClass,cn=Schema,cn=Configuration,dc=X you MUST add CN to tne attributes dn: cn:myNewClass (thow it should be added automaticaly).
编辑： 据微软文档：
至于RDN而言有源指南模型和LDAP数据模型之间的对应关系如下。与它的属性和值的对象对应一个LDAP项，其属性和值。这种模式和LDAP同意的对象类属性的定义。 RDN的此模型中的定义是LDAP的定义的子集;在这个模型中，所有的RDN是有效的LDAP的RDN，而不是相反。例如，下面的多值的RDN是有效的LDAP RDN，但它不是有效的在该模型：CN =彼得休斯敦+ EMPLOYEEID = ABC123。鉴于RDN定义，在此模型中的DN的定义是一样的LDAP的定义。在LDAP数据模型中，父子关系是psented在孩子和家长的DN重$ P $，而在Active Directory中的数据模型中，父子关系重新psented父属性$ P $和的DN导出。 Active Directory不通过LDAP公开模型的父属性。
As far as RDN is concerned the correspondence between Active-Directory model and the LDAP data model is as follows. An object with its attributes and values corresponds to an LDAP entry with its attributes and values. This model and LDAP agree on the definition of the objectClass attribute. The definition of RDN in this model is a subset of LDAP's definition; all RDNs in this model are valid LDAP RDNs, but not vice versa. For example, the following multivalued RDN is a valid LDAP RDN, but it is not valid in this model: "cn=Peter Houston+employeeID=ABC123". Given the RDN definition, the definition of DN in this model is the same as LDAP's definition. In the LDAP data model, the child-parent relationship is represented in the DNs of the child and parent, whereas in the Active Directory data model, the child-parent relationship is represented in the parent attribute and the DN is derived. Active Directory does not expose the model's parent attribute through LDAP.
相关推荐
最新文章