Highlighted
Outstanding Contributor.
Outstanding Contributor.
1266 views

Catching Illegal UPN Value in AD Driver

I have a pretty much out-of-the-box AD driver setup using Email address mapping for UPN. So the email address in the vault is used for the UPN value in AD. The default UserMap ruleset is being used to handle setting of the UPN. So it writes the mail attribute into the source DirXML-ADAliasName and destination DirXML-ADAliasName (which maps to the UPN) at the same time. This all works fine, as designed out of the box.

But what I want to do is catch an error if someone uses a domain that is not valid in AD. This site has 60+ valid domains in AD. So I thought I could just catch the status error coming back in the input transform and send an email alert. However, this driver seems to work different. If the UPN value is is not valid, I get a 9010 error immediately following the source write to DirXML-ADAliasName. So there is no chance to catch this status error anywhere that I can see. I don't quite understand how that is failing so fast actually and the "bad" value does get stored in DirXML-ADAliasName in eDir.

Here is the error:

[12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
[12/04/18 13:07:19.530]:AD-DRVR=> ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.7.1.1">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
<modify-attr attr-name="DirXML-ADAliasName">
<remove-all-values/>
<add-value>
<value>000Test.User1204@abaddomain.com</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
[12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
[12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
[12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
[12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
[12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
[12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
[12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
[12/04/18 13:07:19.544]:AD-DRVR=> ST:
DirXML Log Event -------------------
Driver: \ID-VAULT\system\driverset1\AD-DRVR
Channel: Subscriber
Object: \ID-VAULT\data\users\000TestUser1204
Status: Error
Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE
[12/04/18 13:07:19.546]:AD-DRVR=> ST: Direct command from policy result
[12/04/18 13:07:19.547]:AD-DRVR=> ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.7.1.1">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" level="error">Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
<module>AD-DRVR</module>
<object-dn>\ID-VAULT\data\users\000TestUser1204</object-dn>
<component>Subscriber</component>
</status>
</output>
</nds>



Any ideas how I can catch that happening? Thanks.

Matt
Labels (1)
0 Likes
18 Replies
Highlighted
Knowledge Partner
Knowledge Partner

On 12/4/2018 5:04 PM, matt wrote:
>
> I have a pretty much out-of-the-box AD driver setup using Email address
> mapping for UPN. So the email address in the vault is used for the UPN
> value in AD. The default UserMap ruleset is being used to handle
> setting of the UPN. So it writes the mail attribute into the source
> DirXML-ADAliasName and destination DirXML-ADAliasName (which maps to the
> UPN) at the same time. This all works fine, as designed out of the box.
>
>
> But what I want to do is catch an error if someone uses a domain that is
> not valid in AD. This site has 60+ valid domains in AD. So I thought I
> could just catch the status error coming back in the input transform and
> send an email alert. However, this driver seems to work different. If
> the UPN value is is not valid, I get a 9010 error immediately following
> the source write to DirXML-ADAliasName. So there is no chance to catch
> this status error anywhere that I can see. I don't quite understand how
> that is failing so fast actually and the "bad" value does get stored in
> DirXML-ADAliasName in eDir.


I was discussing this with someone recently and had remarked that UPN is
a weird attribute since the validation was done in ADUC, and you could
write any crap you wanted to the attribute. My colleague disagreed. I
noted I knew this in older AD's and a few years back I had validate
dthis fact. (Alas as I think of it, it could have been almost 10 years
ago now. Where has the time flown?)

Anyway, that makes me think they 'fixed' it in AD.

So the DirXMl-ADALiasName is a write back to source, before the event is
finished sending to AD so that makes sense.

You should find the place setting it, and then do something like:

XPATH substring-after($VALUE,"@") (or split on @ (maybe escape it as \@)
and take the second value. Both would work to get it into a variable.

Then store all your values in a mapping table. Really only need one
column on these allowed values but maybe have a second column that
returns "valid" and then maybe as you get ready to phase areas out you
can change it to "deprecated" and maybe warn when one of these comes in?

Anyway, use the Map token, as something wildly silly like this:

<do-set-local-variable name="VALUE" scope="policy">
<arg-node-set>
<token-split delimiter="\@">
<token-op-attr name="DirXML-ADAliasName"/>
</token-split>
</arg-node-set>
</do-set-local-variable>
<do-set-local-variable name="VALUE" scope="policy">
<arg-string>
<token-xpath expression="$VALUE[1]"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="ALLOWED" scope="policy">
<arg-string>
<token-map default-value="false" dest="valid" src="token-text"
table="some\table\location">
<token-text xml:space="preserve">upn</token-text>
<token-local-variable name="VALUE"/>
</token-map>
</arg-string>
</do-set-local-variable>

Key point being, Default value, if the SPN (UPN after the @) is not
found, you get false. and then test if false to do something, else let
it through.



> Here is the error:
>
> Code:
> --------------------
>
> [12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
> [12/04/18 13:07:19.530]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <input>
> <modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
> <modify-attr attr-name="DirXML-ADAliasName">
> <remove-all-values/>
> <add-value>
> <value>000Test.User1204@abaddomain.com</value>
> </add-value>
> </modify-attr>
> </modify>
> </input>
> </nds>
> [12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
> [12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
> [12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
> [12/04/18 13:07:19.544]:AD-DRVR=> ST:
> DirXML Log Event -------------------
> Driver: \ID-VAULT\system\driverset1\AD-DRVR
> Channel: Subscriber
> Object: \ID-VAULT\data\users\000TestUser1204
> Status: Error
> Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE
> [12/04/18 13:07:19.546]:AD-DRVR=> ST: Direct command from policy result
> [12/04/18 13:07:19.547]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <output>
> <status event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" level="error">Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
> <module>AD-DRVR</module>
> <object-dn>\ID-VAULT\data\users\000TestUser1204</object-dn>
> <component>Subscriber</component>
> </status>
> </output>
> </nds>
>
> --------------------
>
>
> Thanks.
>
> Matt
>
>


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

You right (like usual) 🙂
By schema definition, UPN just simple string. You can push to this attribute any string value.
MMC has own validation/generation logic for some attributes.

This attribute contains the UPN that is an Internet-style login name for a user based on the Internet standard RFC 822. The UPN is shorter than the distinguished name and easier to remember. By convention, this should map to the user email name. The value set for this attribute is equal to the length of the user's ID and the domain name. For more information about this attribute, see User Naming Attributes.

CN User-Principal-Name
Ldap-Display-Name userPrincipalName
Size -
Update Privilege Domain administrator or account owner.
Update Frequency In theory this should never change.
Attribute-Id 1.2.840.113556.1.4.656
System-Id-Guid 28630ebb-41d5-11d1-a9c1-0000f80367c1
Syntax String(Unicode)
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Matt,
Your trace example is not really related to AD.
Your trace shows, that you have issue, when you trying to update DirXML-ADAliasName attribute in eDirectory object \ID-VAULT\data\users\000TestUser1204, but this policy from Subscriber channel.

[12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
[12/04/18 13:07:19.530]:AD-DRVR=> ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.7.1.1">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
<modify-attr attr-name="DirXML-ADAliasName">
<remove-all-values/>
<add-value>
<value>000Test.User1204@abaddomain.com</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
[12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
[12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
[12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
[12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
[12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
[12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
[12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
[12/04/18 13:07:19.544]:AD-DRVR=> ST:
DirXML Log Event -------------------
Driver: \ID-VAULT\system\driverset1\AD-DRVR
Channel: Subscriber
Object: \ID-VAULT\data\users\000TestUser1204
Status: Error
Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE
[12/04/18 13:07:19.546]:AD-DRVR=> ST: Direct command from policy result
[12/04/18 13:07:19.547]:AD-DRVR=> ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.7.1.1">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" level="error">Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
<module>AD-DRVR</module>
<object-dn>\ID-VAULT\data\users\000TestUser1204</object-dn>
<component>Subscriber</component>
</status>
</output>
</nds>


Could you provide "full" trace for this policy? (starting from doc before this policy till this error message)
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 12/4/2018 5:42 PM, Geoffrey Carman wrote:
> On 12/4/2018 5:04 PM, matt wrote:
>>
>> I have a pretty much out-of-the-box AD driver setup using Email address
>> mapping for UPN.  So the email address in the vault is used for the UPN
>> value in AD.  The default UserMap ruleset is being used to handle
>> setting of the UPN.  So it writes the mail attribute into the source
>> DirXML-ADAliasName and destination DirXML-ADAliasName (which maps to the
>> UPN) at the same time.  This all works fine, as designed out of the box.
>>
>>
>> But what I want to do is catch an error if someone uses a domain that is
>> not valid in AD.  This site has 60+ valid domains in AD.  So I thought I
>> could just catch the status error coming back in the input transform and
>> send an email alert.  However, this driver seems to work different.  If
>> the UPN value is is not valid, I get a 9010 error immediately following
>> the source write to DirXML-ADAliasName.  So there is no chance to catch
>> this status error anywhere that I can see.  I don't quite understand how
>> that is failing so fast actually and the "bad" value does get stored in
>> DirXML-ADAliasName in eDir.

>
> I was discussing this with someone recently and had remarked that UPN is
> a weird attribute since the validation was done in ADUC, and you could
> write any crap you wanted to the attribute. My colleague disagreed. I
> noted I knew this in older AD's and a few years back I had validate
> dthis fact. (Alas as I think of it, it could have been almost 10 years
> ago now. Where has the time flown?)
>
> Anyway, that makes me think they 'fixed' it in AD.
>
> So the DirXMl-ADALiasName is a write back to source, before the event is
> finished sending to AD so that makes sense.
>
> You should find the place setting it, and then do something like:
>
> XPATH substring-after($VALUE,"@") (or split on @ (maybe escape it as \@)
> and take the second value. Both would work to get it into a variable.
>
> Then store all your values in a mapping table. Really only need one
> column on these allowed values but maybe have a second column that
> returns "valid" and then maybe as you get ready to phase areas out you
> can change it to "deprecated" and maybe warn when one of these comes in?
>
> Anyway, use the Map token, as something wildly silly like this:
>
>             <do-set-local-variable name="VALUE" scope="policy">
>                 <arg-node-set>
>                     <token-split delimiter="\@">
>                         <token-op-attr name="DirXML-ADAliasName"/>
>                     </token-split>
>                 </arg-node-set>
>             </do-set-local-variable>
>             <do-set-local-variable name="VALUE" scope="policy">
>                 <arg-string>
>                     <token-xpath expression="$VALUE[1]"/>
>                 </arg-string>
>             </do-set-local-variable>
>             <do-set-local-variable name="ALLOWED" scope="policy">
>                 <arg-string>
>                     <token-map default-value="false" dest="valid"
> src="token-text" table="some\table\location">
>                         <token-text xml:space="preserve">upn</token-text>
>                         <token-local-variable name="VALUE"/>
>                     </token-map>
>                 </arg-string>
>             </do-set-local-variable>
>
> Key point being, Default value, if the SPN (UPN after the @) is not
> found, you get false. and then test if false to do something, else let
> it through.
>
>
>
>> Here is the error:
>>
>> Code:
>> --------------------
>>    [12/04/18 13:07:19.530]:AD-DRVR=> ST:  Direct command from policy
>>    [12/04/18 13:07:19.530]:AD-DRVR=> ST:
>>    <nds dtdversion="4.0" ndsversion="8.x">
>>    <source>
>>    <product edition="Standard" version="4.7.1.1">DirXML</product>
>>    <contact>NetIQ Corporation</contact>
>>    </source>
>>    <input>
>>    <modify class-name="User"
>> dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094"
>> event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8"
>> src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
>>    <modify-attr attr-name="DirXML-ADAliasName">
>>    <remove-all-values/>
>>    <add-value>
>>    <value>000Test.User1204@abaddomain.com</value>
>>    </add-value>
>>    </modify-attr>
>>    </modify>
>>    </input>
>>    </nds>
>>    [12/04/18 13:07:19.535]:AD-DRVR=> ST:  Pumping XDS to eDirectory.
>>    [12/04/18 13:07:19.536]:AD-DRVR=> ST:  Performing operation modify
>> for \ID-VAULT\data\users\000TestUser1204.
>>    [12/04/18 13:07:19.537]:AD-DRVR=> ST:  --JCLNT--
>> \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context =
>> 224723117, tempContext = 224723179
>>    [12/04/18 13:07:19.540]:AD-DRVR=> ST:  Modifying entry
>> \ID-VAULT\data\users\000TestUser1204.
>>    [12/04/18 13:07:19.541]:AD-DRVR=> ST:  --JCLNT--
>> \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext =
>> 224723179
>>    [12/04/18 13:07:19.543]:AD-DRVR=> ST:  Processing returned document.
>>    [12/04/18 13:07:19.543]:AD-DRVR=> ST:  Processing operation
>> <status> for .
>>    [12/04/18 13:07:19.544]:AD-DRVR=> ST:
>>    DirXML Log Event -------------------
>>    Driver:   \ID-VAULT\system\driverset1\AD-DRVR
>>    Channel:  Subscriber
>>    Object:   \ID-VAULT\data\users\000TestUser1204
>>    Status:   Error
>>    Message:  Code(-9010) An exception occurred:
>> novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE
>>    [12/04/18 13:07:19.546]:AD-DRVR=> ST:  Direct command from policy
>> result
>>    [12/04/18 13:07:19.547]:AD-DRVR=> ST:
>>    <nds dtdversion="4.0" ndsversion="8.x">
>>    <source>
>>    <product edition="Standard" version="4.7.1.1">DirXML</product>
>>    <contact>NetIQ Corporation</contact>
>>    </source>
>>    <output>
>>    <status
>> event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8"
>> level="error">Code(-9010) An exception occurred:
>> novell.jclient.JCException: modifyEntry -608
>> ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
>>    <module>AD-DRVR</module>
>>    <object-dn>\ID-VAULT\data\users\000TestUser1204</object-dn>
>>    <component>Subscriber</component>
>>    </status>
>>    </output>
>>    </nds>


Oops, I did not really read the trace, I quickly read the message. My
answer is completely irrelevant to the actual error.


0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

geoffc;2491910 wrote:
On 12/4/2018 5:04 PM, matt wrote:
>
> I have a pretty much out-of-the-box AD driver setup using Email address
> mapping for UPN. So the email address in the vault is used for the UPN
> value in AD. The default UserMap ruleset is being used to handle
> setting of the UPN. So it writes the mail attribute into the source
> DirXML-ADAliasName and destination DirXML-ADAliasName (which maps to the
> UPN) at the same time. This all works fine, as designed out of the box.
>
>
> But what I want to do is catch an error if someone uses a domain that is
> not valid in AD. This site has 60+ valid domains in AD. So I thought I
> could just catch the status error coming back in the input transform and
> send an email alert. However, this driver seems to work different. If
> the UPN value is is not valid, I get a 9010 error immediately following
> the source write to DirXML-ADAliasName. So there is no chance to catch
> this status error anywhere that I can see. I don't quite understand how
> that is failing so fast actually and the "bad" value does get stored in
> DirXML-ADAliasName in eDir.


I was discussing this with someone recently and had remarked that UPN is
a weird attribute since the validation was done in ADUC, and you could
write any **** you wanted to the attribute. My colleague disagreed. I
noted I knew this in older AD's and a few years back I had validate
dthis fact. (Alas as I think of it, it could have been almost 10 years
ago now. Where has the time flown?)

Anyway, that makes me think they 'fixed' it in AD.

So the DirXMl-ADALiasName is a write back to source, before the event is
finished sending to AD so that makes sense.

You should find the place setting it, and then do something like:

XPATH substring-after($VALUE,"@") (or split on @ (maybe escape it as \@)
and take the second value. Both would work to get it into a variable.

Then store all your values in a mapping table. Really only need one
column on these allowed values but maybe have a second column that
returns "valid" and then maybe as you get ready to phase areas out you
can change it to "deprecated" and maybe warn when one of these comes in?

Anyway, use the Map token, as something wildly silly like this:

<do-set-local-variable name="VALUE" scope="policy">
<arg-node-set>
<token-split delimiter="\@">
<token-op-attr name="DirXML-ADAliasName"/>
</token-split>
</arg-node-set>
</do-set-local-variable>
<do-set-local-variable name="VALUE" scope="policy">
<arg-string>
<token-xpath expression="$VALUE[1]"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="ALLOWED" scope="policy">
<arg-string>
<token-map default-value="false" dest="valid" src="token-text"
table="some\table\location">
<token-text xml:space="preserve">upn</token-text>
<token-local-variable name="VALUE"/>
</token-map>
</arg-string>
</do-set-local-variable>

Key point being, Default value, if the SPN (UPN after the @) is not
found, you get false. and then test if false to do something, else let
it through.



> Here is the error:
>
> Code:
> --------------------
>
> [12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
> [12/04/18 13:07:19.530]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <input>
> <modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
> <modify-attr attr-name="DirXML-ADAliasName">
> <remove-all-values/>
> <add-value>
> <value>000Test.User1204@abaddomain.com</value>
> </add-value>
> </modify-attr>
> </modify>
> </input>
> </nds>
> [12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
> [12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
> [12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
> [12/04/18 13:07:19.544]:AD-DRVR=> ST:
> DirXML Log Event -------------------
> Driver: \ID-VAULT\system\driverset1\AD-DRVR
> Channel: Subscriber
> Object: \ID-VAULT\data\users\000TestUser1204
> Status: Error
> Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE
> [12/04/18 13:07:19.546]:AD-DRVR=> ST: Direct command from policy result
> [12/04/18 13:07:19.547]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <output>
> <status event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" level="error">Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
> <module>AD-DRVR</module>
> <object-dn>\ID-VAULT\data\users\000TestUser1204</object-dn>
> <component>Subscriber</component>
> </status>
> </output>
> </nds>
>
> --------------------
>
>
> Thanks.
>
> Matt
>
>


Sorry for the delay, just getting back to this issue now.

So this is actually kinda what I used to do in the customer's old AD driver. I had a Global Configuration Variable with all 64 valid domain names and then I would do a for loop and step through each one to make sure I found a match. If I did not, I'd veto the event and send an email warning. Your method using the mapping table is a bit cleaner I think than what I was doing with a GCV, so I may go that route instead.

Thanks!

Matt
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

> Sorry for the delay, just getting back to this issue now.
>
> So this is actually kinda what I used to do in the customer's old AD
> driver. I had a Global Configuration Variable with all 64 valid domain
> names and then I would do a for loop and step through each one to make
> sure I found a match. If I did not, I'd veto the event and send an email
> warning. Your method using the mapping table is a bit cleaner I think
> than what I was doing with a GCV, so I may go that route instead.


If you had a list GCV then you could have assigned it to a Nodeset
variable (make it driver scoped so you only do it once) and then if
local variable ThisValue is equal $GCVVarabile$

it would have done it in one test.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 12/04/2018 03:04 PM, matt wrote:
>
> But what I want to do is catch an error if someone uses a domain that is
> not valid in AD. This site has 60+ valid domains in AD. So I thought I
> could just catch the status error coming back in the input transform and
> send an email alert. However, this driver seems to work different. If
> the UPN value is is not valid, I get a 9010 error immediately following
> the source write to DirXML-ADAliasName. So there is no chance to catch
> this status error anywhere that I can see. I don't quite understand how
> that is failing so fast actually and the "bad" value does get stored in
> DirXML-ADAliasName in eDir.


Just to be clear, there is no way for eDirectory to know the value is
illegal. The reason for the error below is because the object in
eDirectory getting this attribute is not allowed to have this attribute at
all, meaning it probably does not have the auxiliary class that adds the
ability to have these IDM attributes. I think that aux class is
'DirXML-ApplicationAttrs' or something like that, and normally it is
written by default when you try to add this.

I am guessing either you added a new policy, or your direct write is
skipping the auto-aux-class-adder, or maybe something else is amiss. As a
quick workaround, find the rule doing this write and have it also write
back an addition of 'Object Class' (attribute) with value
'DirXML-ApplicationAttrs' (assuming that's the one I thin it is; verify it
has the DirXML-ADAliasName attribute as one of its optionals), and then
computer/push/restart.

> Here is the error:
>
> Code:
> --------------------
>
> [12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
> [12/04/18 13:07:19.530]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <input>
> <modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
> <modify-attr attr-name="DirXML-ADAliasName">
> <remove-all-values/>
> <add-value>
> <value>000Test.User1204@abaddomain.com</value>
> </add-value>
> </modify-attr>
> </modify>
> </input>
> </nds>
> [12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
> [12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
> [12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
> [12/04/18 13:07:19.544]:AD-DRVR=> ST:
> DirXML Log Event -------------------
> Driver: \ID-VAULT\system\driverset1\AD-DRVR
> Channel: Subscriber
> Object: \ID-VAULT\data\users\000TestUser1204
> Status: Error
> Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE


-608 is clear; you are trying to add an attribute that is illegal, meaning
not allowed on this object per schema rule. Once you add the aux class,
that problem will go away. This is normally done by default as part of
the driver config, so it may be useful to see what is different when this
works.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Highlighted
Outstanding Contributor.
Outstanding Contributor.

ab;2491947 wrote:
On 12/04/2018 03:04 PM, matt wrote:
>
> But what I want to do is catch an error if someone uses a domain that is
> not valid in AD. This site has 60+ valid domains in AD. So I thought I
> could just catch the status error coming back in the input transform and
> send an email alert. However, this driver seems to work different. If
> the UPN value is is not valid, I get a 9010 error immediately following
> the source write to DirXML-ADAliasName. So there is no chance to catch
> this status error anywhere that I can see. I don't quite understand how
> that is failing so fast actually and the "bad" value does get stored in
> DirXML-ADAliasName in eDir.


Just to be clear, there is no way for eDirectory to know the value is
illegal. The reason for the error below is because the object in
eDirectory getting this attribute is not allowed to have this attribute at
all, meaning it probably does not have the auxiliary class that adds the
ability to have these IDM attributes. I think that aux class is
'DirXML-ApplicationAttrs' or something like that, and normally it is
written by default when you try to add this.

I am guessing either you added a new policy, or your direct write is
skipping the auto-aux-class-adder, or maybe something else is amiss. As a
quick workaround, find the rule doing this write and have it also write
back an addition of 'Object Class' (attribute) with value
'DirXML-ApplicationAttrs' (assuming that's the one I thin it is; verify it
has the DirXML-ADAliasName attribute as one of its optionals), and then
computer/push/restart.

> Here is the error:
>
> Code:
> --------------------
>
> [12/04/18 13:07:19.530]:AD-DRVR=> ST: Direct command from policy
> [12/04/18 13:07:19.530]:AD-DRVR=> ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.7.1.1">DirXML</product>
> <contact>NetIQ Corporation</contact>
> </source>
> <input>
> <modify class-name="User" dest-dn="\ID-VAULT\data\users\000TestUser1204" dest-entry-id="37094" event-id="lclsidv01#20181204210718#1#2:7fc757f7-e805-46c1-a193-f757c77f05e8" src-dn="cn=000TestUser1204,ou=a,ou=Sites,dc=acme,dc=ad">
> <modify-attr attr-name="DirXML-ADAliasName">
> <remove-all-values/>
> <add-value>
> <value>000Test.User1204@abaddomain.com</value>
> </add-value>
> </modify-attr>
> </modify>
> </input>
> </nds>
> [12/04/18 13:07:19.535]:AD-DRVR=> ST: Pumping XDS to eDirectory.
> [12/04/18 13:07:19.536]:AD-DRVR=> ST: Performing operation modify for \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.537]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Duplicating : context = 224723117, tempContext = 224723179
> [12/04/18 13:07:19.540]:AD-DRVR=> ST: Modifying entry \ID-VAULT\data\users\000TestUser1204.
> [12/04/18 13:07:19.541]:AD-DRVR=> ST: --JCLNT-- \ID-VAULT\system\driverset1\AD-AD-DRVR : Calling free on tempContext = 224723179
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing returned document.
> [12/04/18 13:07:19.543]:AD-DRVR=> ST: Processing operation <status> for .
> [12/04/18 13:07:19.544]:AD-DRVR=> ST:
> DirXML Log Event -------------------
> Driver: \ID-VAULT\system\driverset1\AD-DRVR
> Channel: Subscriber
> Object: \ID-VAULT\data\users\000TestUser1204
> Status: Error
> Message: Code(-9010) An exception occurred: novell.jclient.JCException: modifyEntry -608 ERR_ILLEGAL_ATTRIBUTE


-608 is clear; you are trying to add an attribute that is illegal, meaning
not allowed on this object per schema rule. Once you add the aux class,
that problem will go away. This is normally done by default as part of
the driver config, so it may be useful to see what is different when this
works.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.



No, I don't think that is the issue. This works fine if I use a valid UPN domain. It only throws the error if I use an invalid/illegal domain. That is what I'm trying to catch, an invalid UPN value. I didn't want to have to maintain a second list of valid domain suffixes, but it appears I have to. I wish I could just read it out of AD and validate it that way. But it appears there is no way to do this?

Matt
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

matt;2493003 wrote:
No, I don't think that is the issue. This works fine if I use a valid UPN domain. It only throws the error if I use an invalid/illegal domain. That is what I'm trying to catch, an invalid UPN value. I didn't want to have to maintain a second list of valid domain suffixes, but it appears I have to. I wish I could just read it out of AD and validate it that way. But it appears there is no way to do this?

Matt


Something must have changed. At least my memory says that uPN is just a string, you can write anything you want to it. But it sounds like they're now validating the right hand side of the uPN.

This contains some clues:

https://blog.technotesdesk.com/how-to-list-upn-suffixes-of-an-active-directory-forest

So maybe do something akin to a "code map refresh". Use heartbeat, query once every so many hours, then use the results to build a mapping table object of "valid" values.
0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

dgersic;2493011 wrote:
Something must have changed. At least my memory says that uPN is just a string, you can write anything you want to it. But it sounds like they're now validating the right hand side of the uPN.

This contains some clues:

https://blog.technotesdesk.com/how-to-list-upn-suffixes-of-an-active-directory-forest

So maybe do something akin to a "code map refresh". Use heartbeat, query once every so many hours, then use the results to build a mapping table object of "valid" values.



I think you are right actually. I went back to working on this today and I did a mapping table like Geoff suggested and that worked fine. But I also noticed that I could indeed write any value I wanted into the UPN! I'm a little baffled because I know I was testing this back when I posted and I was getting an error when I used an invalid UPN suffix. Of course, you can't change it in ADUC to an invalid value. Sure as heck though it let me write anything I wanted via the IdM driver. So I a guess Aaron was right and what I was seeing was something else entirely. I'm still investigating because I know it wasn't letting me write invalid values in there at one point.

We'll have to decide how important it is to automate the domain suffix list versus just maintaining the mapping table. But based on that simple PowerShell command, it may not be that hard.

Matt
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

matt;2493012 wrote:
I think you are right actually. I went back to working on this today and I did a mapping table like Geoff suggested and that worked fine. But I also noticed that I could indeed write any value I wanted into the UPN! I'm a little baffled because I know I was testing this back when I posted and I was getting an error when I used an invalid UPN suffix. Of course, you can't change it in ADUC to an invalid value. Sure as heck though it let me write anything I wanted via the IdM driver. So I a guess Aaron was right and what I was seeing was something else entirely. I'm still investigating because I know it wasn't letting me write invalid values in there at one point.

We'll have to decide how important it is to automate the domain suffix list versus just maintaining the mapping table. But based on that simple PowerShell command, it may not be that hard.

Matt


Thinking about it, I'm not sure that you can do it with heartbeat. That'd be on the publisher, and I don't know if you can get a psexecute to work from a publisher policy. Might have to use a trigger job to kick it off instead. If you can get it to return anything. psexecute is kinda fire and forget. Maybe an LDAP query against the domain to get the same thing(s).

If you can post the output from that powershell script, I'd be curious to see what you get back.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.