I have a question for a unique use case using the Privilege Task Automation & Get or Search AD User. We have a requirement to occasionally look up users in a separate Active Directory domain from our primary one. We do not want to connect to this domain as a source because it has approximately half a million users in it and we only occasionally need to do a lookup on a few.
I thought PTA get / search AD user would be perfect for this. It works well except the attributes returned from the call are only basic default AD attributes. There are a couple critical custom attributes that we need returned. It seems like there should be a way in the PTA JSON to pass a schema or at least pass in “*+” like in an LDAP query but I can’t find anything documented.
PTAs are poorly documented so I would recommend using the run powershell script with the parameters you need and return the output as JSON for your processing. I have done that and it works very well!
Thanks @WhiteBat. I also thought to run powershell as the first option actually, but our security team is blocking WinRM and port 5986 and does not want to allow the security exception. We are in a highly regulated industry so getting the ports is difficult at times.
@kyle_knox YOu might have already done this but try to debug with different parameters to extend the output by adding parameters with the prefix “inputForPag_”, what I do is I duplicate the step and I add different parameter in each step and add error handling (fails or not go to the next step) and I try to read from the VA logs. If that’s hard, the best way is to invest in your Ask-An-Architect sessions if you have any left!
Use Active Directory action - search_users command in PTA. Search by attributes such as sAMAccountName, userPrincipalName, email, any supported AD attribute to retrieve the user details.
Not what my issue is. I know I how to use the search action. The issue is in the attributes that are returned. Even search only returns a few OOTB attributes.
@kyle_knox I think the PTA itself has issues, Becuase i tried for Delete and it did not work earlier for me.
I won’t goto PTA that much but thinking outside right now. If you need the attributes can you use something like (modify the search filter on AD) using ISC API’s and get the information use it and then on the next run again you do the same.
Now this is not an ideal solution but that just came to top of my head.
Alternatively, maybe u can use the create account API (to create an account on the Active Directory connector - a new one you setup for this specific case). Provide the account name and account id attributes. and create an account and then perform a single account aggregation from the workflow.
I have tried the second approach myself and it works, but the first one is just as an suggestion if PTA still does not work…
@neeraj99 we didn’t got with your solution in the end. I really like it but the one issue is that it really works only for the first aggregation. If we need to have subsequent aggregations to update status’s for example, we would need either a really complicated search filter or a workflow that performed a single account aggregation on each one of those with a loop. Since we have about 800 of those accounts I didn’t think that would be the best way.
I am not very happy with the solution we landed on because it is a bit disjointed. But we settled on using the PTA to get the users into ISC via automated workflow. Then on our IQService server we have a powershell script that runs every hour. It will use ISC serach API to get a list of sAMAccountNames of all of these borrowed users and then make a powershell call to AD to fetch all of their attributes. The powershell script builds a delim file that we then aggregate back to pull the attributes into ISC.
The whole powershell route could be avoided if the PTA action offered a schema you could pass in as an argument.