Microsoft KB Archive/318257

= Cannot Use the ADMA to Convert a Contact Object to a User Object =

Article ID: 318257

Article Last Modified on 9/30/2005

-

APPLIES TO


 * Microsoft Metadirectory Services 2.2 Service Pack 1

-



This article was previously published under Q318257



SYMPTOMS
You may not be able to convert an object that you previously created as a contact object in the Active Directory to a user object.



CAUSE
This issue occurs because of an LDAP limitation. You cannot modify the object class once the object is created in an LDAP directory.



RESOLUTION
To resolve this issue, delete the contact object, and then create the user object in the Active Directory. You can do so by manually deleting the object in Active Directory, and then making sure that the msMMS-ManagedbyMA attribute is assigned to the metaverse object with the correct MA dn assignment. For additional information about the msMMS-ManagedByMA attribute, click the article number below to view the article in the Microsoft Knowledge Base:

285298 How to Use the MsMMS-ManagedByMa Attribute to Create Users in Active Directory



MORE INFORMATION
You may also be able to accomplish your goal in Microsoft Metadirectory Services (MMS) by using the following sample code. The feasibility of this design depends on your attributes and the ability to distinguish between objects that will be created as contact or user in the Active Directory starting from the Reflector MA, for example, an HR Type MA, CD and MA to the objects that currently reside in the Active Directory. Note that the following example is very simple, so the idea may or may not be adaptable to your environment.

Imp.st or the Metaverse Construction Template for the HR MA
$mv.employeetype = $cd.employeetype
 * 1) in the users section of code add this attribute flow

Advanced Attribute Flow in the HRMA (Populator MA)
If $cd.employeetype ! $mv.employeetype then $mv.employeetype = $cd.employeetype endif

If $mvp.employeetype = User then $mv.msmms-managedbyma = ma=ADMA,DsaName=mmssrv,ou=Applications,dc=microsoft,dc=com endif NOTE: If the Employeetype attribute is not (by default) in HRMA, you must synthesize this attribute value in the MA templates, or use another attribute as your trigger attribute from the HRMA Connected Directory.

In the Rep.st or New Connectors Template on the ADMA

 * 1) You need to set a flag for user or contact on the cs object on initial
 * 2) creation and set the Time to Live (TTL). Setting the TTL to 0 deletes the #object right way for users you may want to have a longer time period.

if $mv.employeetype = contact then $cs.employeetype = contact $cs.msmms-timetolive = 0 endif

if $mv.employeetype = User then $cs.employeetype = User $cs.msmms-timetolive = 2592000 endif Place in the advanced flow script in the ADMA: If $cs.employeetype = contact then If $mv.employeetype = User then #ensure that the msmms-managedbyma it this ADMA ma         If $mv.msmms-managedbyma = ($ma) then $disconnect_Specific($ma) endif endif endif After you run the ADMA to disconnect the object, it should automatically be deleted because of the TTL you set when the object with TAMA is built. On the next TAMA pass, the object is recreated and built with the appropriate object class in the ADMA. Because contact objects are not security principles, there is no loss from a Security Identifier (SID) and Access Control List (ACL) perspective.
 * 1) We will test to CS and MV value to see if this information has changed.

Additional query words: zoomit

Keywords: kbqfe kbenv kbui kbprb kbhotfixserver KB318257

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.