IDM not creating AD user objects

We have an IDM 4.6 system which automatically generates user accounts in
Active Directory. Just recently it has started failing to generate user
accounts in some cases. It is supposed to create a MAD account named
<firstname lastname> with a samAccountName corresponding to the CN in
the vault. All I see in the trace is "LDAP_INVALID_SYNTAX" but I'm
having trouble determining what attribute it's choking on. Level 3
trace is here: https://pastebin.com/SmHAwePa




Thanks
  • Wildly guessing you have accountExpires in there twice, once writing a
    nice big integer (maybe valid) and another time writing this (likely invalid):


    <add-attr attr-name="accountExpires">
    <value type="octet"/>
    </add-attr>


    Having both may not be terrible, but this one is probably a plague on your
    MAD house (redundant as that may be).

    I'm going to poke at this rule as a possible culprit, as it does not first
    verify the op-attr is even there before operating on it, with a reformat
    no less:


    [05/08/19 09:28:13.022]:AD-OSUMC ST: Evaluating selection
    criteria for rule 'accountExpires: Convert to Active Directory form'.
    [05/08/19 09:28:13.023]:AD-OSUMC ST: (if-op-attr
    'accountExpires' not-equal "9223372036854775807") = TRUE.
    [05/08/19 09:28:13.023]:AD-OSUMC ST: Rule selected.
    [05/08/19 09:28:13.023]:AD-OSUMC ST: Applying rule
    'accountExpires: Convert to Active Directory form'.
    [05/08/19 09:28:13.023]:AD-OSUMC ST: Action:
    do-reformat-op-attr("accountExpires",token-xpath("jadutil:translateEpoch2FileTime($current-value)")).


    --
    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.
  • On 5/8/2019 12:29, ab wrote:
    > Wildly guessing you have accountExpires in there twice, once writing a
    > nice big integer (maybe valid) and another time writing this (likely invalid):
    >

    The huge number is what Active Directory sees as "never": September 13,
    30828. I'll try to figure out what's writing the blank value.

    I still don't understand why this only affects a subset of new accounts,
    but we can add that to a long list.


    >
    > I'm going to poke at this rule as a possible culprit, as it does not first
    > verify the op-attr is even there before operating on it, with a reformat
    > no less:
    >
    >

    > [05/08/19 09:28:13.022]:AD-OSUMC ST: Evaluating selection
    > criteria for rule 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: (if-op-attr
    > 'accountExpires' not-equal "9223372036854775807") = TRUE.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Rule selected.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Applying rule
    > 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Action:
    > do-reformat-op-attr("accountExpires",token-xpath("jadutil:translateEpoch2FileTime($current-value)")).
    >

    >


    I will add a condition "if operation attribute 'accountExpires'
    available" and see if that helps things.

    Thanks
  • On 5/8/2019 12:29, ab wrote:
    > Wildly guessing you have accountExpires in there twice, once writing a
    > nice big integer (maybe valid) and another time writing this (likely invalid):
    >
    >

    > <add-attr attr-name="accountExpires">
    > <value type="octet"/>
    > </add-attr>
    >

    >
    > Having both may not be terrible, but this one is probably a plague on your
    > MAD house (redundant as that may be).
    >
    > I'm going to poke at this rule as a possible culprit, as it does not first
    > verify the op-attr is even there before operating on it, with a reformat
    > no less:
    >
    >

    > [05/08/19 09:28:13.022]:AD-OSUMC ST: Evaluating selection
    > criteria for rule 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: (if-op-attr
    > 'accountExpires' not-equal "9223372036854775807") = TRUE.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Rule selected.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Applying rule
    > 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Action:
    > do-reformat-op-attr("accountExpires",token-xpath("jadutil:translateEpoch2FileTime($current-value)")).
    >

    >


    I addressed that with a new condition "if operation attribute
    'accountExpires' available..." in the OTP rule. That wasn't the problem
    though -- or at least not the only problem. There was also a rule in the
    sub-CTP which set Login Expiration Time to <some attribute value>
    without first verifying that <some attribute value> actually exists and
    is non-null. Once I fixed that, things started behaving as expected.

    Thanks



  • 6423241;2499424 wrote:
    On 5/8/2019 12:29, ab wrote:
    > Wildly guessing you have accountExpires in there twice, once writing a
    > nice big integer (maybe valid) and another time writing this (likely invalid):
    >

    The huge number is what Active Directory sees as "never": September 13,
    30828. I'll try to figure out what's writing the blank value.

    I still don't understand why this only affects a subset of new accounts,
    but we can add that to a long list.


    >
    > I'm going to poke at this rule as a possible culprit, as it does not first
    > verify the op-attr is even there before operating on it, with a reformat
    > no less:
    >
    >

    > [05/08/19 09:28:13.022]:AD-OSUMC ST: Evaluating selection
    > criteria for rule 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: (if-op-attr
    > 'accountExpires' not-equal "9223372036854775807") = TRUE.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Rule selected.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Applying rule
    > 'accountExpires: Convert to Active Directory form'.
    > [05/08/19 09:28:13.023]:AD-OSUMC ST: Action:
    > do-reformat-op-attr("accountExpires",token-xpath("jadutil:translateEpoch2FileTime($current-value)")).
    >

    >


    I will add a condition "if operation attribute 'accountExpires'
    available" and see if that helps things.

    Thanks


    This number represents the largest possible value of an Int64

    public const long MaxValue = 9223372036854775807;
    The value of this constant is 9,223,372,036,854,775,807; that is, hexadecimal 0x7FFFFFFFFFFFFFFF.