Those last three are not mandatory.

Groups are different than other types. If you do not have a pointer attribute (User->Group or Group->User) as part of your entitlement, then you do not need the member-xml tags as well.

So you can look at the Exchange entitlement in AD Ithink,since it needs a string, vs the Group example in AD.

You do have to have somewhere, where UA can do a code map refresh and load the possible entitlement values based on an LDAP query.

What I have done for super large AD's is actually sync the names/descriptions of all the groups in AD, as different objects, then intercept the CMR query in the OTP, make it return nothing fast (Usually use the driver ID query) and then in the ITP, I query the fake objects I had made, and clone the response into the CMR query response.  This is way faster than querying AD, and won't time out, usually. 

The other case was for 10 different types of data we pulled in via a CSV driver as objects, and we did the same redirect of CMR queries from the app (Which does not support querying these objects) and instead clone in the query against eDir.

Hi Geoffrey,

thanks for your answer! This sounds great, when it is coming to the group entitlement, but for now I am struggling to understand the correct configuration of the User Account Entitlement.

In it’s legacy format, the User Account Entitlement was valueless, which is making sense, since in most cases the status of the enactment will be sufficient to process it correctly.

But starting with IDM 4 the format of an entitlement value has changed, and the User Account Entitlement was defined with a value as well.

I am wondering, how the XML code in the entitlementConfiguration obcet has to be correctly setup, for a custom Account Entitlement. For example, I want to provide a (static) value, like the AD UserAccountEntitlemet does.

According to the DTD the elements parameters and account a mandatory - the other parameters might only be used if the entitlement query should be different from the one defined in the entitlement itself.

For my understanding, the other elements, control, which users might be selected, in case of an direct assignment - but this is far away from being well documented.

The Entitlement configuration for the AD driver uses the following parameter definition:

<parameters>

<parameter mandatory="true" name="ID" source="read-attr" source-name="ADDomainValue"/>

</parameters>

This might be working on an AD driver, but never on a custom, REST driver. Therefore, I am wondering if someone is able to tell me how the source and source-name attributes can be modified to provide something different but the domain name, received by an query through the AD driver?

To be 100% correct, the definition should contain an account element with account-id and account-status child elements. I belive, those are used only py CPRS, are they not?

<account>

<account-id source="read-attr" source-name="sAMAccountName"/>

<account-id source="read-attr" source-name="userPrincipalName"/>

<account-id source="src-dn"/>

<account-id source="association"/>

<account-status active="false" inactive="true" source="read-attr" source-name="dirxml-uACAccountDisable"/>

</account>

But again, I cannot find any useful information, how these elements should be configured for a custom application - I assume both elements define which attributes are used for login and account status in the connected system, but I am not 100% sure. If I am correct, those attributes could be defined directly in the namespace of the connected application, if there is no direct mapping to attributes in the vault.

Kind regards

Thorsten

Hi Thorsten,

If I remember correctly, this <accounts> stuff was first introduced for reporting purposes. First, for identity tracking (early on with Sentinel) and then reused by the identity reporting messaged system gateway driver (MSGD).

If configured correctly, MSGD would then inject an "account" query into the target system driver (e.g. AD), which would then return the queried objects and set the DirXML-Accounts attribute in the IDV. This stuff was never really documented. At least for DirXML accounts there is an old KB available:

https://support.microfocus.com/kb/doc.php?id=7005550

And the "accounts" would finally end up in the identity reporting warehosue, if everything was set up properly.

But, to be honest, I rarely saw an installation that had all this stuff set up and working properly, due to the high complexity and number of moving parts involved.

Best regards,
Philipp

The irony here is actually quite rich. Competing products in this space have an issue since they do not support an Account entitlement.  Which causes problems of reactivation that have to be fought.  (Ask me privately, not here). 

WHat the AD driver does is define a CMR query for ADDomain which comes back as the Driver ID query which is hard coded in the shim and fastest query/response pair there is.  It should only return a single value.  Every shim has to support the driver ID query, so your REST shim will work with this approach.

I know I wrote a bunch of articles picking this stuff apart but I am not sure which one has this specific issue in it.

So if you CMR returns a single value of ANYTHING really, then when you define the Account Entitlement to a Resource, you pick from the set of values (set of 1) and it is easy. Because an empty value is not really well supported, even though it used to be in legacy mode.

Thanks Geoffery for this hint! I will give it a tray and see, what kind of value will bereturned by the REST shim in case beeing asced to returen the addomainvaklue? Or did I goit you wrong?

According to the official DTD there are several options to be used in the entitlement configuration, but I did not find any deeper documentation on it.

Did you find out something regarding the different source values and how to use those.

In case of the default AD entitlement configuration source is set to "read-attr" and source-name to "ADDomainValue" and diue to the configuration of the query in the entitlement, this leads to an XDS query for the Class ADDomain, which is converted to the Driver-information as you wrote.

I guess this could be changed, to any attribute, if the query is defined correctly on the entitlement itself - IO will try this as well.

But in case we need really only one fixed/static value - in case of an account entitlement to provide at least on parameter - this is quite to complex in my eyes. Therefore, I was wondering, if there is a chance to haerd code a value for the ID parameter in the entitlement configuration by utilizing one of the other possible source values.

Kind regards

Thorsten