Is it bug or feature, that %member% in version 2019.2 returns GUID instead of DN that it returned in previous version

Question

We were used to bind to group member object using: $member = $Context.BindToObjectByDN("%member%") which worked perfectly, but now it is not. Its because %member% is returning something like: <GUID=3a53f79a-c4e9-444e-9f45-40878ac0e601>

Is it bug or feature? And is it possible to get DN of added/removed member using another variable?

Answer 1

Hello,

Is it bug or feature?

This behavior is by design. To bind to a member being added/removed from a group, use the following code:

$member = $Context.BindToObject("Adaxes://%member%")

And is it possible to get DN of added/removed member using another variable?

Unfortunately, there is no such possibility using value references.

Comments

I disagree that %member% always returned GUID instead of DN. We have used %member% on several places and treat it like it returns DN and everyhing was working fine until we updated Adaxes to version 2020.1 (sorry for wrong version in title of this question).

On screenshots bellow you can see comparison of one powershell business rule script, that is used to check new members of AD group. You can clearly see, that when run in Adaxes console (2019.2 or 2020.1), %member% returns DN:

But when this rules is invoked in adaxes web, it returns GUID:

So to sum this up. Adaxes console is working correctly and returns DN, but in new version of web interface something changed, so it returns GUID now.

For me, this is clearly a bug..

---

Hello,

Sorry for the confusion, but we did not mean that the value reference always resolves into a distinguished name or GUID. It is by design that the value reference can resolve differently in different cases (it can also resolve into the SID) and that is why it is recommended to use the approach we specified in our previous post to bind to members being added/removed from groups.

---

OK thanks