Please Read: Significant Update Planned, Migrating Forum Software This Month

See more
See less

AD schema extension issues

  • Filter
  • Time
  • Show
Clear All
new posts

  • AD schema extension issues

    hey all,

    I'm trying to synchronize our OpenLDAP user database to a Server 2008 AD. I
    wrote a Perl script to convert the LDAP schema definition to AD LDF and I've
    been able to import the samba and apple schemata into AD. However, when I try
    to import our own classes, I get errors of two types:

    The server side error is: 0x20c7 Schema update failed: class in subclassof
    list does not exist or does not satisfy hierarchy rules.
    The extended server error is:
    000020C7: SvcErr: DSID-03260339, problem 5003 (WILL_NOT_PERFORM), data 8391


    Add error on entry starting on line 22: Attribute Or Value Exists
    The server side error is: 0x2083 The specified value already exists.
    The extended server error is:
    00002083: AtrErr: DSID-03151699, :
    0: 00002083: DSID-03151699, problem 1006 (ATT_OR_VALUE_EXISTS), data
    0, Att 20019 (mayContain):len 4

    The first one seems to stem from the fact that I'm trying to derive our
    class dphysUser from posixUser. When I change the LDF to subClassOf: top,
    this error message disappears. I'd like to use posixUser though.
    The second message complains about one of the mayContain: fields, but I
    cannot figure out which one. By deleting all of them I can get the class to
    import. All attributes used in mayContain: do exist (I checked with adfind
    -sc sl:<attribute>) and I cannot figure out what AD's trying to tell me here.

    I'd appreciate if anyone could provide any hints. The error messages are not
    exactly self-explaining and I haven't found anything helpful in google.
    Thanks a lot in advance.

    below you can find the LDAP schema definition and the LDF created by my Perl


    objectclass ( NAME 'dphysUser'
    DESC 'D-PHYS User Base ObjectClass'
    SUP ( posixAccount $ shadowAccount ) AUXILIARY
    MUST ( uniqkey $ affiliation )
    MAY ( givenName $ affiliation $ mail $ legi $ lastUseMacWsTo $
    mailDrop $ lastUsePhdMailTo $ language $ pageStat $ ou $
    lastUsePasswordSuccess $ lastUsePasswordFailFrom $
    lastUsePasswordFailTo $ apple-user-homeurl $ authAuthority $
    expireDate ) )


    dn: CN=dphysUser,CN=schema,CN=configuration,DC=phys,DC =ethz,DC=ch
    changetype: ntdsSchemaAdd
    adminDisplayName: dphysUser
    cn: dphysUser
    defaultHidingValue: FALSE
    CN=dphysUser,CN=schema,CN=configuration,DC=phys,DC =ethz,DC=ch
    description: D-PHYS User Base ObjectClass
    lDAPDisplayName: dphysUser
    mustContain: uniqkey
    mustContain: affiliation
    mayContain: givenName
    mayContain: affiliation
    mayContain: authAuthority
    mayContain: expireDate
    CN=dphysUser,CN=schema,CN=configuration,DC=phys,DC =ethz,DC=ch
    CN=Class-Schema,CN=schema,CN=configuration,DC=phys,DC=ethz, DC=ch
    objectClass: classSchema
    objectClassCategory: 1
    name: dphysUser
    rDNAttID: cn
    schemaIDGUID:: gkKfhT+Qd0GzLfO2fmgBWQ==
    subClassOf: posixAccount
    subClassOf: shadowAccount

  • #2
    Re: AD schema extension issues

    posixAccount and shadowAccout are auxiliary classes, meaning that you can't instantiate an object of this type, but you can "enhance" another structural class.
    Instead of using subClassOf you need to use auxiliaryClass.

    May I ask why you need to do this ? Why would you need Samba schema extensions in AD ?
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"


    • #3
      Re: AD schema extension issues

      hey Guy,

      thanks a log for your answer. I was not aware of this difference as in 'normal' LDAP schema definitions SUP also works for auxiliary classes.

      I do not need the samba schema per se, but both the apple schema and our own extension depend on it. Basically our dphysUser class offers attributes for all 3 OS. The general idea is to replicate the OpenLDAP user data in the AD so that all users can use the Windows domain.

      You don't happen to know anything about the 'Attribute Or Value Exists' error message? Of course the mayContain attributes exist already, but why is LDIFDE complaining about it?

      thanks again,


      • #4
        Re: AD schema extension issues

        I suggest you setup a test lab and start modeling the schema there. Schema MMC will help you a bit.
        You LDF has some basic mistakes (trying to derive from aux class, mayContain gets attributes that are already inherited from some other class, usage of "ou" attribute for object whose RDN is not "OU", etc...). Trying to automate schema extension by importing it from non-AD system is not a wise idea - you'd better sit down and design the schema extensions the "AD way" taking into account the existing AD schema layout.
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"


        • #5
          Re: AD schema extension issues


          thanks again.
          I'm on a (virtual) test machine anyway, no worries here.
          Is this really what I have to do? I have to believe you on this (I'm a Linux head) but that's what I wanted to avoid since we modify our schema from time to time and it would have been very nice to incorporate these changes automatically. I'm a bit disappointed that LDAP is so incoherent across platforms.

          all right, schema design by hand it is then...



          • #6
            Re: AD schema extension issues

            I too had my fair share with Linux and OpenLDAP, but I do admit that I'm an MS head after all
            My point is this: AD is far from being only LDAP. It is leveraging LDAP extensively to provide other services (like Kerberos authentication, GPOs, DNS, etc...).
            With OpenLDAP you can whack your LDAP data, restore and resync the slaves (if you have any).
            If you whack the AD's schema, the implications are much wider - computers can not boot correctly, users can not logon, all your infrastructure MS services go down the hill.
            My advice: never automate schema extensions creation. Do it manually, thnk about each and every change (i.e.: how can you automate the decision whether to include some attribute in Partial Attribute Set ? How can you automate the allowed ranges of attribute values ? What will drive the decision to either statically linking an aux class to a structural object class or whether link the aux class dynamically to an existing object ?)

            I would also think twice before pushing all this data into AD. Do you really need it there ? What is the intended purpose of those extensions when introduced in AD ? Will there be applications to leverage it ? Can this be solved without touching schema ? What is the impact of the schema extensions and the data that will be added to AD on the size of the AD database and replication latency/bandwidth ?

            As you see there are quite a few questions to answer and I doubt that these decisions can be fully automated.
            Guy Teverovsky
            "Smith & Wesson - the original point and click interface"


            • #7
              Re: AD schema extension issues

              hey Guy,

              again thanks for your answer. I really appreciate your input as I'm new to the AD world.
              Perhaps I should explain better the motivation for my egregious intention: the aim is not to get all these values in there because we actually need them, but because getting the AD to the point at which it accepts our OpenLDAP data we could just use OpenLDAP's slurpd to replicate the data into the AD without any further conversion. I absolutely agree to your words of warning, but I'm also a bit astonished that the AD world seems to be a bit afraid of extending the schema - first thing you do with OpenLDAP. The dphysUser class mentioned in the original post is actually the last class I need to get in, all the rest seems to be working.
              Also, I was not talking about a completely automatic schema extension procedure, but my script should at least provide a solid foundation.
              I'm not too worried about the data actually disturbing AD as I do hope it can cope with 4000 users and about 50 attributes each...

              I have now eliminated all mayContain attributes that already show up in parent classes, but I must have missed one since it still spills this error.

              thanks for your help,


              • #8
                Re: AD schema extension issues


                It's not that AD world is afraid, it's just that AD world is very cautious about schema extensions. If you do it right, there is not reason to be afraid. I've done it multiple times and I am far from being the only one touching the schema. Alas, almost every upgrade of AD to the next OS version brings in schema extension.

                I suggest you do some reading about extending schema in AD environment ( covers quite a lot).
                The point is: usually extending AD schema has much more implications than extending OpenLDAP schema.

                As for the LDIF you are fighting with, try to create the schema extension using GUI (Schema MMC) and export the final result to LDIF - the GUI wil let you know when trying to perform illegal operation and is much more intuitive than plain LDIF file.
                Guy Teverovsky
                "Smith & Wesson - the original point and click interface"


                • #9
                  Re: AD schema extension issues

                  hey Guy,

                  thanks for your suggestions. I guess I do need a better understanding of AD specifics.
                  Somebody also proposed the following: point ADSchemaAnalyzer in base mode to the AD and in target mode to OpenLDAP and then have it create the LDF. I've played with this tool before and this might be an interesting idea.