AnsweredAssumed Answered

sAMAccountName generation during user auto-provisioning in AD

Question asked by Vijayabaskar Balakrishnan

on Feb 20, 2016
Latest reply on Aug 2, 2016 by Venkata Palakaveeti

Like • Show 0 Likes0
Comment • 23

For provisioning users manually in AD, it is mere email notification to AD provisioning team, they will take care of the rest by updating the activity to complete the workflow. When there is an AFX to be incorporated to do auto-provisioning into AD, as an implementation team, it is our responsibility to get the logic from customer to create the unique sAMAccountName.

In case of auto provisioning, do we have any best practise that can be used across all domains in the customer environment.

For now, we have a plan to go ahead with a java code which will be invoked by CRON job at every night. This job will not only create value for sAMAccountName and also checks for the duplication. If there is a duplication on generated value, we will be appending the value with the increment of 1.

Once the job processing is done, it generates a csv file with the relevant attributes and those values will be loaded into newly created tables in aveksa database. From there, IDC will pull the complete identities.

Is this right approach or do we have any best practise approach for generating sAMAccountName and avoiding the duplicate value?

Boris Lekumovich

Feb 21, 2016 3:24 AM

Correct Answer

As you have all the information (first names, middle names, last names, samaccountnames) collected, you can use one of the following approaches.

1. Calculate the samaccountname in the post processor phase

