Q&A: Rename Event for the IDM Notes Driver



By: pnuffer

May 16, 2008 9:52 am

Reads: 303

Comments:0

Rating:0

  • What constitutes a rename event in Notes?

    Full Name changing, sure. That is the main naming attribute inside the Notes addressbook.

    So on the Sub channel, need to watch for changes to Full Name, and if they happen, make sure to add the correct Cert-id and cert-id-password if you use more than one Cert. (If you only have one cert, then the driver uses the default and you never notice. It only gets complicated once you start using multiple certs.)

    What if just the First Name or Last Name change? Is that a rename, or a simple sync of an attribute?

    Most important to me though is, what if email address changes in the Vault, and the Sub channel sends it through. Is that a rename event?

    If so, does the shim handle the conversion to a rename or do I have to do it in policy? Conversely, what needs to be done if the email address is changing?

  • What about Shortname?

    The Notes Driver Shim will automatically attempt to perform an AdminP user rename operation by issuing an AdminP initiate rename request under the following circumstances:

    1. allow-adminp-support driver parameter is set to true, and/or the XML attribute allow-adminp-support=”true” exists within the modify element of the input document.
    2. The XDS document’s modify element also contains an adminp-rename-user=”true” XML attribute or contains child elements which modify the FirstName, MiddleInitial, or LastName of the Notes person document.

    Also (as you noted in your question), appropriate organizational (containment OU) certifier and certifier password must be provided for the rename to be successful. If cert-id and cert-pwd (or equivalents) attributes are not specified, then the default driver certifier will be utilized.

    If setting the XML attribute adminp-rename-user=”true” without providing appropriate at least one of the requisite user rename fields (data), then the AdminP user rename request will fail to be submitted.

    Appropriate User Rename data to include in the XDS document:

    1. FirstName
    2. MiddleInitial
    3. LastName
    4. Qualifiying OrgUnit
    5. Short Name
    6. Internet Address

    If provided, these above fields (with an appropriate certifier and certifier password) become parameters within the AdminP ‘Initiate Rename request’ generated by the NotesDriverShim.

    The following sample XDS document is an example of these attributes being submitted to the NotesDriverShim:

    ===BEGIN SAMPLE XDS DOC===
    <nds dtdversion="2.0" ndsversion="8.x">
    <source>
    <product version="3.0.0.2823">DirXML</product>
    <contact>Novell, Inc.</contact>
    </source>
    <input>
    <modify adminp-rename-user="true"
    allow-adminp-support="true"
    class-name="Person"
    drv-param-cert-id="mktg-cert-id-file"
    drv-param-cert-pwd="mktg-cert-id-password"
    event-id="SERVER-NDS#20051129190509#1#1"
    qualified-src-dn="O=DirXML\OU=Notes\OU=mktg\CN=WileCoyote"
    src-dn="\SERVER_TREE\DirXML\Notes\mktg\WileCoyote"
    src-entry-id="33029"
    tell-adminp-process="tell adminp process all"
    timestamp="1133291109#1">
    <association
    state="associated">E88C2874C38855A6872570C80068D8B3</association>
    <modify-attr attr-name="FirstName">
    <add-value>
    <value>Wile</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="MiddleInitial">
    <add-value>
    <value>E</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="LastName">
    <add-value>
    <value>Coyote</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="[OrgUnit]">
    <add-value>
    <value type="string">West</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="ShortName">
    <add-value>
    <value type="string">wcoyote</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="InternetAddress">
    <add-value>      
    <value>WileECoyote@dirxml.com</value>
    </add-value>
    </modify-attr>
    </modify>
    </input>
    </nds>
    ===END SAMPLE XDS DOC===
    
    

    If an XDS modify command contains child elements which update the FirstName, MiddleInitial, or LastName of the Notes person, but if it would be undesirable to issue an AdminP rename request, then the NotesDriverShim’s automatic generation of AdminP rename request can be disabled by inserting an adminp-rename-user=”false”; XML attribute into the modify element. Inserting allow-adminp-support=”false” XML attribute into the modify element would also have the same results. Insertion of these XDS document attributes can be done on a command by command basis to over-ride the default behavior of the driver.

    What is the [OrgUnit] attribute in the above document? This attribute is handled in a special way by the NotesDriverShim. It is interpreted as a qualifying organizational unit for a Notes user name. Setting this attribute is equivalent of inserting an extended-ou within the current command element (add or modify). Notes fields are not allowed to begin with the [ character. As such, attribute names enclosed in square brackets [] will not exists within a Notes database, and can be used in this way by the NotesDriverShim as special command attributes.

    More information about how this special field attribute is handled can be found in a CoolSolution here: ‘IDM Notes Driver and the Alternate Common Name | Novell User Communities’ (http://tinyurl.com/6q6j43)

  • What if email address changes in the Vault, and the Sub channel sends it through. Is that a rename event?
    No. By default the NotesDriverShim will not issue an AdminP initiate rename request due to a changing e-mail attribute. However, if you want an AdminP initiate rename request generated, you could do so via driver policy, as explained in the CoolSolution that was previously referenced.

  • What needs to be done if the email address is changing?
    In the general sense, this is a business solution that each Lotus Notes/Domino and IDM configuration will solve differently. However, with respect to generating an AdminP initiate rename request, a policy
    could be created within the subscriber to detect the changing (or new) e-mail address, and then insert a necessary ‘adminp-rename-user=”true”‘ attribute (and any other necessary attributes such allow-adminp-support, certifier and certifier password references.)

    1. Is the [OrgUnit] needed? I.e. Isn’t the org implicit in the dest-DN of the user in Notes? Also, I do not understand extended-OU which [OrgUnit] is the alternate too… If the user is /US/ACME in Notes, then their OU is /US/ACME. If the user is in /NY/US/ACME then you could not say their extended OU is in NY, but they are in /US/ACME, could you?
    2. Does a change of email address constitute a rename event from Notes’s perspective? (I see the code example how to do force it in policy, but is it neccasary? Same question for achange in Shortname.)

  • Isn’t the org implicit in the dest-DN of the user in Notes?
    Yes.

  • Is the [OrgUnit] needed?
    No. But it can be used by a Domino administrator to create a deeper naming hierarchy within a particular Notes certifier.

  • If the user is /US/ACME in Notes, then their OU is /US/ACME. If the user is in /NY/US/ACME then you could not say their extended OU is in NY, but they are in /US/ACME, could you?
    Yes, that’s the idea.

    More specifically, the FullName containment of the designated Notes certifier used for a Notes rename operation (or new person registration) cannot be avoided or changed (let’s say /OU=US/O=ACME for user Wile Coyote; FullName=’CN=Wile Coyote/OU=US/O=ACME’). However, for some Domino administrators, more (or extended) containers within a particular Notes certifier’s naming heirarchy are desired. These extended containers (certifier name extensions) can be specified when a Notes person is registered or renamed.

    Thus, using the above example, if the /OU=US/O=ACME container is used, and the new user is registered
    with an extended-ou ([OrgUnit]) of ‘NY’, then their full name would become CN=Wile Coyote/OU=NY/OU=US/O=ACME. If a middle initial (E.) is added to this user’s name, and a Notes rename operation occurred on this Notes person and the same certifier was specified, but a different extended-ou ([OrgUnit]) was specified, let’s say ‘Boston’, then the Notes rename operation would change the user’s Notes FullName to CN=Wile E. Coyote/OU=Boston/OU=US/O=ACME.

  • Does a change of email address constitute a rename event from Notes perspective? I see the code example how to force it in policy, but is it neccasary?
    No. However, depending on the configuration a particular Lotus Notes/Domino configuration and its e-mail dependencies, references, and usage of Notes Groups as distribution lists, a Domino administrator may
    have a need (or find it useful) to initiate an AdminP rename request (‘Lotus Domino Administrator 7 Help – Rename person’(http://tinyurl.com/6g6etp) ) when a user’s e-mail address changes.

  • Same question (as above) for a change in Shortname?
    No. However, some Domino administrators, depending on the configuration of their Notes/Domino system and the usage of the ShortName field within the Domino Directory, may have a need (or find it useful) to initiate an AdminP rename request ( ‘Lotus Domino Administrator 7 Help – Rename person’ (http://tinyurl.com/6g6etp) ) when a user’s ShortName field changes.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment