Anonymous_User Absent Member.
Absent Member.
211 views

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
Labels (1)
0 Likes
4 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: IDM not creating AD user objects

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.
Anonymous_User Absent Member.
Absent Member.

Re: IDM not creating AD user objects

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: IDM not creating AD user objects

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.
Anonymous_User Absent Member.
Absent Member.

Re: IDM not creating AD user objects

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



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.