2. Calculate the samaccoountname in the fulfillment workflow and then use the output parameter feature (in the connector) to change the account in the change request (as you don't know the account name when the change request is starting the system will creating a pending account name with a value that is configured in the account template)

There is additional approach, calculate the value, store it in a custom table, collect the value using IDC...

Each approach has it's advantages and disadvantages

See the reply in context

No one else had this question

Outcomes

23 Replies

Boris Lekumovich Feb 21, 2016 1:35 AM
Mark Correct
Correct Answer
It seems to me that the process of calculating a samaccountname using a java code is very custom approach.
Is the calculation so complex?
what is the naming convention for new samaccountnames?

If you plan to use java code, why not incorporate it in the workflow? Add a java node that will return the value of a new samaccountname which you will be able to provision later

With regards to your question on best practices, I know that there is a work in progress to create best practices for JML processes.
Like • Show 0 Likes0
Actions
- Vijayabaskar Balakrishnan @ Boris Lekumovich on Feb 21, 2016 3:01 AM
  Mark Correct
  Correct Answer
  Absolutely Boris. We can use java node, using job variable we can use the value for sAMAccountName.
  
  Logic is like, we have to use first letter of first name, first letter of second/middle name and complete lastname.
  
  If we have any duplication, we should append it by one digit numeric value with an increment of 1.
  Like • Show 0 Likes0
  Actions
  - Boris Lekumovich @ Vijayabaskar Balakrishnan on Feb 21, 2016 3:24 AM
    Unmark Correct
    Correct Answer
    As you have all the information (first names, middle names, last names, samaccountnames) collected, you can use one of the following approaches.
    
    1. Calculate the samaccountname in the post processor phase
    2. Calculate the samaccoountname in the fulfillment workflow and then use the output parameter feature (in the connector) to change the account in the change request (as you don't know the account name when the change request is starting the system will creating a pending account name with a value that is configured in the account template)
    
    There is additional approach, calculate the value, store it in a custom table, collect the value using IDC...
    
    Each approach has it's advantages and disadvantages
    Like • Show 1 Like1
    Actions
    - Vijayabaskar Balakrishnan @ Boris Lekumovich on Feb 21, 2016 4:31 AM
      Mark Correct
      Correct Answer
      Yeah, but i'm not familiar with output parameter.
      
      Better I will use SQL Execute node and incorporate the logic with store procedure to store it in a job variable which I can use it in provisioning command node. I have exception handler mechanism to check the workflow failure also.
      
      I think this should be fine, your take on this?
      Like • Show 0 Likes0
      Actions
      - Boris Lekumovich @ Vijayabaskar Balakrishnan on Feb 21, 2016 4:54 AM
        Mark Correct
        Correct Answer
        you should take into consideration if your solution covers a scenario when you have more than 1 joiner with the exact same name.
        
        I don't have the full visibility on the solution which you are designing, but I think you will have to use the output parameter.
        
        See the AFX Guide for more information on output parameter
        Like • Show 0 Likes0
        Actions
        Mike Sims @ Boris Lekumovich on Feb 23, 2016 7:41 AM
        Mark Correct
        Correct Answer
        To Boris's point. There are two concerns if generating the sAMAccountName at request time.
        
        1.) Workflows can be concurrent.. therefore you may have several new starters with the same/simular names requesting AD accounts simultaneously. Any generation of sAMAccountName would have to take this into consideration.
        2.) If the request for a new account was requested indirectly and the pending attributes on the account template are used. The name attribute is already fixed. If you change this in a workflow, the request will not be correctly verified.
        
        Using the Post-Processor resolves both the above issues as processing is sequential, and done in advance of the request.
        Like • Show 1 Like1
        Actions
        Boris Lekumovich @ Mike Sims on Feb 23, 2016 8:13 AM
        Mark Correct
        Correct Answer
        Good points Mike
        
        To lower the risk of more than 1 joiner with the exact same name, you can write your calculated sAMAccountName into a managed attribute and during the calculations take into account these values as well.
        To lower the risk more, you can check the result of the provisioning action and if it fails on "already exists" (or any other similar message), you can take action accordingly... (requires some DB manipulation - not ideal)
        To lower the risk even more, I agree with the Post-Processor. Using the Post-Processor will require some maintenance. After every upgrade you need to reconfigure the Post-Processor.
        
        Regarding your second item, that is why I mentioned that the output parameter feature should be used. This will override the initial "fixed" value coming from the account template Name value.
        Like • Show 0 Likes0
        Actions
        Vijayabaskar Balakrishnan @ Boris Lekumovich on Feb 23, 2016 9:42 AM
        Mark Correct
        Correct Answer
        okay, I think we need to do some poc in our lab setup before taking this up in customer place.
        
        Thanks Mike and Boris for your thoughts on this.
        Like • Show 0 Likes0
        Actions
        Dushyant Singh @ Mike Sims on Mar 7, 2016 8:12 AM
        Mark Correct
        Correct Answer
        Mike , Please throw some light on how to add samaccountname generation logic in post processing ?
        Like • Show 0 Likes0
        Actions
        Mike Sims @ Dushyant Singh on Mar 7, 2016 8:38 AM
        Mark Correct
        Correct Answer
        First Extend the user schema from the Attributes section within Via L&G with a new attribute to hold sAMAccountName.
        
        To create custom post processors connect to the oracle backend database using SQLPLUS or Oracle SQL Developer.
        
        Open/Modify the package: Post_Data_Process_Handlers_Pkg
        
        Within the Post_ID_Unification_Handler procedure, enter and custom code after the /*Add Custom Code here */ line. This will run everytime collection/unification is run. You'll need to write your logic to generate the sAMAccountName then write it to the T_MASTER_ENTERPRISE_USERS table. Make sure you know the correct CUS_ATTR_USER_CAS_** attribute (the newly extended attribute) where you want to store your sAMAccountName.
        
        Once complete, compile the package. Either test by running a collection/unification or running the package directly from SQLPLUS or SQL Developer.
        
        Be very careful when writing code that modifies any tables directly however. I would consult RSA professional services directly before performing any of these actions of a non POC/LAB environment.
        Like • Show 1 Like1
        Actions
      - Vishwanath Babali @ Vijayabaskar Balakrishnan on Feb 22, 2016 9:49 PM
        Mark Correct
        Correct Answer
        I agree using Oracle/PLSQL Function or Stored procedure would be the better option.
        Like • Show 0 Likes0
        Actions
        Vijayabaskar Balakrishnan @ Vishwanath Babali on Feb 23, 2016 2:04 AM
        Mark Correct
        Correct Answer
        Yes, I will try this option before going ahead with Output Parameter as i'm more comfortable in controlling the flow in SQL code.
        Like • Show 0 Likes0
        Actions
    - Dushyant Singh @ Boris Lekumovich on Mar 3, 2016 3:21 AM
      Mark Correct
      Correct Answer
      After calculating the samaccoountname in the fulfillment workflow and then use the output parameter feature (in the connector) to change the account in the change request (as you don't know the account name when the change request is starting the system will creating a pending account name with a value that is configured in the account template).
      What should be the configuration for output parameter to collect samaccountname for created account ?
      Like • Show 0 Likes0
      Actions
      - Boris Lekumovich @ Dushyant Singh on Mar 3, 2016 3:31 AM
        Mark Correct
        Correct Answer
        That's is the exact purpose of the output parameter. To change the pending account name of the change request.
        
        Like • Show 0 Likes0
        Actions
        Daniel Cinnamon @ Boris Lekumovich on Mar 3, 2016 9:52 AM
        Mark Correct
        Correct Answer
        Have you done this before? The part that I'm not sure about would be that the request process inserts a pending account into t_av_accounts prior to workflow beginning- so if there is a duplicate account issue, there would be a unique key violation (I don't think it's technically a constraint in the DB- but the application looks to validate it) before you even get a chance to resolve it in workflow.
        Like • Show 1 Like1
        Actions
        Daniel Cinnamon @ Daniel Cinnamon on Mar 7, 2016 9:21 AM
        Mark Correct
        Correct Answer
        Okay- so FYI I just ran into this again at a customer- in this case the customer had a REST webservice to generate the samaccountname, so we used a REST node in the workflow to get the samaccountname, and we put it into an "AFXCUSTOM" variable. Then we used an output parameter to update the pending account name- works great!
        To prevent any issue with account name violations, we initially/temporarily set the pending account name as the User ID- that way there can be no duplicates, and it is updated after AFX is called successfully.
        
        So taking all this in mind, I think calculating in the workflow is *usually* the best solution. I'd say this so long as it can still be out of the box with SQL nodes or similar. If a javanode is required to do the work due to more advanced logic, then I'd honestly move more toward the post-unification handler, as there is no java build environment/compilation necessary.
        2 people found this helpful
        Like • Show 1 Like1
        Actions
        Mike Gillan @ Daniel Cinnamon on Apr 21, 2016 9:39 AM
        Mark Correct
        Correct Answer
        Hi Daniel,
        
        I've taken the same approach with my client - generating the sAMAccountName in the workflow via SQL (including a lookup against T_AV_ACCOUNTS to ensure uniqueness across all applications as per their requirement) and using an AFXCUSTOM variable to get the value to the provisioning handler. I wasn't able to get the output parameter working though, I wonder if you could share your configuration on that please?
        
        My solution involved manipulating the ADDITIONAL_DATA XML in the T_AV_CHANGE_REQUEST_DETAILS table - I would much rather use the output parameter feature as this seems to be its intended use!
        Like • Show 0 Likes0
        Actions
Tim Willemstein Feb 22, 2016 1:45 AM
Mark Correct
Correct Answer
Have you looked at the options the naming policy functionality provides?
Like • Show 0 Likes0
Actions
- Boris Lekumovich @ Tim Willemstein on Feb 22, 2016 2:03 AM
  Mark Correct
  Correct Answer
  As far as I know, you can use the naming policies only when using forms
  Like • Show 1 Like1
  Actions
  - Tim Willemstein @ Boris Lekumovich on Feb 22, 2016 2:31 AM
    Mark Correct
    Correct Answer
    Ahh yeah, you are right. It's a shame thou because it would be very powerfull to use it in so many other ways.
    Like • Show 0 Likes0
    Actions
  - Vijayabaskar Balakrishnan @ Boris Lekumovich on Feb 24, 2016 3:49 AM
    Mark Correct
    Correct Answer
    Yes I agree, Naming Policies can be used mainly to register a user as contractors/vendors from IDAM.
    Like • Show 0 Likes0
    Actions
Daniel Cinnamon Feb 26, 2016 4:48 PM
Mark Correct
Correct Answer
I am also looking to do a post-unification processor for this same functionality. I agree with all your comments and have struggled with this.
One additional benefit to the post-unification processor is in the case where you may have another system as part of birthright that also requires samaccountname be specified - like SQL server DB for example. If you don't know your samaccountname until request time- you cannot provision to those endpoints until later on.
Like • Show 1 Like1
Actions
Venkata Palakaveeti Aug 2, 2016 12:09 AM
Mark Correct
Correct Answer
I've taken the approach of generating the sAMAccountName in the workflow via SQL (with a lookup against T_AV_ACCOUNTS to ensure uniqueness) and using an AFXCUSTOM_CUSTOM_******* variable to get the value to the provisioning handler. Also, per my requirement I need to place the account in different OUs according the User Location. I can successfully do that as well using DN Sufix mappings and using AFX_OU_Picker variable.
But my problem is the output parameter is not working. I doubt the output parameter is going and checking the account in base DN, whereas my account has been created in a different OU. So I can see in AD a unique account is generated but in VIA the placeholder account is not getting replaced by the actual account. Also my CR is not closing.

Any thoughts on how to configure the output parameter to check the account in the OU that the account has been created and there by replaces the placeholder account and close the CR.
Like • Show 0 Likes0
Actions

Incoming Links

Re: AD provisioning based on User Defined name for samaccount

sAMAccountName generation during user auto-provisioning in AD

Outcomes

Related Content

Recommended Content

Incoming Links