Persist dynamic data through driver restarts

I have a SOAP driver that I wrote back in 2010 that I currently use for account creation in eDirectory from some internal applications. One of the account types it creates are service accounts and our naming convention is an alpha prefix with a 5 digit number that is incremented for each account created for the username. I have the below action using the unique name token to iterate through the existing accounts to find the first number that is not used. There definitely may be much better ways to do this but I wrote this as one of my first drivers so I am sure there are a lot of things in there that can be done better. :D

The problem I have with this solution is I use a GCV to contain the starting point to start incrementing from since we don't won't to reuse any accounts. Since it is a GCV, that means I have to manually update the value every so often and restart the driver so we don't end up reusing an account that was deleted. What I am wondering is if there is somewhere else I can store a counter that can be read/written to from policy that will not be lost on a driver restart. I see there is a DirXML-PersistentData attribute on the drivers that it appears the drivers read/write to so not sure if there is a way to read/write to that location in policy or if there is somewhere else better suited for this purpose. If there is somewhere that I could write to from policy then I could store the number in their so it will always have the last account number that was created and I wouldn't have to use the unique name token to loop through to find the next open number.

Thanks in advance.

<token-unique-name counter-digits="5" counter-pad="true" counter-pattern="first" counter-start="~XX-start-counter~" counter-use="always" name="uniqueID" on-unavailable="error" scope="subordinates">
<arg-dn>
<token-text xml:space="preserve">\</token-text>
<token-global-variable name="dirxml.auto.treename"/>
<token-text xml:space="preserve">\</token-text>
<token-map dest="RDN" src="Account_Type" table="..\..\Mapping Tables\Account Types Table">
<token-local-variable name="accounttype"/>
</token-map>
</arg-dn>
<arg-string>
<token-lower-case>
<token-local-variable name="accounttype"/>
</token-lower-case>
</arg-string>
</token-unique-name>
Parents
  • On 9/6/2018 3:04 PM, geistc wrote:
    >
    > I have a SOAP driver that I wrote back in 2010 that I currently use for
    > account creation in eDirectory from some internal applications. One of
    > the account types it creates are service accounts and our naming
    > convention is an alpha prefix with a 5 digit number that is incremented
    > for each account created for the username. I have the below action using
    > the unique name token to iterate through the existing accounts to find
    > the first number that is not used. There definitely may be much better
    > ways to do this but I wrote this as one of my first drivers so I am sure
    > there are a lot of things in there that can be done better. :D
    >
    > The problem I have with this solution is I use a GCV to contain the
    > starting point to start incrementing from since we don't won't to reuse
    > any accounts. Since it is a GCV, that means I have to manually update
    > the value every so often and restart the driver so we don't end up
    > reusing an account that was deleted. What I am wondering is if there is
    > somewhere else I can store a counter that can be read/written to from
    > policy that will not be lost on a driver restart. I see there is a
    > DirXML-PersistentData attribute on the drivers that it appears the
    > drivers read/write to so not sure if there is a way to read/write to
    > that location in policy or if there is somewhere else better suited for
    > this purpose. If there is somewhere that I could write to from policy
    > then I could store the number in their so it will always have the last
    > account number that was created and I wouldn't have to use the unique
    > name token to loop through to find the next open number.


    Try DirXML-DriverStorage instead...
Reply
  • On 9/6/2018 3:04 PM, geistc wrote:
    >
    > I have a SOAP driver that I wrote back in 2010 that I currently use for
    > account creation in eDirectory from some internal applications. One of
    > the account types it creates are service accounts and our naming
    > convention is an alpha prefix with a 5 digit number that is incremented
    > for each account created for the username. I have the below action using
    > the unique name token to iterate through the existing accounts to find
    > the first number that is not used. There definitely may be much better
    > ways to do this but I wrote this as one of my first drivers so I am sure
    > there are a lot of things in there that can be done better. :D
    >
    > The problem I have with this solution is I use a GCV to contain the
    > starting point to start incrementing from since we don't won't to reuse
    > any accounts. Since it is a GCV, that means I have to manually update
    > the value every so often and restart the driver so we don't end up
    > reusing an account that was deleted. What I am wondering is if there is
    > somewhere else I can store a counter that can be read/written to from
    > policy that will not be lost on a driver restart. I see there is a
    > DirXML-PersistentData attribute on the drivers that it appears the
    > drivers read/write to so not sure if there is a way to read/write to
    > that location in policy or if there is somewhere else better suited for
    > this purpose. If there is somewhere that I could write to from policy
    > then I could store the number in their so it will always have the last
    > account number that was created and I wouldn't have to use the unique
    > name token to loop through to find the next open number.


    Try DirXML-DriverStorage instead...
Children
  • We have many of those demands for several drivers. Therefor we use a "HelperObject" named Object of any class you like (we use inetOrgPerson). In there we use different Attributes to keep such persistent data or setup queues other drivers have to work on. We use GCV to reference that object and other GCV to reference the attributes and their meaning
  • Is there any built-in ways of managing that attribute from within policy or do you just modify it by just modifying the driver the same as you would modify other objects (i.e. set dest attribute or the like)?
  • On 9/7/2018 9:44 AM, geistc wrote:
    >
    > Is there any built-in ways of managing that attribute from within policy
    > or do you just modify it by just modifying the driver the same as you
    > would modify other objects (i.e. set dest attribute or the like)?


    Just modify the driver. You can see the Generic File Shim from Stephaan
    do it to store the last line read, so on a restart you pick up where you
    left off.


  • Sure, you can modify the object, but the functionality you are describing
    (a counter for a unique name) is what "al b" has already answered using
    the ID Provider driver; its whole purpose in life is to give out unique
    IDs in a counter-like way, and to do so in a way that guarantees no reuse,
    and even to do so via non-IDM-driver RPC-based calls if desired.

    DirXML-DriverStorage is per-replica, so if you lose your server, you lose
    your counter since it will not have replicated anywhere else; the same
    goes for GCVs stored on the driver object I believe.

    Once upon a time, before the ID Provider driver existed, I wrote a
    CoolSolution that would LUM-enable users (adding posixAccount and the
    related attributes) via IDM, and in that case I used the LUM-default "Unix
    Config" object to store the counter, since that is where it was stored
    when used outside of IDM anyway, but there was always a risk of a race
    condition where somebody could be LUM-enabling via iManager at the same
    time IDM was doing something on another object and you could end up with
    duplicate IDs. That probably exists for anything not coded explicitly to
    prevent it, like the ID Provider.

    --
    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.