Cannot Use the ADMA to Convert a Contact Object to a User Object (318257)
The information in this article applies to:
- Microsoft Metadirectory Services 2.2 SP1
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
#in the users section of code add this attribute flow
$mv.employeetype = $cd.employeetype
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
#You need to set a flag for user or contact on the cs object on initial
#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:
# We will test to CS and MV value to see if this information has changed.
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.
Modification Type: | Minor | Last Reviewed: | 9/30/2005 |
---|
Keywords: | kbHotfixServer kbQFE kbenv kbprb kbui KB318257 |
---|
|