Finding the object that was just created?

I'm working in an environment where User object naming is deliberately
randomized. There is a loopback driver that takes any newly created User
object and renames it to a randomly generated string. So if I have a test
that creates a User, it doesn't matter that I specified cn=foo, it's
going to be renamed to something like cn=dk49s76X. Because.

So, how to then find out what user was created to do further testing?

The only things I've come up with so far are based on knowing something
about the created user. I can set Surname to "Test User" for example, and
probably assume that there won't be anybody else with that name. Or I
could find some un-used attribute like accessCardNumber and set it to
some special value, so that I can search for / find the User after
creation. I could probably even loop on this, waiting for the User I
created (cn=foo) to be renamed.

Any other good ideas for how to validate that the user was created
successfully, and get its object name, when the object name is not under
your control?


--
David Gersic
Knowledge Partner http://forums.microfocus.com
If you find this post helpful, please click on the star below.

Tags:

  • On 07/25/2016 02:15 PM, David Gersic wrote:
    > I'm working in an environment where User object naming is deliberately
    > randomized. There is a loopback driver that takes any newly created User
    > object and renames it to a randomly generated string. So if I have a test
    > that creates a User, it doesn't matter that I specified cn=foo, it's
    > going to be renamed to something like cn=dk49s76X. Because.


    This is always the reason, it seems.

    > The only things I've come up with so far are based on knowing something
    > about the created user. I can set Surname to "Test User" for example, and
    > probably assume that there won't be anybody else with that name. Or I
    > could find some un-used attribute like accessCardNumber and set it to
    > some special value, so that I can search for / find the User after
    > creation. I could probably even loop on this, waiting for the User I
    > created (cn=foo) to be renamed.


    Yup, that's probably where I'd play. Once upon a time I was using
    Validtor in a way that did not mirror the real environment because the
    real environment used the ID Provider to generate unique IDs when they
    came from the HR system. Since I did not have the ID Provider in
    Validator I was a little stuck, until I realized I could have Validator
    call a shell script which would then ask the ID Provider's network
    interface for a unique ID, and all of a sudden I was generating IDs in the
    exact same range as the HR driver's create process which I was simulating.
    That was very nice, and simple, since the JAR to make the ID Provider
    client work is part of IDM out of the box.

    This basically amounts to having some kind of unique ID set on create
    which can be used for searching later, from within Validator, prior to
    subsequent tests.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • On Mon, 25 Jul 2016 20:37:00 0000, ab wrote:

    > On 07/25/2016 02:15 PM, David Gersic wrote:
    >> I'm working in an environment where User object naming is deliberately
    >> randomized. There is a loopback driver that takes any newly created
    >> User object and renames it to a randomly generated string. So if I have
    >> a test that creates a User, it doesn't matter that I specified cn=foo,
    >> it's going to be renamed to something like cn=dk49s76X. Because.

    >
    > This is always the reason, it seems.


    Yep. It's not up to me, it's how things work. It's one of many possible
    solutions to the problem of having to name things. It solves some
    problems, and causes others. But, it is what it is, and it's not going to
    change.


    >> The only things I've come up with so far are based on knowing something
    >> about the created user. I can set Surname to "Test User" for example,
    >> and probably assume that there won't be anybody else with that name. Or
    >> I could find some un-used attribute like accessCardNumber and set it to
    >> some special value, so that I can search for / find the User after
    >> creation. I could probably even loop on this, waiting for the User I
    >> created (cn=foo) to be renamed.

    >
    > Yup, that's probably where I'd play.


    Tested this idea, and it does work. I'm not sure if I like it or not, but
    I can't see a better way to handle the situation.


    > Once upon a time I was using
    > Validtor in a way that did not mirror the real environment because the
    > real environment used the ID Provider to generate unique IDs when they
    > came from the HR system. Since I did not have the ID Provider in
    > Validator I was a little stuck, until I realized I could have Validator
    > call a shell script which would then ask the ID Provider's network
    > interface for a unique ID, and all of a sudden I was generating IDs in
    > the exact same range as the HR driver's create process which I was
    > simulating.
    > That was very nice, and simple, since the JAR to make the ID Provider
    > client work is part of IDM out of the box.


    That's cool. I'll keep that in mind too.


    --
    David Gersic
    Knowledge Partner http://forums.microfocus.com
    If you find this post helpful, please click on the star below.
  • Hi David,
    I believe that you will be able to use "complex" LDAP filter from Surname and create/modify timestamp.
    It will allow to get right object DN even you have non-unique Surname.
  • On Tue, 26 Jul 2016 18:26:02 0000, al b wrote:

    > Hi David,
    > I believe that you will be able to use "complex" LDAP filter from
    > Surname and create/modify timestamp.
    > It will allow to get right object DN even you have non-unique Surname.


    Hm. Can you elaborate on this?

    --
    David Gersic
    Knowledge Partner http://forums.microfocus.com
    If you find this post helpful, please click on the star below.